'Keeper' — A New Game for the Atari Video Computer System

Keep practicing.

Here’s another one for all you 2600 fans, a game I’ve made called Keeper. Since finishing Rain, I decided I wanted to give 2600 dev at least one more go. I didn’t have any particular goals going into this, but I did want to make an effort to make it slightly more robust than Rain.

I think I succeeded. Unlike Rain, Keeper features multiple game modes, a lives feature, and changing playfield graphics. It’s also got better sound effects and more dynamic gameplay. Plus, since it’s a joystick game, it doesn’t require a niche input device to play, and I’m hoping that means someone out there will give it a shot.

The game itself isn’t very mechanically complicated at all, though. It’s a simple ballgame in the vein of those the VCS was initially conceived to support. Your only objective is to keep the ball inside the bounds of the screen. You do so with the assistance of the eponymous Keeper, which surrounds the ball. The Keeper is separated into eight sections that can only be activated one at a time by pressing the joystick in the direction of the section you wish to activate and pressing fire. While active, the Keeper will reflect the ball back into play and award you a point. The only catch is that you must activate it just before the ball arrives, or it will speed up. Allow this to happen too many times, and it may get too hot to handle. But not all is lost! You can still slow it back down by activating the Keeper with perfect timing on the next bounce. If you let the ball leave the screen three times, though, the game is over.

For an additional challenge, you can use your Select switch to change to Game Mode 2, which features a larger ball and no “Trackers” following the ball to help indicate when the ball is about to reach the otherwise invisible inactive Keeper.

And that’s all there is to it! Like Rain, this is a small, relatively unambitious arcade-style game. Your only goal is to shoot for a high score. However, because of the game’s tight timing constraints you could think of this as a nice trainer for the parry mechanic present in many other popular games.

I would include screenshots, but it is difficult to capture the action of a game so simple with an image. If you’re curious about it, I encourage you to try it (binary is linked at the bottom of this post), and I would be so appreciative if you did.

Lotta strands in old Duder’s head.

Even though this game is only marginally more complicated than Rain, it still took some learning for me to get it done. However, I didn’t want to learn about bank switching, so I needed to keep this game at four kilobytes in size (I ended up with around 50 bytes to spare).

The first hurdle was getting the playfield graphics to change during gameplay, since the playfield is how the Keeper is represented. This was pretty trivial to do, but the necessary code took up a pretty monstrous amount of the 4KB at my disposal. If there was a more space-efficient way to do so, I’m unaware of it. Another approach would likely have been to find a way to represent the Keeper with some other graphical element (such as player sprites), but I ultimately stuck with this.

With that done, I used some smooth collision detection logic I found in the batari Basic documentation (linked below), and suddenly the game was most of the way done! The fundamentals were there at least, but the long tail of polish stood ahead of me.

Lives were a feature I left out of Rain in an effort to keep that project as limited in scope as possible. It turns out that really wasn’t necessary, as there actually exists a minikernel I was able to import that simplified it drastically. It supports up to six lives (hence its name, 6lives) and handles the HUD aspect of life count, which saved me the headache of figuring out a decent way to do that! Sure am glad that exists.

The last little gameplay detail to get right was the speed up/down mechanic that is so central to making the game more than a glorified DVD player idle screen. Because integer velocities for on-screen objects quickly get way too fast for practical play, I had to learn how to use floating point speeds for the ball. This took a little finagling (certainly more than it would have in any modern development environment), but I got it, and I think the game has a nice pace as a result. Additionally, to help sell it a bit better, I played around with the sounds until I landed on two effects that I think pretty solidly represent speeding up or slowing down. This turned out to just be a matter of increasing or decreasing the pitch value of said sound by one for each frame since the sound started playing. Fun little trick.

Finally, in order to make sure spamming the fire button could not circumvent the short frame window for a successful slowdown, I implemented a little cooldown mechanic as well. This means that corners can be very tricky and maybe impossible to hit without speeding up at times, but I decided that was an acceptable quirk of the game to force even great players to occasionally have to deal with a speed up.

You have entered POWER DRIVE.

One other feature I wanted to be sure to include in this game is at least two different game modes. A fun little idiosyncracy of the 2600 hardware is its “Select” switch, which is used to cycle through the various modes that were commonly included in Atari games in those days. They were often listed on game boxes as entirely different games, in fact. Whether that was marketing fluff or a genuine belief that slight gameplay changes constituted truly different games is something I can’t say I can verify either way, but I imagine it’s the former. Regardless, it’s interesting how it was handled at the time, and I wanted to play with that.

By pressing the Select switch on your emulator (or original hardware!) you can enter the Game Select mode of my game. It will halt play and render a 1 or 2 depending on which game you’ve selected. Simply hold the switch down to toggle between them, and press Fire or Reset when you want to restart play in your mode of choice.

This is more or less how it worked at the time, and this is mostly a consequence of in-game menus being too difficult to implement on 2600. Early game cartridges even listed the modes right on the labels (as I did on the label at the top of this post), but this was later eschewed in favor of artwork, with the mode numbers relegated to the manual. When implementing my Game Select, I tried to follow the Atari Game Standards and Procedures as closely as possible for this for authenticity’s sake, which meant this mode select stuff took up a silly amount of dev time. But hey, that’s all part of the fun.

The only bummer here is that the two modes differ only very slightly. This is mostly because of how much ROM space the playfield logic took up combined with my insistence on keeping this game at 4KB. I simply didn’t have many bytes of code left to work with to make something more interesting. Maybe if I can bring myself to learn bank switching, I can make all kinds of wacky new modes for this game.

Coding is fun, actually.

With Game Select done, all that was left was to keep playing with the numbers on ball speed and the perfect timing mechanic until I felt comfortable putting my pencil down on this one. At some point, you’ve got to. Even after my tinkering, I still think it may be a bit too hard, but it is nevertheless still definitely a game and a concept I saw through to completion. Maybe now that I’m done making it, I can spend time playing it and actually get better at it!

The most thrilling takeaway from all this, though, is that I can sit and code for hours and enjoy it the whole time. When I’m trying to make a good, cute little Atari game, I’m willing to grind through that brutal stage of not knowing something. Somehow, it’s more rewarding than trying to unlock the mysteries of backend web development for the boring companies I’ve spent my life working for. Weird.

I know I said the same thing about Rain, but it bears repeating. It’s been kind of soul-crushing to do something for a living that I wanted to do as a kid and totally hate it. At least it’s still fun as a hobby. That’s very genuinely heartening for me.

Keep an eye out for my next game. Now that I’ve made two tiny games and learned a thing or two, I’m gonna do my best to make my third effort actually good.

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 Keeper. Playable on any 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. Despite the rather insane opinions espoused on various corners of this site, this is the primary source for information on the batari Basic language, short of looking through the source code yourself. It’s a shame that such a great document is hosted on such an unusual and garish website. If nothing else, perhaps you can have a laugh at the contrast of such a rich text being hosted alongside affiliate links for 2000 Mules DVDs.

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.

Thanks for reading, gamers. If you give my game a try and score 10 points, I’ll donate $26.00 to the charity of your choosing (assuming their mission isn’t one I vehemently oppose). 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?