Sploidz Revisited (Unofficially)

I’ve already written about the semi-conductor project and how I’ve written some Flash animations/applications for it. Of course, I’m more interested in making fun stuff¹, so I’ve decided to put my knowledge to good use and write a small game to see how difficult/awkward Flash actually is.

To sum it up, it is somewhat awkward, at least if you use the IDE itself. FlashDevelop still is as nice as ever, but you can quickly develop games nonetheless. I prefer Torque Game Builder though in retrospect.

Before I continue talking about the development itself, let’s take a look at the actual game. Sploidz was the first game I wrote using Torque Game Builder for Joshua Dallman, and since I still had all the assets in my subversion repository, it was an easy decision to try and port this game. If you want to play it, you can download it for free here. I haven’t ported everything: I’ve just rewritten the main characteristic features that make up Sploidz’s code in ActionScript.

Without further ado, here is the game:

Because the art is still copyrighted and I haven’t heard back from Joshua yet, I decided to create a free version that only uses “coder art” :-)

Mr. jRAD has said that this version looks cuter, decide for yourself:

Below you’ll find a description of the development and at least one helpful trick and most importantly a link to the source code of the “copyright-free” version.

Because the orginal version is way too difficult to be really fun, I actually sat down one more time and added code to make the platform slower if you’re in danger of losing (up to 3 times slower):

Development

I think I spent less than 20 hours on the project. It’s hard to say because I worked on it on three different days, but only probably less than 6 hours on each.

The main problems during the development were:

• How do I get the art assets into Flash?
• How do I use the IDE and objects in a way that is helpful?

Lessons learned:

Even though the project isn’t that big, it didn’t take long for annoying bugs to appear - mainly in the matching code, because it’s somewhat asynchronous and you have to make sure that an item doesn’t get removed between events, etc. So again, I can only say that assertions and lots of debug messages are your friend and are really useful for understanding the sometimes mysterious ways of non-obvious code interaction.

Again one of the biggest headache was how to make the game a game and this resulted in implementing the platform game element from the original Sploidz game, although I wanted to avoid that in the beginning because of the added complexity. Roy pointed out though, that if you have 8 columns and only 5 different item types, the main idea of matching items becomes trivial. It’s obvious, but I didn’t think of it while coding the proof of concept code. Of course you have to somewhat tune the speed and animation durations of everything to make it playable. The game is really hard at the moment, but that’s better than too easy and I especially added the “survival timer” in the upper right panel to allow for some competition and personal best times. I might change the platform code at some point to be more player-friendly, but I have more pressing projects to do at the moment: my Bachelor Thesis… /o.

As said above, I actually sat down and added a time scaler to the platform. The code is quite simple but helps the game a bit (I managed to survive 2 minutes and it was more challenging and less depressing to play the game ^ ^). The code is quite simple:

public function getPlatformTimeScale():Number {
    var maxRow:int = 0;
    for ( var column:int = 0 ; column < Grid.numColumns ; column++ ) {
        var firstEmptyRow:int = grid.getFirstEmptyCellRow( column );
        if ( firstEmptyRow > maxRow ) {
            maxRow = firstEmptyRow;
        }
    }

    const minScale:Number = 1.0;
    const maxScale:Number = 3.0;
    var scale:Number = minScale + (maxScale - minScale) * Math.pow( maxRow / (Grid.numRows - 1), 8 );
    trace( "Using platform scale: " + scale );
    return scale;
}

As you see, it uses a power function to make the platform slower only if really few empty rows are left.

Interesting things to know

• If you want to important a sequence of images (say you have an animation stored as picture frames diamond_black00.png to diamond_black15.png, only select the first image when “importing to stage” in Flash, otherwise you won’t get the dialog asking you whether you want to import an image sequence as animation.
• If you have animations that stores multiple frames in one image, you’ll have to split the images up into the respective frames. To do this in Photoshop make use of “guides” and slicing and notice the “Slices from Guides” button that is offered. It’s really helpful. You can also store the creation of the guides and the slicing as action/macro and reuse it which also saves some time.
• If you ever get the error “type was not defined or was not a compile-time constant”, you might have a symbol instance that has the same name and class name. Flash freaks out for some reason and displays this weird error message.

For added fanciness, I’ve also included two older builds that show the evolution of the game code.

Note: There are bugs in these builds, so they are really just meant to show the progress on the first and second day.

Click to open Sploidz0810 in its own window

Click to open Sploidz0813 in its own window

Fun note: I implemented most of the fancy features (combo matches, the score bubbles, the platform) today in a few hours (a lot less than expected). I think ActionScript is an okay language, although it lacks quite a few comfort features of regular modern programming languages (eg function overloading or delegate types that actually check parameter type).

Last but not least here is the link to the code: FlashySploidz Source I release the code itself under GPL and the art under Common Creative.

Over and out, Andreas