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:
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.
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:
Version 1.3 of WoopsiGfx, my Woopsi-derived 2D graphics library for the DS, has been released. Download it now from the BitBucket page:
This version adds in all of the latest Woopsi goodness, including all of the new string functionality, the floodfill bugfix, font and bitmap refactoring, etc. The full changelog can be found in the archive.
WoopsiGfx is a C++ 2D graphics library for the Nintendo DS, derived from Woopsi. It allows developers to create and manipulate bitmaps using a comprehensive set of drawing tools. It includes an extensible font system for drawing text to bitmaps, and features support for packed monochrome and 16-bit fonts out of the box.
WoopsiGfx can be used to draw directly to the DS’ VRAM. This is useful when the DS is in MODE_FB0 or MODE_5_2D.
- Extensible font system that supports compressed proportional and fixed-width fonts (monochrome and 16-bit);
- Animation class with support for variable framerates and standard/pingpong looping;
- Bitmap class for 16-bit bitmap image manipulation;
- Graphics class providing clipped, DMA-accelerated drawing functions;
- Dynamic array container and iterator classes;
- Object-orientated design for easy integration into other C++ software;
- Simple API;
- Unicode strings encoded with UTF-8;
- Compatible with Woopsi font tools.
You can download a demo here:
The source is available as a zip here:
Alternatively, you can pull down the Mercurial sourcecode repository from here: