Last journal post until I actually make some progress, I swear!
After making a long post about my choice in game engines and then another explaining where my original game concept came from, I’m going to, finally, explain the history of my first game’s development. In brief, I hope.
Heartbreak version 1: Unity 3D for Windows
Original Heartbreak game, made in Unity3D
As you can probably see, the game is very flawed. One major issue was with the controls, which were tied to the mouse, so moving the mouse left and right caused the ring to spin. Hitting left mouse button would fire the balls from the central heart. On top of that, the game itself is bugged. At the eleventh hour, we discovered a bug on the fourth or fifth level that would cause the score to reset to 0 after the player had progressed to the following level. Finally, at the time I made a big deal out of “elegance of design”, which I saw as every part of a game coming together to compliment everything else.
Don’t get me wrong–elegance of design is a good thing, but I may have taken it a bit too far by creating a menu system that you could literally “lose” at (by accidentally selecting the exit button), in the interest of turning even the menu screen into a gameplay tutorial. I think I had seen one too many episodes of Sequelitis.
After the 2013 Game Jam, I was excited to try my hand at game programming, since I’d been only the lead designer for the original Heartbreak. I wanted to learn the craft of programming for myself, in the interest of being more self-sufficient. To that end, I decided to start as “simple” as possible and got into programming for the Atari 2600. Yes, the real Atari 2600.
If it’s a bit debatable whether or not I technically “made” Heartbreak version 1, since I was really just directing a Unity 3D programmer in what to do, I consider my actual first game to be my first remake of Heartbreak for the Atari 2600. I used the homebrew tool Visual Batari Basic, which, when combined with Batari Basic, gave me a convenient and simple IDE with many helpful sprite and sound design tools, plus the ability to code in BASIC and use a pre-made kernel, rather than coding everything directly in 6502 Assembly. I was extremely grateful for that.
Heartbreak version 2: Visual Batari Basic for Atari 2600
Prototype Heartbreak game, made in Visual Batari Basic for the Atari 2600
It took me a couple months to actually make Heartbreak for the 2600, since I was learning along the way and frequently had to go back and reprogram bits of code here and there as I discovered more efficient ways to organize the game logic. Keep in mind this was all done for a system with a 1.19Mhz processor and 128 bytes (yes, individual bytes) of memory (only 26 bytes of which were available to me in Batari Basic, since the kernel I used consumed the rest of it to write the playfield to the screen).
In the end, it was again thanks to a more experienced programmer, who generously wrote a custom kernel for me, that Heartbreak was able to function well on the 2600. Normally, using Batari Basic’s standard kernel, only a single playfield color can be displayed on-screen per playfield pixel (those big, rectangular blocks), but the programmer managed to work around that limitation with some clever 6502 Assembly wizardry that I still don’t fully comprehend.
From the custom kernel as a framework, I was able to build the finished game. Some months later, I revisited my old code and cleaned it up, organizing everything into neat, clean functions that you can view here. I’m rather proud of how tidy and efficient it all is (relatively, keeping in mind that this is BASIC with 6502 Assembly calls in it, all programmed in non-object oriented in a language that relies on spaghetti code). The game itself only uses about 1000 out of ~3000 CPU cycles that are available with this particular kernel, and the game itself is under 4 kilobytes. And, yes, it works on a real Atari 2600. If you’d like to try for yourself, I included Heartbreak, with a few other small games I developed for the Atari 2600, in a 32k compilation ROM (along with an updated version of my previous LD, Ping) that you can get here (you’ll need an emulator such as Stella to run it, unless you have a real 2600 with a Harmony cartridge), and you can see the finished version of the game below.
There have been a number of gameplay changes since the Unity3D and earlier 2600 versions.
Heartbreak version 3: GameMaker for Mobile
Originally, the player had to hit a button (joystick fire on the 2600, spacebar or left mouse on Windows) to fire a new ball from the heart. The ball would take on the color of the heart and it had to either match the block’s primary color or be one of the primary colors that made up the block’s color, or else the player would lose a life (indicated by the size of the central heart). Hitting a wrong block three times meant game over, but the player’s heart would be brought back up to full size after every stage.
Once I’d finished the basic game on the 2600, I was seeking to program in alternative gameplay modes, since alternate modes were a thing with many 2600 games. One of those modes included a bouncing ball, so rather than the player having to spawn each ball (which would fire from the heart and then disappear once it had stricken a block), the player only had to press the fire button when they wanted to transfer the heart’s current color to the ball. This meant a lot less button mashing, and it was far more satisfying to just control the blocks to catch the ball as it bounced. This ended up being the only game mode in later versions.
With the block colors, I’d always intended the game to start with simple primaries–Red, Yellow, and Blue, and work up to secondaries–Orange, Green, and Purple–and finally to White and Black. White blocks would give you a heart back, but black would take away a heart if they were struck and had to be avoided, which was particularly challenging in the 2600 version, because the background is solid black as well.
However, this lead to the game becoming progressively easier, since an orange block could be broken by either a red or a yellow ball, a green with yellow or blue, and a purple with red or blue. Obviously, a game should get more challenging over time, not less. I fixed this in the 2600 version by having the ball remove a color from the block’s color, leaving the remaining colors in its wake. For instance, if a red ball hits an orange block, it bounces off and leaves a yellow block behind, which must then be broken by a yellow ball. And if the orange block was hit by a yellow ball, it would bounce off leaving the block red. Yellow blocks would need to be hit by all three primary colors before they would disappear.
Overall, I’m very pleased with how the game itself plays as of the final 2600 version, but a few things had to be sacrificed in the move to the 2600’s limited hardware.
For one, the ball will only bounce at a few pre-determined angles, as letting it bounce freely would result in the ball always getting lost, particularly since the blocks aren’t of uniform shape and they don’t fully encircle the central heart.
Additionally, there was no way to add multiple concentric circles to the game, so it always operates on a single ring. I would very much like the game to have up to three or four rings at a time, as in the original Unity3D version.
Finally, I always intended the game to be a musical arcade game, but having background music wasn’t feasible with the 4 kilobyte size limit of the 2600’s ROM. I would like to bring a musical quality back into the game, with the heartbeat matching the tempo of the current soundtrack, rather than set to a steady, heart-beating sound effect.
On top of all that, I’d also like to bring the game to a mobile setting, which I think would fit the gameplay very well, being a sort of casual game that works best in just a few moments played at a time. This would, of course, mean reconsidering the control scheme. I would like a simple swipe gesture to allow the ring to spin, perhaps with a simple tap used to set the ball’s current color to the color displayed by the heart.
On the other hand, I may modify that mechanic so that the heart does not change colors on its own, but instead must be tapped by the player in order to change the ball’s color. Or maybe the heart and ball always share the same color and, rather than tapping at the right moment to get the right color on the ball, the player would need to tap the heart to swap between its colors? We’ll see.
While I’m at it, I’d like to update the game’s visual style, maybe moving away from the direct pixel-art look into something a bit cleaner. And, who knows–if I find the time, maybe I’ll try implementing some kind of power-up system, similar to Arkanoid. I may have an idea of how it could work.
Now it’s (finally) time to get to started!
Tags: atari 2600, batari basic, GameJam, GameMaker Studio, heartbreak, journal, ping, Unity 3D
