When Tom and I sat down in January to plan Gerk Games, we had a simple question: what actually makes a browser game good? Not "good for a browser game" with the implied lower standards, but genuinely good — the kind of game someone chooses to play instead of scrolling Instagram.
We had both spent years in and around game portals. I'd reviewed hundreds of HTML5 games during my time at the games vertical. Tom had built dozens of prototypes, some of which shipped, most of which didn't. We'd seen the full spectrum: brilliant indie gems buried under terrible UI, and polished-looking titles that played like someone had never tested them on an actual phone.
So we decided to find out empirically. We committed to building 30 games — not 30 variations on the same template, but 30 genuinely different titles across puzzle, action, arcade, word, and strategy. Each one written from scratch, no game engines, no copied code. The constraint forced us to think about what matters at the most fundamental level.
The plan was straightforward and insane in equal measure: build one game every three days for three months. Sam would design the concept and write the wrapper content; Tom would code the entire thing in vanilla JavaScript on Canvas. No Phaser, no PixiJS, no Unity WebGL exports. Pure JavaScript and the Canvas API.
By game 5, we had a workflow. By game 15, we had opinions. By game 30, we had data. Here's what we learned.
The Three Traits That Matter
After playing through our entire catalog — and watching dozens of friends, family members, and beta testers play them — three traits emerged as the consistent predictors of whether someone would play a game more than once:
1. Instant Comprehension (The 3-Second Rule)
If a player can't figure out what the game is about within three seconds of the first frame loading, they're gone. Not "three seconds of reading the instructions" — three seconds of looking at the screen.
We learned this the hard way with game 7, a tile-matching puzzle that Tom spent four days on. The mechanics were clever: match tiles by color AND pattern, with a cascading combo system that rewarded planning three moves ahead. It was genuinely deep. It was also completely invisible.
Testers opened the game, saw a grid of icons with no obvious affordance, and closed the tab. Average session duration: 4 seconds. We scrapped it and rebuilt the concept as Color Rush — a game where the mechanic is so obvious you understand it before you even touch the controls: colored things are falling, tap the matching color. Zero tutorial required.
The 3-second rule isn't about dumbing things down. It's about making the first interaction so intuitive that the player's brain engages before their conscious mind has time to evaluate whether to stay. Our best-performing games — Snake Arena, Tower Stacker, Color Rush — all pass this test instantly.
2. Escalating Tension (The "One More Try" Loop)
Great browser games create a specific feeling: the conviction that you were so close to beating your score, and the next run will be the one. This isn't randomness — it's engineered.
In Tower Stacker, we tuned the block speed so that the margin between a perfect drop and a fatal miss is consistently about 2-3 pixels. That's tight enough to feel skill-based, but loose enough that players blame themselves rather than the game. When someone loses at 42 blocks, they don't think "this game is unfair" — they think "I blinked."
We also discovered that score milestones matter enormously. In Snake Arena, the snake speeds up at exactly 50-point intervals. We tried making the acceleration gradual — a tiny speed increase per point — and engagement cratered. Players need discrete moments where the game says "things just got harder." The escalation has to be visible and explicit.
The "one more try" loop has three components, and all three need to be present: (1) clear feedback on why you failed, (2) a sense that success is within reach, and (3) instant restart with no loading screen, no menu, no friction. On point 3, we benchmarked: every additional second between "Game Over" and "playing again" costs roughly 8% of retry attempts.
3. Zero Friction Architecture
This is the one that separates browser games from everything else, and it's the hill we'll die on. A browser game that takes more than two seconds to load isn't a browser game — it's a download that happens to run in a tab.
Our entire site — homepage, game grid, CSS, JS — weighs less than 50KB uncompressed. Individual game files average 12KB. There are zero external JavaScript dependencies. The font stack is system fonts. Images are inline SVGs. The heaviest asset on any page is the CSS file, and we've stripped every unused rule.
We test on a throttled 3G connection because that's what millions of people actually have. On that connection, our homepage renders in 1.8 seconds and any individual game loads in under 1.3 seconds. For comparison, the average game portal we benchmarked during research took 6.2 seconds to become interactive on the same connection.
The technical decisions that make this possible aren't glamorous: no frameworks, no build step, no npm, no Webpack config that's longer than the game code. Tom wrote a 40-line Python script that minifies our CSS and HTML. That's our entire build pipeline.
What Didn't Matter
Just as important as what did matter: the things we expected to be critical that turned out to be irrelevant.
Graphics quality. We have games with elaborate sprite animations and games that are literally colored rectangles. The playtime distribution is almost identical. Players care about how a game feels, not how it looks. Responsive controls and satisfying feedback (screen shake, particle bursts, audio pings) matter far more than visual polish.
Game length. We worried that people wouldn't play games without progression systems, levels, or unlockable content. The data says otherwise. Our most-played game is Tower Stacker, which has exactly one screen and one mechanic. It gets replayed because the mechanic is satisfying, not because there's a level 2.
Sound design complexity. Every game uses procedurally generated audio via the Web Audio API — simple oscillator tones, no sample files. Not once has a tester commented on the sound quality. They notice when audio feedback isn't there, but they don't care whether the beep came from a .wav file or a sine wave.
What This Means if You're Building Browser Games
If you're working on an HTML5 game — whether as a solo developer or part of a team — the data from 30 original titles points to a clear set of priorities:
- Make the first interaction obvious without text. If you need a tutorial paragraph, the mechanic isn't visible enough.
- Build explicit difficulty escalations, not gradual ones. Players need to feel when the game gets harder.
- Keep your total page weight under 100KB. If you need a framework, you're probably over-engineering.
- Test on throttled 3G. Your WiFi is lying to you about load times.
- Measure retry rate, not session duration. A game that gets replayed 10 times for 30 seconds each is better than one played once for 5 minutes.
We're still learning. Every new game we build teaches us something about what works and what doesn't. The 3-second rule, escalating tension, and zero friction are our current best model — but we expect it to evolve as we keep building.
If you've built browser games and have data that contradicts (or confirms) any of this, we'd genuinely like to hear from you. Email us at [email protected].