How to make a casual game with AI
Your player did not decide to play this. They tapped something. You get one input and about five seconds to teach the whole game, and no text is going to help you.
Jump to a section
Pick a mechanic that fits in one input, then design the opening so the rule arrives without a word of text. That is the entire brief for a casual game. The person playing it did not seek it out and will not read anything, so everything they need has to be visible in the first few seconds of play.
Write for somebody who tapped a link, is half paying attention and has another tab open. They will not read a how to play panel. They will not look for a key. If the game has not explained itself through what is moving on the screen, they are gone, and nothing about the design was wrong except that it needed explaining.
Four steps to a game nobody has to explain#
If you need two keys, you have two mechanics, and one of them is going to need explaining.
The first obstacle should be so wide and so slow that hitting it takes effort. That is the tutorial.
Not your phone and not a word of help. Watch where their thumbs go and whether they work out the rule.
Whatever you wrote to cover the gap is covering a design fault. Fix the opening and the text has nothing left to say.
Build a casual one input game as ONE self-contained .html file. No
frameworks, no libraries, no image files.
THE GAME: blocks swing left and right above a tower. One input drops
the current block. A block that lands on the tower adds to it, and the
overhanging part is trimmed off, so the tower narrows as it grows. A
block that misses entirely ends the run.
ONE INPUT: a tap, a click and the space bar all do the same single
thing. Nothing else is bound to anything. There is no pause, no menu
and no second action anywhere in the game.
TEACHING, treat this as the main requirement: for the first few drops
the block is nearly as wide as the screen and swings slowly, so the
player cannot miss even by accident. The swing then speeds up and the
tower narrows. Put NO instruction text anywhere in the page. Not a how
to play box, not a hint, not a caption. The opening has to carry it.
LOOK: large flat shapes in high contrast, no thin outlines, no small
detail. The only text in the whole game is the score. A dropped block
flashes and squashes briefly on landing so the input is unmistakably
acknowledged.
PHONE FIRST: the canvas fills the viewport and reacts to a resize and
to rotation. Keep the tower and the swinging block in the upper two
thirds, clear of where thumbs rest. Make sure it reads on a phone held
in portrait before you worry about a desktop window.
Base every movement on the seconds that have passed since the previous
frame, clamped to a maximum of 0.05 so a backgrounded tab cannot swing
a block across the screen in one step. Put canvas { touch-action:
none; } in the CSS so a tap does not scroll or zoom the page. Keep all
adjustable numbers together in a CONFIG object at the top, including
SWING_SPEED, SWING_GROWTH, START_WIDTH and TRIM.START_WIDTH and SWING_SPEED are the teaching numbers, so make the start wider and slower than feels right to you. The no text rule is the one to keep. The moment a hint box appears, you stop finding out whether the opening works.
One input, and what it buys you#
One input is not a limitation you accept reluctantly. It removes the entire category of problem where a player does not know what to press. There is nothing to learn, because there is only one thing to do, and the only question left is when to do it.
It also makes the game work everywhere without a second control scheme. A tap, a click and a key press map to the same function, so there is no touch version and no desktop version. Games that need a keyboard quietly exclude most of the people who will ever open them.
- Make the timing the skill. With one input, difficulty lives in when the player acts rather than what they choose. That is enough for a surprising number of games.
- Or make holding different from tapping. A press and a hold are still one input, and the difference is discoverable by accident, which is the test any control has to pass.
- Acknowledge every press. A tap that produces no visible change reads as a broken game. Something has to move on the frame the finger lands.
- Resist the pause button. On a phone the pause is leaving the page. A pause button is a second thing on screen that does nothing the player needs.
The opening five seconds are the tutorial#
The rule has to be learned by doing, and the only way to allow that is to make the first few attempts impossible to fail. Wide targets, slow movement, generous margins. The player acts, something good happens, and they now know the game without having been told anything.
Then let the difficulty arrive quickly. An opening that stays easy becomes boring well before the player has decided to care. The curve should be flat for a handful of attempts and then climb, so learning and losing are never happening at the same time.
This is also why text does not work as a substitute. Reading is a different activity from playing, and a player who has stopped to read has stopped. Anything you would have put in a help panel can be built as a slow, harmless first obstacle instead.
Readable at a glance, on a small screen#
Casual games are played in bad conditions. Half attention, a bright room, a phone held at arm's length. The visual design has to survive that, which mostly means being larger and plainer than you would choose on a monitor.
| Ask for this | Rather than this | Because |
|---|---|---|
| Big flat shapes in strong colours | Detailed sprites and thin outlines | Detail disappears on a small bright screen |
| One accent colour for what matters | A palette where everything is colourful | The player needs to know where to look |
| Score in one corner, large | A panel of statistics | Anything else on screen is competing with the game |
| Shape and position to show state | Colour alone to show state | Some players will not see the colour difference |
| Motion to draw the eye | Text to draw the eye | Movement is noticed without being read |
The last row is the whole article in one line. Anything you would say in words can usually be said by making something move.
A phone is the device, not a variant#
Most people who ever open a casual game will open it on a phone. If you build on a laptop and add touch at the end, you get a game that technically responds to a tap and was laid out for a mouse. The two are not the same thing.
- Let the canvas follow the window. A fixed size canvas either overflows a phone or sits in the middle of a desktop window. Ask for it to fill the viewport and redraw on resize and on rotation.
- Keep the action out of the bottom third. That strip is where thumbs live and where phone browsers put their own furniture.
- Turn off the browser's own gestures. Without the touch action rule in the CSS, a tap can scroll the page and a quick double tap can zoom it.
- Test it on a real phone, not a narrow window. A resized desktop window gets the layout right and tells you nothing about how the game feels under a thumb.
🎈Casual games written by AI
Opus 5.5
GPT-6 Astra
GLM-5.3
Gemini 3.8 Flash
MiMo V2.6 ProCommon questions#
What counts as a casual game?
One that a stranger can pick up and understand without being taught, play in a short sitting, and put down without losing anything. The test is not how simple the code is. It is whether somebody who did not choose to play it can work it out.
Can a casual game really have only one input?
Most of the good ones do. With a single action the difficulty has to live in timing or in judgement, which is plenty. A press and a hold counts as one input, because the difference between them gets discovered by accident.
Why should I not add a how to play screen?
Because it hides the fault rather than fixing it. A help panel tells you the opening does not teach the rule, and it stops you finding out whether your change worked. Make the first attempts impossible to fail instead.
How do I make the first few seconds impossible to fail?
Oversize everything that matters and slow everything down. Wide targets, long gaps, generous collision margins. Then ask for those values to tighten over the first handful of attempts until the real game is running.
Does my casual game need sound?
It helps and it cannot be relied on. Many phones arrive muted and browsers block audio until the player touches the screen. Treat sound as something that makes a good game better, never as the thing that explains a rule.
Should it be relaxing or should it be hard?
Either works, as long as it is clear within seconds which one you built. The failure case is a game that looks gentle and punishes carelessly, because the player learns to distrust what they are looking at.
Where to go next#
When somebody else can play it on their phone without you saying a word, put it up. The page it gets lists the model and the prompt behind it, and the plays come from people who meet it exactly the way you designed for. The casual games here are worth opening on a phone to see which of them pass the same test.
The general method sits in how to make a game with AI, and the canvas and resize code behind all of this is covered in the 2D guide. If people play once and stop, the restart loop in the arcade guide is the next thing to fix.
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