How to make an action game with AI
An action game is decided by what happens in the frames after you connect. Subtracting health is not feedback. A flash, a freeze, a shove and a few specks are.
Jump to a section
Ask for an arena, a player who swings, and something that walks towards you. That takes one prompt. Then put all of your remaining effort into the quarter second after contact, because that is where an action game is won or lost. A rectangle with a sword can feel better to fight with than a far more finished game that takes damage in silence.
A first build does the combat maths correctly and shows you nothing. Health goes down, the enemy carries on walking at the same speed, and your swing may as well have passed through fog. Nothing is broken. The frames that sell the contact were never written, and no amount of balancing the damage will replace them.
Four steps to combat you can feel#
Walls, movement, a swing on a cooldown, and one shape that chases you. Resist adding a second enemy type.
You are testing one thing only. At the instant you connect, can you tell? The honest answer is almost always no.
Flash, freeze, knockback and particles arrive together or not at all. Alone, each of them reads as a rendering fault.
Shake is the one effect with a real cost. Keep it for the kill, and the kill becomes an event.
Build a top down action game as ONE self-contained .html file. No
frameworks, no libraries, no image files.
ARENA: a square room drawn with canvas shapes and solid walls on all
four sides. The player is a rectangle with a small nose showing the
direction it faces.
CONTROLS: WASD or the arrow keys to move. Space swings. A swing is an
arc in front of the player lasting about 120ms, on a cooldown, so it
cannot be held down.
ENEMIES: plain shapes that walk towards the player and hurt it on
contact. One more arrives every few seconds. Three swings kill one.
HIT FEEDBACK. Treat this section as the main feature of the game:
- Tint whatever was hit solid white for 80ms, attacker or enemy.
- Freeze every update for 3 frames on a hit, then carry on. Keep
drawing during the freeze and keep recording key presses.
- Shove the target along the line away from whatever hit it, with the
shove decaying to a stop rather than ending abruptly.
- Throw 8 small short lived specks out from the point of contact.
- Shake the camera for about 200ms ONLY when a hit reduces something
to zero health. Never on a hit that something survives.
- One short Web Audio oscillator blip per hit, with a lower pitch for
heavier damage. Create the AudioContext on the first key press.
PHONE: dragging anywhere moves the player and a tap on the right half
swings.
Work out all movement from the number of seconds that elapsed since the
previous frame, and clamp that number to 0.05 so a tab left in the
background cannot teleport anything across the room. Put
canvas { touch-action: none; } in the CSS. Gather every number worth
changing into one CONFIG object at the top, FLASH_MS, FREEZE_FRAMES,
KNOCKBACK, SHAKE_MS, SWING_MS and SWING_COOLDOWN among them.
The hit feedback section is the whole point of the prompt. FREEZE_FRAMES and KNOCKBACK are taste, so push them around until the swing feels like yours. Leave the shake condition exactly as written until the other five are tuned, because a moving camera hides whether any of them is working.
The five effects behind a hit that reads#
Players describe good combat as weighty or crunchy, and neither word points at anything a model can implement. What they are actually reacting to is a small pile of effects that all fire on the same frame. Each one is a few lines. None of them changes the rules, the damage or the balance.
Order inside the frame barely matters. Simultaneity does. If the flash starts on the frame of contact and the freeze starts two frames later, the brain stops reading them as the same event. Ask for one function that takes the target and the direction of the blow, and have every effect start inside it.
Hit stop, the effect nobody asks for#
Hit stop is a pause in the simulation at the moment of contact. The world stops updating for three or four frames while the screen keeps drawing. Fighting games have used it for decades and almost nobody building their first action game has heard of it.
It is the cheapest large improvement available to you. The flash tells the player which thing was hit. The freeze tells them the hit was hard. Hold it too long and the game feels like it is stuttering, so keep the pause short and count frames rather than guessing in milliseconds.
- Pause updates, not rendering. If you skip the draw call as well, the player sees a dropped frame instead of a held one. The screen must stay lit and still.
- Keep listening to the keyboard. A player who presses the swing key during a freeze expects it to come out the moment the freeze ends. Buffer the press, do not discard it.
- Do not freeze the audio. The blip wants to start on the contact frame and ring through the pause. Silence during hit stop makes the whole thing feel broken.
- Scale it with the damage. A light tap barely pauses. A heavy blow holds noticeably longer. That difference alone communicates which of your attacks is the big one.
Screen shake on every hit makes a game unreadable#
Shake is the first thing people add and the first thing that needs taking back out. It moves the entire frame, so it is the only effect here that costs the player information. In a game where you are dodging three things at once, a camera that jolts on every swing means you can no longer see what you are dodging.
There is a second reason to ration it. Feedback only communicates size by contrast. If every hit shakes, no hit is big. Giving the shake to killing blows and heavy attacks sorts your whole combat into two volumes, and the player learns the difference without being told.
If you do want more of it, ask for the shake to decay from its starting size rather than running flat and stopping. A jolt that fades reads as an impact. A jolt that holds steady for a fifth of a second reads as a fault in the code.
What each effect costs you#
Worth knowing before you start trading them off. Four of the five are close to free, which is the argument for asking for all of them at once.
| Effect | What the player reads from it | What it costs you |
|---|---|---|
| White flash | Which of several things on screen was hit | A countdown on the target and one fill colour swapped |
| Hit stop | That the blow was heavy rather than glancing | A flag that skips the update step for a few frames |
| Knockback | Space between the fighters, and a moment to recover | A velocity on the target that decays, plus wall clamping |
| Particles | Something to watch at the instant they succeeded | A small array of specks with a lifetime each |
| Screen shake | That this hit mattered more than the last one | The player's grip on where everything is, so ration it |
Knockback is the one with a rule attached: a target shoved into a wall must stop at the wall, not pass through it.
Enemies worth hitting#
Good feedback is wasted on enemies that do nothing. Once the hits land properly, the next thing that makes the combat interesting is giving the player something to read before it attacks.
- Telegraph the attack. Ask for a wind up the player can see, a colour change or a lean, held long enough to dodge. An enemy that damages on contact with no warning is not a fight, it is weather.
- Give the player brief invulnerability after taking damage. Without it, standing inside an enemy drains the whole health bar in a second and the death feels unfair.
- Make the second enemy type move differently, not just faster. One that charges in a straight line and one that circles create different problems. A faster copy creates the same problem sooner.
- Let a death leave something behind. Specks that linger, or a mark on the floor. It is a small thing that makes the arena feel like it has a history.
Keep the arena small. Action reads best when the player and the threat are close enough to see both at once, and a large empty room mostly produces walking. If the fight feels thin, shrink the room before you add another enemy.
⚔️Action games written by AI
Common questions#
Can AI make an action game?
Yes, and the combat loop is one of the easier things to get working. An arena, a swing on a cooldown and enemies that chase is a single prompt. The part that takes judgement is the feedback on contact, which models will not add unless you name each effect.
Why does my combat feel like nothing is happening?
Because hitting something only changes a number. Ask for a white flash on the target, a freeze of a few frames, a shove away from the attacker and a small burst of specks, all triggered from one place. The damage maths was never the problem.
What is hit stop?
A pause in the simulation for a few frames at the moment of contact, while the screen keeps drawing. It is how a hit communicates weight. Ask for updates to be skipped briefly, not for the drawing to stop, or it looks like a dropped frame.
How much screen shake is too much?
Any amount on an ordinary hit is too much. Shake moves the whole frame, so it costs the player their sense of where things are. Keep it for killing blows and heavy attacks, and ask for it to fade out rather than stopping flat.
Should enemies have health bars?
Usually not. A flash on the hit and a visible change in colour as they weaken does the same job without adding furniture over everything. Save the bar for a single large enemy where the player needs to judge how much is left.
How do I add combos?
Only after one swing feels right. A combo is a window after a hit during which the next swing comes out faster. Build it as a timer on the player rather than a list of moves, and tune the window length until chaining feels deliberate.
Where to go next#
When a fight is worth having twice, put it up. The page it gets records the model and the prompt behind it, and other people can see how the combat holds up against theirs. The action games here are the fastest way to calibrate your own feedback against somebody else's.
The general method, including the loop for getting faults fixed, is in how to make a game with AI. For the restart loop that decides whether anyone plays a second round, see the arcade guide. Ready prompts for common faults sit in the prompt guide, and the 2D guide covers the canvas code this all sits on.
Built something? Put it on Agent Games.
Publishing takes a file and a minute. Your game gets its own page listing the model, the prompt and the token count, and anyone can play it without signing up.
Read next