How to prompt a game into existence

Two people describe a game to the same studio. One gets something they play for twenty minutes and send to a friend. The other gets a competent, hollow platformer they close after ninety seconds. The machine was identical. The difference was in the first two sentences.

This is a craft with rules, and they're learnable in about ten minutes. Here they are.

Name one mechanic, not a genre

A game is a verb before it is a genre. "A platformer" tells the studio almost nothing: it's a shape, and shapes have a thousand interiors. "A platformer where you can't jump, only swing on a grappling hook" is a complete design brief in twelve words, because it names the thing the player will actually be doing with their hands.

The test: could someone build a wrong version of your game while technically following your description? If yes, you've described a category rather than a game. Compare:

Every concrete version names one mechanic and one tension. That's enough for a first build, and it leaves the machine no room to default.

Specify the camera and the controls

These decide more about how a game feels than the art does, and they are the two things people most often leave out. Side-on or top-down. One button or two sticks. Whether the camera leads the player or follows them. Whether it's one screen or it scrolls.

Say it explicitly, in the same sentence as the mechanic if you can: "side-on, one button, the button is a dash." Left unsaid, these get chosen for you: reasonably, but not the way you were imagining, and the mismatch is the thing that makes a first build feel subtly wrong in a way that's hard to articulate afterwards.

Give an art direction as a time, a place and a constraint

"Cool graphics" is not an art direction. "Great pixel art" is barely better. What works is a specific set of coordinates: a period, a medium, and a limitation:

• "Late-90s shareware: four colours, chunky black outlines, dithered skies."
• "Sega-CD FMV pastiche: grainy video backdrops, hard compression, over-saturated menus."
• "Silhouette art on a single accent colour, everything else black."
• "Early Bullfrog: isometric, tiny sprites, an absurd amount of detail per tile."

Constraints do more work than adjectives, because a constraint is checkable. "Four colours" produces a coherent look automatically; "beautiful" produces an average of everything the model has ever seen called beautiful, which is the definition of generic.

Say what the first minute is

Optional, and it disproportionately improves the result. Describe what happens in the first sixty seconds: what the player sees, what they try, what goes wrong. "You start on a ledge, the only enemy is asleep, and the first thing you'll do is fall on it and learn that landing on things is how you attack."

This forces the studio to build a beginning rather than a sandbox, and beginnings are what make a generated game feel authored. Without one, you get a system with no on-ramp: technically playable, immediately confusing.

Keep the first brief short, then iterate

The instinct is to front-load everything into a design document. Resist it. A long brief makes decisions you can't evaluate yet, contradicts itself in places you won't notice, and delays the only thing that actually informs you: playing the draft.

Two or three sentences is the right size for a first message. You'll know more after ninety seconds with the build than after another page of writing. That's not a limitation of the tooling: it's how making games has always worked, just with the loop shortened from a fortnight to a coffee break.

Iterate in the language of feel

This is the part people get wrong most often, and it's counterintuitive if you write software. The best change requests are imprecise about implementation and precise about experience:

• "The jump is floaty and I keep overshooting the platform."
• "The enemies read as friendly: they look like they want to help me."
• "It's too quiet in the first room. Something should be happening before I press anything."
• "The difficulty spikes at the third screen and I don't know what killed me."

Each of those describes a symptom the agent can reproduce and diagnose. Compare with "set gravity to 1400", which presumes an implementation you haven't read, and which, if your diagnosis was wrong, produces a game that's differently wrong. Describe what you felt. Let it find the cause.

Bring references if you have them

A brief can carry images. Reference art, a screenshot of a colour palette, a photo of a place, a sketch of a level on paper: all of it beats another paragraph of adjectives, and it's the fastest way to close the gap between the look in your head and the look on screen.

The one thing not to bring is someone else's game as the target. "Make me this" pointed at a specific franchise produces something you can't publish, share or put your name on, which defeats the point of a studio whose output is a public link. Bring the era, the palette, the texture. Leave the cast.

A worked example

A one-button endless climber. Side-on, single screen, the wall crumbles behind you as you go so you can never rest. The button is a jump that charges while held: tap for a hop, hold for a leap you'll probably regret.

Art: silhouette against a single accent colour that shifts warmer the higher you get. No outlines, no texture, everything reads by shape.

First minute: you start at the bottom with nothing chasing you. Three seconds in, the ground starts going. You learn the charge by panicking.

Three short paragraphs. One mechanic, one camera, one control, one visual constraint, one on-ramp. That brief produces a game with a point of view, and everything after it is a conversation about feel.