Iterative Change

By: Oliver Awat, Lead Designer & Programmer

Battery Boy started as an idea. It’s derivative of a GBA series Boktai where you fight vampires using a Solar Gun that charges with a photometric light sensor on the GBA cartridge while your outside. While I know “Ambient Light Sensor Boy” could’ve been a major success, we went for a much tamer approach with something that people associate more heavily with phones, which is where the battery life aspect came to be.

Getting Started & Making Mistakes

We didn’t know what to do at the start. Unlike our other games which focused heavily on the gameplay as the main pitch (spinning puzzle game, sorting ice cream game), Battery Boy had the length of a 3-4 hour game jam to create this really simple, one-touch endless “jumper” where you try to squeeze past the gaps. It was supposed to be similar to the log cutting game from Pokemon Stadium 2, but the time constraints prevented it from even somewhat resembling that idea which was flawed to begin with since a lot of what made that particular game compelling was the anticipation of getting a more perfect slice than your side-by-side competition.

It was “fun enough.” We thought it was just that it was early and that we could build upon the gameplay from the jam as a base to eventually have something worth playing. That was our first mistake. We tried making more complex obstacles with different patterns, but it soon showed how limiting the design of our base mechanic was.

And we kept trying. That was our second mistake. We found a bit of hope by adding a rhythm system which controlled the movements of the obstacles (faster/slower based on battery life). It got a bit better–except you didn’t really tap to the rhythm, and the scoring/multiplier wasn’t clear, and the shift in difficulty from the battery was jarring, and most people didn’t listen to the music, and it still wasn’t fun.

Moving Past Mistakes & Changes!

We had already done a shift from 2D to 3D, and the art was really starting to come along. It started becoming exciting to show, but the gameplay was still incredibly lacking. So we did what we should’ve done the first day–start over.

There might’ve been a genre shift had we done it sooner, but with a lot of systems / assets completed, we were pretty ingrained on the endless runner idea. It started with an overhaul of the movement system. We heard from several testers that it was one-dimensional, so we took it from a literal sense and experimented with having more free reign over movements on the x and z (2D eventually winning out).

Giving the player control also gave way to more obstacle layouts and possibilities. It was no longer just a decision about when to go; it became more about how to dodge the obstacles as giving more minute control over movement let us better convey a sense of speed and helps establish the space as a self-contained environment.

Closing Thoughts

There were a lot of things that went into that one reset which was only really a period of two weeks. I’ll save the bulk of it for another post, but while it’s a bit baffling that it took us three months to get to that point, it’s amazing how a lot of the game was made in what was essentially 13% of development in that point in time. To paraphrase my good friend Tommy E: “We didn’t fail at making an endless runner 1000 times. We failed at making the same runner like 4 times because we kept just adding onto it and dressing it up and then made it into a rhythm game.”

You can’t just shove ingredients into the oven and call it a cake. It’s about making a bunch of cakes, trying other people’s cakes, and then developing your own recipe because a PhD in cakes can only take you so far.

This Months Blog Author

Oliver Awat

Lead Designer & Programmer

The creative genius, Oliver guides the creative vision for our games helping bring them from tiny prototypes to big bursts of fun. He’s also a talented developer, quickly conveying design ideas into code.