'King Bee' -- My Third Game for the Atari Video Computer System

Why does anyone do anything?

All right, I promised a game about a bee by June 30th. Today’s June 30th, and here it is. It isn’t much, but it’s finished. I think there’s value in finishing modest things.

Of all the pieces of software I’ve produced for 2600, this is the one that, by far, most closely resembles a video game. As a result, it has also given me the most empathy for the people who made games for this thing back in the ’70s and ’80s. Frankly, it’s a miracle they made anything at all.

This tiny, tiny game took me forever to make, and there’s still so much more it could be. But it is at least a game. Hell, it’s arguably more sophisticated than some contemporaneous retail games that did quite well. But I only did a bit of the work I would’ve had to have been done in 1978.

See, I’ve written these past three games in the batari Basic programming language. Before starting this game, I briefly considered learning the assembly language for the processor of the Atari VCS, the MOS Technology 6502 (technically the VCS uses the variant 6507, but it uses the same instruction set). I felt that if I could do that, I could say I did (more or less) exactly what the devs did all those decades ago. Ultimately, I decided that idea sounded pretty brutal after diving a bit into Atari 2600 Programming for Newbies. I’m sure I could’ve managed to make something if I had stuck with that plan, but it certainly would not have been King Bee, especially not with a June 30th deadline.

While batari Basic affords innumerable conveniences over assembly language from a pure code-writing standpoint, the way it feels most like cheating is that I used no fewer than two pre-written kernels and one minikernel to actually render the game. In other words, the people that wrote the code that actually works with the Television Interface Adapter (TIA) to display my game on screen were not me. I’m Racing the Beam in the sense that my code has to execute in few enough cycles that those kernels can update the TIA in time for the next scanline, but I’m not telling the beam what to do. In that sense, am I really a 2600 dev?

Of course I am. Who cares?

Show me the levels! The bet is the levels.

When I set out to make this game, my intent was to make something with characters and levels and some sort of threadbare plot the likes of which you’d find in the manual in those days (these days, you’ll find it in the README of the github repo the game is hosted in). If nothing else, I accomplished that goal. The game is a little shooter in which you control a bee and shoot bad guys across two levels.

Just look at that screenshot! There’s the bee at the top and an enemy at the bottom (based very loosely on the guy on the cover of Tempest 2000). They are fighting inside the bee’s hive. Can’t you tell? Isn’t that what that hideous image with those garish colors looks like? Those little protrusions from the walls are supposed to be a sort of side view of some sort of the hexagonal nooks common in such hives (to the best of my understanding). I’m begging you to use your imagination here.

The point is, the titular King Bee Arthur has returned home to find his hive taken over by the evil Giancarlo Anton (not pictured above, as he’s the final boss). He’s got to kill some guys and then kill Giancarlo to reclaim his throne and free his people. If you know what you’re doing, you can achieve the feat in about two or three thrilling minutes before the game loops and you do it again.

But by god, this game has characters and levels and a beatable “final” objective. It loops because that’s what games of this sort do, but if you kill Giancarlo Anton, you can say you’ve beaten this game as far as I’m concerned. You did it. The game doesn’t get any harder on subsequent loops or anything. If you got good enough, you could probably play it until the score rolls over. Knock yourself out.

Every Little Thing

But the reason this game of mine feels more like a video game than the other little ones I did isn’t just because it actually has characters or discrete stages or anything like that. It’s because of that damnable thing called polish.

Unlike Keeper or Rain, this game has a life bar and lives. It has a little opening sequence to let the player know the game is beginning. It has unique sound effects when each of the different enemies (or player) get hit. When the player dies, a death animation and sound effects play, then there’s a brief pause with a screen indicating how many lives are left. When the major enemies die, they too have their little animations. There is victory fanfare for beating the first level, and it’s slightly extended for beating the second. There’s even what you could argue is a cutscene (or scripted sequence, if you prefer) at the end after you beat the boss.

All those little things take time. They take looking up how to even do any of that shit on the 2600.

For the music, I plunked a little melody out on guitar and figured out how to tell the Atari to make those sounds using this thing. It’s a good thing that exists, otherwise it really would’ve been an exercise in guessing and checking. For collision detection for the bubbles (which are hardware-replicated using a TIA register), I scoured the AtariAge forums for a working solution. In turn, I considered with awe the inner workings of the Space Invaders 2600 port.

But I’m glad I added all the small things. As down as I sort of am on this game, part of me does love it because it’s the first one that really feels like a finished game and not just one I stopped working on.

You Can’t Do That

This also marks the first time I’ve really banged my head against the limits of the 2600 (or at least of the kernels I chose to use). The 2600 was designed to play Combat and Pong, and every other game that was ever made for it exists in spite of that. Through determination, you can wring out something approximating your vision from this humble machine.

The 2600 was only supposed to be able to render two unique sprites on screen. My game renders as many as four at once (thanks, again, to the multisprite kernel that I didn’t write). It can only read 4K of ROM at a time, so I finally faced my fears and learned to bank switch.

Meanwhile, though, there are things that simply aren’t possible. I wanted to make a bigger and badder final boss, but there was simply no way I could do what I initially envisioned within the constraints of the 2600’s rendering capabilities. Also, because I chose to use the multisprite kernel, I had to accept that my playfield graphics could not change during the course of the game. Ultimately, I think that was fine.

Even the orientation of play was chosen based on hardware limitations. Because of the way the TIA works, no more than two unique player sprites can be drawn on a single scanline. The multisprite kernel circumvents this problem by swapping the “player 1” sprite data each frame if such a case does arise. On a 60z CRT display, this flickering is perceptible, but image ghosting also means everything is still visible at once. Still, it’s not ideal. Because same constraint does not apply vertically, I figured it made sense to generally have my enemies appear above or below each other as often as possible and shoot them from above as well.

And such limitations just never stop. The 2600 only has two audio channels and a smallish variety of sounds it can make with them. Its color palette is very small. It’s got to execute everything in the time that the electron gun of the TV is repositioning. It has 128 itty bitty bytes of RAM. These are the sorts of things that no amount of programming ingenuity can get around. These are the reasons it’s truly remarkable that things like Pitfall! or yes even E.T. managed to exist at all.

So why do something like this now? I didn’t even grow up with the 2600! Most people around my age don’t even seem to think consoles that predate the NES are real, so they certainly don’t care about this little thing I made for such a machine.

I don’t know. I guess I just love the cathode-ray tube. I did grow up with those. I love the beam of the electron gun and the glow of the phosphors. I love the 2600’s bizarre marriage to it. I don’t know if I’ll make any more 2600 games, but I’m glad to have made this one. Maybe I’ll make my next game for a platform that people are actually excited to play. But then I suppose I’d run the risk of my work being perceived. Maybe it’s time.

Resources

Want to play the game? Want to know how I learned how to make it? Well here are some links.

Source and Binary for King Bee. Playable on any VCS emulator. You could also look into a Harmony cartridge if you wish to play on original hardware.

Stella Emulator, a great, multi-platform Atari 2600 emulator. You could use it to play my game!

Javatari, a browser-based 2600 emulator. With this, you should even be able to play the game on mobile (although it will be considerably harder).

batari Basic documentation. I’ve issued disclaimers on my past posts about this site. It’s got some really interesting opinions espoused at the bottom of each page. It’s also, unfortunately, the very best resource for learning batari Basic. Whatever!

Label Maker 2600 is exactly what it sounds like. I used it to make the cute little label art at the top of this post.

The title of this game was inspired by a Slim Harpo song. Please listen to the blues sometime. It’s good for you.

Thanks for reading, gamers. 🕹️

I’m once again making the offer I’ve made with my previous games. If you beat Giancarlo Anton, I’ll donate $26.00 to the charity of your choosing (assuming their mission isn’t one I vehemently oppose). I will honor the first ten such requests, just send me a screenshot. If this offer is still in this blog post, it is still available. If you are struggling with ideas, may I suggest the Campaign for Southern Equality or perhaps your local food bank (or mine)?