102 lines
3.2 KiB

Game setup involves a collection of Cards selected to be included in the game
and Players playing the game. Each Player connects to the game via a
web browser and choses a name.
Each Card included in the Game is randomly assigned to Player or "buried".
The buried Card is omitted from the game; some Cards have rules which
forbid them to be buried.
Each Card has a Color, Allegiance (differs from Color for e.g. spies),
RoleName, human-readable Description, and collection of Powers and
Conditions it gives to the Player that gets it at the start of the game.
Code-wise: In the database, Cards, Powers, and Conditions are all
represented in the database by strings identifying them that correspond
to the names of Python classes which implement callbacks for every way
they could impact gameplay.
To support private table-talk (for the online version), have a concept
of chat messages being "whispers" (to a sub-room with additional
commands for inviting people to a sub-room or disbanding it (or
kicking?)) or "yells" (to entire room, even those in whisper groups).
# Database Tables
## Game
## Round
# Rounds are created at the start of the game, so round number and length
# can be set. Must be numbered consecutively 1 through max_round.
game_id INT FOREIGN KEY (Game),
round_num INT, # 1-5
round_length INT, # round length in sections
## Event - master table for all events
game_id INT FOREIGN KEY (Game),
timestamp DATETIME,
actor FOREIGN KEY (Player),
target_player FOREIGN KEY (Player) NULL,
### Event kinds
* round_start / round_end ?
* color_share_offer / color_share / color_share_reject:
(card_share_offer / card_share / card_share_reject)
* Accepting causes an immediate color share, so there's no
color_share_accept event.
* color_share_offer may not be rescinded (by game rules)...
* ... but is automatically considered rejected at the end of a round.
* color_private_reveal / color_public_reveal / color_permanent_reveal
(card_private_reveal / card_public_reveal / card_permanent_reveal)
* Unilateral actions, so no offer/accept.
* private_reveal has a player target; public_reveal is to entire room.
* Permanent reveals may be caused by powers.
* claim_leader
* no target, requires no current leader
* usurp
* initiate a vote, requires not being current leader
* should votes be tracked by a separate table?
* vote
* Must have an active usurp
* ... a votes table would make this easier to track.
* Targets a player.
* change_leader
* Targets a player, announcing they are now leader
(due to claim_leader or vote event)
* select_hostage / deselect_hostage
* Only leader can take this action.
* Hostages should probably be tracked by a separate table or
flag in the Players table?
* use_power? Or maybe mark events caused by a power to track usages?
## Player
player_id INT PRIMARY KEY,
name CHAR(20),
## PlayerCondition
player FOREIGN KEY (Player),
condition CHAR,
relatedPlayer FOREIGN KEY (Player) NULL, # e.g. for the "in love" condition
gained DATETIME,