What's in this transcript? The Game Design Doc authorship session for Chess Arena. Aviv rewrites the GDD in real time: pivots the game model from "12 curated battles" to a level-based wave-defense system, locks movement/capture rules, designs the tutorial-as-real-match, and directs a subagent GDD review whose 6-axis scorecard he answers point-by-point — daily quests, chests, timer-based matches, ability unlocks on XP, asset manifests.
Play the live game: chess-arena-tt.vercel.app ↗
Stage 1 — Pivot the game model and lock open questions
[Stage 1 — GDD rewrite directive · ChessArenaTT_Phaser.json msg 0 · 2026-03-21]
Aviv: ## Issues
1. Spawn bar - it should be a configurable. Start at 6 seconds per spawn.
3. Let's actually switch the main mode to be level (levels vs the enemy).
Enemy pieces spawn/appear from the top. Every level has a different
configuration (should be config driven), where there are different
starting pieces and spawning pieces. this will allow us to control
difficulty, i.e. through "waves", etc. the enemy king may not even
be visible initially.
4. board layouts should also be config-driven and there should be room
to add new layout elements in the future (in addition to rocks,
bushes, etc.). for now we can use procedural generation, i.e. levels
will be generated with random placement of rocks and bushes, with a
limit of 3 rocks and 3 bushes per level (but the number is randomized)
9. campaign progress only when winning, otherwise stuck at that level.
10. Localstorage for now
31. See procedural generation of levels. we should continue to generate
harder and harder levels and enemy configurations - more waves, more
difficulty pieces, etc. As the enemy becomes really hard (bigger
waves, more challenging pieces), the player will start to get
abilities (bombs, freezes, piece rerolls, etc.)
Clarifications
5. Yes, AI gets reinforcements but not the same as the player. i.e. this
is configurable and we will use it to escalate difficulty over the
course of the campaign (faster reinforcements, more reinforcements, etc.)
15. pieces move to where the player dragged them, i.e. they stop when
they get there. BTW pawns can move horizontally as well (but only
capture diagonally)
16. any piece can have a queued premove.
22. no lives during onboarding. it starts once player starts the campaign.
by the way, we should also add on-rails tutorial step in the main
menu after the onboarding is done, to instruct the player to start
the first level in the campaign.
36. pawns can move back
42. AI should still try to move in bushes but it only remembers the
player's last position, so it will try to target that.
Nice to specify
17. The last tutorial step is a "real" match with the AI (but AI always
loses). before that, the enemy pieces are frozen.
26. When king is captured - show checkmate animation and then go to
match summary. @References/BattleScreen/MatchResults.webp
28. We should be relatively lenient with the drag. We need to "preview"
the move (player sees where it will go with a ghost piece) and
then when they drop it moves there. When the player "picks up" the
piece, they see a little green dot on viable squares for movement.
38. Premove gets cancelled if the piece can't move there anymore.
Claude: [shifts game model from "12 curated battles" to level-based
wave defense with procedural generation; rewrites spawn, terrain, AI,
tutorial, onboarding sections of GameDesignDoc.md]
Aviv: RE: matchmaking - remember we pivoted to a level system. in this
system there is no matchmaking at all. However, we WILL add matchmaking
as a feature (PvP) at a certain point (e.g. unlocked at level 10). At
that point, we'll use the matchmaking screen and logic. We'll get to
that later.
RE: match victory, let's use this reference: @References/RoyalMatch_Victory.jpg
Stage 2 — Commission a subagent GDD review, then make the calls
[Stage 2 — Review + decisions · ChessArenaTT_Phaser.json msgs 112, 116, 117]
Aviv: Okay, spin up another subagent to review the plan for anything
confusing and not clear. The agent should examine:
- Is game design clear?
- Are configurations clear for everything? are they separated from code
such that we can change configs without playing around with code?
I.e. the tutorial system should also be config-driven
- Is the tutorial clear in teaching how to play the game? Does it
adhere to mobile best practices?
- Are we missing any critical features to engage players in the first
day and get D1 retention metrics? Compare to the top mobile games
like royal match, clash royale, tennis clash. we are also taking
inspiration from words with friends, yahtzee with buddies, match masters.
- Is the UI and interface clear? Will it be usable and delightful?
- Are we clear on art style and how art will be used across the project?
Claude (review subagent output, verbatim):
GDD Review Results — 6-Axis Scorecard
1. Game Design Clarity 3.5/5 — movement speed, sliding capture rules,
lose condition missing
2. Config-Driven Architecture 4/5 — tutorial and AI aren't config-driven,
schemas undocumented
3. Tutorial & Onboarding 3/5 — only teaches basics; premove, bushes,
sliding need interactive steps
4. D1 Retention 2/5 — BIGGEST GAP. No daily rewards, chests,
tasks; coins have no purpose
5. UI & UX Clarity 3.5/5 — needs wireframes, screen-fit math
6. Art Style & Assets 3.5/5 — no asset manifest, placeholder strategy,
or terrain art spec
Top 5 priorities:
1. Add Daily Rewards + Victory Chests (D1 retention — critical)
2. Specify Movement Speed + Sliding Capture + Lose Condition (blocking)
3. Expand Tutorial Across 3 Levels + Interactive Steps
4. Make Tutorial Config-Driven + Document Config Schemas
5. XP Levels Should Unlock Things (premove at L2, reroll at L3, cosmetic
at L5, instant-spawn at L8)
Notable gaps: No timeout/stalemate/draw condition. Knight L-shape on
4-wide board is severely constrained. Pawn-diagonal-capture + bush
stealth interaction undefined. 6 ability slots won't fit small phones.
v1 gameplay placeholder strategy not defined.
Which of these do you want me to address in the doc now?
Aviv: 1. Okay, let's add daily tasks and victory chests with a timer.
Spin up subagents to research and design the features specs.
2. We should make solid assumptions initially and make it configurable.
3. You're right. The tutorial should make sure you interact with each
of those things. Also, we should require specific interaction during
the tutorial. I.e. the element the user needs to interact with is
highlighted, and we show them the action we want them to take. When
showing bushes, we can spawn the player inside a bush and tell them to
"wait". The enemy king will pass and when they do, the match stops,
and we say "they fell for it!". then the player is instructed (via
the highlight, game still paused) to capture the enemy king. Also,
there needs to be a hidden "state" in the bushes, i.e. the piece is
slightly transparent.
Last level of the tutorial is a real "match" against the computer.
computer can speak some banter too.
if we add new systems (daily quests, chests) those should be shown in
the on-rails onboarding too. I.e. when the player wins their first
match, we instruct them to collect a chest, etc. (we give them one, too)
4. Okay, add it.
5. Premove should be unlocked by default. As for the other stuff, agreed,
let's unlock them. but don't design new systems just for the rewards,
we should only use systems we already have and unlock those (i.e. daily
quests, chest, etc.)
Other findings
- yes, you can capture a hidden piece but pawns can't move diagonally
into a bush so they can't
- good point, let's add a timer to matches. start at 30 seconds. player
loses unless they checkmates the enemy king. this way player needs
to be on the offensive and AI can play defensive in some levels
- don't worry about knight movement and auto placement randomness
- create wireframe for battle hud using the reference I provided (clash royale)
- we don't need 6 ability slots. use clash royale reference.
- lock to portrait orientation
- agree on result popup
- add an asset manifest
- add terrain sprite manifest (we'll probably use SVG for all of these
atm. we should still maintain a manifest so we can replace later
with sprites if we want)
- for placeholder strategy - we should have a loading screen before
the match to avoid this.
