How to Write AI LLM Prompts That One-Shot a Fantasy Side Scroller

The best AI LLM prompts for a one-shot fantasy side scroller read like a short game design spec. Name the format (one HTML file with a canvas) and the win condition, give numbers for the controls, then add the technical rules a model tends to skip, such as frame-rate-independent movement. That gives a capable model enough to produce a playable game in a single reply. "Make me a fantasy platformer" leaves room to guess, and models guess generously.

Below is a prompt you can copy, then why each part is there and how to recover when the first shot misses.

What one-shot means in AI LLM prompts

"One-shot" has two meanings, and people making games use the newer one.

In the research sense, a one-shot prompt contains a single worked example of the task. The GPT-3 paper, Language Models are Few-Shot Learners, defined one-shot as one demonstration plus a natural language description of the task. Zero-shot meant the description with no examples at all. By that definition most game prompts are zero-shot, since nobody pastes in a finished platformer as the example.

In vibe coding, meaning building software by describing it to a model and running what comes back, one-shot means one attempt. You send one prompt and get one file, and the game either runs or it does not. No follow-ups, no "now fix the jump." It is partly practical and partly sport: a one-shot game is a fair test of how much a model can plan on its own.

The bar is higher than it looks. A side scroller needs physics and a camera that agree with each other for several hundred lines of code. One wrong sign in the gravity code and your hero drifts politely upward into the night sky, forever.

A one-shot fantasy side scroller prompt you can copy

This prompt targets a single HTML file because that format runs anywhere: save it, double-click it, play. Paste it as written, or swap the theme for your own.

Build a complete, playable 2D fantasy side scroller as a single HTML
file. Use one <canvas> (960x540) and plain JavaScript. No libraries
and no external images or sounds: draw everything with canvas shapes
and gradients.

Setting
- The player is a hooded ranger carrying a lantern through a
  moonlit forest.
- The goal is to reach the stone gate at the right end of the level.

Gameplay
- Arrow keys or A/D to move, Space to jump. Allow a jump for 100 ms
  after leaving a ledge, and buffer a jump pressed up to 100 ms
  before landing.
- One hand-built level about 6 screens wide with platforms and pits.
- Two enemy types: slimes that patrol a platform, and bats that
  swoop in a sine wave.
- Landing on an enemy defeats it. Touching one from the side costs a
  heart. The player has 3 hearts and respawns at the last lantern
  checkpoint.
- Glowing runes to collect. Show hearts and runes in a HUD.

Feel
- The camera follows the player smoothly and never shows past the
  level edges.
- Three parallax background layers: sky with moon, far hills,
  near trees.
- Small particle bursts on landing and on rune pickup.

Technical
- Use requestAnimationFrame and scale all movement by delta time,
  so the game runs at the same speed on 60 Hz and 144 Hz screens.
  Cap delta at 50 ms.
- Include a title screen, pause on P, a game-over screen and a
  win screen.

Before you finish, check that the level can be completed, and list
any feature you left out.

It runs to about 260 words, and the length is deliberate. Short prompts produce short games, and every line here closes off a guess the model would otherwise make.

Why the prompt reads like a game design spec

The opening constraint matters most. Ask for sprites and a model will often reference image files that do not exist, which gets you invisible characters bumping into invisible walls. Drawing with canvas shapes keeps the whole game inside one reply.

The gameplay numbers are where the prompt earns its length. Coyote time, the short grace window where a jump still works after the player runs off a ledge, and jump buffering, which remembers a jump pressed a moment before landing, are what make platformers feel fair. Models know both techniques and often leave them out unless asked.

The delta-time line fixes the bug people hit most. A browser game normally runs its loop with requestAnimationFrame, which fires once per screen refresh. MDN's guide to the anatomy of a video game points out that monitors refresh at different rates, from 30 up to 144 frames per second. If movement is a fixed number of pixels per frame, the game runs more than twice as fast on a 144 Hz monitor. Delta time, meaning the time elapsed since the last frame, scales movement so the speed stays constant.

The phrasing follows Anthropic's prompting best practices. If you want more than the task strictly requires, the guide says to request it explicitly, and explaining why an instruction matters helps the model aim. That is why the delta-time line states what it is for.

The closing self-check suits most models. The same guide notes an exception: Claude Opus 5 checks its own work without being asked, and verification lines carried over from older prompts can make it over-check. Drop the last line there.

Which AI tools handle a one-shot game best

Pick a tool that can show you the result. A game you cannot run is a long text file with ambitions.

Chat apps with a live preview are the fastest route. Claude can render the HTML as an artifact you play in the side panel, so you see the result seconds after the reply finishes.

Coding agents go a step further. A tool such as Claude Code writes the file to disk, opens it, and can read the console error before you ever see a broken screen. Our guide to the text editor AI agent explains how these tools edit and run code. If you are new to Claude, Claude AI for Beginners walks through vibe coding with Claude Code from the first install.

Model choice matters more here than for most prompts. The model has to keep the collision code consistent with the level layout across the whole file. Smaller, faster models tend to produce games that load and look right, then drop the player through the floor at the first pit, which is at least thematically on brand for a pit. Use the strongest model you can, with extended thinking switched on if the tool offers it.

Follow-up prompts for when the first shot misses

Even a good prompt misses sometimes. The purist move is to edit the original prompt and resend it in a fresh chat, which keeps the run a true one-shot. The practical move is a short follow-up.

Fix one thing per follow-up, and describe the symptom with a number when you can:

• "The player falls through platforms when landing at speed. Make collision check the path between frames and keep everything else unchanged."
• "The game runs too fast on my 120 Hz monitor. Confirm all movement uses delta time."
• "Jumps feel floaty. Raise gravity by 30% and lower the jump so the peak is about three tiles high."
• "The console shows Uncaught TypeError: Cannot read properties of undefined on line 212. Find the cause and return the full corrected file."

"Keep everything else unchanged" earns its place. Without it, a fix for the jump can arrive with a redesigned level and a bat that now fires lasers.

Ask for the full file every time. Partial snippets marked "rest of code unchanged" are the main way a working game turns into a broken one halfway through a chat.

Keep the prompt that worked

Save the winning prompt next to the game it produced. A prompt is cheap to keep and expensive to reconstruct from memory three weeks later.

A folder per game does the job, holding the prompt as a text file and each version of the HTML with a date in the name. When a new model comes out, rerun the same prompt and compare. It is the cheapest model benchmark you will ever run, and the only one that tells you whether the bats got smarter.

For a larger collection, our guide to building an AI prompt library covers organising and versioning prompts, and the AI prompt examples post has more templates in the same spec style. For the reasoning behind structured prompts, AI Prompt Engineering by Nelson Ming treats prompts as systems you maintain.

The rule of thumb: write the prompt you would hand a new developer on their first day. Name the format and the win condition. Give the numbers that define the feel, and say what done looks like. Then send it once and see how far one shot gets you.