Skip to content

Generalize the analysis stack to other games and external conversation corpora #3

Description

@jeremymanning

Deferred from the initial scoping of #1, which is D12-only. Filing so we don't lose it.

Idea

Nothing in the analysis stack is actually specific to Dominating 12. A game reduces to: a map with
a territory adjacency graph, a sequence of board states, a set of players, and timestamped
conversation turns. Any territorial negotiation game fits that shape. If the loaders are written
against that interface rather than against D12's HTML, the same metrics and models run on other
sources for free.

Why it's worth doing

  • Generalization is the scientific claim. "Conversations follow stereotyped trajectories as a
    function of position strength" is much stronger if it holds in two unrelated games than in one.
    A single-site result is always vulnerable to "that's a quirk of D12's player base."
  • Insurance. If D12 data access is limited in scope or volume, an external corpus keeps the
    conversation analysis alive.
  • More board context per message. Some corpora ship annotations (e.g. intent, deception) that
    D12 chat won't have, which lets us validate our unsupervised trajectory findings against labels.

Candidate sources

  • Diplomacy deception dataset (Peskov et al., ACL 2020) — real human negotiation in a
    territorial conquest game, ~17k messages with board context and per-message truthfulness labels.
    Closest available analogue to the D12 setting. Needs a licensing/availability check.
  • WebDiplomacy / Diplomacy engine logs more broadly
  • Other online Risk implementations with public game archives and permissive terms
  • Settlers-style trading games, if we want negotiation without territorial conquest as a contrast

Scope sketch

  • Formalize the loader interface implied by basic approach #1 (map -> graph, log -> board state sequence,
    chat -> turn sequence aligned to board states) as the package's public boundary
  • Write a second loader for one external corpus
  • Re-run the basic approach #1 analyses on it and report where results replicate and where they don't

Depends on

#1 — the interface has to exist before there's anything to generalize. Ideally #1 is written with
this in mind so the loader boundary is already clean and this issue is mostly additive.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions