Method of compressing tile data [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Because this question may lead to opinionated discussion, debate, and answers, it has been closed. You may edit the question if you feel you can improve it so that it requires answers that include facts and citations or a detailed explanation of the proposed solution. If edited, the question will be reviewed and might be reopened.

Closed 3 years ago.

Improve this question

I'm making a game in which a row of tiles may look something like this, in which each block is represented with a unicode char:

"gggggggggggggggggggggggggggggggggggtttttttttjjjjjjjjjjjjjjj"

So my method of compression shortens it to this (I may have the numbers wrong, it is just for demonstration):

"g23 t9 j17"

Seems fairly simple right?

My friend suggests to use an enum and represent each block with a number and work with bytes, reasoning that numbers are faster to compare

So it may look something like this 0001 0002 0004 0003 0034

I said that using this is pain, and saving a few ms isn't gonna help the pain I have to go through

I'm using C# and Unity, which method should I use for compressing world data?

• DMGregory: It sounds like you've already decided which approach you prefer, and reasoned that the storage or performance difference is not significant for your use case. What do you need from strangers on the Internet like us?
• Coder2195: Im asking about whether my friend approach is better or mine @DMGregory
• DMGregory: "Better" under what criteria? You've raised reasonable objections that this approach is less intuitive or convenient for your style of working, and that milliseconds of performance are not an important consideration for your needs, so under those criteria, you've established that your way is "better". Other people may choose different criteria and arrive at a different answer, but that doesn't make one right and the other wrong. It's not clear why one would prefer criteria chosen by a stranger on the Internet over those chosen by someone with far more experience in the game you're making: you.

Answer 1

My friend suggests to use an enum and represent each block with a number and work with bytes, reasoning that numbers are faster to compare

If you write your files as utf8, then you are effectively doing this in your uncompressed method: each utf8 char is a number in the same range as a byte (8 bits). If you started doing bit packing, then number method would be more efficient: it would allow you to fit multiple blocks into a byte (depending on the number of block types). However, using char gives you the advantage of creating levels in a text editor and it's easier to understand the level data seen in your watch window.

The compression scheme you're describing is Run-length encoding. It would definitely be more efficient if you wrote your counts as numbers instead of strings.

However, for the compressed version you might be better off using an existing compression library instead of doing something painful. It's pretty simple to use SharpZipLib to decompress files. While you could likely get a higher compression ratio with a custom scheme, it's pain you could avoid and unlikely to be worthwhile unless your world data is measured in GB.

I'm assuming you're only concerned about the disk size of your world data since your runtime data will presumably be constructed world objects (tileset images, collision, etc) and you'll discard the level definition after load.

• DMGregory: Minor technicality: a C# char type is UTF-16, so it's two bytes. And storing the numbers as characters is also bulkier. In the example "g23 t9 j17", we could store each number in a single byte, so in binary form the whole thing could be just 6 bytes. In text form (including spaces), it's 20 bytes. Not that this will break the bank by any means.
• idbrii: @DMGregory: I didn't know it was utf-16! Clarified that you'd write files at utf8. OP's friend had an odd number of values so it wasn't run length encoding, but mentioned that regardless to be clear of the merit of their method. Thanks!