Three games. One is 104 kilobytes. One is 3.3 megabytes. One is twenty. All three are single self-contained files that run in a browser, and all three were made by the same studio in the same way.
The spread is not a quality difference and it is not sloppiness in the large one. It is a decision taken right at the start of each build about where the pictures come from, and it turns out to be the decision that shapes almost everything else: the cost, the schedule, and whether the finished thing can sensibly live on a web page at all.
The 104KB one
Fighting Chess is a complete chess game. Legal move generation, castling, en passant, the fifty-move counter, threefold repetition, three difficulty settings, and a fight animation on every capture where the cavalier charges and the sorceress throws chain lightning.
It contains zero image files and zero audio files.
Every one of the thirty-two pieces is drawn in code: shapes, colours and proportions described as instructions rather than stored as pictures. Every sound is generated at runtime from oscillators. The whole thing, engine and art and music, is a hundred and four kilobytes, which is less than a single photograph off a modern phone.
Drawing in code has one obvious problem: doing it every frame is far too slow. Thirty-two hand-built vector warriors, redrawn sixty times a second, will not hold a frame rate.
The fix is a cache. Each combination of piece type and colour is rendered once into an offscreen canvas, and from then on the game copies that finished image around rather than redrawing it. What stops the board looking like a stiff diagram is that the idle movement is applied at copy time: a cheap bob and sway added as the piece is blitted, not baked into the drawing. One render, endless motion.
The 20MB one
Edward & B.Bear is the opposite decision taken deliberately. It carries 502 painted images and eighteen pieces of recorded music, inlined into one file that comes to about twenty megabytes.
Nothing in it could have been drawn in code. A Georgian terrace with its stucco and railings and a red door, a canal in the rain, the glass roof of a station, the light on a wet apron: these are paintings, and a painting is a picture or it is nothing.
The music is the same argument. Two of our builds synthesise every sound from oscillators, which costs no file size at all. That works when the game wants to sound like a machine. A painted storybook crossing London wants a score, and a score has to be recorded.
So the twenty megabytes is not waste. It is 502 decisions that each said this needs to be painted, and the file size is simply the sum of them.
The one in the middle
Tape Loader sits between the two and shows the split cleanly, because it made a different choice for each half.
Its pictures are painted: fifty pieces of pixel artwork, which is most of its 3.3 megabytes. Its sound is entirely generated — not one audio file in the build. The tape screech at the loading screen, the pickup blips, the little fanfare when you finish are all built at runtime from square and triangle waves.
That is exactly right for what the game is about. It is remembering a machine that also made its noises out of oscillators, so synthesised sound is not a saving here, it is the correct texture.
What this means when you are commissioning one
Three things follow from all of the above, and they are the useful part.
Artwork is the cost, not the code. In all three builds the program is a few hundred kilobytes. What separates a £99 commission from a £1,200 one is how many original pictures have to exist, and how many distinct places the game has to be convincing in. A single level needs one setting. A journey across London needs twelve.
Style should decide the technique, not the budget. A game about someone who plays chess wants pieces with weight and posture, and those can be drawn. A game about a childhood bedroom in 1982 wants that bedroom, and that has to be painted. Choosing the cheaper technique for a brief that needs the other one shows immediately.
Size decides where it can live. This is the one that caught us out. Twenty megabytes is completely fine for a family opening a game on a private link, which is what a commission is. It is the wrong size for a public web page somebody might only be reading, which is why Edward & B.Bear is not playable on this site while the other two are. Same file, same quality, different context.
Why they are all one file
One thing does not vary. Every commission we deliver is a single self-contained file with the artwork and the sound inside it. No folder of assets, no server, no install.
That costs something. Inlining images makes a file larger than the same assets served separately, and it means the whole thing arrives before anything starts. We take that trade every time, for one reason: a game given to a family should still work in five years.
A build that loads its pictures from somewhere else is a build that breaks when that somewhere else changes hands, moves, or is switched off. One file on a laptop, or a memory stick in a drawer, has no such dependency. Nothing to maintain and nothing to expire.
It is also the reason both playable builds in the arcade are the exact files that were delivered rather than web versions of them. There is no web version. There is just the game.
If you want the longer version of how the biggest of the three was built, the build diary goes through the design problems in detail. The cost guide covers what moves the price between tiers, and the process guide covers brief to delivery.
