This is a sort of script-heavy post, I apologize in advance. But like I have mentioned in a previous post, I have been working on a level editor for I Hate Traffic. One of the concerns of the game is somehow storing these levels as something small and compact enough to fit easily into copy and paste bits of code. We all love those massive million character codes, but since we are planning on making this a game with levels built into a level select system, we decided to make things smaller…er. Prepare for some geekiness….
I first took the raw code for the level above…
So 2,187 characters… is about ~2.2 kb. Not much right? Sort of. It’s just a tiny bit on this scale, but once you start putting it on a larger level (thousands and thousands of plays) that data transfer can add up. Every three digit number (displayed back to back) represents a single tile in the system, in case you were wondering.
So in an attempt to shrink down that number a bit I formatted the tiles to write themselves down sort of like a gif file. Gif files reference a table of data, then run a set of algorithms to eliminate the need to map every pixel independently. So instead of 109109109109109109 to represent 6 tiles we can put in 109×6 instead, which is much less beafy. So, after this algorithm runs….
We’re down to 1,802 characters, or 15% streamlining. Not bad. And given the circumstances and complexity this precentage can rise up into the high 50-99% compact rate, but since this is a rather complex level it’s not streamlined that heavily. So let’s go one more.
With the help of Joey we have discovered that dumping the code into a ByteArray makes it even smaller. ByteArray are containers of bits, as way of accessing and working with binary data. In this way we can move things around in smaller chunks of data. Transferring the data into byteArray data and compressing… well…
We’re down to 676 characters, tapping out at only 30% of the original code.
2,187 -> 1,802 -> 676, not bad. That’s for a level with 625 tiles on it, pulling from a library of about 100+ different tile types.
So in this way we can store much smaller chunks of data. I’m guessing there’s even smaller ways to store the data beyond these methods but we’re extremely happy with what we have come up with so far.
Programming aside, the game is going well and the tools in the editor should be plenty fun to play with. Should be done soon!
Tags: coding
If you are using less than 256 tiles you can use a single byte to store each tile.
Wich programs are you using to create an flashgame like this? And how long have you been using that/those softwares?
I would have started with base64 encoding (since it looks like you just have a series of decimals), and then moved forward with run-length encoding and then a compressed byteArray (which looks like it already uses base64). On the other hand, the order in which you encode things does have an effect on its compressability.
Depending on the values available in each three digit number, you might be able to get away with one byte per tile, in which case starting with a byteArray might be smarter.
Have you compressed the byteArray?
byteArray.compress();
byteArray.uncompress();
Found that out from Glaiel-Gamer
If you have a big grid that uses a limited subset from a larger library you could make an index for each map, where you map a library-id to a value that’s the smallest you can use for this map (eg: a map that uses less then 127 different tiles uses 7 bits per tile). Then write your index and re-encode tiles to the bytearray and compress that.
And of course there’s image compression: use a BitmapData to write each tile-id to a pixel: you can also do something clever with the ARGB space (compress 4 maps in one image, or use smaller image etc), then encode as a PNG. (not JPG because it’s lossy and will create tiling artifacts).
And there’s re-ordering of compressed bytes: sometimes if you use a re-ordering algo on a compressed bytearray the result will re-compress nicely again, but that depends on the kind of data you have.