102 lines
3.2 KiB
Plaintext
102 lines
3.2 KiB
Plaintext
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
|
|
|
|
game_id INT PRIMARY KEY,
|
|
|
|
|
|
## 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.
|
|
|
|
round_id INT PRIMARY KEY,
|
|
game_id INT FOREIGN KEY (Game),
|
|
round_num INT, # 1-5
|
|
round_length INT, # round length in sections
|
|
|
|
|
|
## Event - master table for all events
|
|
|
|
event_id INT PRIMARY KEY,
|
|
game_id INT FOREIGN KEY (Game),
|
|
timestamp DATETIME,
|
|
round,
|
|
room,
|
|
event_kind,
|
|
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,
|
|
lost DATETIME NULL,
|
|
|
|
|