Earth Shaker No More

Unfortunately, my Earth Shaker remakes for the Nintendo DS and Mac are no longer available. I received a nastygram from the [“balding hash”-ed] company who demanded that I take it down because it will cause them “financial damages”.

Quite why it took them 22 years to find Earth Shaker objectionable, I’m not sure. Possibly because it’s more fun to threaten indie developers now than it was to try and take on Future Publishing back in 1990 when they were still at the top of their game. If I tried to be more understanding I’d admit that the audience for retro games is vanishingly small, but then I’d have to point out to myself that, given that the audience is so small, one would expect the company to try to ingratiate itself with it rather than alienate it.


EarthShakerDS 20120513

It’s about time for another EarthShakerDS release:

EarthShakerDS 20120513

Changes this time around include:

  • The ability to load and save levels in the editor with user-defined names (so you can have more than one custom level, and share them with other people);
  • A “Custom Level” option on the title screen listing all user-created levels
  • Slightly re-organised level editor;
  • The ability to load and save boulder/wall/door/soil types in a custom level;
  • Fixed for the latest devkitARM;
  • Updated to the latest WoopsiGfxGameTemplate (fixes SDL version);
  • Start button can be used to test a level in the editor;
  • Select button can page through level editor menu panels.

I need to finish off the file requester in the level editor and it’ll finally be done.

Looking through this code again, I’m astonished at the level of spaghettification. On the other hand, I did knock the whole thing up in a couple of weeks.


EarthShakerDS Revived

It’s been 10 months since the last update, so I figure it’s about time to revive the EarthShakerDS code and finish off the level editor. Changes so far:

  • Updated the OSX version to the latest codebase;
  • Fixed SDL bugs in the WoopsiGfxGameTemplate;
  • Added the ability to save and load soil/boulder/wall/door types to the level editor;
  • Added a keyboard and file lister to the level editor to allow the saving and loading of custom levels with user-defined names;
  • Added a list of custom levels to the title screen menu;
  • The Start button tests the current level in the level editor;
  • The Select button flips between level editor panels.

I’ve got to make the custom level select on the title screen actually start a level and allow interaction with the file requester in the level editor. Once those are done the game will finally be finished.

Here’s a grab of the new file requester. It isn’t pretty but it’ll work…


Farewell, DS Homebrew

It’s time for me to say goodbye to the DS. I’ve been working on DS homebrew projects in my spare time since March 2007, and I’ve learned a huge amount doing so. However, I’ve noticed recently that I’m not really learning much from any of the new projects I work on. It’s still hugely enjoyable, particularly now that I can get games whipped up in a few days and polished for release in a few weeks, but I’m just repeating the same patterns in the same language. Worse, there isn’t an audience for DS homebrew any more. The audience, and most of the developers, have moved over to iOS and Android devices. The DS itself is two generations out of date.

To be honest, I wanted to ditch the DS back when Quirky switched to Android development. In fact, I wanted to ditch the DS as soon as Apple announced officially-supported apps for the iPhone. I’ve stuck with it for three reasons:

  • I wanted to see Woopsi through to completion;
  • The iPhone’s input devices aren’t a patch on the DS’ physical buttons for the kind of games I enjoy playing;
  • Having grown up playing Atari, Sega and Nintendo consoles, actually writing software for one fills me with childlike delight.

I’ve achieved everything I set out to with the DS. I’ve written developer tools, libraries and games for a handheld console, and even entered a homebrewing competition. EarthShakerDS placed 7th out of 24 in GBATemp’s homebrew bounty competition, which isn’t bad for a game knocked up in a couple of weeks.

It’s time to move on.

I do have a few updates to release before I say goodbye to devKitARM - bugfixes to Woopsi, WoopsiGfx and EarthShakerDS, and Really Bad Eggs will get a final release as soon as the title screen is done. I won’t be starting any new DS projects, though.

Unlike Quirky, I’m switching to Apple development. My current project is to port Really Bad Eggs from C++/DS/SDL to Objective-C/cocos2d. I know that I could just use the C++ version on the Mac, but I want to learn Objective-C. Porting something I’ve recently written seems like a good first project. The game engine and AI are already running; I/O is next in the list.


Really Bad Eggs Progress

The final version of Really Bad Eggs is almost ready. All of the coding is done. I’m just waiting for a title screen graphic from Noj, creator of the Simian Zombie monkey, before I release it.

As you’d expect from a jump from an alpha version to a full release, there are many substantial changes. First off, I’ve ditched the Tetris-style mechanics in the single-player game. Like I said in the last blog post, the single-player version of Puyo Puyo is dull no matter what you do. The real excitement comes from suddenly being given a dozen garbage eggs to deal with, which doesn’t happen when playing solo. “Game A” is now “Practice”, and “Game B” no longer exists.

The AI is almost entirely new - I rewrote it pretty much from scratch. It is considerably better at playing with 5 and 6 block colours than the previous version, and on a similar level when playing with 4 blocks. To test the performance of the new AI I had it play against the old AI as a benchmark. I watched each match and tweaked the code to deal with errors that it was making. As 4-colour matches took around 20 minutes each, this was a laborious task…

As an interesting aside, the new AI can rotate shapes in all 4 orientations, but enabling this ability led to it getting resoundingly beaten by the old AI in almost every match. I’ve got a few of theories as to why. It could be that playing horizontally reduces the opportunity for the AI to create vertical towers and hasten its own death. It could be that placing blocks horizontally leads to greater opportunities for accidentally creating sequences of chains. Lastly, it could be that, given the opportunity to place blocks vertically, the AI is more likely to block off a potential chain when adding to it by placing the chain block’s partner above it. The new AI will only use horizontal rotations.

The final version of the game includes a practice mode (single player renamed), easy, medium and hard AI modes, and a two-player mode. I initially dismissed the two-player mode as impossible, given the dismal state of wifi on the DS and the awkwardness of using a single DS between two people. However, the shared DS option was so trivial to implement that I added it in. I’ve included a suggestion in the readme that players switch sides between rounds of a two-player game to ensure that the player on the right isn’t at a complete disadvantage.

All of the block colours, bitmaps, sound effects and music are now in place. Various bugs have been squashed. It will compile and run in MacOSX thank to the usual SDL abstractions that I build into my DS code. Unfortunately, the SDL_mixer library does not support playing samples at user-defined frequencies, so the chain explosion glissando doesn’t increase in pitch each time a new chain sequence is created.

If you’re a regular reader (though I don’t think I have any regular readers), you might have noticed that I haven’t blogged much about this game. Other than the initial announcement/release, there’s been nothing. There is a reason for that: Really Bad Eggs was fairly trivial to write. Other than a mildly interesting graph traversal algorithm to identify chained eggs, the game is a simple grid-based Tetris clone. There really wasn’t much to blog about. Like EarthShakerDS, though, it was enormous fun to write.

One thing that is worth blogging about is the template I’ve put together for WoopsiGfx projects:

WoopsiGfx Template

This extends libwoopsigfx with:

  • Abstractions for the DS’ buttons that will compile with SDL and map to keys;
  • Abstractions for the DS’ touchscreen that will compile with SDL and map to the mouse;
  • Double-buffered framebuffer class that can be used as a wrapper around an SDL surface;
  • Hardware class that initialises the DS into a state ready for libwoopsigfx;
  • Makefile that builds and includes Maxmod-compatible files in the /sfx folder;
  • Pre-built folder structure.

You can take the template and get a libwoopsigfx-based game running in no time. Even better, the same code should compile on just about any platform with an SDL port so that you can test your code in a real debugger. Coding without a debugger or any kind of profiler makes you proficient at debugging by the seat of your pants, but sometimes it’s nice just to run Xcode’s memory leak identifier and have it spot problems for you. EarthShakerDS used an embryonic version of this template, whilst Really Bad Eggs uses the latest version.


EarthShakerDS and EarthShakerOSX Releases

EarthShakerDS has had about half a dozen releases since the last blog post as I tried to get as much done as possible before the GBATemp Homebrew Bounty deadline. This version has a lot of changes, most of which you won’t notice:

One of the big changes is the inclusion of the “poke” functionality. This allows you to poke an adjacent block using the A, B, X and Y buttons without moving into that block. It’s essential for getting anywhere at all on level 9. Unfortunately, poking has nothing to do with pushing values into RAM via a call to the BASIC POKE function to enable cheats. Authenticity has to stop somewhere.

The other big change is the addition of a level editor. This has been a much bigger job than I’d hoped as I’ve had to write a simple GUI system - stylus-driven buttons, event handlers, etc - to build the interface. Why do that, you ask, when I’ve got a perfectly good GUI system already written? Well, it seems that the M3i Zero at least can’t cope with homebrew ROMs bigger than 3MB. EarthShakerDS includes a few large WAV files that bulk the ROM out significantly. If I include Woopsi I’d make the game unplayable on at least one popular flash cart. When your target audience is people who a) had a Spectrum, b) played EarthShaker on it, c) own a DS, d) own a flash cart, e) are nostalgic enough to want to play EarthShaker still and f) want to play a remake instead of a perfect emulation offered by any of the Spectrum emulators for a DS, you don’t want to exclude members of that tiny audience unless you absolutely have to.

At present the level editor only allows a single level to be edited, saved, reloaded and tested. Supporting multiple levels requires me to create a keyboard and file lister, and haven’t I done all of this before? Gnnk. Level data is saved to “/data/EarthShakerDS”. The folder is created automatically if it doesn’t exist.

I followed the patterns established in Woopsi when coding EarthShakerDS to ensure that it was as portable as possible. This approach allowed me to get an SDL-based build running on OSX very easily:

The OSX build requires OSX 10.6 as I’ve built it with LLVM, Clang, LLDB and Xcode 4, but it should be trivial to get it working on 10.4 simply by switching back to GCC etc. It should also be very simple to get it working under Linux, but as I don’t have a Linux install at present I’m not in a position to make one. There’s one OSX-specific API call used in the LevelIO class to determine the location of the user’s data folder that would need to be altered, but otherwise it’s all platform-independent with a few POSIX I/O calls.

Here’s a screengrab from the OSX build:


EarthShakerDS Release #4

EarthShakerDS has had two releases since the last post. Here’s the latest:

At this point, the game is complete. All levels are in place, a host of bugs have been squashed, everything seems to work as expected, the code is commented and there’s not much left that could be refactored.

I’m quite pleased with the outcome. One of my homebrew heroes is Richard Quirk, who has written about half a dozen fantastic remakes of Spectrum games for the GBA and NDS (and, most recently, Android). I’ve tried to achieve the same level of polish and communicate the same level of affection for the source material that Quirky gets across with his remakes. I don’t know if I succeeded, but I certainly enjoyed the attempt.

All that remains to do is a level editor.

EDIT: Although I commit to source control a lot - Mercurial has changed the way I code more than anything else I can think of - I tend to only commit working code. That means it’s easy to get a working build from just about any revision of the EarthShakerDS repository. I went through a dozen or so revisions at random, built them, and stuck them in the zip below. It’s interesting to see how the game grew and developed over time.


EarthShakerDS Release #2

EarthShakerDS has had another release:

The most obvious improvement is the inclusion of sound (thanks to a chap on the GBADev forum who helped out with the Maxmod makefile problem), but there are a number of other bugfixes and improvements.

I’ve got a plan for automating the import of levels from the original game, so hopefully I’ll be able to get them all in fairly soon.


Earth Shaker DS Released

One of my favourite ZX Spectrum games from back in the mists of time was Earth Shaker. It’s a fantastic Boulderdash clone that featured, relatively speaking, great graphics and sound, and fast but puzzle-based action.

I recently decided to see if Woopsi would be fast enough to run a full-screen, bitmap-based game. Boulderdash seemed to be a pretty simple game to write, so I set about it. Not long into the process I realised that the game was looking more and more like Earth Shaker, so I set about turning it into a full-blown port of the original game.

A week or so into development it became obvious that Woopsi isn’t really up to the task of running a full-screen game at 60fps. It flickered just a little bit too much. 10 minutes later I had it ported to the much lighter-weight WoopsiGfx library instead, which has proven itself invaluable when knocking up little games like this in no time at all. The total development time so far has been a little over two weeks, which includes the time it took to grab all of the graphics from the original game and figure out how its algorithms worked.

I’ve entered the port into the GBATemp Homebrew Bounty competition. It’s not quite finished yet - no sound and missing levels - but it is perfectly playable in its current silent, shortened form. Inicidentally, if anyone can help getting the makefile modified to support maxmod and convert a directory into a soundbank, please let me know.

The source is available from BitBucket under the MIT/X11 licence that I’ve come to favour lately. I’d initially intended to release it under the GPL v3, but got bored before I’d read the pages and pages of text that comprise the latest version. The copyright for the game’s assets - graphics and level designs - is held by the original author. He has kindly given me permission to use them in this port, but anyone else who wants to use this code will either need to negotiate with him for the right to redistribute his assets, or will need to make their own replacements.

Many thanks to Michael Batty, the original coder, for his approval!

You can download the game here:

The sourcecode is here:

EDIT: In the time it took me to write this blog post, the guys over at Nintendo Max managed to get a YouTube video up. Fast work, guys! Watching this reminded me - press the L and R shoulder buttons simultaneously to commit suicide if you screw up the level and get stuck.

Here are a few screenshots: