-
Notifications
You must be signed in to change notification settings - Fork 3
/
JIRA.txt
169 lines (135 loc) · 6.81 KB
/
JIRA.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
## Cleanup Work
[ ] Get rid of front-end module, make it a single module project
[ ] Remove the idea of an "opponent", games can have anywhere from 1-6 players
[ ] (think) get rid of CardId?
[ ] Separate the Application layer from the Domain
[ ] Move PORT to application
[ ] Split out card shuffle (RandomCardShuffler) into PORT and ADAPTER
[ ] Pull in ArchUnit
## Game Layout
Per Game:
* TILEs
* ACTION CARD DECK
* ACTION CARD DISCARD PILE
* TEST RESULTS DECK
* TEST RESULTS DISCARD PILE
* 6-SIDED DIE
Per Player:
* PAWN (indicates which TILE they're on)
* HAND
* PLAY AREA
* TECH NEGLECT AREA
* COMMIT TRACKER
* RISK TRACKER
Player's "State Machine":
Player's "TURN" is complete when either: play/discard 3 cards OR explicitly END TURN
## Need
[ ] Structure for the BOARD as 9 separate TILEs,
[ ] PLAYER is ON a TILE (has a game state machine)
[ ] player's COMMAND causes change, potentially transition to new TILE
[ ] MOVE PAWN - moves the player to a new tile
[ ] DRAW CARD (and DRAW FULL)
[ ] DISCARD CARD (often causes a transition)
[ ] PLAY CARD
[ ] END TURN
## Ubiquitous Language
* Game (deck, card, tile, etc.)
* Competitive: every member for themselves (1:1 player:pawn)
* Co-op (mob programming): working together to move pawn forward (N:1 player:pawn)
* Player - ties an Account/Member to a specific game ("player in game")
* Host - part of a Team, they created an instance of a game
* Team - which is an "account-based" thing: who can "see" each other's games and join
* Group - set of players currently playing a specific game (they have all JOINed a specific GAME or are members of the game)
* one/many PAWN <-> one/many PLAYER (premature)
* Support variation where GROUP controls single PAWN
* Coach - can observe the game without playing, can control/manipulate game elements
* "Attached" to one or more TEAMs
* Win Condition (when is the game over)
* First to 5 commits (or 3 commits, whatever)
* Timeboxed: most commits within a period of time (duration)
* Game Master view: can see state of game(s) that have been created/in-progress
* Admin version of this allows manipulation of elements for any reason (not sure if this is different from coach role)
* Admin can see any game any time
* Coach can only see games for the TEAMs to which they're attached
## Behavior
1. Host Creates Game (defines competitive or co-op)
2. Player Joins (existing) Game
* Invited by host, or
* Chooses available game from team/group
* If Host wants to play, they have to join too
3. Start Game
* Decks are shuffled
* Cards are dealt: 5 to each Player
* Pawns placed at first TILE
* Commit tracker set to 0
* Risk tracker set to 0/0
* Starting player chosen (proceeds clockwise)
4. Player 1 plays...
## Interaction
[X] 1. Ask for name for new game (start with competitive)
[X] 2. Create game -> provide identifier/link (handle)
[X] 3. Member joins game with human-readable "Handle" (via typing it in, not link)
[X] Member becomes Player when joined the game
[X] Multiple different Members can join the same game
[X] Constraint: A Member can not join the same game twice, i.e., can't represent TWO Players
* If a Member joins a game where they are already a player, that is "rejoining" (reconnecting)
[X] Constraint: 4 players maximum per game (rejoins don't count, of course)
[ ] 4. Waiting for game to start (once at least 1 member has joined the game)
[X] Receive notification when additional players are added
[ ] Can only start game at this point by calling .start()
[ ] 5. "start game" is Triggered
[ ] Action Card deck shuffled, 5 cards dealt to each Player, etc.
[X] Create ActionCard, Deck container, able to draw and replenish from discard
[X] Nullable-ize the Deck with Embedded Stub for configuring response to "give me shuffled deck"
==> WE ARE HERE:
[ ] Player draws to full hand from Action Card deck
[ ] Player discards card, which adds to Discard Pile
[ ] Represented in UI by checkboxes?
[ ] Player has "Hand" and "Tech Neglect" area
[ ] Player has "In-Play" area (for WRITE CODE, LESS CODE, PREDICT)
==> switch to working on UI display of Player hands, in-play areas, etc.
[ ] (Temporary) Constraint: players can't join once game is started
[ ] Inbound HTTP Adapter
[X] Host create game: numeric-only textbox and "Create Game" button does POST
[X] MVC part
[X] Test to make sure hostNewGame has Game created and stored
[X] Lobby shows games available with handles for each
[X] Person join game: textbox (for handle) and "Join Game" button does POST
[X] MVC test for /join endpoint
[X] PostMapping that does:
[X] Creates Player in the Game for the Person
[X] Redirects to page that shows the game page
[ ] Game-in-progress page: show "modal"
[X] Show other players as they join -- via WebSockets (htmx)
[X] Associate logged-in user (username?) with a MemberId for joining, by looking up that username in MemberStore
[X] Get first name from the Player (their in-game name)
[ ] Show "Start Game" button (might have constraints on when this button shows up later)
[ ] Start Game starts the game and the modal goes away
[ ] Outbound (Notifier) WebSocket Adapter
[ ] Display name of game, all players, decks, pawns, etc.
## Event-Sourcing Game Persistence
>>> Commands -> Events -> State
[X] EventSourcedAggregate<GameEvent>
[X] Static method for creating initial game
[X] GameEvent interface, with subclasses for each event type
[X] Fix the Game.join() method to not return the Player, but instead provide method to obtain the Player based on the PersonId
Using in-memory persistence for Game
[X] Use case to use load (from Repository), modify, save (to Repository) pattern
[X] GameStore in-memory implementation
[X] Make it use the event-source storage model (so freshEvents is clear upon reconstitution, i.e., when findBy happens)
[ ] GameViewLoader implementation using the GameRepository
Real Database
[ ] Repository Adapter for JDBC
[ ] JDBC concrete implementation
## Tooling
[ ] Add HexArchTest
[ ] Add rule that Production code must not call nullable methods (createNull) and only call constructors
## Naming
[X] Come up with a name other than Person(Id) that's easier to differentiate from Player(Id), hopefully something other than "Account" or "User"
Perhaps "Member"?
## Future Features
[ ] Person's own page showing their profile, active games they're in, past games they've played, etc.
## Open Questions
[ ] Do we allow non-Players to see the Game page?
[ ] If so, who is allowed to observe?
[ ] If they can, they must not be able to click on any buttons, etc.