Making a Game Called 'Rain'

It’s just a state of mind

For the first time in a long time, I have written software for pleasure. I made a little video game called Rain for Atari 2600.

People close to me know how often I lament having chosen software development as a career path. How I complain about the unpleasantness of coding horrible boring webapps I don’t care about (if my employer is reading this, this is parody! 🙂). Well, I still think that shit sucks, but the past couple weeks of poking around in batari Basic have reminded me that coding something you give a shit about is great!

Now, this is not a particularly ambitious project, but it has been a fun one. My decision to make it was inspired by a confluence of events. First, I’ve been generally anxious about how consumptive my leisure time has been as an adult. I have produced very little of meaning that I was not paid for, and I’ve already hinted at how rewarding I find my day job. Second, I’ve become more interested in the Atari 2600 (and pre-NES consoles in general) since I’ve been playing some of them on MiSTer and some as part of the excellent Atari 50: The Anniversary Celebration.

Perhaps most importantly, playing around with spinner-based games on the MiSTer like Arkanoid stirred within me a desire to make a game based on the bygone input method. The precision a dial offers for one-dimensional movement is neat and felt like something worth trying to develop for. When I found out that the joystick controller for the Atari VCS also works as a spinner, and that the Atari 7800 MiSTer core is compatible with it as a Paddle controller, I knew I had to make something with that.

The idea for the game itself had been in my head long before I became intrigued by spinners, though. I initially conceived of it as a single-input game for mobile platforms. A little guy would run around a little microplanet he lives on dodging space debris hurdling toward his home. I figured he would automatically run, and tapping the screen would cause him to change direction. That would be it in terms of control! The resulting game, I realized, would be a vague mashup of concepts from Pyoro, VVVVVV, and Super Hexagon. When I started thinking about spinner controls, this old idea I had seemed like a natural fit.

Rain I don’t mind

Rain, however, is an Atari 2600 game, not an Android or iOS game. A significant positive of the platform is that, again, it natively supports Paddle controllers. This trivialized creating a game with that input method. The downsides and limitations of the aged platform are many, though. This meant I had to make a drastically reduced version of my game concept. But that’s no problem. I looked up a reference for the batari Basic language and got to work.

I immediately found that the initial decision to use Paddle controls, despite its relative ease to implement, constrained things further. Paddles can only be read when using batari Basic’s standard kernel (and I certainly wasn’t going to try to write my own nor write assembly). Using the standard kernel reduced of unique sprites I could use in the game to two. Other kernel options allow for as many as ten sprites, which certainly could’ve helped if I had wanted to make a more sophisticated game. With the standard kernel, I could render a background, a playfield, two “players” (read: sprites that I have the freedom to draw/define), two missiles (read: rectangles of settable length), a ball (read: square of settable size), and the score. But wait! Reading paddles also requires another kernel option to be set that reduces the missile count to one.

At this point, it’s kind of amusing to take stock of all the assumptions the 2600 made. There was a clear belief that the 2600 would play host to enough space shooters and ball-oriented games to make missiles and balls something the platform supported out of the box. The Paddle controller itself was further evidence of this inasmuch as it was designed to control its namesake in Breakout or Pong-like titles. And while my game doesn’t use either object as a literal missile or ball, both are used to represent something else — with a little imagination, at least. You can read more about the Television Interface Adaptor on Wikipedia. Interesting shit.

Anyway, the only real annoyance was that I didn’t fully comprehend the two-sprite limit until I was already a few hours into implementation. That realization sucked for a minute.

Shine, the weather’s fine

But it’s really not all that bad. A good way to finish something is to keep it simple, so the bounds of the standard kernel certainly helped enforce that. By limiting myself to just the two player sprites, one missile, and one ball, I was able to keep the scope of the game to approximately that of a one-week college homework assignment. The result is pictured below.

So what’s happening here? Well, the green square in the middle is the planet (the “playfield” in Atari terms). The lighter-green square with a dot in the middle is the player character. It’s supposed to represent an eye: enough to make it seem biotic without occupying any more screen space than necessary. The two light blue rectangles are the raindrops from which the game gets is name. One is the second player sprite, and the other is the missile, but they are both just rectangles. Finally, the green square (which shares its color with the planet thanks to another 2600 constraint) is the ball and represents a meteoroid that the player must dodge. It sweeps horizontally across the planet’s four faces while the raindrops fall perpendicular to it.

The player’s job is just to dodge these things as long as possible, earning points for each meteoroid that leaves the screen and each raindrop that hits the ground. A single hit is Game Over!

And that’s all there is to it. I recognize that this has probably the bare minimum number of moving parts to make it technically a game, but it’s finished! It has graphics and sound and the controls work. If you don’t do anything, you will eventually reach the failure state. If you do dodge stuff, you will score points. That’s a game if you ask me.

Slip into the shade

Under the hood, this was just 234 lines of code (linked below), and that’s including comments. The vast majority of the effort and time was spent poring over the documentation (also linked below) to understand how any of this even works. If you dig into the source code, you’ll see that batari Basic actually offers a great number of conveniences! Perhaps most important of all, collision detection is a built-in function (which, really, is a convenience of the hardware; see the Wikipedia article on the TIA linked above). With that out of the way, the only real logic my game employs is movement and “enemy” spawning. Getting the eye to rotate around the planet required converting the current paddle position (it can assume values from 0 to 77) to an actual screen location, and adding some randomness to raindrop and meteoroid spawn locations and frequency required a little fun with bitwise operations.

But overall, this thing is super simple. I considered playing with it a bit more to add variable drop speeds or maybe support for different difficulty levels, but getting into the weeds of that looked like more of an undertaking than was necessary for this to reach a V1 state.

Ultimately, I decided to call it finished when I sat down to play it and actually kind of enjoyed it. Playing it on MiSTer with the spinner just felt great, even as rudimentary as the game is. My impulse to go to all this effort had been justified. I bought a new toy and made a little something to play with it.

If you choose to download it, I can guarantee that Rain will provide untold minutes of entertainment. Maybe even as long as it took to read all this shit.

I can show you

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

Source and Binary for Rain. Playable on any emulator and presumably the original console itself if you are an everdrive haver or something.

batari Basic documentation. I didn’t notice until after finishing the game that this website has insane anti-vax shit and climate change denial stuff at the bottom, but oh well lmao! If you can ignore that, it’s an outstanding resource for the language. I learned everything I needed to know from this page or the examples it links to.

This Medium article was the first thing I found when I first googled “2600 dev” or whatever. I didn’t make much use of it, but it did at least lead me to the resource above, so I did want to give author Petros Demetrakopoulos a shoutout at the very least.

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 actually take the time to read this and play the game, I’ll donate $20 to the charity of your choice if you can score more than 100 points and send me the screenshot. (Limiting this offer to 5 people, although I will be surprised if even one person takes me up on it).