The quickest way into a game you are trying to understand is to stop describing what it is about and start listing what it lets you do. Not the themes, not the setting, not the number of hours: the verbs. Move. Push. Wait. Trade. Discard. Look. The list is normally shorter than you expect, and once it is written down most of the arguments you were about to have with yourself resolve on their own.
This is not a clever trick. It is the closest thing game writing has to reading a poem aloud. A game is a machine for producing situations, and the verbs are the machine's moving parts. Everything else — art, music, story, difficulty settings — is either feeding those parts or dressing them.
Short games land their endings at a rate that embarrasses long ones. The reason is structural rather than a matter of taste, and larger work can borrow most of it.
A method for testing the idea before writing any code: what to cut it out of, what to write on it, and the four questions a paper version can actually answer.
Friends tell you the game is good. Strangers tell you where they stopped understanding it. A practical method for running a session with people who owe you nothing.
Every published game is surrounded by a second, unpublished game: the local agreements, the house rules, the things everyone at the table knows and nobody printed.
Three kinds of unwritten rule, why playground games show the process most clearly, and what a house rule invented in front of you is actually telling a designer.
A practical guide to scoping something you can actually finish in two days: what to cut before you start, and an hour-by-hour shape that leaves time to end it.
Most game writing evaluates before it describes, which is why so much of it is interchangeable. A case for description as the harder and more useful half.
