Sixteen browser games without a game engine
Every game on Lynxy is written by hand in plain HTML, CSS and JavaScript. There is no game engine, no framework, no build step - and in most games not a single image or sound file. Sixteen games in, here is what that approach is good for, what it costs, and the small lessons that only show up once real people start playing on real phones.
Why no engine
Game engines are wonderful, and for a big 3D game we would use one. For small games that should open the instant you tap a link, they bring a lot of weight you do not need: a runtime to download, a loading screen, a canvas that does not quite behave like the rest of the page.
Without one, each Lynxy game is a single page. Its code, styles and markup come to somewhere between 50 and 190 KB before compression, depending on the game, plus about 30 KB of shared code for the whole site - the top bar, the cookie banner, the theme switch. That is less than a single photo on many news sites. On a slow connection the game is playable about as fast as the page appears.
It also means the games keep working. There is no server behind them, no account, no database. Your progress lives in your own browser's storage. If Lynxy's server disappeared tomorrow, a game you already had open would carry on.
Drawing everything in code
Most of the games draw their graphics themselves, at the moment they are needed. The bricks in Nova Bricks, the gems in Gem Cascade, the asteroids in Star Prospector and the whole world of Lynx Run are painted on a canvas by JavaScript. Maria and the Missing Coder goes furthest: its characters are stored as little maps of letters, one letter per pixel, each letter a colour from a palette. Maria herself is 14 by 16 such pixels. Her animations are the same picture with a few rows swapped, and Maria glowing from an energy drink is the same picture in a different palette.
Drawing in code has two big advantages. Everything is sharp at any screen density, because it is drawn at the device's own resolution rather than scaled from a fixed image. And a dark theme is nearly free: the colours are variables, so night in Lily Leap or Lynx Run is the same drawing with a different palette - plus a few headlights and stars.
The cost is that every visual idea has to be expressed as code. A glossy bevelled brick is a gradient, a highlight and a shadow, drawn once per colour and size and then reused. A gem in Gem Cascade is a set of facets in its own colour and cut, painted onto a canvas. It takes longer than drawing a picture - but the result is a few lines of text rather than a file to download.
Sound without sound files
The same goes for sound. There are no MP3 files in the games. Every effect is synthesised on the spot with the browser's Web Audio interface: an oscillator, a shape, a short volume envelope. A jump in Maria is a rising square wave; a laser shot is a falling sawtooth with a little noise; collecting coffee is two quick blips. The music in Maria is a bass line and a melody scheduled a moment ahead, in six themes. Pipe Flow's water makes a bubble sound that climbs in pitch as the board fills.
Every game is checked by a program
The part of the work players never see is testing. Almost every game has a tool that plays it, solves it or simulates it before a release:
- Sudoku checks every puzzle with a solver to make sure it has exactly one solution.
- Solitaire deals only from a list of deals a solver has actually won - 600 for Draw 1 and 600 for Draw 3 - each win replayed move by move under the game's own rules.
- Mahjong and Pipe Flow build their boards backwards from a solution, so every board can be finished.
- Lily Leap has a solver that must get a frog home on every level within a single life's clock.
- Nova Bricks checks that no brick is sealed in by steel, and an autopilot plays every stage.
- Gem Cascade sets its par scores from a bot that plays each level forty times.
- Harvest Hollow and Star Prospector have their economies simulated, so that progress takes minutes and hours rather than seconds or weeks.
- Maria and the Missing Coder builds a graph of every jump on every map to prove that each door can be reached and each enemy can be stomped.
The guides on this site go into several of these in detail. The common thread is that “it seemed fine when I played it” is not good enough for a puzzle. A level that is impossible one time in fifty will eventually reach someone who spends twenty minutes on it, and they deserve better.
Small lessons from real phones
Some of the most useful details in the games are tiny, and almost all of them are about phones:
- A thumb is still on the screen when the game ends. In Snake and Block Drop, the game-over dialog ignores taps for 600 milliseconds, so a thumb still pressing a button cannot close it before you have read your score.
- Fingers do not lift where they landed. Maria's buttons listen for the finger being lifted anywhere on the page, not just on the button. Otherwise a thumb that slid off a direction button while lifting would leave Maria running in that direction.
- A thumb covers what it touches. In Nova Bricks the paddle moves with your finger rather than jumping to it, so you can steer from low on the screen without hiding the ball. In Lily Leap you never have to touch the frog: a tap anywhere hops forward, a swipe hops in its direction, and the swipe fires after just 22 pixels of movement so hops feel instant.
- Buttons react on touch, not on release. On-screen pads in the action games respond the moment a finger goes down. Waiting for a full “click” adds a delay you can feel in a fast game.
- Phones throw tabs away. A browser can unload a background tab to save memory. That is why the games save as you play, why they pause when you switch away, and why the final screen of Maria is stored with your progress - before that, players who switched apps at the end came back to the world map instead of the ending.
- Pause should not be a cheat. In Memory Match the pause screen covers the board, so it cannot be used to study the cards you have turned.
Names are harder than code
One lesson had nothing to do with programming. Three games started life under working titles that belonged to someone else - the falling-block game, the brick breaker and the space miner - and were renamed Block Drop, Nova Bricks and Star Prospector. Game names are trademarks, and a small independent site has no business using someone else's. Every game here is our own: the code, the graphics, the sounds, the characters and the names.
What we would do the same way again
Almost everything. Plain pages have aged well. They load fast, a game that is already open keeps working without a connection, and anything that goes wrong can be fixed by reading the code that is actually running - there is no layer of tooling between the problem and the fix. The one thing we would do earlier is the testing. Once a game has a solver or a bot, every change becomes safe to make: change one rule, run the tool, and within a minute you know whether a level somewhere just became impossible.
If you have an idea for the next game, or a bug in one of these, we would like to hear it. The contact page says how to reach us.
← All guides