How a game gets tested before it goes on this site
Most browser game sites add a game by pasting an embed code. We cannot do that, because we do not embed anyone. Every game on this site is a copy of the game sitting on our own servers, which means when something is broken, it is broken for us to fix. So each one goes through the same checks before it gets a page.
The checklist
It has to start. Sounds obvious. It is the check that has caught the most problems, because a lot of browser games were built for a desktop window and quietly fall apart at phone width.
It has to fit. We load the game at a phone viewport and measure whether the page scrolls sideways. Any horizontal overflow means part of the game is off the edge of the screen, and on a small screen that is usually the part you need.
It has to be sharp. A game with no mobile viewport setting gets laid out by the phone at desktop width and then scaled down, which makes every line and letter soft. It still works. It just looks cheap, and it is a two-line fix.
It has to be quiet. We record every network request the game makes while it loads and plays. The number we want is zero. Not zero ads, zero requests. Nothing here should be phoning another server while you play.
It has to be played. Not loaded, not screenshotted, played, until the score moves or the level changes. A game that renders a title screen and does nothing else will pass every automated check ever written.
What it catches
ReversAi had a board that was a fixed 508 pixels wide. On a phone, the last two columns were simply off the screen, so the game was unplayable while looking completely fine in a screenshot. The board now sizes itself from the screen.
Five of the games we added from the LittleJS Arcade had no mobile viewport setting at all. They worked, but every one of them was being rendered at desktop width and squeezed down. Adding one line to each fixed it.
Ten games arrived using a gameplay screenshot as their icon. At the size an icon actually appears on a phone, a screenshot is an unreadable smudge. We drew each of them a proper icon instead.
The one that nearly went wrong
While capturing screenshots for these pages, Suika Drop appeared to be completely broken. The START GAME button did not respond. Not to a tap, not to a click, not at any screen size. We measured the button’s position in the game’s own coordinate system and confirmed our clicks were landing exactly on it.
The conclusion looked obvious: the game is broken, pull it from the site.
It was not broken. The game runs a physics engine, and a physics engine reads the state of the mouse once per frame. Our automated click was pressing and releasing between two frames, so as far as the game was concerned the button was never held down at all. A real finger rests on a button for a couple of hundred milliseconds. When we held the press for that long, it started first time.
We nearly removed a working game, and before that we nearly “fixed” a bug that did not exist. The lesson we took from it is that when a test says something is broken, the test is a suspect too.
Why we bother
Because a game that does not start is worse than a game that is not there. If you tap something on this site, it should work, and if it does not, that is ours to fix rather than someone else’s to shrug at.
