How We Build a New Browser Game Every Week

Why One Game Per Week?

A browser game is a video game that runs entirely in a web browser using HTML5, JavaScript, and CSS — requiring no downloads, plugins, or installations. The browser gaming market is projected to reach $35.1 billion by 2027, growing at 8.9% CAGR according to Mordor Intelligence.

Most game studios spend months — sometimes years — on a single title. We do the opposite. Weekly Arcade ships one new browser game every 7 days, and we've done it 16 releases straight.

The constraint is the point. A weekly cadence forces us to make sharp decisions: cut scope ruthlessly, focus on one mechanic that feels great, and ship before we overthink it. Research on creative constraints supports this approach: a study published in the Journal of Consumer Research found that scarcity of resources can boost creativity by forcing novel problem-solving. The result is a library of 16+ polished, free browser games spanning 3D racing, card roguelites, and classic arcade.

We took direct inspiration from Ludum Dare, one of the world's largest game jams where over 3,000 developers build entire games in 48–72 hours. Our 7-day window gives us enough room to polish without losing urgency.

Day 1–2: Finding the Right Idea

Every game starts on Monday with the same question: what would be fun to play for 5 minutes on a phone?

We filter ideas through three criteria:

1. Instant appeal — Can someone understand the game in under 10 seconds without a tutorial?
2. One-more-round factor — Does the core loop create natural "just one more try" moments?
3. Mobile-first feasibility — Can this work with touch controls on a 375px-wide screen?

Ideas come from everywhere: classic arcade games we grew up with, trending mechanics on platforms like itch.io, or simply a "what if" question. "What if Tetris built a kingdom?" became Fieldstone. We also track which game categories our players gravitate toward — puzzle and arcade consistently perform well, which is why you'll find games like 2048 and Stack Tower in the library.

By Tuesday evening, we've narrowed to one concept and written a 1-page design brief covering: the core mechanic, target session length, scoring system, and what "fun" means for this specific game.

Day 2–3: Designing the Core Loop

A core loop is the 15–30 second repeating cycle of actions that forms the foundation of gameplay — the pattern a player performs dozens or hundreds of times per session. Game designer Jesse Schell describes it as the "essential experience" in The Art of Game Design (CRC Press, 3rd ed.). Getting this right is the single most important step in our browser game development process.

Here's how core loops differ across three of our games:

We prototype the core loop before anything else — often as a bare-bones version with colored rectangles instead of real art. If the loop isn't fun with placeholder graphics, no amount of polish will save it. We've killed 3 out of 19 total concepts at this stage (a 16% rejection rate) because the loop felt flat, and that's fine. Failing fast on Day 2 is cheaper than failing on Day 6.

Day 3–5: Building the Game

This is where the majority of the code gets written. Our stack is intentionally simple — we want every game to load instantly in any browser without downloads or plugins.

Every game is built as a single-page application using vanilla JavaScript and CSS. No heavy frameworks, no bundlers for the game itself. According to Google's Web Performance research, a 1-second delay in page load reduces conversions by 7%. Our games average under 50KB total — loading in under 1 second on most connections, compared to the 2–5MB typical of framework-heavy web games.

Here's what gets built in this window:

• Game engine — Rendering (Canvas 2D or CSS-based), input handling (touch + keyboard + mouse), and game state management
• Scoring system — Points, combos, multipliers, and leaderboard integration via our Firebase backend
• Sound effects — All synthesized programmatically using the Web Audio API. No audio files to download. Every "ping," "whoosh," and "crash" is generated with oscillators and gain nodes in ~20 lines of code each
• Responsive layout — Mobile-first CSS that works from 320px phones to 2560px ultrawide monitors. According to StatCounter, mobile devices account for 59.4% of global web traffic (2025), making mobile-first development essential for browser games
• Accessibility — Reduced-motion support via the prefers-reduced-motion CSS media query, WCAG 2.1 AA-compliant color contrast (minimum 4.5:1 ratio), and keyboard navigation

One hard lesson we learned: never add a feature on Day 4 that wasn't in the Day 2 brief. Scope creep is the number one killer of weekly releases. When we built Cricket Blitz, we almost added a full tournament mode. We cut it, shipped the core batting/bowling experience, and the game worked great without it.

Day 5–6: Playtesting and Polish

Playtesting is the process of having real users play a game to identify bugs, usability issues, and balance problems before public release. It's where good games become great. We test every game on at least 4 device types before launch:

• iPhone SE — small screen, touch only
• iPad — medium screen, touch
• 13" laptop — keyboard + trackpad
• Desktop with mouse — large screen

Common issues we catch at this stage:

• Touch targets smaller than 44×44px (Apple's Human Interface Guidelines minimum)
• Text too small to read on mobile without zooming
• Animations that cause jank on mid-range phones
• Sound effects where timing feels off
• Score submission edge cases (network timeouts, duplicate submissions)

We've adopted a "juice last" philosophy. Game juice is a game design term coined by Martin Jonasson and Petri Purho in their 2012 GDC talk "Juice It or Lose It" — it refers to screen shake, particle effects, and satisfying sound feedback that make interactions feel responsive. These effects take 10% of development time but create 50% of perceived quality. Coin Cascade is a perfect example — the physics are simple, but the cascade animations and coin-clink sounds make it feel premium.

Day 6–7: Launch Day

Launch day is mostly about integration. The game code is done. Now we:

1. Wire up leaderboards — Connect to our global leaderboard system so scores sync across devices
2. Add achievements — Define 3–5 achievements per game
3. Write the game page — Title, description, tags, Open Graph meta for social sharing
4. Update the homepage — The new game gets the "New This Week" spotlight
5. Run a final smoke test — Play through the full experience on mobile, submit a score, verify the leaderboard

We deploy to Firebase Hosting, Google's global CDN with edge nodes in 150+ locations. Average time-to-interactive: under 1.5 seconds on a 4G connection. Firebase automatically provisions SSL certificates and applies Brotli compression, reducing our game payloads by an additional 15–20%.

Then we update our PWA service worker so returning players get a "New game available!" notification, and move on to next week's idea.

Our Tech Stack

We chose Astro specifically because it ships zero JavaScript by default — an approach the Astro team calls the "Islands Architecture." The game's JS only loads when you open a game page — the homepage, about page, and leaderboards are pure static HTML. This keeps our Lighthouse performance score above 90 across the site.

What We've Learned After 16+ Games

After shipping a new game every week, some patterns have emerged. These are first-party observations from our own analytics:

1. Simplicity wins. Our most-played games (Snake, 2048, Stack Tower) have the simplest mechanics. Games with 1-tap controls see 40% longer average sessions than games requiring multi-gesture input.
2. Sound is underrated. Adding synthesized audio feedback increased average session time by 22% across our game library. The Web Audio API lets us generate effects programmatically — zero loading delays, zero audio file management.
3. Mobile is 70% of traffic. Across all Weekly Arcade games, 70% of sessions originate from mobile devices. Every design decision starts with a phone-sized screen. Desktop is the enhancement, not the default.
4. Leaderboards drive retention. Players who sign in and compete on leaderboards play 3x more sessions than guest players. This aligns with Self-Determination Theory research showing that competence and relatedness are core drivers of intrinsic motivation.
5. Ship, then polish. Our best games got better after launch based on real player behavior, not assumptions. We update games within 48 hours of launch based on actual usage data.

What This Approach Can't Do

A 7-day development cycle has real trade-offs. We're transparent about what our process sacrifices:

• No AAA depth. We can't build a 40-hour RPG or an open-world adventure in a week. Our games are designed for 2–15 minute sessions.
• Limited narrative. Story-driven games require writing, branching dialogue, and pacing that doesn't fit a weekly cadence. Our games are mechanics-first.
• Browser constraints. WebGL and Canvas 2D can't match native GPU performance. Complex particle systems, real-time shadows, and high-poly 3D models remain challenging in a browser.
• No custom art pipeline. We use CSS-drawn visuals and procedural graphics rather than hand-drawn sprites or 3D-modeled assets, which limits visual variety.

These constraints are acceptable for our goal: instant, free, fun games that anyone can play without friction.

What's Next

We're expanding the library toward 30 games by end of 2026, with a focus on:

• Multiplayer modes — Real-time competitive play (Chess 3D and Drift Legends already support this)
• Deeper 3D experiences — Powered by Babylon.js, pushing what's possible in a browser
• Community features — Player profiles, friends lists, and challenge modes
• Themed collections — Curated game bundles like "5-Minute Break" and "Brain Teasers"

Have an idea for a game you'd like to see? Drop us a line at hello@weeklyarcade.games.

Frequently Asked Questions