How to make a mobile game with AI in the browser

Start with a browser game that has touch controls and a canvas that fits the phone. That way one codebase reaches desktop and mobile players, and you can still wrap it in an app later.

The details here are from September 2026, and many of them link to MDN, where you can recheck them later.

Should you build a browser game or a store app?

Build the browser game first, since web.dev describes a progressive web app as a web app that reaches any user on any device with a single codebase (web.dev). You can always add a store app later.

Route	What you ship	What you need
Web game	A URL that opens in the phone’s browser	Web hosting
Installable web app	The same game plus a web app manifest	HTTPS and a manifest
Store app	The web game inside a native shell such as Capacitor	A store account and the store’s review

For an installable web app, Chromium-based browsers need a manifest with a name, 192 px and 512 px icons, a start URL and a display mode, served over HTTPS. You don’t even need a service worker (MDN).

Capacitor describes itself as a cross-platform native runtime for building iOS and Android apps with web tooling (Capacitor). If you only need Google Play, a Trusted Web Activity opens your web app full screen inside an Android app, and Chrome’s docs point to the Bubblewrap CLI to build one (Chrome docs).

The App Store is a little stricter. Apple’s App Review Guidelines ask for features, content and UI beyond a repackaged website (guideline 4.2), so plan on more than a wrapper there (Apple).

A touch-first game starts with reachable controls

Our mobile games list includes every game whose entry records mobile support, and “list mobile” only means the platforms include mobile. The label says where a game runs, and the examples further down show how players control them.

The counts are current as of November 14, 2026. Puzzle games list mobile more often than the catalog as a whole, and roguelikes less often, with the counts overlapping because a game can carry up to three genres.

Genre	Games	List mobile
Action	227	119 (52%)
Adventure	67	37 (55%)
Arcade	94	45 (48%)
Casual	50	21 (42%)
Puzzle	77	46 (60%)
Racing	41	22 (54%)
Roguelike	43	14 (33%)
RPG	27	16 (59%)
Shooter	115	60 (52%)
Simulation	109	47 (43%)
Strategy	100	48 (48%)
All games	588	293 (50%)

It turns out mobile games are also more likely to have online multiplayer.

Some entries describe how they handle phones. Block Yard was built mobile first, so it’s designed around touch, and Cannon Clash was made simple and fast to play on mobile, with touch screens in mind.

Rainy Day Sort is designed for touch screens too, and its creator made it as an answer to mobile puzzle games crowded with ads.

Ophidian, a Snake game, adds on-screen arrow keys for phones and tablets. Survive Coders gives each voice-command power both a keyboard key and a touch target on phones.

Phones can even be controllers. Ombres runs on a shared screen while players scan a QR code and steer from their phones, so nobody needs a gamepad.

Use pointer events for touch controls

Ask for pointer events, not mouse events, because MDN says pointer events give you a single event model for a mouse, a pen or touch, including several fingers. Each finger gets its own pointerId, and isPrimary marks the first touch, so a twin-stick layout can tell two thumbs apart (MDN).

You’ll also want to stop the browser from grabbing the gesture. It handles panning and pinching by default, and a page that uses pointer events gets a pointercancel event when it does. Setting touch-action: none on the game canvas turns off the browser’s panning and zooming there (MDN).

But leave page zoom alone. MDN warns that user-scalable=no stops people with low vision from reading a page, and it says WCAG requires at least 2x scaling (MDN). That’s why touch-action goes on the canvas only.

Size buttons for thumbs, too, which really matters on a small screen. For an on-screen game button, go with the larger target (W3C, W3C).

WCAG 2.2 level	Target size
AA minimum	24 by 24 CSS pixels
AAA	44 by 44 CSS pixels

Make it fit any phone screen

Start with the viewport tag, where MDN recommends <meta name="viewport" content="width=device-width"> (MDN). Then there are four things to handle.

• Canvas size. In Three.js, renderer.setSize() takes the device pixel ratio into account, and setPixelRatio() sets it (Three.js docs). We’d cap the ratio at 2 to protect the frame rate.

• Scaling. In Phaser, the Scale Manager’s FIT mode adjusts the game to fit its target area while keeping the aspect ratio, and autoCenter centers it (Phaser docs).

• Browser bars. These are tricky, because vh matches the large viewport, so content can end up hidden when the address bar expands, while dvh follows the bars and fits the visible area (MDN).

• Notches. Keep controls inside the safe area with env(safe-area-inset-bottom) and its siblings (MDN).

Orientation needs a decision. Locking it with the Screen Orientation API usually only works on mobile devices in full screen, and MDN marks it as not Baseline (MDN), so design for both orientations or show a rotate hint.

Start sound on a tap and renew the wake lock

Start audio after the first tap. MDN says playback of media with audio is generally blocked when it starts programmatically in a tab with no user interaction, and a Web Audio start() call outside a user input event follows the same rules (MDN). So put a “Tap to start” screen first.

To keep the screen from dimming or locking while your game runs, use the Screen Wake Lock API. MDN lists it as Baseline 2025, and a bit annoyingly, the browser releases the lock when the page is hidden, so request it again when the page becomes visible (MDN).

let lock = null;
const keepAwake = async () => {
  try { lock = await navigator.wakeLock?.request('screen'); } catch { lock = null; }
};
keepAwake();
document.addEventListener('visibilitychange', () => {
  if (lock && document.visibilityState === 'visible') keepAwake();
});

How to test a mobile game

Test on real hardware first, then automate what you can.

1. Play on a real phone. Open your local server or a preview URL from the phone.

2. Inspect an Android phone from your computer. Chrome DevTools remote debugging needs USB debugging on the phone, and Toggle Screencast shows the phone’s screen in DevTools (Chrome docs).

3. Emulate phones in tests. Playwright has a registry of device settings, like iPhone 13, for the user agent, screen size, viewport and touch. isMobile turns on the meta viewport and touch events (Playwright docs).

4. Give the agent a check it can run. Anthropic’s guide says to give Claude something it can run, like tests, a build or a screenshot to compare (Claude Code docs).

Emulation misses real-device quirks, so play the finished game on a phone before you publish.

Ask for touch input, screen fit and a phone test

Here are three prompts, with the parts in brackets for you to change. The first one sets up touch controls.

Make this game playable on a phone. Use pointer events, not mouse events. Drag anywhere on the left half of the screen to move and tap the right half to act. Set touch-action: none on the canvas only. Make every on-screen button at least [44] by [44] CSS pixels and keep controls inside the safe area.

The second handles fit and audio.

Make the canvas fill the screen on any phone in portrait and landscape. Use dvh units, handle resize and orientation changes, and cap the pixel ratio at [2]. Show a “Tap to start” screen, and create the audio context only after that tap.

And the third writes a phone test.

Write a Playwright test that opens the game with the iPhone 13 device, taps through one full round and takes a screenshot at the end. Run it, fix what fails and show me the screenshot.

Then publish it

Where to publish a browser game covers the portals, their size limits and how to find players. For more prompt templates, see our 10 prompts to copy, and how to make game assets with AI covers small downloads and sprite sizes.

Vibe coding game jam shows how many top entries list mobile, and how to make a game with AI and vibe coding a game cover the basics. Or browse the puzzle and casual hubs, or the Three.js and Phaser hubs.