Learning AI-DLC building a game, part 8: inception
This is part 8 of a series on learning AI-DLC by building a game, World Rift Conflict, in Godot with an AWS backend. Part 7 turned a one-page idea into an approved scope. This post covers Inception: nine stages that turn that scope into something a builder can start on.
Parts so far:
- Part 1: setup
- Part 2: a proof of concept
- Part 3: automated E2E tests
- Part 4: what the reviews caught
- Part 5: inside a stage
- Part 6: a bugfix intent
- Part 7: ideation
- Part 8: inception (this post)
TL;DR
- Nine stages: Reverse Engineering, Practices Discovery, Requirements Analysis, User Stories, Refined Mockups, Domain Design, Units Generation, Contract Design and Delivery Planning.
- The result: 50 functional and 10 non-functional requirements, 31 stories, 10 screens, 13 components, 7 units of work, 10 contracts and a plan of 6 Bolts, with the walking skeleton first.
- Six reviews raised 50 findings. I approved every stage with its findings open, and the same gaps kept coming back.
- A script caught a miscount I had already reported: 31 stories, not 29.
- The final check passed: every requirement traces to a story, a component and a unit.
Scanning the code again
Reverse Engineering rescanned the whole project, because the old code knowledge base was out of date. It came back with 44 components and seven gaps between today's code and the game. The only screen is sign-in. The backend does sign-in and nothing else. The Amplify Godot plugin sends its live updates as ordinary web requests, so it cannot carry live matches.
That last fact matters later. It is the first hard technical constraint on the design.
Practices for a real game
Practices Discovery had run before, for the test work. This time it re-ran with the affirmed practices as the baseline and asked only what the game changes. Twelve questions settled it.
- The walking skeleton, a thin slice that runs the whole way through, built first to prove the pieces connect, is a match against computer-run countries in the web build, plus the player's result saved to the backend.
- End-to-end tests will run several players in one match.
- Web and Linux pass every requirement. Windows and macOS get a smoke check.
- Six product rules from Ideation became standing project rules, such as no pay-to-win and never storing card numbers.
From requirements to 31 stories
Requirements Analysis asked ten questions. One answer changed the approved scope: 15 rounds of 60 seconds make a match of about 15 to 20 minutes, not 20 to 30. AI-DLC wrote it as replacing the scope and left the approved document alone.
The review called the requirements not ready. Treaties, trade and conflicts had no rules, matchmaking was undefined, and the balance check was too small to detect anything. I approved anyway. User Stories then offered to settle the major gaps, and five short questions closed them.
- A proposal is answered within the round, and no answer counts as a refusal.
- Balance is checked over 200 simulated matches.
- Matchmaking waits 30 seconds, then fills the match with computer-run countries.
- If no economic data source qualifies, disaster or weather data is used instead.
- Display names are 3 to 16 characters, and the email is never shown.
Design in four steps
- Refined Mockups: ten screens, a dark scheme where every country color comes with a symbol and a name, a minimum window of 1024 x 600, and a new answer: English and Spanish.
- Domain Design: 13 components around one pure rules core, shared by the skeleton and live play. One authoritative match host owns each live match, which the Godot multiplayer guidance recommends.
- Units Generation: seven units of work, cut as feature slices, with the skeleton as the only starting point.
- Contract Design: ten contracts written as operations and messages, because I deferred the transports to later stages.
Six Bolts
A Bolt is one build pass over a piece of the work that ends in something that runs. The order puts content and balance right after the skeleton, because my biggest worry is whether random countries make a fair game. Owner tools come before live play, because live play is the largest cost.
| Bolt | Units | Proves |
|---|---|---|
| B1 | skeleton match | the rules core runs a full match and a result reaches the backend |
| B2 | content and balance | random countries can make a fair match |
| B3 | accounts and profile | real players can join and leave within the data rules |
| B4 | owner tools | the owner can steer cost and see if players return |
| B5 | live play and data feed | live play works in the browser and on desktop within $50 |
| B6 | desktop builds | the same game runs as a download |
What the reviews found
Six advisory reviews raised 50 findings. Advisory means the review informs my decision but cannot block it. I approved every stage with its findings open. That was a choice to keep moving, and it had a cost: the same gaps came back stage after stage.
- The skeleton: the stories review found its set did not hold together. The domain review then found nothing in the design saved a local match's result.
- Live play: the units and contracts reviews both found its missing links to the data feed and owner tools.
- Identity: no component checked who joins a live match, until a join token appeared in the contracts.
Some findings were closed by later stages, as a project rule now asks. Others are still open going into the build.
Small things that went wrong
- I reported 29 stories and 80 criteria at a gate. When I built the component catalogue from a script, the count came out as 31 and 78. Counts are now produced by a script, never by hand.
- I copied one artifact into the record with
cp. The review then refused to start, because the file had "no recorded write". Saving it again with the file tool fixed it. - A sub-agent stopped on the account's monthly spend limit. After I said "continue", the same agent was resumed and finished its saved work.
What is next
Construction: Functional Design for the walking skeleton, then the first code.