The structure every game needs before it needs anything else.
game-loop.txt
Build me a game skeleton in one HTML file. Canvas, no libraries, no
build step.
Structure, strictly:
- One `state` object holding everything mutable.
- `update(dt)` — changes state only, never draws. Takes elapsed
seconds, so movement is speed × dt and not per-frame.
- `draw()` — reads state and renders, changes nothing.
- A requestAnimationFrame loop calling both, with dt clamped so a
tab returning from the background doesn't teleport everything.
Include a `mode` field with 'playing', 'paused' and 'gameover' from
the start, and a placeholder square I can move with the arrow keys.
Then tell me where I'd add a new entity type, a collision, and a score.
Clamping dt is the line everyone omits. Without it, switching tabs for a minute produces one frame with a 60-second delta and everything ends up outside the level.
Overlapping is easy. Resolving is where the bugs are.
collisions.txt
Add collision handling to my game. Entities are <rectangles / circles>:
<paste the entity shape and movement code>
- Detection: <AABB / circle> overlap, with the maths explained.
- Resolution: move on X, resolve, then move on Y, resolve. Not both
at once — I know that causes sticking to walls while falling.
- Report which side the collision happened on, so I can tell landing
on a platform from hitting its underside.
- Handle fast-moving objects passing through thin walls between
frames. Tell me whether that's a real risk at my speeds before
adding anything for it.
Keep detection separate from response, so I can reuse detection for
triggers and pickups that don't push anything.
Separate axes is the fix for the two most common platformer bugs at once: sticking to walls, and being unable to walk over a seam between two floor tiles.
Frames, timing, and not tying animation to frame rate.
sprite-animation.txt
Add sprite animation. My sprite sheet: <dimensions, frames per row,
frame size>.
- An animation is a named list of frame indices plus a duration per
frame, driven by elapsed time — never by frame count.
- Support looping and one-shot animations, with a callback when a
one-shot finishes.
- Switching animation resets to frame zero, unless I ask it not to.
- Horizontal flip for facing direction, without a second sheet.
Define the animations as data at the top so I can add one without
touching the drawing code.
Then show me how I'd drive it from state: idle when not moving, run
when moving, jump when airborne.
Frame-count timing looks right on your machine and runs at double speed on a 120Hz display. Elapsed time is the only version that's correct everywhere.
Add touch controls to my game, keeping keyboard working: <paste input
handling>
- <Virtual stick / swipe / tap zones> — recommend which suits my game
and say why.
- Controls sized for thumbs and positioned where thumbs actually rest,
not centred at the bottom.
- Handle multi-touch: moving and jumping at the same time must work.
- Prevent the browser's defaults — scrolling, pull-to-refresh,
double-tap zoom, text selection — inside the game area only.
- Hide touch controls when a keyboard is used, and vice versa.
Also handle the screen rotating mid-game without breaking the canvas.
Pull-to-refresh is the one that ruins a game. A downward swipe reloading the page mid-play is unrecoverable, and it takes one CSS property to prevent.
Design behaviour for an enemy that <describe what it should feel like
to fight>.
Use a small state machine — patrol, alert, chase, attack, retreat —
with explicit transitions. For each state: what it does, what makes it
leave, and what the player sees that tells them the state changed.
That last part is the point: the player must be able to read the
enemy's intent. Tell me the visual or audio cue for each transition.
Add a short delay on noticing the player and on losing them, so it
doesn't snap instantly between states.
Keep the numbers in a config object I can tune while playing.
Readable beats smart. An enemy whose behaviour a player can predict and outwit is more fun than one that's genuinely cleverer and appears random.
Generate levels for my game: <describe the space — rooms? platforms?
a grid?>
Requirements:
- Seeded random, so I can reproduce a specific level from its seed.
Essential for debugging a broken one.
- Guarantee it's completable. Say how you verify that, and what happens
when generation produces an impossible layout — regenerate, or repair?
- Constraints, not pure randomness: <minimum gap, maximum jump
distance, no dead ends, at least one of each pickup>.
- Difficulty as an input parameter, and explain what it changes.
Show me how to dump a generated level as text so I can look at fifty
of them quickly and judge whether they're any good.
Generate fifty and read them before wiring it into the game. Bad generators produce levels that are individually plausible and collectively identical.
Here's my game code: <paste>
Pull every magic number that affects how the game feels into one
CONFIG object at the top. Speeds, gravity, cooldowns, damage, spawn
rates, costs, thresholds.
For each: a comment saying what it does to the feel, and a sensible
range. "Higher = floatier jump" is what I want, not "jump strength".
Leave genuine constants — canvas size, array indices — where they are.
Tell me which you decided weren't tuning values, and why.
Then: how do I expose these as on-screen sliders during development so
I can tune while playing?
Tuning while playing beats tuning while reading, every time. Feel is not something you can reason your way to from a number.
Add saving to my game. State: <paste the state object>
- Serialise only what's needed to rebuild — never functions, images or
DOM nodes. Tell me what you excluded.
- A schema version in the save. On load, migrate old versions rather
than wiping them.
- Corrupt or unparseable save starts a fresh game instead of crashing.
- Every read and write in try/catch — private browsing throws on
storage access, and that must never break the game.
- Save on meaningful events, not every frame. Say which you chose.
Then show me how to add a new field without breaking existing saves.
The try/catch is not defensive padding. An unhandled storage exception at startup is a blank screen, and it only happens to people using a private window.
The cheapest way to make a game feel twice as responsive.
game-audio.txt
Add sound effects to my game: <list the events>
- Web Audio, with sounds preloaded before play starts.
- Browsers block audio until a user gesture — handle that properly so
the first sound isn't swallowed, and don't leave the context
suspended.
- Slight random pitch variation on repeated sounds so they don't
become grating.
- Cap simultaneous instances of the same sound. Ten coins collected at
once must not be ten overlapping clips at full volume.
- A mute toggle, remembered in localStorage, and honour it from the
first frame.
Separate volume for effects and music. Default the whole thing to a
sensible level, not maximum.
Never autoplay music on load. Muted by default with an obvious unmute is the version people don't close the tab on.
If the client reports the score, the score is fiction.
leaderboard.txt
Add a leaderboard to my game. Stack: <stack>.
Understand first: anything the browser sends can be edited. Tell me
honestly which of these fits my situation:
- Local-only high scores. No server, no cheating problem.
- Server-submitted scores, accepting that some will be fake, with
basic sanity limits.
- Server-authoritative, where the server simulates or validates the
run. Say what that costs me to build.
For the option you recommend, implement it with:
- Rate limiting per player and per IP.
- A plausibility check rejecting impossible scores and impossible
times, with the thresholds explained.
- Name filtering, and a length limit.
- Pagination, plus "your rank" for players outside the top page.
Decide up front how much cheating you can live with. A casual game's leaderboard being a bit fictional is fine; building server-authoritative scoring for it is weeks you didn't need to spend.
The plumbing that makes a prototype feel like a game.
game-states.txt
Add proper state handling to my game: <paste the loop>
States: menu, playing, paused, game over. One `mode` field, and both
update and draw switch on it.
- Pause on Escape and on the window losing focus — a tab switch must
not run the game invisibly.
- Paused freezes update but keeps drawing, with an overlay.
- Game over shows the score and restarts without a page reload.
- Restart resets state cleanly. Tell me what has to be reset that's
easy to miss — timers, event listeners, spawned entities.
Menu and game over must be keyboard and touch navigable, not
click-only.
Pausing on blur is the one people forget. A player who alt-tabs for two minutes should not come back to a dead character.
My level is larger than the canvas and I need a camera: <paste the
draw code>
- A camera position, with everything drawn relative to it. Show me
where the offset gets applied so I only do it in one place.
- Smooth following with a lag, not locked rigidly to the player.
- A dead zone in the middle so small movements don't shift the view.
- Clamped to the level bounds — never show empty space past the edge.
- Convert between screen and world coordinates, for mouse input.
Keep the camera values in the config object so I can tune the feel.
A camera locked exactly to the player is nauseating. The lag and the dead zone are what make it feel like a camera rather than a rigid frame.
My level is a grid of tiles: <describe size and tile size>
- Store the map as a simple array I can edit by hand — ideally
readable as text.
- Draw only the tiles currently visible, computed from the camera.
Don't loop the whole map every frame.
- Tile lookup for collisions: given a world position, which tile?
- Handle the map being larger than the visible area in both axes.
Then tell me at what map size this approach stops being fast enough,
and what I'd do then.
Culling to the visible range is the whole optimisation. A 500×500 map drawn in full is 250,000 draw calls a frame; visible-only is a few hundred.
Add an inventory to my game. Items have <describe — name, type,
stackable?>.
- The data structure, and why that one.
- Adding an item when the inventory is full, or partly full for a
stack — split it, or refuse it? Say which and be consistent.
- Removing a specific quantity across multiple stacks.
- Sorting and filtering.
- Serialising for a save, in a way that survives me adding new item
types later.
Handle these explicitly: adding zero, adding more than the stack
limit, removing more than I have, and an item type that no longer
exists in a loaded save.
The unknown-item-type case matters. Remove an item from your game and every old save containing it must load rather than crash.
Branching conversation, kept in data rather than code.
dialogue.txt
I need branching dialogue in my game.
- Store conversations as data — JSON or something hand-editable — not
as code. Writing dialogue must not mean editing source.
- Nodes with text, a speaker, and choices leading to other nodes.
- Conditions on choices, based on game state, and effects when a
choice is taken.
- Handle a node that references one that doesn't exist: fail loudly in
development, gracefully in production.
Then: text that reveals character by character, skippable on input,
and never mid-word wrapping.
Show me how a writer with no coding knowledge would add a conversation.
If adding dialogue requires touching code, you'll write less of it. Data-driven from the start is the difference between a game with a script and one with three lines.
Add impact feedback to my game: <paste the collision handling>
- Screen shake: magnitude and duration as parameters, decaying over
time, applied at the camera so it doesn't move game state.
- Hit pause: freeze updates for a few frames on significant impacts,
keeping rendering alive.
- A brief flash or colour change on the thing that got hit.
All values in the config object. Give me sensible starting numbers and
tell me what range is reasonable for each.
Important: shake and pause must not affect physics or timing. A frozen
frame must not become a large delta afterwards.
Hit pause of 50–80ms is enough. It reads as weight; any longer reads as a bug or a dropped frame.
I've built a browser game with <stack> and I want it live on <host>.
Get it online properly:
- Which files to upload, and where.
- Correct content types for every asset, including audio and fonts.
- Caching so returning players load instantly, with new versions still
reaching them.
- Compression for scripts and data files.
- A share preview: title, description and a screenshot image.
- Checking it on a phone over mobile data before I tell anyone.
Keep it to what this host can do.
Test the live version on a phone over mobile data. Audio formats, touch input and load time all behave differently from your laptop on wifi.
Store scores on the server, and assume some will be fake.
score-api.txt
My browser game needs an online leaderboard. Backend: <stack> on <host>.
Build:
- One endpoint to submit a score and one to fetch the top 20.
- A table with name, score, date, and whatever I need to reject
duplicates.
- A sanity check that rejects impossible scores and impossibly fast runs.
- A rate limit per player.
- Names trimmed, length-limited and escaped when displayed.
Be honest about how much cheating this stops, and what more would cost.
Anything the browser sends can be edited. A plausibility check stops casual cheating, and for a small game that's usually enough.