AgentGames

Search titles, descriptions, models and tags. Press Enter to see results.

⚔️ Guide

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.

Updated 5 October 2026 7 min read By the Agent Games team
Jump to a section
  1. Four steps to combat you can feel
  2. The five effects behind a hit that reads
  3. Hit stop, the effect nobody asks for
  4. Screen shake on every hit makes a game unreadable
  5. What each effect costs you
  6. Enemies worth hitting
  7. Common questions
  8. Where to go next

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.

Subtracting health is not feedback

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#

Get the arena and one enemy standing up

Walls, movement, a swing on a cooldown, and one shape that chases you. Resist adding a second enemy type.

Fight it once with the sound off

You are testing one thing only. At the instant you connect, can you tell? The honest answer is almost always no.

Ask for the whole feedback stack in a single message

Flash, freeze, knockback and particles arrive together or not at all. Alone, each of them reads as a rendering fault.

Hold the camera still until something dies

Shake is the one effect with a real cost. Keep it for the kill, and the kill becomes an event.

PromptCopy this, paste it, send it
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.

What fires on a single hit All of it in the same frame the collision is detected, not spread over a second. 1 White flash The thing that got hit turns solid white for about 80ms. 2 Hit stop Every update pauses for three or four frames, then resumes. 3 Knockback The target slides away from the attacker and settles. 4 Particle burst A handful of short lived specks from the contact point. 5 Blip One oscillator tone, pitched by how much damage landed. 6 Screen shake Killing blows only. Never on an ordinary swing. Ask for all six in one message. Added one at a time, no single one looks like it works.
Fired together they read as one impact. Fired separately they read as five small bugs, which is why asking for them one per message tends to end with all five removed again.

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.

Where the shake belongs The same combat, with the camera moving on every swing and then only on a kill. Shake on every hit shake(200) inside onHit()The arena never stops moving.Players lose track of where they are.Nothing reads as bigger than anything. Shake on the kill only if (target.dead) shake(200)Normal hits stay still and legible.The kill is the loudest thing on screen.The camera means something again. Shake is the only effect here with a cost. Spend it on the moments you want remembered.
Put the shake behind a condition on the first message, not later. Once it is firing on every hit, the combat has been tuned around a moving camera, and taking it out makes everything feel weaker than it is.

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.

EffectWhat the player reads from itWhat it costs you
White flashWhich of several things on screen was hitA countdown on the target and one fill colour swapped
Hit stopThat the blow was heavy rather than glancingA flag that skips the update step for a few frames
KnockbackSpace between the fighters, and a moment to recoverA velocity on the target that decays, plus wall clamping
ParticlesSomething to watch at the instant they succeededA small array of specks with a lifetime each
Screen shakeThat this hit mattered more than the last oneThe 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.