Sets and Maps

The second half of my flood filling proof is available here. In addition to mu, you'll also need another little helper library to load the VERGE 3 resources: gcsio

For testing, I included the overworld map from The Sully Chronicles, Simple Edition. I perform a couple flood fills on the first map layer, using the same MuFloodFiller interface from yesterday. Pretty swank!

I also demonstrate iteration over the map layer, using both indexing and then a formal iterator. The iterator form is the more interesting of the two. The nifty thing about classes which implement the Iterable interface is that you can loop over them with Java 1.5's for-each construct. From the proof:

for (Short tile : layer) {
    if (tile == match) {
        result++;
    }
}

This loops through every tile in the layer. With this decadent new superpower, I wreak havoc on Sully's domain by clamifying stumps and doorifying boulders! Never mind my flooding of the ocean with stars and overpopulating the southern land mass with bunnies.

Cower! Cringe! TREMBLE at my might!

Right. So, I could iterate similarly over the pixels in a MuBitmap:

for (MuColor color : bitmap) {
    ...
}

This is possible because MuBitmap implements MuMap, just as VERGE3_MapLayer does. MuMap in turn implements MuSet, which implements Iterable.

If my terminology is a little confusing, note that "set" and "map" as used in Mu do not refer to mathematical sets (unique elements) or hash maps (key/value pairs.) As explained yesterday, a MuSet is basically a list, and a MuMap is a grid. I chose this language because the terms help get me in a more game-oriented frame of mind.

Think tilesets and bitmaps.

As with interfaces, I am making heavy use of the context. Mu has no formal "tile set" object, for example (gcsio has VERGE3_VSP, but this models a file format.) A tile set is simply a MuSet<MuBitmap>. The layers in a VERGE3_MAP are a "layer set", or MuSet<VERGE3_MapLayer>, which is ultimately a MuSet<MuMap<Short>>. A MuBitmap is ultimately a MuMap<MuColor> and so forth. With all of this common ground, you begin to find a lot of ways in which to reuse code.

I have another demonstration in the works which will reuse code for animation. Some of the classes are already present in the current incarnation of Mu, but the idea is as follows:

The MuAnimation interface models animation. Ideally, I should be able to reuse a substantial amount of code from an implementing class to animate just about anything. Tile animations, sprite animations, or full motion video.

Furthermore, because a MuAnimation is a MuPaintable, and also manages a set of paintables, I should be able to trivially embed animations as frames of other animations. This would enable the composition and execution of a fairly visually complex animation with very straightforward code. Crafting a little Flash-esque animation composer with bitmaps only would be a nice proof.

At any rate, a lot of entertaining stuff to explore!

Barring circumstances beyond my control, I should have SVN properly set up on my host tomorrow. Then I can get everything versioned and more developer-friendly. At that point I'll slowly be committing portions of FORCE and MOME RATH as I make the rounds documenting and polishing stuff.

Until then!