2011-07-04

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.