One Game a Month, Just Barely

I challenged myself to make one game a month in 2013, and I'm starting the year off getting something complete(ish) with almost a day to spare, and published with more than 12 hours on the clock before the end of the month.

I've mentioned it before, but January's game is Switch 2013, a port of a game design idea that I've been poking at for several years now (hey, there's even a history page kicking around the old webpage).

I had got most of the functionality working early on in the month, but there's a pattern that I like to use that I call "ModeMgr", which is usually a stack of game modes. This allows you to have the normal gameplay happen in its own class, and then if you need a dialog box, or an options menu, or whatever, that all is implemented in separate classes. A dialog box probably is pushed on top of a gameplay mode, and the dialog will select what to pass along the "chain of responsibility" - for example, the dialog will let the underlying game mode draw the screen once, and then the dialog will draw itself, perhaps darkening the game scene to draw attention to the dialog. Updates will probably not be passed along to the game mode for a modal dialog. (Maybe you want a modeless dialog, but I don't think this is a great system for that.)

Anyway, that system has worked well for me in systems past, but I had some difficulty getting the system up and running on JavaScript, and in particular, with the Closure Compiler. I'm not yet thinking clearly about what depends on what, and what needs to include what - programming in Python has allowed me to get lazy about circular dependencies.

What I ended up getting implemented last night was to create the ModeMgr as a singleton (I'm not entirely sure I like that decision, and may revisit it as I do my next game(s)), and then register each game mode with the ModeMgr with a string. Right now, I have raw strings floating around in disconnected parts of the code, but it'd be easy enough to capture those in a constants file. When a game mode wants to switch modes, it tells the ModeMgr to switch modes (there's no stack at this point, again, something to add over time) by passing the tag and an optional argument. The argument is only currently used when the player is choosing a level; I pass the level number in as a special function call.

There are a lot of gross things about the current implementation, several of which I hinted at above. An awkward thing is that the modes are objects, but I hand the constructor to JawsJS, so I don't get the option of passing arguments to the constructor, so choosing the level is this extra bit of initialization that happens after construction. Gross.

Another disappointing thing is that I managed to get 600 levels into the original Switch, and I generated 256 levels for Switch 2013, but due to laziness, and font kerning hassles, I couldn't be bothered to make a compelling UI to select more than 10 levels (the base level, plus 9 additional selectable levels). With a little work, I could implement the Angry Birds level selection model, which might be OK.

But that's an idea for a game for next month.