game_sides

Per-game side records linking players/labels to armies

SQL Gameplay Runtime Structure

game_sides

Purpose

Stores the side-level records for a game. In practice this table holds the two sides, typically A and B, and links each side to an army list and optional player label.

Role in the system

games
 └── game_sides
      └── game_units

Columns

Column	Type	Null	Notes
`id`	bigint unsigned	No	Primary key
`game_id`	bigint unsigned	No	Parent game
`side_code`	char(1)	No	Typically A or B
`player_name`	varchar(120)	Yes	Display name for the side/player
`army_list_id`	bigint unsigned	Yes	Selected army list
`created_at`	datetime(3)	No	Creation timestamp
`updated_at`	datetime(3)	No	Last update timestamp

Keys and indexes

PRIMARY KEY (id)
UNIQUE KEY uq_game_side (game_id, side_code)
KEY ix_game_sides_game (game_id)
KEY ix_game_sides_army (army_list_id)

Foreign keys

fk_game_sides_game: game_sides.game_id → games.id ON DELETE CASCADE
fk_game_sides_army: game_sides.army_list_id → army_lists.id ON DELETE SET NULL

Relationships

Relationship	Type	Notes
`game_sides.game_id → games.id`	Many-to-one	Each side belongs to one game
`game_sides.army_list_id → army_lists.id`	Optional many-to-one	Selected army for the side
`game_units.game_side_id → game_sides.id`	One-to-many	Instantiated units belong to a side

Used by

Game setup and side assignment flows
Game start logic when units are instantiated
Play-state views and score breakdowns

Design notes

The unique constraint ensures only one row per side code per game
army_list_id is nullable so incomplete setup states are supported
This is a lightweight structural table; most gameplay state lives deeper in game_units and game_events

Risks

Side code semantics are application-controlled rather than enum-constrained
Null army assignments must be handled cleanly by setup/play logic

Recommended future improvements

Document allowed side codes explicitly
Consider a DB check constraint if side values should remain fixed