Iteration Cycles and Versioning
Flashcards on running disciplined one-variable iteration cycles and keeping recoverable versions of your game.
Keyboard Shortcuts
💡 Pro tip: Use keyboard shortcuts for faster studying!
Study Smart Tips for Iteration Cycles and Versioning
Master these concepts using proven study techniques that actually work:
Active Recall
Test yourself before flipping each card to strengthen memory retention
Spaced Repetition
Review difficult cards more frequently than easy ones
Multiple Sessions
Break study time into shorter, focused sessions
Explain Aloud
Verbalize answers to reinforce understanding
Questions Covered in This Set
10 cards to master
Why shouldn't you fix nine problems at once?
If the game changes, you can't tell which edit caused it — you may keep a bad fix or throw out a good one, and you never converge.
What are the five steps of a disciplined iteration cycle?
1) Observe something specific, 2) Hypothesize a cause, 3) Change one thing, 4) Test with a written prediction, 5) Compare and record (keep or revert).
Which step do beginners skip, and why does it matter?
Writing a prediction before testing. It turns playtesting from vibes into an experiment; a wrong prediction teaches you about the game's real structure.
What does 'change one thing' actually mean?
One hypothesis per cycle, with the minimum set of edits needed to keep the game coherent — not literally one edit, and never unrelated fixes bundled together.
What is a 'parking lot'?
A running list of ideas and complaints you are deliberately not addressing now, so nothing is lost and you don't feel forced to act on everything.
How should version numbers be bumped?
Minor number for each tested change (v0.8, v0.9); major number for structural overhauls (v1.0).
Why should you never edit a tested version in place?
Old versions are your control group — copy the file, rename it, then edit, so past builds stay reconstructible for comparison.
Why put version numbers on physical components?
So you never accidentally play a Frankenstein mix of two builds; colored card backs or different paper stock per version works even better.
What belongs in a change log entry?
Version, date, player count and length, the CHANGE, WHY, PREDICT, RESULT, VERDICT (keep/revert), and PARKING items.
Example of a bad vs. good observation
Bad: 'the midgame is boring.' Good: 'in 3 of 4 tests players spent turns 4–8 only drawing cards.'