Build a browser game from an empty repository

A game is the most fun thing to build in small steps, because every step is playable: movement first, then one level, then more levels, a title screen and sound. Each piece arrives as a change with a screenshot, you play it, and you say what to tweak, from an empty repository to a game with a public link.

Example project. Tidepool is a small top-down puzzle game: a crab collects shells on a beach before the wave comes in, across ten short levels, played with arrow keys or a thumb. The project is an illustration written to show the steps.

A game built this way: Claude Cope, a multiplayer terminal game, went from an empty repository to 458 merged pull requests through ProPR.

Pick the stack

These are the standard tools for 2D games in the browser, free to use, with thousands of examples the agents have learned from.

Piece	Pick	Why
Game framework	Phaser	The standard open-source framework for 2D browser games: scenes, sprites, physics, input and sound all built in.
Project tooling	Vite with TypeScript	A fast build with a preview server, so each pull request produces a playable build.
Tests	Vitest	Level rules, scoring and collision maths get tests, so a tweak to one level never breaks another.
Publishing	GitHub Pages, then itch.io	GitHub Pages publishes a public repository free on every merge. itch.io hosts browser games free and gives you a storefront page when you want one.

Verified November 2026: Phaser 4 is the current stable release under the MIT licence; Vite and Vitest are current. GitHub Pages is free for public repositories. itch.io hosts HTML5 games at no charge, played directly in the browser.

Create the repository

On GitHub, create a public repository called tidepool and tick Add README. Public means GitHub Pages hosts it free. In ProPR, open Repositories, choose Add Repository, enter the repository name, and switch on Visual previews with both images and video, so each pull request shows you the new screen and a few seconds of it moving.

Tell the planner what you want

Open Planner Studio, pick the repository, and describe the game as you would to a friend.

Build a 2D browser game called Tidepool with Phaser, Vite and TypeScript. A crab moves on a grid-based beach and must collect all the shells before the wave reaches it. Arrow keys on desktop, swipe or on-screen arrows on phones. Ten short levels defined in simple data files so new levels are easy to add. A title screen, a pause button, a level-complete screen with time taken, and the best time per level saved in the browser. Simple flat colours, big sprites, two sound effects. Publish to GitHub Pages on every merge.

The planner replies with a plan. Ask for changes in the chat: "make the first playable level its own task", "add a task that generates placeholder art so nothing waits on drawings". Approve it, and ProPR files one GitHub issue per task.

Refining a plan in chat: asked to merge payment and review and to ship behind a flag, the assistant changes those steps and leaves the rest alone — Asked to change two steps, the assistant changes those two and keeps the rest.

The plan becomes issues

Each issue has a checklist of what done means. A plan for this game looks like this.

Set up the Phaser project with Vite, a blank scene and GitHub Pages publishingDone when: the project builds, a page shows an empty beach scene at a fixed 16:9 size that scales to the window, and the published link works after merge.
Crab movement with keyboard and touchDone when: the crab moves one grid cell per key press or swipe, cannot leave the beach, and on-screen arrows appear on touch devices. Tests cover the grid maths.
Level one: shells, the wave, win and loseDone when: level one loads from a data file, collecting every shell wins, the wave advances one row every two seconds and touching it loses, and both outcomes show a message with a retry button.
Levels two to tenDone when: nine more level files exist with rising difficulty, a level-select screen shows them, and a test loads every level file and checks it is solvable in principle (a path to every shell exists).
Title screen, pause, level-complete screen and best timesDone when: the game opens on a title screen, pause stops the wave, the complete screen shows the time, and the best time per level survives a page reload.
Sound and placeholder artDone when: picking up a shell and losing to the wave each play a sound, a mute button works, and the crab, shells and wave have clear flat-colour sprites generated in code until real art arrives.

ProPR builds each issue

Start the issues. Each runs in its own clean workspace on its own branch. For the movement issue, the agent writes the grid logic and its tests, wires the keys and touch input, runs the build, and records a short clip of the crab moving. ProPR opens the pull request with the summary, the test results and the clip at the top. Issues that build on one another run in order when you execute the plan as an epic.

The execution trace of a live run in plain language: why the time-zone fix is needed, the new DST test cases, and all 14 checkout tests passing — The live log of a running task: what the agent changed and why.

What you look at in each pull request

The clip and screenshots. Does the crab move the way you pictured? Is the wave scary enough?
The playable build. Merge the first issue and the game has a public link; from then on you play the latest merged version there. For a pull request before merge, the agent's video shows the change moving.
The summary against the checklist. The agent lists what it built and which tests ran.

Feel is a matter of taste. Say what you want in a comment.

@youcommented on the pull request

The crab moves too slowly to feel fun. Make each step about half as long, and let me hold the key to keep moving. Keep the wave speed as it is.

A new commit lands on the same pull request with a new clip, and you merge when you are happy. If a merged level turns out unfair, you revert that pull request from GitHub and the game goes back to the version before it.

How the game grows

New levels are new issues, often one line each: "level eleven: two waves from opposite sides". Real art replaces the placeholders through a pull request you compare side by side with the old look. Hand an open-ended outcome to a goal, such as making the game feel good on a small phone, and follow its checkpoints on the draft pull request. Before a big release, ask a second model to review the whole thing. When you want a storefront, upload the built folder to itch.io.

Good to know

The agent's workspace is a Linux container with Node.js and Python and no screen or speakers. It installs a headless browser with npm to capture screenshots and clips, and it checks the rules with tests. How the game feels in your hands is your call, made on the published build.
GitHub Pages publishes from the repository on every merge; itch.io takes a zip of the built game whenever you want a storefront page.
Sounds and art you own go into the repository through GitHub's upload button, or attach them to the plan or a pull request comment and the agent wires them in.

Start your game.

Everything above happens in a browser. ProPR Hosted gives you your own instance, run by the ProPR team; the live demo lets you click through plans and pull requests first.

Start on Hosted Try the live demo

On your own server, self-host ProPR, free and open source.

All Build something walkthroughs