Write the document that the next build needs
A game design document should explain what to build, what to leave out, and how to tell whether the prototype works. For AI-assisted development, its most useful sections are concrete rules, controls, scope boundaries, and acceptance checks. A long story outline cannot resolve whether a pickup can be counted twice or what Restart must reset.
This guide uses one teaching example throughout: Rain Route, a tiny robot delivery game. Its GDD, prompts, revision, and tests all refer to the same proposed game. It is not an actual generated project or a reported user experience. The workflow shows how to connect decisions to implementation without claiming the proposed build already exists.
Copy this filled mini-GDD
Rain Route, design version 0.1.
Pitch: A top-down robot carries memory parcels across one rainy city block.
Player and platform: A solo player on a desktop browser using a keyboard. Target a roughly five-minute first session as a design goal, not a measured result.
Promise and pillars: Calm navigation, readable destinations, and small route choices. Prefer clear feedback over additional systems.
Core loop: Pick up one parcel at the depot, walk to the matching numbered doorstep, deliver it, return for the next parcel. Complete three deliveries to win.
Controls and camera: Fixed top-down camera. WASD or arrows move. E picks up or delivers when inside the marked interaction area. R restarts after a win. Show instructions on screen.
Rules: Only one parcel can be carried. Deliveries occur in order: doors 1, 2, then 3. E at the wrong door shows a message but does not remove the parcel. Each correct delivery increments the counter once. Repeated E cannot count an already completed delivery.
Map and challenge: One block, one depot, three doors, a puddle crossing, and a dry detour. Inside the puddle, movement speed is half normal. No health loss, enemies, or timer failure.
Feedback: Show current destination, carried parcel, and deliveries completed. Use distinct door numbers and a visible delivery confirmation. Rain ambience should remain quiet; provide mute.
Technical scope: One browser prototype, no accounts, cloud saves, networking, purchases, extra maps, or unlock system. Reload begins a new run. Use simple original shapes until the loop passes.
Win and reset: After delivery three, show a win panel. R resets the robot, parcel, destination, delivery counter, and win panel to the initial state.
Review question: Can a new player complete the first delivery using only the visible instructions?
Step 1: Translate the GDD into one build request
Use the document as input, not as proof of implementation. Before submitting it, check for contradictions between scope, controls, and the win condition. “Reload begins a new run” rules out promising persistent deliveries; “one parcel” rules out a hidden inventory queue. Resolve these decisions in the GDD instead of leaving the implementation to guess. A suitable first prompt is:
Build Rain Route from design version 0.1. First implement the map, movement, depot pickup, and door 1 delivery only. Keep later doors visible but inactive. Show the current destination and carried state. Use simple original shapes. Do not add weather effects, unlocks, failure timers, or extra mechanics. Explain the components changed and how to test pickup, wrong-door interaction, correct delivery, and repeated E.
Keep this first request limited to the delivery slice. Its output should let you inspect one complete interaction before multiplying the number of destinations. If the route cannot be completed with the documented controls, correct the slice rather than expanding the map.
Step 2: Trace requirements to tests in the same game
Give important rules short identifiers and retain them across the prompt, notes, and test record:
| Requirement | Action in Rain Route | Expected outcome |
|---|---|---|
| R1: One parcel maximum | Press E at the depot twice | Still carry one parcel |
| R2: Correct destination only | Visit door 2 with parcel 1 | Message appears; parcel remains |
| R3: Delivery counted once | Deliver at door 1, then press E repeatedly | Counter stays at one |
| R4: Ordered progression | Complete all three deliveries | Destination advances 1 → 2 → 3; win appears once |
| R5: Puddle slowdown | Time the same marked route inside and outside water | Puddle speed matches the specified half rate |
| R6: Full reset | Press R after winning | Initial position, empty hands, zero deliveries, no win panel |
Record actual observations in a separate run log with the build version and environment. Add a status such as pass, fail, or blocked only after performing the action. If the first slice fails R2, fix that interaction before requesting three deliveries. Keep the input sequence precise enough that another person can reproduce the failure.
Step 3: Extend the loop, then add atmosphere
After the first delivery passes, request doors 2 and 3 plus the win and reset states. Run R1 through R4 and R6 again. Then request the puddle slowdown and check R5 without changing pickup logic.
Only after those rules pass should you add rain visuals and quiet ambience. Verify that rain does not obscure numbers or interaction markers, and that mute works. If the weather effect makes the map unreadable, reduce it rather than accepting atmosphere at the expense of the documented player promise.
Step 4: Update the GDD when evidence changes a decision
Suppose a future playtest shows that players miss the current destination. That is a hypothetical observation here, not a result. A focused revision would ask for a more prominent destination label while preserving door order and delivery rules. Retest the same first-delivery question with a new player.
Record the decision as version 0.2, state why it changed, and link it to the affected requirement and build. Keep earlier decisions available so an old test result is not mistaken for evidence about a new rule. A revised requirement should identify which earlier checks need to run again.
When a generated change breaks an earlier requirement, revert or isolate it. Report the failing requirement, exact input, expected result, and actual result. “R3 counts twice after repeated E” is more actionable than “the prototype feels buggy.”
Use SEELE between the specification and the test log
SEELE supports natural-language game creation and iterative changes involving gameplay, scenes, and assets. Supply the mini-GDD as the design input, then request one bounded implementation slice. The useful output is a candidate build that can be compared with the same document, not a replacement for design judgment or a completed test record.
For each follow-up, name the requirement that changed and the requirements that must remain stable. Requesting a clearer destination label should not silently introduce a timer or reorder the doors. Keep the document, prompt, and observed result linked by version so a polished description never stands in for actual behavior.
Use the GDD to start, not postpone, the build
A useful GDD shortens the distance between a decision and a check. Rain Route needs a clear pickup rule, destination order, and reset definition before it needs a longer story outline. Keep the document small, but make the rules precise enough that a different person can judge the same build.
Copy the specification into SEELE and request the first delivery slice. Keep the document, working build, and test log aligned by version. Expand scope only when the same game’s existing rules survive implementation and revision, and update the GDD when evidence changes a decision.
Trace the design to a playable check
This matrix organizes the article’s proposed checks. It is not a report of a completed test.
| GDD element | Question it answers | Example acceptance check |
|---|---|---|
| Player and input | Who plays and how do they act? | A desktop player can move the robot with the specified keyboard controls. |
| Objective and scope | What must happen in this version? | The player can deliver the specified parcel in the defined scene. |
| Rules and boundaries | What happens when a rule is triggered? | A delivery or pickup is counted only as the design specifies. |
| Failure and recovery | What happens when the player cannot complete the task? | The stated failure or restart behavior returns the game to its documented state. |
| Revision log | Which decision changed and why? | Record the observation, changed rule, and result of rerunning the check. |
FAQ
How long should a prototype GDD be?
As short as possible while resolving the next implementation decisions. The filled example specifies scope, controls, rules, and tests without a production bible. Add sections when they change what someone builds or checks. A missing interaction rule is more costly than a missing page of background lore.
Can AI write the document for me?
AI can draft sections and expose ambiguities, but you must decide the rules and verify feasibility. Ask it to identify conflicting requirements and missing acceptance criteria. Do not treat a polished document as validation of fun, implementation quality, asset rights, or product capabilities that have not been checked.
What is the difference between the GDD and the test log?
The GDD states intended behavior and decisions. The test log records what happened in a specific build and environment. Keep them connected but separate: a passing expectation is not a passing test. When observations justify changing a rule, update the design explicitly and rerun affected checks.
A chapter checklist for a larger GDD
Add sections only when they guide a decision for the next build. Start with the audience, platform, and one-sentence pitch. Follow with the core loop, controls, progression, world or narrative, art and sound constraints, and technical requirements. For each feature in scope, state its owner, the smallest playable proof, and a test the team can rerun. Move optional ideas to a separate backlog.
