This installment is going to be a bit different. I thought I’d discuss some of the more “personal” aspects of development, using ROBOT-SB as the example. If that’s not that what you’re here for, I totally understand — feel free to skip this one, maybe come back next time for more coding talk.

Motivation

Why do I make games? Perhaps to make a load of cash? Hmm, sure, that’d be a nice bonus, but wouldn’t really keep me motivated. In truth, I do it because I just enjoy the creative process and technical challenges – this is a hobby, rather than a job. Further, and more importantly, I enjoy the fact that my kids like being part of the process, as it gives us yet another thing to do together, and they’re pretty good at thinking up game ideas.

What follows are some examples from ROBOT-SB…

Inspiration

Early on, ROBOT-SB with pretty “stingy” with its awarding of stars (the in-game upgrade currency). This was mainly due to not yet having tuned the cost curves – everything was essentially too linear and too cheap.

So the “quick fix” was to just make it harder to get stars. As the cost-curve developed, eventually I was going to need to go back and re-balance the star awards in order get it all working.

My son Nick noticed this problem before I actually got around to fixing it — he’s my in-house alpha tester. He came to me saying “It’s too hard to get stars”, and of course, he was right. So, the two of us sat down one day and brainstormed possible ways to award more stars.

As is often the case in such sessions, development decisions directed by an elementary school kid tend toward the “flashy” rather than merely “functional”, but we came up with a bunch of just-spawn-multiple-stars-whenever-you-would-have-done-just-one type solutions:

Some of these patterns might actually make it into the final game, but more importantly it was the “research work” needed to get multi-valued stars implemented. (not only was the early game stingy with stars, but they were only ever worth 1 each)

Hacking

Sometimes, rather than brainstorm interactively, I’ll take a collected group of ideas and suggestions, try to pre-implement them quickly, then show them off to my alpha-testers to gauge reactions. Most of this comes about from random comments of the form “it would be cool if it could…”. And you know how kids think, so finish the comment with things like: ..have a super-mega-ultra-gun, be invinvincible, ..look like Mine Craft, ..et cetera.

We call that “hacking”, and it goes something like this:

Wrapping Up

Anyway, hope you enjoyed a bit of behind-the-scenes, I’ll be back to technical stuff next time, cheers!

ROBOT-SB is essentially a “one-tap” game – tap to change direction, trying to dodge and/or shoot the various obstacles. But it need not be just a “one-tap”, as there are a number of control schemes that could work with it.

I debated long and hard whether to allow alternate control schemes, primarily because I felt it might unfairly tip the leaderboards in favor of one control scheme or another.

Plus, there was also a bit of irrational desire to preserve some sort of “artistic purity” imagined to be present in the one-tap scheme – but that was easily shed.

I had mocked-up various control schemes while “hacking” the game with my son (aside: actually, we’ve hacked in all sorts of wacky stuff, like super-guns, invincibility, even reskinned it with some ‘borrowed’ Minecraft art) but never truly tested them.

The only way to truly settle the issue was to properly implement and test these alternate control schemes. And you know what? The choice of control scheme doesn’t have that much effect on scoring potential after all, so the argument regarding leaderboard preservation went up in smoke.

So why not just give the users what they want? For example, here’s the “stick” control (the only one that needs a visual):

I figured I’d talk about how I structure the code to make this “easy”, as maybe it’d be of use to someone else.

The way the code works is that each control scheme is its own class, following a common interface and referencing a common “control state” where it’s “output” is stored. So all that’s really necessary to implement the various schemes is to just create an instance of the correct class.

The control classes are kept in a table, keyed in a way that matches the persistent user-preference value. (note: all of the below is technically “pseudo-code”, but functionally describes actual game code)

Then, when it comes to create an actual instance, it’s just:

Then, there’s a bit of wiring that needs to occur between the Player and the control scheme’s “state”. There are any number of ways to “connect” the two (event/message system, player-refs-state and “observes”, state-refs-player and “controls”, state passed to player as needed, etc), and I won’t get into the why of my decision, but Player get a reference to the control state and is wired up as so:

Another advantage of the tabled control schemes, and the way the player references the controls, is that it would be easy to drop in a “game.controls.DemoAI” control scheme, for example, if I later decide to do the “game plays itself in demo mode underneath the main title screen” thingy.

Then just create a game instance that overrides the user-preference setting with a request for the “demoai” controls, and presto! instant demo mode. It doesn’t do this at present, and probably won’t ever, mainly because of low-resolution “clutter” concerns, though it’s something that’s worked successfully for me in other games.

One of the components that I needed for ROBOT-SB was bitmap font support.

I didn’t need anything elaborate – in fact, given the low-resolution that I’m working at, I hardly needed a proper “library” at all, just a few “helper functions” might have done the job.

So I began by exploring extant solutions, hoping to avoid reinventing the wheel if I could find something suitable already out there.

But the libraries that I found were either 1) outdated, and I had no desire to spend time updating someone else’s code that might not end up being what I needed anyway; or 2) a bit too elaborate, in that they weren’t focused on the particular issue that I needed to solve, primarily: proper pixel alignment.

I don’t need variable spacing, or kerning pairs, or tools for converting True-Type fonts, or styling support, or animation, et cetera. Primarily because features of that type tend to move characters around in a way that is not pixel-perfect. (or, at least, would have required a bit of patching to ensure pixel-perfect positioning in all cases)

So, in the end, I reinvented a toy-sized wheel, and I am oh so proud to now present you with.. wait for it… tah dah… SimpleBitmapFont!

I’m pretty sure that letters that look like fire are still cool, right?

You can get it from github.

Please note that it is definitely not intended as the be-all-end-all implementation of bitmap fonts! I’ll leave that to others with grander aspirations. But feel free to use it as a jumping-off point if it seems more-or-less appropriate for your particular project.

It is about as minimal as I could practically make it, something that just “gets the job done,” but not much more. (The version I’m using in-game is a bit different, with a few more specialized helper methods, but they aren’t of general-use enough to include.)