DEV Community

ABA Games
ABA Games

Posted on

I Kept Enjoying Game Programming—and Ended Up with 500 Homemade Games

If you watch the animated GIF on my personal website in the tweet below for about two minutes, you can see screenshots of all the games I’ve made.

“500 games” sounds like a lot, but most of them are tiny one-minute mini-games. There are hardly any large-scale titles. Out of curiosity, I broke them down by category.

Rank Category Count Share
1 One-button games 245 48.1%
2 Flash games 114 22.4%
3 Browser games 88 17.3%
4 Windows 14 2.8%
5 Palm 9 1.8%
6 Other 8 1.6%
7 Java 7 1.4%
8 P/ECE 5 1.0%
9 i-appli 5 1.0%
10 Wonder Witch 3 0.6%
11 Petit Computer 3 0.6%
12 PC-9801 2 0.4%
13 Unity 2 0.4%
14 Pocket Cosmo 1 0.2%
15 Ruputer 1 0.2%
16 Zaurus 1 0.2%
17 PC-6001 1 0.2%
Total 509

The mini-games mostly fall into one-button games, Flash games, and browser games. Unfortunately, most of the Flash games can no longer be played today. The Windows games are mainly shoot-’em-ups, some built with XNA that also ran on the Xbox 360. There are also a few home console titles, such as games for WonderSwan made with Wonder Witch, and Nintendo Switch games made with SmileBASIC 4.

The “Other” category includes non-game projects such as the bullet-hell description language BulletML and the mini-game library crisp-game-lib. So the total of 509 includes some things that aren’t strictly games—but 509 is close enough.

I’ve also made games for old mobile devices like Palm, P/ECE, i-appli (applications running on Java-enabled NTT DoCoMo feature phones), Pocket Cosmo, Ruputer, and Zaurus. Programming to fit the characteristics and constraints of each device was a lot of fun.

The oldest game of mine that still remains on the web is a PC-6001 game called Meteorite, published in the September 1989 issue of the programming magazine Mycom BASIC Magazine (aka “Be-Maga”), which was famous for its type-in programs. It was written in N60-BASIC and was short enough to fit on a single magazine page.

Toward the end of that program, there is a mysterious sequence of numbers defined with DATA statements. This was a familiar sight for Be-Maga readers at the time: a machine-code definition block. For parts that BASIC was too slow to handle—like processing large numbers of falling meteorites—I wrote routines in Z80 assembly and then manually converted them into hexadecimal machine code.

The joy of programming in the machine-code era was figuring out how to realize the desired game logic within extremely limited execution speed and memory. Because you worked directly with the lowest layers of the software stack, you needed a solid understanding of the hardware characteristics of the time.

At the other end of the timeline, my most recent homemade game is a one-button action mini-game that runs in the browser. It is written in JavaScript, but the base code was generated by a coding agent.

This style of programming—giving a coding agent the right toolset and letting it handle idea generation, design, implementation, and iteration—is a much higher-level approach compared to writing machine code directly. The fun of programming has shifted toward understanding what elements make a game enjoyable, looking at games from a meta perspective, and figuring out how to convey that understanding to an LLM.

One reason I’ve been able to keep developing games for so long is that game programming offers different kinds of fun across layers—from very low-level to very high-level—depending on the era. Solo game development is especially well-suited for experimenting with whatever technology stack or device happens to be in vogue at the time. Even with rough, immature technologies, languages, libraries, or devices, you can try and fail as much as you like when making small games on your own. That roughness itself becomes part of the fun of game programming.

Learning assembly today may have little practical value. Still, the broad, multi-layered technical knowledge I’ve accumulated through long-term solo game development has built a solid technical foundation that helps me enjoy and make sense of new technologies as they appear. It feeds into an intuitive sense for performance, an ability to handle the abstractions each layer provides properly, and an eye for choosing the right technology to realize the game I want to make.

In the end, having your existing knowledge support your understanding of new technology—and being able to keep your curiosity alive—may be what really matters.

Top comments (0)