The Making of Mystic Balloon


Idea by Gaveno

Code by Gaveno - JO3RI

Sprites by CastPixel, Gaveno & JO3RI

Banner & titleScreens by Castpixel


When Gaveno wanted to join TEAM a.r.g. (or was it the other way around) the team asked him to create a game, so we would be able to assess his skills and from that challange a game was born. At a certain point in development, Gaveno ran out of space with only 7 levels and no room for artwork. But because what he had done so far, Gaveno was accepted into the team and started coding right away. Not on Mystic Balloon, but on Trolly Fish, another game that needed some help.


Castpixel designed a beautiful titlescreen for Mystic Balloon and once we had published Trolly Fish, Gaveno restarted coding on Mystic Balloon. JO3RI gave him the advice to code the map engine in a different way and what we came up with, is what we would like to show you in this technical page.


It shoudn't surprise you by now, that every map based game uses tiles. The only difference here is, that we used 16x16 pixel tiles (opposed to the 8x8)

With these tiles we are able to build a complete map, that has been set to 24x24 tiles, or is actually 384x384 pixels (147456 pixels using 18432 bytes). At this rate, only 1 map would fit, but we're using tiles, so a map is actually 24x24 bytes (576 bytes). Now Gaveno wanted to fit in 20 levels, which means 11520 bytes. Altough that's not bad, but we needed even more compression.


When STG came to the 8th Arduino Jam, we had been discussing all sorts of map building systems. One of the most promising systems, would be the one that uses 1 bit per tile. Yes 1 bit. Tile on or Tile off.

Now I can hear you think: "ok , fun and all, but you have 11 different tiles and a bit can only be 0 or 1, that doesn't give you much room for all those tiles you have." Aha ... and now the fun really begins.


Before we start explaining, let's calculate. A 128x128 pixels map would use 2048 bytes. Using the classic tile system with 16x16 pixels for a tile, we would only need 64 bytes for every map AND with the BIT-tile system, we will need only 8 bytes !!! YES 8. In our game we would go from 576 to 72 bytes.

As an example we'll use a 8x8 map, which equals to 64 bytes, but because we'll use bits instead of bytes, it's actually 8 bytes.

If we replace the 0's by a tile and the 1's by another, we already have a map using 2 different tiles, and a size of 128x128 pixels.

Let's do some magic. What if we can make a function and call it getTile, that will look at the neighboring tiles, before it decides what tile to render? (some how it reminds me of the game "mineswiper"). If a tile has no neighbours (all 0's) it's a lonely tile. If it has no neighbour above, it's a tile with a border on the top. If it has no neighbour left and top, it's a corner tile. And so on. And voila, we have a map using the correct tiles, with a size of 128x128 pixels, using only 8 bytes.

A game has more to it than a map, it needs elements like enemies, collectables, a starting point and an ending point. Those are stored as x,y coordinates for each element. While the actual size is 384x384 pixels, a byte would not be big enough to position each element on the map, but we'll put our elements on the same grid as our map: 24x24 and multiply every coordinate with 16. This way 2 bytes for every element will do.


Voila, this how we reduced the bytes used for our maps. Imagine what we can do when, we start combining this method with the one explaned in Virus LQP-79. Enjoy the game and do visit the highScore section to find out how to post your score.