How to Make a Game with Opus 5

If you want to know how to make a game with Opus 5, here’s the honest answer: don’t start by asking it to build your dream RPG.

That’s the common mistake. You get a flashy prototype, a character that floats through walls, menus that break after the second click, and a codebase nobody understands. Opus 5 is powerful enough to build a genuinely playable game, but it still needs a human director. You choose the scope, the engine, the art style, and the order of work. Claude writes a lot of the implementation.

The best first project is a small browser game with one clear gameplay loop. In this tutorial, we’ll build a complete top-down survival game called Night Garden. You move around a small arena, collect glowing seeds, avoid enemies, survive for two minutes, and restart when you lose.

This is a useful project because it includes the parts that make games feel like games: input, movement, collisions, enemies, spawning, scoring, a timer, a health system, screen feedback, audio hooks, and a win or lose state. It’s small enough to finish and substantial enough to expose the places where AI-generated code usually falls apart.

As of August 2026, Claude Opus 5 is available through Claude Code and the Claude API under the model ID claude-opus-5. Anthropic lists a 1 million token context window, up to 128,000 output tokens, adaptive thinking enabled by default, and API pricing of $5 per million input tokens and $25 per million output tokens. The Claude Pro plan is $20 per month in the United States and includes Claude Code access, while Max plans cost $100 or $200 per month with higher usage capacity.

The model is much better at long-running coding tasks than earlier Opus releases. That doesn’t mean it can invent good game design for you. It means it can keep more of your project in view, make larger multi-file changes, find bugs across files, and follow a structured plan without losing the plot as quickly.

That difference matters.

Prerequisites before you start

You’ll need:

• A computer running macOS, Windows, or Linux
• Node.js 20 or newer
• Git
• A Claude account with Claude Code access, or an API key if you’re using the API
• A terminal
• A code editor
• A modern browser such as Chrome, Edge, Firefox, or Safari
• Around two to four hours for the first playable version
• A willingness to test the game after every meaningful change

You do not need Unity, Unreal Engine, Blender, a paid asset library, or a graphics tablet. For this project, we’ll use Phaser 3 with TypeScript and Vite. Phaser is a good fit for AI-assisted game work because it has a clear browser runtime, straightforward JavaScript APIs, and a large amount of training material available to coding models.

You could use Godot instead. Opus 5 can work with GDScript and Godot projects, and Godot is the better choice if your goal is a downloadable desktop game. But the browser route gives you faster feedback, easier sharing, and fewer moving parts.

If you’re specifically interested in making a focused personal tool rather than a game, the same scope rules apply to projects such as building a personal Voidpet-style game. The technical loop may be achievable in weeks, but content volume, art, and balancing are where the work expands.

1. Pick a game small enough to finish

The exact action is to write a one-page game brief before asking Opus 5 to create code.

Do not begin with “make me a fun game.” That prompt sounds flexible, but it removes every useful constraint. The model will fill the blank space with features. You’ll get shops, inventories, procedural worlds, multiplayer, dialogue systems, particle effects, save files, and a settings menu before the player can move.

Write this instead:

Game title: Night Garden

Platform: Desktop browser

Genre: Top-down survival arcade game

Player goal: Collect 30 glowing seeds and survive for 120 seconds.

Player actions:
- Move with WASD or arrow keys
- Sprint while holding Space
- Collect seeds by touching them
- Avoid shadow moths
- Press R to restart after losing

Core systems:
- Player movement
- Enemy movement
- Collision detection
- Seed spawning
- Score counter
- Health bar
- Countdown timer
- Win state
- Lose state
- Restart button

Visual style:
- Dark blue background
- Neon green collectibles
- Purple enemies
- Simple geometric shapes
- No external image assets for version one

Out of scope:
- Multiplayer
- Accounts
- Shop
- Inventory
- Character customization
- Procedural map generation
- Mobile controls
- Online leaderboard
- Story campaign

Why does this matter? Because AI coding tools are very good at implementing a defined system and much less reliable at deciding what the system should be. A brief turns Opus 5 from an improvising designer into an unusually fast junior engineer.

The out-of-scope list matters just as much as the feature list. It gives you something to point at when the model tries to widen the project. Opus 5 is specifically documented as capable of long-horizon agentic work, and that strength can become a problem when the task has no hard boundary. It may reasonably decide that your survival game needs a tutorial, a pause screen, enemy types, and persistent high scores.

You don’t need those things yet.

Before moving on, your brief should answer five questions:

1. What does the player do every few seconds?
2. What causes the player to win?
3. What causes the player to lose?
4. What is deliberately excluded?
5. What is the smallest version that would still be fun for five minutes?

If you can’t answer those questions, don’t open Claude Code yet. You’re still designing the game.

2. Choose the engine and create a clean project

The exact action is to create a blank Phaser project and confirm that it runs before Opus 5 touches the game logic.

Open your terminal and run:

npm create vite@latest night-garden -- --template vanilla-ts
cd night-garden
npm install
npm install phaser
npm install -D @types/node
npm run dev

Open the local address shown by Vite. You should see the default starter page. Stop there for a moment.

The point is not to rush. If the blank project doesn’t run before you add AI-generated code, you won’t know whether a later error came from your machine, Vite, Phaser, or Claude’s changes.

Now initialize Git:

git init
git add .
git commit -m "Create blank Phaser project"

Create a simple project note:

mkdir docs
touch docs/game-brief.md

Copy your brief into docs/game-brief.md. This gives Opus 5 a durable reference file that it can read during later sessions. It also gives you a recovery point when the conversation becomes too long or the model starts making assumptions.

Your project should eventually look something like this:

night-garden/
├── docs/
│   └── game-brief.md
├── src/
│   ├── main.ts
│   ├── scenes/
│   │   ├── BootScene.ts
│   │   ├── GameScene.ts
│   │   └── GameOverScene.ts
│   ├── entities/
│   │   ├── Player.ts
│   │   ├── Enemy.ts
│   │   └── Seed.ts
│   └── systems/
│       ├── SpawnSystem.ts
│       └── ScoreSystem.ts
├── index.html
├── package.json
└── vite.config.ts

You don’t have to create every file yourself. In fact, you want Opus 5 to propose the structure. But you should understand the purpose of the folders before you accept it.

A common AI coding mistake is putting the entire game in main.ts. That can feel convenient during the first ten minutes. After five features, it becomes a 1,000-line file with tangled state, repeated collision logic, and functions that quietly depend on variables declared somewhere else.

For a tiny prototype, one file is acceptable. For a game you intend to keep improving, separate the main scene from reusable entities. The goal is not enterprise architecture. The goal is making the next bug findable.

Before moving on, confirm three things:

• The Vite starter runs
• Git has a clean initial commit
• The game brief exists inside the repository

3. Give Opus 5 a planning prompt, not a coding prompt

The exact action is to ask Opus 5 for a technical plan and have it inspect the existing project before writing the first feature.

Start Claude Code from the project directory:

claude

Your first prompt should be deliberately boring:

Read docs/game-brief.md and inspect the existing Vite project.

Do not write code yet.

Create a practical implementation plan for the smallest playable version of Night Garden using Phaser 3 and TypeScript.

The plan must:
- Use simple geometric graphics generated in code
- Avoid external assets
- Keep the first playable build limited to movement, one enemy type, collectibles, health, a timer, win state, lose state, and restart
- Identify the main files you expect to create
- Explain how game state should be managed
- List likely collision and timing bugs
- State what you will not implement yet

Do not add menus, audio, particles, saving, mobile controls, or extra enemy types.

Why ask for a plan first? Because planning gives you a chance to catch a bad technical direction before the model creates it. If Claude suggests a physics-heavy architecture for a game that only needs circles and rectangles, correct it now. If it proposes ten classes for three entities, simplify it.

Opus 5’s official prompting guidance recommends starting at the default high effort and adjusting based on your evaluations. For game development, that means using deeper reasoning for architecture, collision problems, state transitions, and debugging, then lowering effort for repetitive work such as changing colors or adding a text label.

Do not ask the model to “verify everything” in every prompt. Opus 5 already performs more self-checking than earlier versions. Repeating verification instructions can cause it to spend too much time narrating or reviewing trivial changes instead of building the requested feature.

Use a project instruction file if your Claude Code setup supports one. A useful version might say:

# Project instructions

This is a small Phaser 3 TypeScript browser game.

Rules:
- Read docs/game-brief.md before making architectural changes.
- Do not add features outside the brief without asking.
- Prefer simple code over abstractions.
- Use generated shapes instead of external assets until the core loop works.
- Run npm test or npm run build after meaningful changes.
- Never claim a bug is fixed without reproducing or checking the relevant behavior.
- Make one coherent change at a time.
- Keep game rules separate from visual decoration where practical.

That last instruction is especially useful. A game can look correct while its rules are broken. If an enemy sprite appears to touch the player but the health value doesn’t change, the visual result is misleading.

Before moving on, you should have a plan that names the files, the main state variables, and the order of implementation.

4. Build the playable loop in vertical slices

The exact action is to implement one complete feature slice at a time, starting with movement and ending with a playable win or lose condition.

Ask Opus 5:

Implement only the first vertical slice from the plan.

Create the Phaser game bootstrapping and GameScene with:
- A 960 by 540 canvas
- A dark background
- A player represented by a blue circle
- WASD and arrow-key movement
- Movement clamped to the game bounds
- A visible debug-style text label showing the player coordinates
- No enemies, collectibles, menus, audio, or particles yet

Keep the implementation simple and readable.
Run the TypeScript build after making the changes.

A vertical slice means the feature is complete enough to test, not merely started. You’re not asking for all player systems at once. You’re asking for movement, then running the game and checking it yourself.

Test the following:

• Does the player move in all four directions?
• Does diagonal movement become unfairly fast?
• Does the player remain inside the canvas?
• Does movement continue after releasing a key?
• Does the game behave correctly when the browser loses focus?
• Does the game build without TypeScript errors?

Diagonal speed is a classic problem. If horizontal and vertical velocity are both set to 200, diagonal movement becomes approximately 283 pixels per second unless the vector is normalized. You don’t need to calculate that by hand every time, but you should know to look for it. AI-generated code often gets the broad behavior right and misses the mathematical edge case.

If the movement works, commit it:

git add .
git commit -m "Add player movement"

Now add collectibles:

Add the next vertical slice only.

Create a Seed entity as a small glowing green circle. Spawn 10 seeds at random positions inside the play area, keeping them away from the outer 30 pixel boundary.

When the player overlaps a seed:
- Remove the seed
- Increase the score by 1
- Spawn a replacement seed at a valid position
- Update a score label

Keep the score in one clearly named game-state variable.
Do not add enemies or win conditions yet.
Run the build and explain which files changed.

Test whether collectibles disappear exactly once. A frequent AI bug is allowing one overlap event to fire repeatedly for several frames, adding five points from one seed. The fix may involve destroying the object immediately, disabling its body, or guarding the collision callback.

Then add enemies:

Add one enemy type called ShadowMoth.

Requirements:
- Purple circle or polygon generated in code
- Spawn three enemies at positions at least 180 pixels from the player
- Enemies move toward the player
- Enemy speed is 70 pixels per second
- Enemies do not use pathfinding
- Enemy movement should be frame-rate independent
- Colliding with an enemy reduces player health by 1
- Add a short invulnerability window of 750 milliseconds after damage
- Display health in the HUD

Do not add enemy projectiles, enemy animations, or additional enemy types.

The invulnerability window is not decorative. Without it, a single collision can drain all three health points in a few frames. That makes the game feel broken and is one of the reasons small AI-generated games often look more finished than they play.

Use separate commits for each working slice. If a new change damages the project, you can restore the last good version instead of asking the model to untangle a growing mess.

Before moving on, you should be able to launch the game, move, collect seeds, see the score rise, collide with enemies, lose health, and recover during the invulnerability period.

5. Add game rules and state transitions

The exact action is to define the game’s states explicitly instead of letting UI visibility determine whether the game is running.

Ask Opus 5 to add the timer and result states:

Add the game rules to GameScene.

The game starts with:
- score = 0
- health = 3
- timeRemaining = 120
- gameStatus = "playing"

The player wins when score reaches 30.
The player loses when health reaches 0.
The player also loses when the timer reaches 0 before score reaches 30.

Implement:
- A countdown timer that decreases once per second
- A clear win overlay
- A clear lose overlay
- A restart button or R key
- Pausing all player, enemy, and spawn updates after win or lose
- Preventing duplicate win or lose transitions
- Resetting all game state on restart

Use a gameStatus value such as "playing", "won", or "lost". Do not infer game state from whether an overlay is visible.

This is where many prototypes become unreliable. The model may create a gameOver boolean, a hasWon boolean, a timer callback, and a scene shutdown event, all of which can trigger different cleanup behavior. One explicit state value is easier to reason about.

A basic state machine could look like this:

type GameStatus = 'playing' | 'won' | 'lost';

let gameStatus: GameStatus = 'playing';

Every meaningful update should respect that state:

if (gameStatus !== 'playing') {
  return;
}

That check should apply to movement, enemy chasing, spawning, collision effects, and timer handling. Otherwise, the player can continue moving behind the win screen, enemies can keep damaging the player after defeat, or the timer can tick below zero.

Ask Claude to add a small event log while debugging:

For debugging only, log these transitions once:
- game started
- player damaged
- seed collected
- game won
- game lost
- game restarted

Do not log every frame or every enemy position.

This helps you distinguish between a visual bug and a state bug. If the screen says “You Win” but the console shows three additional damage events afterward, the problem is not the overlay. The game loop is still active.

The timer is another place where AI-generated code frequently goes wrong. Phaser’s timed events are usually cleaner than manually subtracting from a value every frame. If the model uses frame delta, check that it divides or converts units correctly. A timer that subtracts delta from seconds instead of milliseconds will finish in less than two seconds.

Test these cases manually:

• Reach 30 points before the timer ends
• Let the timer expire with fewer than 30 points
• Lose all health
• Press R after winning
• Press R after losing
• Try to trigger both win and lose in the same frame
• Click restart repeatedly
• Switch browser tabs during play

Before moving on, the game should have one and only one active state at a time.

6. Use Opus 5 for feel, not just features

The exact action is to ask for one measurable gameplay adjustment at a time, then play the game yourself after every change.

This is the part generic AI tutorials skip. They show a character moving and call the game finished. But movement is not game feel. Game feel comes from timing, feedback, anticipation, recovery, sound, camera response, and the relationship between action and consequence.

Do not tell Opus 5:

Make the game feel better.

That prompt is too vague. It encourages a pile of unrelated changes.

Use prompts like:

Improve player movement without changing the game rules.

Change only:
- Acceleration from 0 to full speed over 120 milliseconds
- Deceleration to zero over 160 milliseconds
- Keep the maximum movement speed at 220 pixels per second
- Keep diagonal movement normalized
- Preserve the existing keyboard controls

Do not change enemies, collisions, camera behavior, or HUD.

Or:

Improve damage feedback only.

When the player is damaged:
- Flash the player white for 120 milliseconds
- Apply a subtle screen shake lasting 100 milliseconds
- Keep the existing 750 millisecond invulnerability window
- Do not change damage values or enemy speed
- Make sure the effect cannot create a second game state transition

Or:

Improve seed collection feedback only.

When a seed is collected:
- Scale it from 1 to 1.4 and fade it out over 100 milliseconds before removal
- Add a small floating +1 text that rises 20 pixels and fades out
- Keep score increments exactly once per collision
- Do not add external assets

These prompts work because each one has a target, a boundary, and a way to tell whether the result is correct.

There is a practical reason to use generated geometry first. Art assets create an entirely separate problem: file formats, sprite dimensions, texture atlases, pivot points, animation frames, licenses, and inconsistent visual styles. If the player is represented by a blue circle, you can focus on whether movement and collisions work. Once the loop feels good, replace the circle with a sprite.

Opus 5 is strong at visual and frontend replication, and it can generate SVGs, UI layouts, and code-based effects. That doesn’t mean it has good taste automatically. If you let it invent every visual detail, your game will likely end up with a familiar AI look: neon gradients, rounded panels, particle explosions, and decorative effects that don’t support the game.

Pick a visual constraint. For Night Garden, use three colors:

• Deep navy background
• Green for goals
• Purple for threats

A limited palette gives the model less room to drift and makes the game more coherent.

Before moving on, play the game without reading the code. Ask yourself:

• Can I tell what to collect?
• Can I tell what hurts me?
• Do hits feel fair?
• Is the player fast enough to escape?
• Is the timer creating pressure?
• Is the win condition reachable without luck?

If the game isn’t enjoyable for five minutes, more features will not save it.

7. Add assets only after the core loop works

The exact action is to introduce one asset category at a time, keeping placeholders available so you can revert quickly.

Start with sound. Sound effects are usually a better investment than elaborate art because they improve feedback without forcing you to rewrite collision or layout code. You can use short original files, public-domain effects, or generate simple sounds through the Web Audio API.

Ask Opus 5:

Add lightweight Web Audio API feedback without external audio files.

Create:
- A short high-pitched tone for seed collection
- A low click for player damage
- A two-tone sequence for winning
- A descending tone for losing

Requirements:
- Audio should begin only after the first user interaction
- Avoid autoplay violations
- Add a mute toggle in the upper-right corner
- Store mute state only for the current session
- Do not change gameplay timing

Browser audio restrictions matter. If the model starts audio during page load, it may work in one browser and fail in another. The first keyboard press or click should unlock the audio context.

For visual assets, ask for a clear art direction and a limited asset list:

Replace the player circle with a single 8-frame sprite sheet.

Style:
- Top-down forest spirit
- 32 by 32 pixel frames
- Blue cloak
- White face
- No text
- Transparent background
- Four walking directions, two frames per direction

Do not change the player hitbox, movement speed, collision radius, camera, or HUD.
Keep the existing circle available behind a debug flag.

The last line gives you a fallback. If the sprite’s dimensions are wrong, the game can still run with the debug shape enabled.

Be careful with generated assets. AI can produce something that looks acceptable in a static preview but fails as a game asset. Animation frames may have different proportions. Shadows may change direction. Transparent backgrounds may contain halos. A character may face left in one frame and slightly toward the camera in another.

You don’t need a perfect art pipeline for a personal game. You do need consistency.

If you want to build a small game with collectible creatures, narrative progression, and hundreds of content items, the mechanics may be manageable while the content burden is not. That’s the same reason a technical Voidpet-style clone is feasible at the systems level but much harder to match as a complete product.

Before moving on, confirm that the game remains playable with every new asset. Never let art become a dependency that blocks testing.

8. Test the game like a player, not like a programmer

The exact action is to create a short test checklist and run it after every substantial change.

AI-generated games often fail in boring ways:

• The restart button works only once
• The player can collect a seed through a wall
• Enemy damage triggers every frame
• The score label overlaps the timer
• The game continues running after the win screen
• A refresh loses all progress, even though no save system was promised
• A key remains stuck after the browser loses focus
• The game crashes when the last enemy is destroyed
• The mobile layout is unusable even though mobile was never part of the brief
• The build passes, but the browser throws a runtime error

A test checklist makes these failures visible.

Create docs/test-checklist.md:

# Night Garden test checklist

## Start
- [ ] Game loads without console errors
- [ ] Player appears inside the arena
- [ ] HUD shows score, health, and timer
- [ ] First input starts audio if audio is enabled

## Movement
- [ ] WASD works
- [ ] Arrow keys work
- [ ] Diagonal movement is normalized
- [ ] Player cannot leave the arena
- [ ] Player stops after keys are released

## Collection
- [ ] Seeds are visible
- [ ] One seed gives exactly one point
- [ ] Collected seeds disappear
- [ ] Replacement seeds appear in valid positions

## Enemies
- [ ] Enemies move toward the player
- [ ] Enemy collisions reduce health once
- [ ] Invulnerability works
- [ ] Damage feedback appears
- [ ] Enemies cannot damage after game over

## End states
- [ ] Score 30 triggers win
- [ ] Health 0 triggers lose
- [ ] Timer 0 triggers lose
- [ ] Win and lose cannot both trigger
- [ ] R restarts cleanly
- [ ] Restart resets score, health, timer, enemies, and seeds

## Build
- [ ] npm run build passes
- [ ] Production preview works
- [ ] No fatal browser console errors

Ask Opus 5 to help you add automated tests for pure functions such as spawn validation, score updates, and state transitions. Don’t ask it to pretend that a unit test proves the game feels good. A test can prove that health goes from 3 to 2. It cannot prove that the hit was readable or fair.

A useful testing prompt is:

Inspect the game and identify pure logic that can be tested without launching Phaser.

Add tests for:
- Score increments once per collection event
- Health cannot fall below zero
- Win triggers at score 30
- Lose triggers at health zero
- Timer expiry loses only when the player has not already won
- Restart resets all state to its initial values

Do not add brittle tests that depend on exact rendering coordinates.
Do not change gameplay behavior while adding tests.

This is where an AI coding agent can save substantial time. It can find logic that should be separated from rendering and create a test harness around it. But you still need to inspect the tests. A test that simply repeats the implementation’s own assumption is not useful.

Before moving on, you should have a game that can survive a fresh browser load, a restart, and a production build.

9. Package and publish the first version

The exact action is to make a production build and publish the game somewhere simple before adding more features.

Run:

npm run build
npm run preview

Open the preview URL and test again. The development server can hide issues that appear in the production bundle. Asset paths, case-sensitive filenames, and environment variables are common causes of “works locally” failures.

If everything works, publish with a static host such as GitHub Pages, Netlify, Cloudflare Pages, or Vercel. A browser game with generated graphics does not need a backend. That is one of the main benefits of choosing this project shape.

If you add online scores later, you will need a server, a database, rate limiting, abuse prevention, and a way to validate scores. Don’t bolt those on casually. A browser can send any score value it wants, so an online leaderboard needs server-side validation or it becomes a list of fabricated numbers.

This is another place where small personal projects are different from commercial products. A local game or a static web game can be cheap to run. A live service with accounts, multiplayer, cloud saves, moderation, analytics, and user-generated content is not just the same game with more buttons.

If you’re comparing this to vibecoding a SaaS product, look at the difference between a personal Jira-style board and a full team collaboration platform. The single-user core is achievable. Permissions, integrations, notifications, search, audit logs, and reliability create the real product.

For Night Garden, a practical first release has:

• One arena
• One player
• One enemy type
• One collectible
• One timer
• One win state
• One lose state
• One restart flow
• One published URL

That is enough.

Before moving on, send the link to one person who was not involved in the build. Watch them play without explaining the controls. Their confusion is more valuable than another hour of asking Claude to polish the interface.

10. Decide what Opus 5 should not build

The exact action is to review your next-feature list and delete anything that doesn’t improve the core loop.

Opus 5 can generate a lot of code quickly. That is useful, but it creates a dangerous illusion: because a feature can be implemented in fifteen minutes, it feels cheap. It isn’t cheap if it introduces bugs into six other systems.

Here are features you should delay:

Multiplayer

Real-time multiplayer needs synchronization, authority, prediction, reconnection, latency handling, cheating prevention, and server hosting. A local two-player game on one keyboard is reasonable. An online multiplayer game is a different project.

Procedural generation

A random map is easy to generate and hard to make good. Players need readable paths, fair spawns, meaningful decisions, and difficulty that escalates without becoming chaotic. Let Opus 5 build a fixed arena first.

Inventory and upgrades

An inventory system sounds simple until items affect movement, damage, collision, spawning, UI, saves, and balance. Add one upgrade only after the base game has a reliable rhythm.

Accounts and cloud saves

Authentication brings password resets, session expiration, account deletion, privacy concerns, and security testing. Don’t add accounts to a local arcade game because every paid game seems to have them.

A large story campaign

Dialogue is easy to generate. Memorable writing, pacing, character voice, and coherent worldbuilding are not. Start with a single-screen experience.

A mobile port

Touch input, responsive layouts, safe areas, device performance, browser audio, and app-store packaging create new testing requirements. Make the desktop version good first.

An AI-generated art explosion

More particles and effects do not equal better game design. If the player can’t tell what matters, visual noise hurts you.

The blunt version is this: Opus 5 can help you build a prototype, a hobby game, a game-jam entry, or a focused personal project. It cannot replace taste, playtesting, production discipline, art direction, or the years of problem-solving behind a commercial game.

That doesn’t make it weak. It makes the correct workflow obvious.

Use the model to move faster through implementation. Keep ownership of the decisions that determine whether the game is worth playing.

How much does it cost to make a game with Opus 5?

For a small browser game, the software cost can be close to zero if you already have a computer and use free hosting.

Claude Pro costs $20 per month in the United States and includes Claude Code. That is the most sensible starting point for a small personal game. Max 5x costs $100 per month, and Max 20x costs $200 per month. Those plans buy higher usage capacity, not a magical guarantee that the model will produce a better game.

API usage is separate from the Claude subscription. Anthropic lists Opus 5 at $5 per million input tokens and $25 per million output tokens. A focused prototype can use a modest amount of API spend, but long autonomous sessions with large files, repeated screenshots, tool calls, and high-effort reasoning can cost more than expected.

The biggest cost is usually not tokens. It’s iteration time.

A one-shot demo may appear in 20 minutes. A game that survives real playtesting can take several evenings. Movement tuning, collision fairness, UI clarity, audio timing, asset cleanup, and browser bugs are where the hours go.

Claude’s 1 million token context window helps with large repositories, but you should not treat it as permission to dump every file and every log into every request. Large context can make a session expensive and harder to reason about. Give the model the files related to the current task and keep the project brief concise.

Use lower effort for small changes. Use high or xhigh effort when the problem genuinely requires architectural reasoning. If you use maximum effort for every color change, you’re paying for thinking you don’t need.

Can Opus 5 make a 3D game?

Yes, but you should start with 2D unless you already understand 3D game concepts.

Opus 5 can generate Three.js scenes, Phaser 3 games, Godot projects, Unity scripts, shaders, camera controllers, and basic 3D interactions. It can also work with tools that expose an editor or scene system. The problem is not whether it can write a 3D player controller. The problem is that 3D multiplies the number of things that can be subtly wrong.

You now have camera orientation, coordinate systems, acceleration, gravity, collision shapes, slopes, animation state, lighting, materials, occlusion, level scale, navigation, and performance. A prototype can look impressive while the camera clips through walls and the player gets trapped in geometry.

A good progression is:

1. Make the complete 2D loop
2. Rebuild one mechanic in 3D
3. Test the 3D mechanic in a small room
4. Add one visual asset
5. Add one enemy
6. Add one level
7. Stop and evaluate

Do not ask Opus 5 to make “a full 3D open-world action game” unless your goal is to watch it generate an impressive but disposable demo.

Is Claude Code better than using Claude in the browser for game development?

For a real project, yes.

The browser interface is useful for brainstorming, writing the game brief, reviewing code, and asking conceptual questions. Claude Code is better when the model needs to inspect files, edit multiple files, run commands, read build errors, and repeat a development loop.

That difference is the entire point of an agentic coding tool. You don’t have to paste GameScene.ts into a chat, copy the response back, then explain what the compiler said. Claude Code can work inside the repository and respond to the actual project state.

But don’t give it unlimited autonomy by default. Start with permissions that let it inspect and edit the project. Review commands that install packages, delete files, modify deployment settings, or touch credentials.

Game repositories often contain assets and configuration files that are difficult to inspect at a glance. Keep secrets outside the repository, add .env files to .gitignore, and never paste an API key into a prompt.

If you’re building a tool that wraps several APIs, the same discipline becomes even more important. A personal Orshot-style image rendering tool is possible, but asynchronous rendering, file handling, format conversion, and API credentials quickly become more important than the initial interface.

What should you prompt Opus 5 when it gets stuck?

Give it the smallest reproducible problem.

Bad prompt:

The game is broken. Fix everything.

Better prompt:

When the player overlaps a seed, the score sometimes increases twice.

Reproduce the issue by inspecting the collision callback and score update path.
Trace all places that can increment score.
Make the smallest fix that guarantees one score increment per seed.
Do not change movement, spawning, HUD layout, or win conditions.
After the fix, add a regression test or a short explanation of why the collision can fire repeatedly.

Include:

• The exact observed behavior
• The expected behavior
• How to reproduce it
• The relevant file or system
• What must not change
• What success looks like

If the model keeps making random edits, stop the session and ask for diagnosis only:

Do not edit files.

Inspect the current code and explain the three most likely causes of duplicate score increments. Rank them by probability and identify the exact functions involved.

This is often faster than letting the agent guess.

You can also ask Opus 5 to create a minimal reproduction in a separate file. That is useful for physics, timers, and collision bugs. A small isolated test can reveal whether the issue is in Phaser’s collision configuration or in your own state logic.

The goal is not to make the model talk more. The goal is to reduce the number of possible causes.

What game can a beginner make with Opus 5?

A beginner should choose a game with one primary action and a short session.

Good choices include:

• Breakout
• Snake
• Top-down survival
• One-screen platformer
• Clicker with upgrades
• Match-three prototype
• Endless runner
• Simple tower defense
• Turn-based grid puzzle
• Memory card game
• Local two-player arena game

Avoid starting with:

• An MMO
• A social game with accounts
• A physics sandbox
• An online card game with trading
• A full RPG
• A competitive shooter
• A procedurally generated open world
• A game that depends on dozens of custom animations

The best beginner project has a clear success condition and can be tested in under ten minutes. If you need a wiki to understand what the player is supposed to do, the scope is already too large.

Can Opus 5 replace a game developer?

No. It can replace some repetitive implementation work.

You still need to make decisions about game design, scope, feedback, art direction, difficulty, level structure, and what “good” feels like. You also need enough technical understanding to recognize a dangerous shortcut.

The people who benefit most from Opus 5 are not necessarily people who know nothing about development. They’re people who can describe a desired result, inspect what was produced, test it, and correct the model when the result is wrong.

That could be a programmer. It could be a designer with technical patience. It could be a hobbyist who learns just enough JavaScript to understand game state and collisions.

The least effective workflow is accepting every generated change because the code looks confident.

FAQ

Can Claude Opus 5 really make a complete game?

It can make a complete small game, especially a browser game with a limited number of mechanics. A finished arcade game, puzzle game, or simple survival game is a realistic target. A commercial-scale game with deep content, polished art, multiplayer infrastructure, and years of balancing is not.

The important distinction is between a playable game and a production-ready product. Opus 5 can help you reach playable quickly. It cannot automatically supply the testing, content, art direction, game feel, and long-term maintenance required for a serious commercial release.

Do I need to know how to code to use Opus 5 for game development?

You can start without professional programming experience, but you should learn basic concepts as you go. Variables, functions, arrays, objects, events, collision callbacks, timers, and state machines are enough to understand most small projects.

If you refuse to read errors or inspect changes, you’ll get stuck quickly. The model can explain code, but you still need to tell the difference between a real fix and a change that merely hides the symptom.

Is Opus 5 better than Sonnet 5 for making games?

Opus 5 is the better choice for architecture, difficult debugging, multi-file changes, and long-running tasks. Sonnet 5 is usually the better value for repetitive implementation and quick iterations.

You don’t need Opus 5 for every request. Use it when the problem involves several interacting systems, such as collision bugs that affect health, invulnerability, animations, and game state. Use a faster or cheaper model for simple text changes, CSS adjustments, or adding a label.

The best workflow is not “always use the biggest model.” It’s using the expensive model when the cost of a bad decision is higher than the token cost.

How long does it take to make a game with Opus 5?

A tiny game can be playable in one afternoon. A polished small game may take several days or a few weeks, depending on your art, audio, platform, and testing requirements.

The first version is usually fast. The second version takes longer because you discover bugs and weak design decisions. The third version is where you decide whether the project is worth finishing.

Treat claims about making a full game in minutes carefully. A generated demo may have a working loop, but that doesn’t prove it has robust restart behavior, fair collisions, stable performance, or enough content to hold attention.

Should I use Phaser, Godot, Unity, or Three.js?

Use Phaser for a fast browser game, Godot for a small downloadable 2D or 3D game, Unity if you already know its ecosystem, and Three.js for a web-native 3D experience.

For a first AI-assisted project, Phaser is the easiest path to a playable result. It has less editor overhead than Unity and fewer deployment complications than a native engine. Godot is an excellent second choice, especially if you want desktop builds or a more traditional scene editor.

Don’t choose an engine because Opus 5 says it is the “best.” Choose based on where you want the game to run and what kind of project you can realistically maintain.

Can Opus 5 create the art and music too?

It can create code-generated visuals, SVG assets, placeholder art, shader effects, and some audio logic. It can also help you write prompts for image and music tools. That doesn’t guarantee consistent character design, animation quality, licensing clarity, or a coherent visual identity.

For a first game, use geometric shapes or a deliberately limited style. Replace placeholders only after the mechanics work. A beautiful broken game is still broken.

How do I stop Opus 5 from adding too many features?

Keep a written out-of-scope list and repeat it in prompts. Ask for one vertical slice or one change at a time. Tell it to inspect the brief before editing. Make a Git commit after every working feature.

If the model suggests a large new system, ask it to explain the cost and risks without implementing it. You’re allowed to say no. In fact, saying no is one of the main skills that makes AI-assisted development effective.

Is Claude Pro enough to make a game with Opus 5?

For a small personal project, Claude Pro is a sensible starting point. It costs $20 per month in the United States and includes Claude Code access, subject to plan usage limits. Max plans provide higher capacity for people running longer or more frequent sessions.

Your plan does not remove the need for API costs if you separately call the Claude API. It also does not guarantee unlimited usage. If your project is small, start with Pro and upgrade only when you can identify a real capacity problem.

Can I sell a game made with Opus 5?

You can generally sell software you create with AI assistance, but you are responsible for the code, assets, licenses, trademarks, privacy requirements, and platform rules. Check the terms of every asset or external service you use.

Don’t copy a recognizable commercial game’s characters, logos, maps, or protected assets and assume changing the color makes it original. Ask Opus 5 to help create a distinct game brief and art direction instead of requesting a direct clone.

The safest commercial path is to use original mechanics, original names, original art, and properly licensed tools and assets.

What is the biggest mistake people make when using Opus 5 for games?

They confuse fast code generation with fast game development.

The model can generate a player controller quickly. It cannot decide whether the jump feels satisfying, whether an enemy is fair, whether the UI is readable, or whether the player understands the objective. Those answers come from playing the game and observing other people play it.

Start small, test constantly, and delete features aggressively. That workflow beats a giant prompt every time.

Should I let Opus 5 build the whole game in one prompt?

No. Use one prompt for the plan, then implement the game in small vertical slices. A single giant prompt may produce an impressive first draft, but debugging becomes harder because too many systems change at once.

Build movement, test it, commit it. Build collection, test it, commit it. Build enemies, test them, commit them. This gives you control over the project and makes failures reversible.

The model is powerful enough to make large changes. That doesn’t mean large changes are the right choice.

What should I build after Night Garden?

Add one feature that improves the existing loop. A second enemy pattern, a riskier collectible, a temporary speed boost, or a second arena can all work. Add them one at a time.

Avoid turning the project into a platform before you’ve proved the game is fun. If players enjoy the first five minutes, then add progression. If they don’t, more systems will only make the disappointment more expensive.

The best use of Opus 5 is not asking it to build the biggest game it can imagine. It’s using it to finish the smallest game you can actually play, test, and improve.

Last updated: August 2026