How to Make a Browser Game with AI

A browser game is a good project for building with AI because you judge the result by playing it. It also exposes problems a static page hides: late controls, a board that overflows a phone, or a leaderboard that accepts any number sent to it.

This guide shows how to make a browser game with AI in Layerwise, from choosing a scope to sharing a link people can play.

1. Pick a scope you can finishCopy Anchor Link

A 2D puzzle has little state, usually a board and a score, so you can check its rules one move at a time. A 3D game adds a camera, movement, collisions, lighting, and frame rate, and some failures appear only after minutes of play.

For a first game, choose a 2D loop. For a 3D game, start from a template so the scene and controls already work. Then write down:

• Core loop: what the player does every few seconds.
• Win and lose rules: how a round ends.
• Input: keyboard, mouse, touch, or a combination.
• Scoring: what earns points and whether scores are saved.

2. Start from a game template or a promptCopy Anchor Link

The game templates give you a playable starting point:

• 2048 puzzle game template: a 2D tile game with keyboard and swipe controls, sound effects, and a Top 100 leaderboard for signed-in players.
• Kart Royale 3D racing template: a Three.js kart racer with drifting, mini-turbo boosts, items, and AI rivals.
• Doodle Shooter wave shooter template: a notebook-style city with enemy waves, four weapons, and a grappling hook.
• Sundown Showdown arena brawler template: four fighters and gas that closes in during a match.
• Inkwave turf-war shooter template: 4v4 matches, ink swimming, and weapon loadouts.

Each template page explains how to copy it with Use this template and make a first change. This guide covers the rest: rules, testing, scores, and publishing.

To start from scratch, install Layerwise, sign in, select a team, and enter your prompt in Describe the app you want to build..., as in the Quick start. Every project includes a database and email sign-in; your game's rules, screens, and score storage still need to be built.

3. Write the core loop and rules into the promptCopy Anchor Link

"Make a fun puzzle game" leaves the agent to invent the rules and gives you nothing to check. State the loop, the input, how a round ends, and what to leave out:

Build a single-player browser puzzle game on a 6x6 grid of gems in four
colors. The player selects a gem, then an adjacent gem, to swap them. A swap
is allowed only if it lines up three or more matching gems in a row or column.
Matched gems clear, score 10 points each, and the gems above fall to fill the
gap. A round has 20 moves and ends with the final score and a Play again
button. Support mouse, touch, and arrow keys with Enter. No sign-in yet.

Play a round and check each sentence: is an invalid swap rejected, and do chained matches score correctly? Quote any wrong rule in your next message.

For larger changes, use Plan mode to review the approach first. See the prompting guide and Direct the agent.

4. Change one mechanic at a timeCopy Anchor Link

Game systems depend on each other. Change speed, drifting, and items together, and you will not know which one made the race worse. Ask for one mechanic and list what must stay the same:

Add a Time Trial mode the player can choose before a race: three laps with no
AI rivals or items. Show the current and best lap times during the race and
all three lap times at the finish. Keep the existing race mode, kart handling,
drifting, and boosts unchanged.

The agent can check its work in the preview by clicking, typing, and reading console errors. It cannot tell you whether a drift feels too loose, so play the change yourself. Describe what you observe: "the kart slides off the track after every drift" is more useful than "handling feels off."

5. Test controls, phone layout, and performanceCopy Anchor Link

Check that arrow keys move the game rather than scroll the page, and that each click or tap lands on the intended target.

The preview's phone width shows whether the board and buttons fit, but a mouse cannot tell you how a swipe feels. Test touch on a real phone after publishing.

For a 3D game, play through the busiest moment, such as a late enemy wave or a full 4v4 match, on the slowest device you plan to support. Then ask for a specific fix:

Later enemy waves drop frames on my laptop. Add a Performance option to the
menu that lowers the render resolution and limits how many enemies can be
active at once. Keep the current graphics and enemy count as the default.

If the preview shows a blank scene, open its console from Project actions and include the error in your next message. See Build and preview.

6. Add a leaderboard with sign-in and server-side checksCopy Anchor Link

The 2048 template shows a basic leaderboard structure:

• At game over or a win, a signed-in player sees Submit to Top 100; a signed-out player sees Sign in to submit.
• A server function reads the player's session, so a request without a signed-in account is not saved.
• The server rejects anything but a whole number from zero to a fixed maximum, then saves the score with the player's account in the project database.
• The Top 100 page reads the highest saved scores, and each player can see their own score history.

These checks confirm who submitted a score and that it is in range, not that the player earned it: the browser reports the final number. For a competition, ask for more:

Make Top 100 scores harder to fake. Have the server issue a random seed when a
game starts and use it for new tiles. Send the recorded moves with the score,
replay the game on the server, and save the score only if the replay matches.
Keep a game in progress working after a refresh, and explain rejected scores.

Each submitted game is saved separately, so one player can appear in the Top 100 more than once. Decide whether you want that.

To test, finish a game with two accounts in the preview and submit both scores. Sign out and confirm the submit button becomes a sign-in link. Then open Database in the project sidebar, choose Local, and check the scores table. The database and authentication guides explain both views.

7. Publish and share the live linkCopy Anchor Link

Choose Publish in the preview header, then Publish in the menu. After the first successful release, the menu shows the live URL. Publishing applies your schema to the production database; it does not copy local scores or test accounts.

At the live URL, create an account and repeat the checks: a full round, a submitted score, and the Top 100 page. Then play on a real phone.

Private in the Publish menu limits the game to your team. It requires a paid plan, and new projects on paid plans start private, so turn it off before sharing publicly. Add UTM parameters to links you post in different places. See Publish a project.

8. Use analytics and logs to see what players doCopy Anchor Link

In Analytics, Pages shows how visits split between the game and the Top 100, Technology shows whether players use phones, and Sources shows referrers and UTM values.

Visit duration counts single-page visits as zero seconds, so a one-page game can show short visits and a high bounce rate even when people play for a long time. To count rounds played, save them in the project database.

When a player reports a missing score, open Logs, choose Online, and filter Status to 4xx or 5xx, or search for the score submission. Several rejected submissions after a release may point to a bug in your checks rather than cheating. See Analytics and Logs.

Start with one loop you can finish, test it with real inputs, and add scores once a round works.