Because of the possibility that I wouldn't have time to draw new sprites, I decided to turn it into a kind of Street Fighter II-style one-on-one game, but with a balloon popping mechanic.

I added an exertion mechanic (indicated by the sweat drop) hoping it would provide some depth to the play, but the stamina values need some tweaking for it to be really useful. You can sometimes tire out the computer opponent if they try camping at the top of the screen, then get in a quick attack.

There are eight levels. The original intent had been to have a level for each character, plus two or more levels with special boss characters, and of course, different music for each level, with nods in the themes to the music from that character's respective game. Alas, as it is, there are only two short, irritating in-game songs, because the music was done in an afternoon.

The characters and what (unreleased) game they're from:

Character		Game
Harvey		AnimoCity
Rudolph		Quest of Zo
Ralph		Buckler Strife
Lopez		Greed'n'Magic
Pierce		Maelstrom
Greedy		Greed'n'Magic
Sam		Convergence
Iceclown		Fobwart

The iceclown isn't a playable character, but was intended to be a boss. (Lopez was supposed to be a boss, too, but for lack of KidThulhu (from the eponymous game) and Peter (from Demon of the Fall), he remained selectable.)

Myr was one of the artists on the team. There also was a sprite that I thought was supposed to be Retsyn, but he disputes this and removed it from the game. (It should be noted that half these games were written by Retsyn; Buckler Strife is the only one I had no involvement in, though.)

Melville is a reference to the Taito game Cameltry. ("Moby died in the Spinning Room.")

According to sloccount, it's about 2620 lines of ARM assembly code (ignoring another 1kLOC of tables and such). It's pretty buggy, but it does have a unique character to it. There were some bugs I consciously decided not to expend time on, like interpenetration resolution having the possibility of pushing a character into the playfield. In the final hour or two, copy-and-paste became the dominant coding paradigm. The code is on github.

GrafX2 was used for all pixels, both in 2002 and in 2015. Levels were created as PCXes (yes, PCX, even in 2015) and converted to tiles with a tool borrowed from Convergence. Music, such as it is, was created in emacs and compiled with mumble.

The original game did run on the real hardware, since we didn't have a usable emulator at the time! All my GBA development hardware is in storage, so no new builds have been tested on the real thing. That's okay; I will be testing it in the future, and maybe I'll patch it later. Most people will be playing on emulators, anyway.

By producing a ROM image that could be run in any emulator, I made it much easier to send builds to my friends and get quick feedback. This was an unexpected benefit. Getting feedback, even on early, broken builds, was helpful in maintaining motivation.

I remember that iterating with the flash linker was a really slow process, so I have no shame in targeting an emulator where I can get nearly immediate feedback from a build.

I was already blessed with some pretty great sprites:

Or so I thought, until Retsyn came to the rescue at the last minute and revamped the sprites and palettes:

He also did the background for Myr's moon stage. (And, of course, the vast majority of the old Rhombus content was done by him, back in 2002 and before.)

It was inspirational, and kept me going in the final moments of the project. Of course, it also made me regret the time wasted that could have gone into polishing other aspects, like the music and sound.

The Perfectionist's Handbook is one of the books that has been a critical part of my journey towards becoming a finisher. I realized I had to expose myself to criticism if I was going to get anything done. I had to stop seeing every piece of code as a reflection of my self-worth. And I had to stop trying to optimize (or elegantize) the hell out of everything.

A number of books draw the distinction between healthy and unhealthy perfectionism, but Szymanski's Handbook was the most useful in convincing me that I could let go of some things without losing the good things about perfectionism. Most importantly, it helped me understand that perfectionism, instead of causing me to release only flawless code, had caused me to withhold tons of good code from release, releasing only mediocre code under duress.

I stole a few tools from my other projects, most importantly tools for converting PCX files to GBA tiles. The code was often terrible – several of the tools were among the first programs I had ever written in OCaml, and it certainly shows. My instinct was to dramatically refactor them immediately, and I am a little proud that I resisted. Maybe I will go back and clean them up, but I recognized that it wouldn't further my goal. The Julian of 2002 would not have been able to bear that.

.section .ewram
.align 2
@@ XXX should use an overlay for this
.lcomm balloons, BALLOON_LEN*MAX_BALLOONS

There were so many opportunities for optimization that I avoided making. For example, separate screens ("activities" in Android lingo) could share the same region of memory for their local variables, using overlays in the linker script. Didn't do it. All the tile data, map data, music data, and even PCM samples (!) are totally uncompressed. Scandalous! Various structures in memory wasted bits or even bytes out of convenience. In 2002, I could never have endured that.

One thing I didn't know at the time was that the code in ROM would have been faster, in general, if it had been written in Thumb mode rather than ARM mode. I strongly considered rewriting my code to use mixed modes, but I reminded myself: I need to ship this in a matter of days. It's just a silly little game. YAGNI.

When it came time to implement normalization of vectors when computing contact normals for collision resolution, I did waste a bit of time thinking about the efficient implementation of reciprocal square root versus atan2. I had also been thinking about implementing the Sunderland algorithm for improving my trigonometric function lookup tables. YAGNI. Maybe later.

compute_contact_normal:
        stmfd sp!, {lr}
        @@ XXX Ideally, we'd use the reciprocal square root here.
        @@ There are great, simple algorithms for it.  But let's get the
        @@ slow way working first.
        mov r0, r7, lsl #PHYS_FIXED_POINT*2
        swi #8<<16              @ sqrt
        mov r7, r0
        mov r0, r8, lsl #PHYS_FIXED_POINT*2
        swi #8<<16              @ sqrt
        mov r8, r0
        @@ r7 = distance (12.4), r8 = penetration (12.4)

I used the slow BIOS division and square-root routines instead; the first time, my hands trembled. I think it's the first time I've written a division on a system like the GBA that wasn't a shift or a reciprocal table lookup. The second time, I stopped and wondered how many divisions I could survive in one frame. By the eighth time, I didn't even think about it. Ship it. Optimize only if there's a reason to do so.

The most important thing that went right is that, to my surprise, I started to enjoy working on the game; I even started to enjoy playing games again.

It's been years since I've enjoyed playing videogames at all. I think the peak for me was when I was in my early 20s. (If I don't enjoy games, why am I writing them? There's a question to answer later this year. I'm still thinking about it.)

The possibilities of the idea, which seemed stunted as I began, opened up as I spent time with it. I didn't get to exploit any of those possibilities, really, but it was a good lesson.

I left the music til pretty late, because I can compose pretty quickly (as evidenced by Chip Weekend); the original music routine written for Hyper Ballon Struggle was missing, but I assumed that the music playroutine in Convergence would be fine, and that my archive of that would include tools to convert some format (probably XM or MIDI) to its internal format.

Imagine my horror when, on January 29th, I attempted to replace the awful test song only to discover that the music conversion tools for Convergence, if they were ever finished, weren't in the copy I had.

I decided I would add support for PH-1 (the Convergence playroutine) to mumble, a compiler for an MML-like textual music description to various playroutines that I wrote when I was working on Atari ST demos and then totally abandoned, circa 2004. It was pretty naïvely implemented, and very incomplete. There was another temptation to rewrite it, especially given how much my understanding of Common Lisp has improved since I wrote it, but at this point I knew there was no time.

;; Victory fanfare
A o3     a12aaa4     >c12ccc4 | c+12c+c+c+4 e12eee4  | e1
B o2 %i2 c+12c+c+c+4 e12eee4  | e12eee4     g12ggg4  | b1
C o2     e12eee4     g12ggg4  | a12aaa4     >c12ccc4 | g+1

I was planning to present Balloon Spite to some friends that evening, so I tried to focus on the straightest path to the goal, even if it meant a lot of compromise. I hacked in crude PH-1 support, although mumble's lack of support for drum kit-style bindings for the noise and PCM channels meant I couldn't quickly write percussion parts. This is one of the worst deficits of the music that ended up in the game, and it's one of the reasons it all feels terribly primitive.

Added to that, the playroutine design for Convergence sucks; there's no getting away from that. Music was left til late in Convergence, too, so the playroutine design was never battle tested. It was my second (or maybe third) chip playroutine design and suffered from me trying to do things differently, thinking that a more musical representation would be compact and efficient. (These days, I think the approach KB used for fr-08 is way better than something like this.) Also, many features were simply unimplemented: no arpeggios, no vibrato, no volume envelopes – those are the essential tools for making chip music that doesn't sound dead, that doesn't sound like the output of BASIC's PLAY statement.

I was aware of the McFunkypants Method for finishing a game, but I didn't follow it as closely as I could have.

I think the biggest mistake was not focusing relentlessly on the core gameplay until it was done. I was seduced by my overall vision, especially aspects that were more "tech demo" than game. The "versus" screen was supposed to have a rotscale spinning-out effect on the "VERSUS" text, for example. Levels were supposed to have different combinations of parallax scrolling foregrounds and backgrounds, et cetera. The select screen has its nauseating rotscale checkerboard effect (a recreation of an effect I remember from the original). Players can have alternate palettes (and palettes are pretty customizable in general). Various time was wasting doing these things or experimenting with them.

That time would have been better focused on the core gameplay. As late as last night, my final night working on the project, I was making major gameplay changes, and the build fluctuated between impossibly hard and incredibly easy. The final build is not as much fun as one of the earlier builds, but I accept that as a lesson about priorities and time management.

For February, I'm planning to follow the aforementioned method much more closely. Today I'll be making my storyboard since the game idea is already established and planning what is required to completely implement the core gameplay in the first week.