Tournament & TO Flow

High-level TO flow

Create / edit tournament
  → add entrants
  → link or import entrant armies
  → run tournament games by round
  → calculate standings

TO UI hierarchy

Events
 └── Event Edit
 └── Event Entrants
      └── Entrant Armies

The TO area is designed around operational workflow rather than around player-facing gameplay.

Core tournament tables

• tournaments
• tournament_entrants
• tournament_entrant_armies
• tournament_scoring_systems
• tournament_scoring_system_bands

Entrant models

Tournament entrants are intentionally flexible. The system supports:

• registered entrants linked directly to a user account
• guest entrants not yet linked to a user
• guest entrants later claimed by a registered user

This makes TO operations practical even when not every player is already in the system.

Army linking model

Each entrant is linked to armies through tournament_entrant_armies. In practice the TO workflows assume a single primary army per entrant.

Armies may come from:

• an existing registered user army
• a new imported army created during the TO workflow
• a manually created army for a guest entrant

Import interaction

The TO entrant-army flow is one of the most cross-cutting areas of the system because it combines:

• TO operational UI
• shared army creation logic
• import parsing/commit logic
• reference data matching (race/faction/canonical units)

Games inside tournaments

Tournament games are still ordinary games. They become tournament games by carrying:

• tournament_id
• tournament_round
• optional entrant A/B references

This is important: tournaments are an overlay on top of the core gameplay model, not a separate game engine.

Standings model

Standings are derived from:

• game results
• tournament round context
• entrant mapping
• tournament scoring-system bands

The TO area and the user-facing tournament view are therefore both dependent on consistent tournament configuration and finalised game data.

Why the TO design is strong

• It reuses the main game model instead of duplicating it
• It supports real-world guest/claim workflows
• It allows TO operations to happen before all player accounts are fully aligned
• It keeps TO complexity outside the normal player-facing app

Main TO / tournament risks

• Changing scoring systems or bands after games exist can alter standings interpretation
• Entrant and army linkage depends on careful lifecycle handling
• Guest-to-user claim transitions introduce identity complexity
• Round uniqueness/finalisation rules are important and easy to break if bypassed