A little while back at the beginning of the year I posted about that neat card-sized Arduino based console; The Arduboy…

…and now’s a good time to get involved if you’re interested because that spiffing gentleman, Kevin Bates, is currently running a Kickstarter campaign to support the development of ‘Arduventure’; an ambitious Arduboy based RPG with backer rewards including the hardware itself…

This past week I’ve been putting in quite a bit of time to push forward my current Arduboy project; it’s another epic platformer, “Ninja Fuzzgrawth”, which is loosely inspired by ‘Super House of Dead Ninjas’ but has mostly been an interesting foray further into my own exploration of programming and game making at a level that I can handle. In truth the bare bones of the game mechanics had been in place for some time, but I had been lacking that motivation to actually put the “game” in to the game. Even now, the biggest task I have remaining is designing the level blocks for the player to navigate. In the intervening months I also threw out into the community the top-down sneaky-sneaky “Zoo at Midnight” in which the player takes the reigns of … erm… a creature… sneaking around the zoo to feed the animals and avoiding the flashlights of the zoo wardens. That project began life as an entry into the first Arduboy game Jam, but sadly (although I began work on it at that time) I suddenly became too busy to finish it, so the game dragged on another month or so before I actually set it free on the world.

When I wrote about my first Arduboy game (Not Just a Hat Rack) I mentioned that the development was more ‘happy-accident’ than ‘intended’ as I’d really just been curious to understand the intricacies of 2D platforming movement by attempting to recreate the same feel of games such as ‘Super Meat Boy’ on a platform that I could handle. Working that up into a game seemed like the right thing to do once I had the basic mechanics in place. I learnt so much from that first experience that I seem to have stuck with the platform for two (well… one and hopefully the next one released in the next few weeks) further adventures in programming so I thought I should share how I’ve fared and what I’ve learnt.

Zoo at Midnight

‘Zoo at Midnight’ began life as a game jam entry that was never entered – for those of you not clued in on this, a game jam is a real (or virtual) event where participants attempt to develop a title in a limited time period. It was an excellent community event which I have a certain guilt tied with because I really wasn’t able at the time to participate or contribute to the level I would have liked. That being said, I was determined to stick with ZaM because I was using it as a vector to try a few new programming ‘techniques’ (Note: despite being ‘enthusiastic’ I am not what you could call a programmer, so everything I know is learned and pieced together as I go… including terminology…). I’d read an excellent piece about ‘Object Oriented Programming’ over on GeekOut South-West and decided to try it out rather than the more procedural nature that I’d stumbled into at first. I’m not about to inexpertly fumble my way through the intricacies of OOP here, but one of the big advantages is being able to create different instances of the same class. In ZaM I wrote different functions to dictate the behavior of a guard, I then created different instances of the guard class as needed. Each one could be assigned their own patrol route, but would obey the same basic rules. What I found to also be useful was creating more abstract classes, such as one I called ‘Menu’; an instance of this class took care of all the housekeeping elements in the game like keeping track of which items had been picked up, or if the player was in-game or at the title menu. By structuring the game in this way I discovered that I could be a bit more ambitious because, it allowed me to focus and test each element of the game individually.

I’ve probably now got a good handful of programmer types yelling at the screen telling me that I’ve oversimplified an extremely complex subject … and I totally have… but the point is that I was in this to better understand the games that I play. By dabbling with OOP I began to understand how a very complicated title with many elements, many similar in behavior, could be gradually built up and implemented and ultimately different instances of these objects combined to create an intricate game-world.

‘Zoo at Midnight’ was a step up in complexity compared to the relatively straightforward ‘Not Just a Hatrack’ which pushed me to improve my 1-bit pixelart, design more challenging game screens, and tackle the problem of dynamic flashlight beams which intercept ingame barriers.

Ninja Fuzzgrawth

So it’s no released yet, and it has a silly name dreamt up on a work trip, but ‘Ninja Fuzzgrawth’ has been an even more challenging undertaking than my first two projects combined, although that might not be obvious when playing it. The first big deviation from my two previous titles has been the use of a scrolling stage; here the stage only scrolls vertically as the player makes their way up the tower. In my previous two offerings the action has all taken place on a static screen with the player sprite moving about that space, in the case of ZaM touching the screen edge will transport the player to the next region – Zelda style. With NF the player sprite moves left and right, but rather than moving up and down the stage scrolls around them, this is a classic technique and if you’ve never though about how the camera moves in a 2D game then I advise checking out this page on Gamasutra which comprehensibly demonstrates all the different techniques.

Continuous scrolling is pretty tricky; unlike a neat tiled area there are now partial tiles draw at the upper/lower edge of the screen each frame as the player ascends in order to make the scrolling smooth rather than juddering as full tiles suddenly materialising when there is space for them to be drawn in their entirety. Also each level is now much much larger; I decided to add a procedural generation aspect, so now each stage is built of 12 level ‘blocks’ which are randomly ordered to add variety in the play throughs. Each block is 16 x 16 tiles big, so in order to store this in an array in memory all the time would require over 3kB of data alone. This isn’t including the memory required to store the status of other entities such as enemies. In order to combat this the level data is stored within the program storage section of memory which is much larger than the working memory, but can’t be written to during play. Now I only need a much smaller array to hold the data of the tiles immediately surrounding (and a few rows either side of the screen for some persistence of action) the player. As the player moves upward each new row of tiles is copied from the program memory in to the working memory and the bottom row is discarded. This comes with the penalty that if you destroy an enemy then move too far away from them and go back the enemy will have respawned because the data in the program storage part of the memory can’t be altered so each time that tile is loaded the game spawns an enemy in that position… just like many older games from the 8-bit & 16-bit era  for essentially the same reason. There is an excellent explanation of how levels and graphics were put together on those system in a video here.

Once again I have been furthering my 1-bit pixelart to bring the game to life; the protagonist has a slight idling animation along with specific frames for jumping and wall-sliding. I used a trick I first noticed in the master system version of Strider for the sword animation and simply add the slash on top of the normal player sprite. Of course no game would be complete without ingame hazards of which I’ve added a pretty typical selection so that hopefully I’ll be able to make some engaging stages.

Looping back around to where I began; I’ve recently been adding lives, a timer, level progression, and bonus conditions to turn the bare essentials of moving a character around the stage into something that better resembles a game. I’ve also been trimming as much excess as I can from the code in order to avoid some slowdown that I’m seeing in more complicated areas and also to free up some storage space for the final elements that I need to add; often speeding things up and freeing up space don’t go hand-in-hand so I have to weigh up the potential savings on either side of that arrangement. This is all part of the challenge of programming on this platform and, whilst I get pretty happy when I free up a few percent of space, I know that there are much more talented people out there int he community using compression to squeeze everything they possibly can from this mini-system.