Build a 3D Game with a Coding Agent

Direct a coding agent to build and publish a playable 3D browser game.

Introduction

30 Second Summary

Playing a game someone else made takes about ten seconds. Making one yourself usually means wrestling with 3D models, file formats and an engine you have never opened before.

In this project, you will point a coding agent at a repo where every 3D object is plain JavaScript it can read and edit. You will describe the game you want in one paragraph and end up with something playable.

What You'll Build

A browser game running on Three.js that you play with your own hands, then send to a friend as a link they open on their phone.

By the end of this project, you'll have:

A playable 3D game in your browser, generated from one paragraph you wrote.
The ability to ask your coding agent for a change, reload the page, and watch the game update.
A public URL on GitHub Pages that loads on your phone and on anyone else's.
Secret Mission: An optional challenge that takes your game further once it is running.

Are there any prerequisites?

You need Node 20 or newer, plus a coding agent that can read files, run shell commands and look at images.

Everything else is free. The repo is open source and the default path needs no accounts, no API keys and no GPU.

Before We Start

Coding agents can write a game loop. What they struggle with is furnishing the world, because 3D models usually arrive as binary files an agent cannot read or edit.

The 404 game recipe repo solves that by storing every 3D object as source code. Before your agent touches any of it, you need the repo on your machine and proof that its checks actually fire.

In this step, get ready to:

Confirm Node.js version 20 or newer is installed on your machine.
Clone the 404 game recipe repo to your Desktop.
Install the dependencies and watch every selftest check pass.

Check your tools are ready

The repo runs its harness on your machine, so two things have to be in place before anything else works.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal and press Enter to open it.
Check which Node.js version you have by running this command:

node --version

✔️ I see v20 or higher

Your Node.js is new enough for the repo's harness. Move on to the Git check.

ⓧ I see a version lower than v20

The repo needs 20 or newer, so upgrade before you go any further.

Open the Node.js downloads page.
Pick a release numbered 20 or higher.
Download the installer for your operating system.
Run the installer and accept its default options.
Close your terminal window, then reopen it.
Confirm the upgrade landed by running this command:

node --version

You should now see v20 or higher printed back.

ⓧ Command not found

Node.js is not on your machine yet. The harness will not run at all without it.

Open the Node.js downloads page.
Pick a release numbered 20 or higher.
Download the installer for your operating system.
Run the installer and accept its default options.
Close your terminal window, then reopen it.
Confirm the install landed by running this command:

node --version

You should now see v20 or higher printed back.

Check that Git is installed by running this command:

git --version

✔️ I see a version number

Both tools are ready, so you can pull the repo down next.

ⓧ Command not found

You need Git to download the repo onto your machine.

Open the Git downloads page.
Download the installer for your operating system.
Run the installer and accept its default options.
Close your terminal window, then reopen it.
Confirm the install landed by running this command:

git --version

You should now see a version number printed back.

Clone the 404 game recipe repo

Move to your Desktop by running this command:

cd ~/Desktop

Download the repo to your Desktop by running this command:

git clone https://github.com/404-Repo/404-game-recipe

Git prints its download progress and hands you back your prompt once the folder is on disk.

Clone didn't finish?

If your terminal says the git command does not exist, go back to the Git check and install it first.

If the download stalls partway, confirm you are online and run the clone command again.

Why did my git clone fail?

Move into the repo and list what came with it by running these commands:

cd 404-game-recipe
ls

You should see GAME.md, 404.md, harness and package.json in the output.

Why assets as code instead of mesh files?

Every 3D object in this repo is a JavaScript module that returns a Three.js group. There are no mesh files and no textures to download.

That means your agent can read an object, change a proportion or a colour, and place it in the scene. A binary mesh gives it none of that.

Install dependencies and run the selftest

Pull down everything the harness needs by running this command:

npm install

This takes a minute or two. npm finishes by printing how many packages it added.

npm install didn't finish?

Deprecation warnings scrolling past in yellow are normal and do not stop the install.

If it stops with an error, confirm you are inside the 404-game-recipe folder before running it again.

My npm install failed, what should I check?

The repo ships a selftest that runs its verifier against assets that are deliberately broken. Before you run it, predict what passing means here: zero problems reported, or the verifier correctly catching every planted fault?

Prove the verifier actually fires by running this command:

npm run selftest

Passing means the verifier caught every planted fault. You should see each check reported as passing and your prompt returned without an error.

A check didn't pass?

Confirm npm install finished cleanly first, because the harness cannot run without its dependencies.

Confirm your Node.js version is 20 or newer, since older versions choke on the harness syntax.

How do I read this selftest failure?

Your machine now runs the repo's own checks, so anything that breaks from here is the game and not your setup. Next up, you'll read the rules that keep your agent honest.

Review the Rules and Start Your Coding Agent

Your selftest passed, which means the repo runs on your machine. Now for the part that decides whether your agent builds a game or a pile of files that will not load.

Every 3D object in this project is a plain JavaScript module that returns a Three.js group. That is what makes the assets readable by an agent, and it is also why the repo has to spell out how they get written.

GAME.md holds those rules. You will read them yourself first, then start your agent inside the project folder so it can read them too.

In this step, get ready to:

Read the rules in GAME.md that decide whether your finished game actually runs.
Start your coding agent inside the 404-game-recipe folder.
Confirm the agent lists your project's files back to you.

Read the rules in GAME.md

A coding agent that has never seen this repo will invent its own way of writing assets. GAME.md is the file that stops it.

Switch back to the terminal you used to run npm run selftest.
Confirm you are still inside the 404-game-recipe folder by listing its contents:

ls

You should see GAME.md, 404.md and the harness folder in the output.

Don't see GAME.md in the list?

Your terminal is in a different folder. Move back into the repo from wherever you cloned it:

cd 404-game-recipe

Still stuck? Help me find my project folder.

Print the rules to your terminal by running this command:

cat GAME.md

Scroll up through the output and find the heading Every object in it comes from 404.
Find the heading Your game must be a folder that works on its own.

The two rules that decide whether your game runs

Every object comes from 404. The agent is not allowed to model an object from a description, or to assemble one out of primitives it invents.

The game has to be a folder that works on its own. Assets live inside the game directory and load with ./assets/thing.js, so the whole folder can be zipped and hosted anywhere.

Start your coding agent in the project folder

Your agent can only follow rules it can see. Starting it anywhere other than 404-game-recipe means it never reads those rules at all.

My agent runs in the terminal

Run your agent's launch command in this same terminal window, without changing folders first.

Whatever folder the terminal is sitting in becomes the folder your agent works in.

My agent runs inside my editor

Open the 404-game-recipe folder as your editor's workspace.
Open your editor's agent panel.

Your agent inherits the workspace folder, so the folder name in the sidebar is your first clue that it is in the right place.

What your agent needs to be able to do

This project needs an agent that can read files, run shell commands and look at images.

The image part matters later. An agent that cannot view a render has no way of telling you the game looks wrong.

Confirm the agent is in the right folder

An agent answering from general knowledge sounds identical to one that has read your files. The way to tell them apart is to ask for something only your folder contains.

Before you send this, decide what you expect. Will the agent name the files in this repo, or describe a generic game project?

Ask the agent to prove where it is by sending this prompt:

List the files and folders in this project. Then read GAME.md and tell me in one sentence where asset files must live inside the game directory.

The reply should name GAME.md, 404.md and the harness folder, and say that assets live inside the game directory.

Agent listing the wrong files?

It started in a different folder, usually whichever one your terminal or editor had open by default.

End the session, move into 404-game-recipe, and start the agent again from there.

Still reading the wrong files? Why is my coding agent looking at the wrong folder?

Your agent knows where it is and what it is allowed to do. Next up, you describe the game you want in one paragraph and watch new asset modules appear in the folder.

Describe Your Game and Let the Agent Build It

Your agent is sitting in the project folder with the GAME.md rules already read. Now it needs to know what to build.

The whole interface is one paragraph of plain English. That paragraph is the only design document your game gets, so what you put in it decides what comes out.

Time to write it, hand it over, and watch the agent turn it into asset modules sitting in your project folder.

In this step, get ready to:

Write a one-paragraph description of the game you want.
Hand your description to the agent and let it build.
Find the new asset modules the agent wrote.

Write your one-paragraph game description

A vague paragraph gives the agent nothing to model, and it will fill the gaps for you. Every object you name is an object it has to generate.

Draft your paragraph in a scratch note first, so you can shape it before the agent starts working.
Name the genre in your first sentence, for example a first person shooter or a top down arcade game.
Say what the player does moment to moment, for example sprint down aisles and shoot targets.
Describe the setting as the objects you want to see in it, for example racking, pallets, totes and a forklift.
Name one thing that has to feel good, for example the weapon or the jump.

Why name the objects?

Every object you name gets written as a JavaScript module that returns a Three.js Group. Nothing is downloaded and nothing is hand-modelled.

Naming five props gives the agent five things to generate and verify. Saying "a cool level" gives it a room of boxes.

Build your prompt by dropping your paragraph into this line:

Read GAME.md in this repo and build me a game about [[GAME_IDEA="your one paragraph game description"]]

Why the prompt starts with GAME.md

That first line points the agent at the rules you read in the last step. Those rules are what stop it inventing geometry out of primitives.

They also tell the agent to fan out sub-agents and run a harsh critic that sends weak work back. Your paragraph decides the game, the rules decide whether it holds up.

Send the description and let the agent work

Switch back to the agent session you started in the project folder.
Paste your prompt in and press **Enter**.
Allow the agent to create files and run shell commands when it asks you for permission.

The agent reads GAME.md and the docs it points to before writing anything. Then candidate asset modules start appearing in its output.

Why it writes more assets than it keeps

For each object the loop makes three independent attempts at the geometry, renders each one from four sides, and picks by looking at the renders.

The published warehouse example wrote 99 candidate modules and kept 33. The ones it throws away are the reason the survivors look right.

Agent stalled or assets coming out wrong?

Your agent has to be able to look at images. If it cannot open the renders, it has no way to tell a good asset from a broken one and the quality falls off fast.

Check it is still working rather than sitting on a permission prompt you scrolled past.

My coding agent stopped partway through building the game, what should I check?

Find the modules the agent wrote

The agent picks its own layout, so the folder name is its decision rather than yours.

Ask your agent which folder it wrote the new asset modules into.
Record the folder it names: the folder your agent named, for example my_assets.

Before you list that folder, how many asset modules do you think the agent kept?

See what actually landed by running this command:

ls [[ASSETS_FOLDER="the folder your agent named, for example my_assets"]]

You should see a list of .js files, roughly one per object in your game.
Open one of those files in your editor.

It is plain JavaScript that assembles an object and returns a Group. There is no mesh file and no texture anywhere in the folder.

Why every asset is a JavaScript file

An agent can change a proportion or a colour by editing lines of source. It cannot do that to a binary mesh.

Assets live in git next to the game, so every change to one is reviewable. A whole prop costs a few kilobytes.

Nothing in that folder?

Ask the agent for the exact path it used. It chooses its own architecture, so the modules may sit a level deeper than you expected.

If the folder genuinely has no modules in it, the agent stopped before the asset pass finished.

Where did my agent put the asset modules it generated?

Your game exists as code now. Next up, you'll serve it and play the first build in your browser.

Play Your First Build in the Browser

Your coding agent has turned one paragraph of description into a pile of JavaScript asset modules. Nobody has looked at any of it yet.

This repo has no build step, so there is nothing to compile. Your game is already a folder of files a browser can read.

The only thing between you and playing it is a server willing to hand those files over. That server ships with the repo.

In this step, get ready to:

Find the folder your coding agent put the game in.
Serve that folder on localhost using the repo's own static server.
Play the first build and see what your paragraph actually turned into.

Find the folder your agent built the game in

GAME.md leaves the project layout entirely to your agent, so the game could be in any folder it picked. The one thing that folder must contain is an index.html file.

Switch back to your coding agent.
Ask it which folder holds your game's index.html file.
Record the folder name it gives you: your game folder name
Open a second terminal tab so your coding agent keeps running in the tab it already has.
Move into the repo and list your game folder by running these commands:

cd ~/Desktop/404-game-recipe
ls [[GAME_DIR="your game folder name"]]

Read the output. You should see index.html listed alongside the asset modules your agent wrote.

Don't see index.html?

Check the folder name matches what your agent told you. A game nested one level deeper needs the full path, like builds/my-game.
If your agent is still working, wait for it to finish writing files before you list the folder again.

Which folder holds my game's index.html?

Serve your game on localhost

Opening index.html straight from your file manager gives you a blank page. ES modules will not import over file://, so the game needs a real server to hand its files over.

The server takes over the terminal tab and holds it until you stop it with Ctrl+C. Leave it running for the rest of this step.

Start the repo's static server by running this command:

node harness/serve.mjs [[GAME_DIR="your game folder name"]]

What does this command do?

harness/serve.mjs is a static server that ships with the repo. It serves the repo on http://localhost:8080.
Passing your game folder mounts its parent as well, so a sibling assets/ folder resolves and a path like ../harness/assetlib.js still reaches this repo.
It prints a second URL under your game: that points straight at your build.

Look at your terminal. You should see one line starting serving and a second line starting your game:.

Got an error instead of two URLs?

Seeing no such directory? The path is resolved from wherever you ran the command, so confirm you are inside 404-game-recipe and the folder name is spelled exactly right.
If port 8080 is already taken by something else, add a port number to the end of the command, such as 9000.

Why won't the server start?

Play your first build

Before you open that URL, make a call. Does this thing run, or does it fall over on the first frame?

Copy the URL printed after your game: in your terminal.
Paste it into your browser's address bar and press Enter.
Click the page once.

Your build starts. Whatever your paragraph described is now running in front of you on Three.js.

Move around using the controls your game shows on screen.
Play for a minute, then pick the one thing you would most want to change.

The view moves as you do. That is your first build, generated from a paragraph, playable in a browser.

Black screen, or stuck on a loading screen?

Look at the terminal tab running the server. Every request the browser makes goes through it, and a file that is not there answers not found.
Open your browser's developer console and look for a 404. A missing module means your agent referenced an asset it never wrote.
If your agent is still mid-run, some modules may not exist yet. Wait for it to finish, then reload the page.

Which asset is failing to load?

Your game runs. Next up, you'll hand your agent that one thing you'd change and watch it land in the build.

Ask Your Agent for a Change and Reload

Your game runs. You played the first build in the browser and the Three.js scene rendered exactly as the agent built it.

First builds are rarely right. Something felt off while you were playing, maybe the speed, the lighting, or an object sitting in the wrong place.

The real test of an agent-built project is whether you can change it. In this step you ask for one change and watch it land in the running game.

In this step, get ready to:

Pick one thing in your game you want changed.
Ask your coding agent to make that change.
Reload the browser and see the change in the running game.

Pick one thing to change

An agent handles one clear instruction far better than a list of five. One change also makes it obvious whether the edit actually worked.

Switch back to the browser tab running your game.
Play for another thirty seconds.
Write down the one thing that bothers you most as a single sentence.

What makes a good change request

The best requests name the thing that is wrong and the thing it should be instead. "The player moves too slowly, make it about twice as fast" gives the agent a target it can hit.

"Make the game more fun" gives it nothing. Vague requests are how you end up with a rebuilt game instead of an edited one.

Send the change request to your agent

Your agent still has the project open and the rules in GAME.md in mind. It needs your change in plain language, plus permission to edit files.

Switch back to the terminal window running your coding agent.
Describe your change by sending this prompt:

In the game, [[CHANGE_REQUEST="what you want changed and what it should be instead"]].
Update only the asset modules that control it, and follow the rules in GAME.md.
Tell me which files you changed when you are done.

What does this prompt do?

The first line names a single change, so the agent edits your game instead of redesigning it.
Pointing it back at GAME.md keeps the edit inside the rules that make the build run.
Asking for the file list gives you something concrete to check.

Approve the file edits when your agent asks for permission.
Wait until the agent reports the files it changed.

The agent names one or two asset modules in the project folder. These are the plain JavaScript files that build the part of the scene you asked about.

Agent rewriting more than you asked for?

Your request named a feeling rather than a value. Send it again with a concrete target, like a speed, a colour, or a size.
The agent lost track of the rules. Ask it to re-read GAME.md before it edits anything else.
You can undo the whole attempt with git checkout . and ask again with a tighter sentence.
My coding agent changed more files than I asked it to, how do I keep it scoped to one edit?

Reload the page and check the change landed

Before you reload, make a call. Do you expect your one change to be there, and do you expect the rest of the game to still play?

Switch back to the browser tab running your game.
Press **Cmd+R** (macOS) or **Ctrl+R** (Windows) to reload the page.
Play the game again and look for the thing you asked to change.

Your game loads with the change applied. Everything else plays exactly as it did before.

Why the reload is the whole point

The agent edited JavaScript modules it could read, and the dev server served them straight back to your browser. No binary asset was exported, imported, or converted anywhere in that loop.

That is what makes the game editable by an agent at all. Assets as code means every change is a text edit it can reason about.

Page looks the same as before?

Your browser served a cached copy. Force a fresh load with **Cmd+Shift+R** (macOS) or **Ctrl+Shift+R** (Windows).
The dev server stopped while the agent was working. Check the terminal tab running it for an error and start it again if it exited.
The agent edited a module the scene never loads. Ask it which file the running scene imports for that object.
My agent says it made the change but I cannot see it in the browser, what should I check?

Your game changes when you ask it to, which means it is genuinely yours to direct. Next up, you'll publish it to a public URL and open it on your phone.

Publish Your Game to GitHub Pages

Your coding agent has built a game and reshaped it to your taste, and so far exactly one machine in the world can play it. Shut the dev server down and the game disappears with it.

The 404 game recipe runs from a served folder with no build step. GitHub Pages serves a folder straight out of a repository, so publishing comes down to getting your folder onto a repository you own.

In this step, get ready to:

Create a repository you own and push your generated game into it.
Switch on GitHub Pages and get a public URL.
Open that URL on your phone and watch the game run.

Create your own repository on GitHub

Your project folder is a clone of someone else's repo, so it still points back at their account. Your game needs somewhere you actually have permission to write.

In the upper-right corner of any GitHub page, click the + dropdown menu.
Click New repository.
Use the Owner dropdown menu to select your own account.
Type my-404-game into the repository name field.
Choose Public for the repository visibility.
Click Create repository.

What is the Quick Setup page?

GitHub drops you onto a Quick Setup page because your new repository has no files in it yet.

It lists the commands for connecting a folder that already exists on your machine. That is exactly the situation you are in.

Record the account name shown at the start of the repository path on that page: your GitHub username.

Name already taken?

Repository names have to be unique within your account, so pick something like my-404-game-2 and use that name everywhere this step says my-404-game.

Stuck on the create form? Why can't I create this repository?

Push your game up to your repository

The asset modules your agent wrote exist on your laptop and nowhere else. Pushing them is what makes them reachable by anything that is not your laptop.

Leave your dev server running and open a second terminal tab with Cmd+T (macOS) or Ctrl+Shift+T (Windows).
Move into your project folder by running this command:

cd ~/Desktop/404-game-recipe

Point the repository at your own account by running this command:

git remote set-url origin https://github.com/[[GITHUB_USERNAME="your GitHub username"]]/my-404-game.git

Confirm the swap landed by running this command:

git remote -v

Both lines now carry your own username instead of 404-Repo. Git will send your work to your account from here on.

Stage and commit everything your coding agent generated by running these commands:

git add .
git commit -m "Add my generated game"

The commit summary line counts the files that just went in. That number is your generated asset modules plus anything else your agent touched.

You may be asked to sign in

The first push to a brand new repository often needs you to prove who you are.

Depending on how your machine is configured, a browser window opens for you to authorise, or the terminal asks for a username and a personal access token. Follow whichever one you get.

Push your game to GitHub by running this command:

git push -u origin main

Return to your repository page on GitHub and refresh it.

The file list fills in, including the folder your coding agent built the game into.

Push rejected?

Rerun git remote -v. If it still shows 404-Repo, the set-url command did not take and the push went to a repository you cannot write to.

Run git branch --show-current to check your branch is called main. A different name means the push target in the command does not exist.

Still blocked? Why is my git push being rejected?

Turn on GitHub Pages and open the public URL

A repository full of files is still just storage. Pages is the switch that puts a served copy of that folder on an address anyone can reach.

Under your repository name, click Settings.
In the "Code, planning, and automation" section of the sidebar, click Pages.
Under "Build and deployment", under "Source", select Deploy from a branch.
Use the branch dropdown menu and select main.
Use the folder dropdown menu and select the repository root.
Click Save.

Why serve the whole repository?

The folder dropdown only offers the repository root or a /docs folder.

Your game sits in its own folder and loads the harness loader from a path above it, like ../harness/assetlib.js. Serving the whole repository keeps that relative path resolving.

Wait a minute, then refresh the Pages settings page.

A banner appears at the top telling you your site is live, followed by your public address. That address ends at the repository root, which is not where your game lives.

Switch back to your coding agent and ask it which folder holds the playable build and where that folder's index.html sits.
Record the folder name your agent gives you: your game folder name.

Before you load the next address, do you expect the game to feel slower over the internet than it did on localhost? Have a guess at why.

Open a new browser tab and go to your game's public address:

https://[[GITHUB_USERNAME="your GitHub username"]].github.io/my-404-game/[[GAME_FOLDER="your game folder name"]]/

Your game loads and plays the same as it did locally. Every object in the scene is JavaScript source, so there are no meshes and no textures waiting to download.

Before you type that address into your phone, what do you think a device with no Node, no repo and no dev server needs in order to run this?

On your phone, open your browser and go to the same address.

The scene loads and renders on a device that has never touched your project. Anyone you send that link to gets exactly the same thing.

Seeing a 404 page?

The first deploy takes a moment. Open the Actions tab of your repository and check the Pages workflow run has finished before you retry.

Compare the folder name in your address against the folder name in the repository file list. Folder names in a URL are case-sensitive.

Still getting nothing? Why is my GitHub Pages URL returning a 404?

Secret mission

Add a Collectible and a Score Counter

Your game runs, but there is nothing in it to chase. In this optional mission, you'll direct your agent to add a collectible object and an on-screen score counter, check it against the repo's own rules, then republish so you can score a point on your phone.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Nothing in this project runs on a paid service, so there are no ongoing costs.

Resources you used:

The 404-game-recipe folder on your Desktop, including the node_modules directory and the asset modules your agent generated.
The local dev server serving your game build.
The coding agent session running in your project folder.
The GitHub Pages deployment hosting your game at its public URL.

Keep everything running

No action needed. Choose this if you're still actively building on your game or you want the public URL live for people to play.

Leave the dev server running so you can keep reloading the game as you change it.
Leave your coding agent session open so it keeps the project context it built up.
Leave your game published so anyone with the URL can play it.

Your node_modules directory stays on disk while the folder exists. It is the largest thing this project leaves on your machine.

Pause - I'll come back to this later

Shut down running processes to free up memory. Your files and your public URL stay exactly where they are.

Press Ctrl+C in the terminal running the dev server to stop it.
Close the terminal window running your coding agent to end the session.
Leave the 404-game-recipe folder on your Desktop so you can restart the dev server whenever you want.

Restarting later

Your dependencies are already installed, so picking this project back up is one command. Move into the folder and start the dev server again.

Delete - I don't want to use this again

Remove every resource this project created. Your game stops being playable both locally and at the public URL.

Press Ctrl+C in the terminal running the dev server to stop it.
Close the terminal window running your coding agent to end the session.
Open your game repository on GitHub.
Click Settings in your repository's top menu bar.
Click Pages in the left sidebar.
Click the three dots button next to the line showing your live site URL.
Click Unpublish site.

Your public URL now returns a not found page. The code in the repository is untouched, so you can publish it again later.

Delete the project folder on macOS or Linux by running these commands:

cd ~/Desktop
rm -rf 404-game-recipe

Delete the project folder on Windows by running these commands in Command Prompt:

cd %USERPROFILE%\Desktop
rmdir /s /q 404-game-recipe

Confirm the folder is gone by opening your Desktop and checking that 404-game-recipe is no longer listed.

Getting a permission or in use error?

A running dev server or an open editor can hold onto files inside the folder. Close both, then run the delete command again.

Still stuck? Why can't I delete my project folder?

Nice Work!

Nice work! You've just built a playable 3D game by directing a coding agent through the 404 game recipe repo, and it now lives on a public URL anyone can open.

You've learned how to:

Set up the 404 game recipe repo and prove your environment is healthy with the repo's selftest checks before an agent touches anything.
Turn one paragraph of description into a working Three.js game, because the GAME.md rules keep the agent inside code it can actually read and fix.
Play your build locally, ask the agent for a change, and publish the result to GitHub Pages as a public URL you own.
Secret Mission: you took on the optional challenge and pushed your game further than the main build.

Ready to quiz yourself?