Arcade Lab: From Playing Games to Building Them

Games got me into computers. After all these years building software, making games of my own feels like coming full circle.

In From Playing on PC to Building Software: My Journey into Programming, I wrote about the 486 my dad brought home, playing Prehistorik with my brother, and the games that kept me in front of a screen. Prince of Persia, Maniac Mansion, Monkey Island. Especially Monkey Island.

That curiosity eventually became a career. Somewhere between databases, frontend frameworks, deployments, and meetings about deployments, the idea of making games stayed around.

Lately, I've been giving it more room. The latest result is Arcade Lab, a collection of six browser games running on a small web engine I built for them. And I've been having a lot of fun with it, even if I end up being the only person who plays them.

That was already enough of a reason to start.

This Wasn't My First Attempt

I had experimented with Unity before, and more recently spent time building with Godot. My Godot games repo includes a platformer, a beat 'em up, a point-and-click adventure, and a survival game called Last Light Clearing.

Small games, with a beginning and an ending, built for learning and experimentation. So this wasn't a sudden discovery that I could make a character move. I was already exploring the kinds of games I wanted to build.

With Arcade Lab, I wanted to try a different route: just the web, with an engine shaped around what I needed. Classic game ideas, short runs, simple controls, and something I could share with a link.

Unity and Godot can do far more than I needed for this experiment. I was curious about how much I could build with a smaller setup, in an environment I already knew well.

AI Made the Custom Route Easier to Try

Writing a custom engine is a very effective way to delay making a game. There is always one more system you could build first.

AI helped make that route practical enough for me to take it anyway. I could move faster through implementation and explore different ideas without spending all my available time getting the foundations in place. Also, as I admitted elsewhere, I had tokens to spare. Apparently, that is a game development budget now.

The setup is TypeScript, Vite, and Canvas 2D. The engine covers things like timing, input, collisions, browser behavior, and the resources a game needs while it runs. Each game keeps its own rules and mechanics.

Last Light Clearing was playable on October 26, the day I created the repo. The next day brought five more games: Skybreak, Clockwork Hollow, Midnight Circuit, Obsidian Duel, and Blastline. A little collection of survival, shooting, platforming, street fighting, dueling, and running around causing problems.

That speed was exciting. It also left plenty of work for the following days.

The direction became clearer as the collection grew. Arcade Lab is a personal workshop, and the shared engine exists to support its games. I don't need to turn it into a general-purpose engine product. When another game needs something, I can build it then.

Playable Arrived Quickly. The Details Stayed.

Getting six games running in two days sounds like the whole story. It was mostly the beginning.

After that came menus, animation, artwork, touch controls, fullscreen behavior, and a long list of small fixes. The things that are easy to overlook when the exciting part is already moving on screen.

Making jumps feel right, getting characters to walk naturally, making attacks look connected to the action. A character can move across the screen correctly and still look like it's moonwalking into battle.

These are different problems from getting the code to compile. They also change the experience much more than their size suggests.

That has been one of the useful lessons from this project: playable is an early milestone. AI helps get there faster, but the result still needs judgment about how it looks, responds, and feels.

The hard part for me was getting lost in those details. There is always another animation to adjust or another little interaction to fix. At some point, the person who wanted a simple game has become very concerned about where a fictional fighter puts his foot.

Changing the Art Was Part of the Fun

Swapping sprites and changing the look of the games became one of my favorite parts.

The same rules can feel very different with another character, environment, or style. Arcade Lab now has Arcade and Deluxe presentations, with different levels of visual finish. You can switch between them while keeping the same run.

That separation matters beyond the theme selector. The artwork can change without redefining where a platform is or how far an attack reaches. It leaves room to play with the identity of a game while keeping its mechanics intact.

There was also a WebGPU/3D detour along the way. That code was eventually removed, and the current games all render through Canvas 2D. For the kinds of games I want to explore here, there is still plenty to do with sprites, layered scenery, animation, and sound.

Keeping the project small doesn't mean every game has to look like a rectangle fighting another rectangle forever.

AudioBits Found Somewhere to Play

In AudioBits: Turn Interactions Into Sound, I wrote about making procedural sound respond to what an application is doing. Small browser games were one of the obvious places I wanted to use it.

Then Arcade Lab gave it six of them.

AudioBits became the sound source for the collection. The library handles the audio engine, while each game defines its sounds and decides when they should happen. The shared integration handles starting, pausing, and cleaning up audio as you move between games.

I like seeing something I built for one project become useful somewhere else. The recipes and sound engine were already there. A new game gave them another job, and gave me a concrete place to use what I had been writing about.

The same thing is happening inside Arcade Lab. Menus, input handling, timing, and artwork loading can support the next game. The survival game's rules don't need to become the platformer's rules for that reuse to be useful.

Building leaves you with more than the thing you shipped. Sometimes it leaves you with a piece that makes the next idea easier to start. I didn't need a grand plan connecting all these projects to enjoy that happening.

What Do I Make With It Now?

The repo is open source, and the games are playable in the browser, with keyboard and touch controls. Sharing something people can actually play has been another good part of the experience.

Now I have a workshop with several game foundations, a sound library that fits, and a better idea of how much work hides behind a small game. I can use that to try a different theme, change the mechanics, or take one of these foundations further.

Maybe the next step is one more complete custom game. Something with its own world, more levels, and an ending worth reaching. I haven't decided yet, and I like having a place where I can try it.

Years ago, I was the kid trying to figure out how to get past the next level. Now I can make the level myself.

Whether I can beat it is a separate problem.