Five browser games, and what each one is for
Games · 2026-08-10 · 9 min read · 2004 words
By ESPYCRUX, Studio
We did not plan a genre spread. We built five games one at a time, and only afterwards noticed what they had become: not a difficulty ladder, but five different questions about what a player is good at. Here is what a small catalogue has to get right, and what we got wrong on the way.
There is a particular kind of browser game site that everyone has landed on. A grid of two hundred thumbnails, most of them the same three games under different names, wrapped in interstitials and a download prompt. It exists because embedding other people's games is nearly free, and because volume is the only strategy available to someone who did not make any of them.
We went the other way. Five games, all written here, no licensed feeds and no embedded third-party titles. That is a lot fewer than two hundred. But it changes what the site has to be good at, and it makes a few decisions for you — mostly by removing the option of hiding a weak game in a crowd.
The spread was not a plan
It would be tidy to claim we mapped the genre space and filled the gaps deliberately. We did not. We built one game, then another, then another, and the spread is what emerged.
Looking at it afterwards:
| Game | Genre | What it asks of you |
|---|---|---|
| Neon Dodge | Arcade · Endless · Casual | Steadiness. One input, held under pressure |
| Neon Rush | Arcade · Endless · Reaction | Speed, and matching under time pressure |
| Roach Survivor | Arcade · Survivor · Stealth | Patience and positioning, not reflex |
| Ludo Party | Board · Party · Multiplayer | Reading other people, and living with luck |
| Word Clash | Word · Multiplayer · Competitive | Vocabulary, under a clock |
The interesting thing is the right-hand column, and it is not a thing we designed. Each game turns out to test a different skill — and that is a more useful way to think about a small catalogue than difficulty.
Not a difficulty ladder
The obvious way to read those five is as a ramp: an easy one, a hard one, a very hard one. That is how most small catalogues are described, and it is wrong here.
People sometimes assume Neon Dodge is the gentle version of Neon Rush because it is tagged casual. In practice, which of the two is harder depends entirely on the player. Someone with fast hands finds Rush obvious and struggles to hold a steady line in Dodge. Someone patient and precise finds the opposite. There is no ordering that holds across people.
The same is true across the whole set. Roach Survivor is not "harder than" Word Clash — it is a different question. A player who is excellent at one may be hopeless at the other, and neither result says anything about the games.
So we stopped thinking about which game is the strongest. No game in the set is weaker than another; each targets specific skills. A catalogue of five is not a ranking, it is a spread of questions, and the aim is that most visitors find at least one they are unexpectedly good at.
That reframing changes practical decisions. It means you do not tune every game toward the same median difficulty. It means "which is our best game?" is the wrong question, and "which player have we not got a game for?" is the right one.
Five games is a portfolio, not a catalogue
With two hundred titles, discovery is the product. Nobody plays them all; they filter, and your job is search, tags and recommendation.
With five, every visitor sees every game. There is no filtering problem. The problem is coverage — five games that all reward the same reflex is really one game with four reskins, and a visitor who bounces off the first will bounce off all of them.
That is why the accidental spread turned out to matter more than any individual title. Four distinct kinds of ability across five games is the actual asset.
What a browser game must do in the first ten seconds
A player arriving at a browser game has spent nothing and committed to nothing. There is no install, no purchase, no download bar to create sunk cost. The tab is one gesture from being closed.
That gives you a brutally short window, and rules out most of what console and mobile games do with their opening minutes. No studio splash. No account wall. No tutorial level. No "choose your difficulty" before the player knows what the game is.
Neon Rush's description is one sentence:
Match your shield to the neon colour-gates, dodge the walls, and chain matches for a rush combo.
That sentence states the verb (match), the obstacle (walls), and the reward (combo). A player who reads it knows what they are about to do. Most games in this category open with something like "an addictive endless arcade experience", which tells you nothing, and then the player learns the rules by dying.
The rule we ended up with: the description should let someone decide whether they want to play, and the first ten seconds should teach the controls without saying anything. If a browser game needs a tutorial screen, it is probably too complicated for the context.
We also stopped trying to design for a target session length. We had assumed we were building ninety-second games. In practice how long someone plays depends entirely on the player and the game — some people take one run at Neon Rush and leave, some sit with Word Clash for half an hour. Designing to an imagined average would have made every game worse for both.
The catalogue has to be a place, not a list
The failure mode of a small games site is that it feels like a folder. Five links, a title, done. Nothing to come back to.
The features around the games are what turn it into somewhere you return: a leaderboard, your own stats, a library of what you have played, friends, clans. None of those are games. All of them are reasons to open the site when you are not in the mood for any specific one.
We built all of that after the games, not before — deliberately, to sharpen the competition once there was something worth competing at. That order matters more than it sounds. Social systems amplify a game people already want to play; they cannot create that want. A leaderboard attached to a game nobody enjoys is just a list of strangers.
The feature that changes behaviour most is resume: landing on the site and being offered the thing you were doing last time, rather than a grid you have to re-navigate. It removes the small decision that makes people close the tab, and it is worth more than a sixth game.
Themes matter more than they look, too. Four options — Crux Red, Neon Cyan, Midnight Violet and a light mode — is not a big feature, but a games hub that only exists in dark mode is unusable in some rooms, and letting someone pick a colour is a cheap way of making a site feel like theirs.
What we would do differently
Accept that the first game is tuition.
Neon Dodge came first. Building it taught us how input should feel, how to structure a loop, how scoring should read, what breaks under pressure. All of that is genuinely useful and none of it is game design — by the second title you are making decisions about play rather than plumbing.
That is not the same as the first game being the worst. Dodge is not the weakest of the five; it asks for steadiness, and there are players who prefer it to everything else we have made. But it cost the most to build per unit of game, because most of that cost was learning.
Decide what "finished" means before starting.
An endless arcade game has no end state, which means it has no natural point at which you stop working on it. There is always one more tweak to the difficulty curve. Without a definition of done, a game can absorb unbounded time and still not ship — and shipping four adequate games teaches you more than perfecting one.
Pick your platform on purpose.
Ours are built for a keyboard and a larger screen. That was not a considered strategic decision so much as the shape the first game took, and everything after inherited it. Making them play properly on a phone is real work still ahead of us, and it is harder than "make the layout responsive" — a game built around a held key does not become a touch game by resizing.
If we were starting again we would decide that on day one, because it propagates into every control scheme you design afterwards.
Be honest in public about what is not done.
iCourier is on the site, named, marked in development, with no play link. It is a delivery game — get from one place to another, reading the terrain and the weather and turning them to your advantage rather than fighting them. It is not finished, so there is nothing to click.
The alternative — hiding it until launch — means nobody knows it is coming. The other alternative, linking to something half-built, means someone clicks and gets a broken page. A visible roadmap with nothing clickable behind it is the honest middle, and we apply the same rule across the studio: a roadmap you can see is more useful than a roadmap you cannot.
What five games cannot do
A small catalogue is fragile in a way a large one is not. If a visitor dislikes both arcade titles and does not play word games, there is nothing else — whereas a site with two hundred always has something. The only real answer is that each of the five has to be worth the visit on its own, which is a far higher bar per title than volume ever sets.
A small catalogue also grows slowly. A sixth game is months, not an afternoon of embedding. That is the actual cost of building your own, and it is worth stating plainly rather than pretending originality is free.
The five are training for something bigger
There is a reason we are building short games rather than one long one, and it is not that short games are the ambition.
We want to build something substantially more advanced. We are not ready to, and the honest way to get ready is to ship small complete things first — games short enough to finish, and competitive enough that people actually play them and tell us where they fail. Five finished games teach you more than one unfinished ambitious one, and they teach it in public, against real players, rather than in a private branch.
So the catalogue is a portfolio in two senses. It is a spread of skills for the player, and it is a spread of problems for us: an endless loop, a turn-based multiplayer game, a stealth system, a word engine with a clock. Each one added something we did not have before.
[APPROVE] This paragraph discloses a future plan. It is a good story and it explains why the catalogue looks the way it does — but say the word and I will cut it.Why build them at all
Partly ownership. A portal that iframes other people's games owns none of what it shows — not the code, not the rights, not the ability to fix anything. If a feed goes away, so does the site.
Partly that it is the only version worth doing. A grid of embedded games is not a product anyone made; it is an aggregation anyone could assemble in a weekend, competing only on volume and ad density.
Mostly, though, because building a game teaches you things about interface work that building an interface does not. A game is an unforgiving, continuous, real-time surface where sixteen milliseconds is a visible defect. After that, ordinary web performance work looks a great deal more tractable.
ESPYCRUX Games is at game.espycrux.com. Five titles, playable in the browser on desktop, nothing to install.
Tags: game design, browser games
ESPYCRUX — ESPYCRUX is a small product studio based in India, building focused web applications and writing about the engineering behind them. Articles are written by whoever did the work, and published under the studio name. Reach the studio at admin@espycrux.com.