Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In your game assets do you make room for explicit sanity checks, or do you have some generally expected bounds which you assert?

I've been thinking about how we compress data and thought that it's much better to have the former, and less of the latter. If your data can exceed your normal valid ranges, but if it does it's an error, then surely that implies you're not compressing the data well enough?

What do you do to find out if your data is compressed as far as it can be, and what do you use to ensure your data isn't corrupted and ensure it's an official release?


I'm not interested in sanity checking the file size, but instead, how you manage your sanity checks and whether you arrange the excess size caused by the opportunity to do sanity checks by using explicit extra data, or through allowing the data enough file space (data member size) to be out of valid range and thus able to be checked merely by looking at the asset in memory after loading.


QUOTE: "runtime performance is valued very highly while maximal compression is merely a nice thing to have"

yes, but we're still having issues with our media being slower than decompression algorithms, especially with situations where programmers and data desginers have not considered the footprint of their data layouts and are unnecessarily creating assets that have redundant storage capacity.

I must assume that there are very few people who consider the importance of bandwidth outside of those working on platforms that are strictly bound by their data throughput rate or storage capacity.

share|improve this question
I'm not sure I understood everything in your question... I personnaly believe that asserts should be as strict as possible, but only on things whe know to be true. I don't understand though where file sizes come into the equation? oO – Jonathan Connell Jun 21 '11 at 14:31
He's asking about ASSETS not ASSERTS. ASSETS as in, textures, models, map files, etc. – TravisG Jun 21 '11 at 14:35
Yes, but he is also talking about asserts ("or do you have some generally expected bounds which you ASSERT?" emphasis mine). – Josh Petrie Jun 21 '11 at 14:41
@heishe Indeed he uses both terms. Not wanting to assume that he made a typo, (that you did, or just didn't read properly), I in turn didn't fully understand the question. – Jonathan Connell Jun 21 '11 at 14:50
oh well, sorry then. misread :D – TravisG Jun 21 '11 at 15:06
up vote 1 down vote accepted

I've done two things for release builds in the past, I've never added extra data.

First is all the data is described by a manifest that has a CRC or MD5 and at program startup the local files are checked against their expected hash. A patching system will do this for you, if you use one, so it's almost automatic.

Second is not to use asserts (which disappear in release modes) but simple range checks, for example does a bitmap have >2048 width, which will catch malformed data.

Josh Petrie's remarks are right on. Since we're talking about Games here, runtime performance is valued very highly while maximal compression is merely a nice thing to have.

Preparing data offline to unpack directly into C structures on a target platform is very fast technique that's been used for decades. While I'm sure it could be perverted into an attack vector it's far more likely that the EXE itself is violated and not the data and so efforts to failsafe the data are wasted and better spent elsewhere.

share|improve this answer
"but simple range checks, for example does a bitmap have >2048 width, which will catch malformed data", this is an example of extra space taken up as opposed to explicit checking data. You don't need to store a value that can hold any image width, you just need to store maybe a 3 bit value to tell you which one of the 8 different valid texture sizes this image is. – Richard Fabian Jun 22 '11 at 10:21
@Richard Fabian Ah now I see what you meant... oO – Jonathan Connell Jun 22 '11 at 10:36

I wouldn't bother sanity checking or asserting against the size of individual assets. I would have a report or something that could tell me the total size of my final asset bundle, and if that exceeded something I was comfortable with I might look into using a more aggressive compression routine or something, but that would be an entirely manual check unless I was working on a platform with very strict hardware limitations (and thus I had very strict memory budgets).

Regardless this would be something done at asset compile time, and would be optional, otherwise one might restrict the ability for end-users to mod one's game, which is usually a negative.

Remember that exceeding the predefined bounds of your asset volume may have just meant you mis-estimated your asset volume in your initial planning, not that anything has, per se, gone "wrong."

I also wouldn't worry too much about this because of most of the time compressing the data "well enough" or not is largely out of our hands -- sure, we can elect to use data formats that compress better under certain algorithms, but we shouldn't be doing that at the cost of quality of the in-game asset as a general rule, and unless we're writing our own compression there's only so far we can get things compressed. Unless I've misunderstood you, I sort of feel like this issue is overly hand-wringy.

share|improve this answer
I was going to answer along these lines but wasn't sure the question was about that. +1 for answering better than I could've ^^. I also thought he wanted to check assets at load-time for example to make sure they haven't been tampered with. In this case I'd have a hash look-up table to check the files (assuming that won't get tampered with too :P). – Jonathan Connell Jun 21 '11 at 14:53

It is telling that big games have not tried too hard to keep the file formats slim. Things like MD2 and MD5 would compress much much better and be much smaller if they weren't text formats, if they were triangle strips and fans and such, and other simple tricks. Its as if the team were deliberately not concerning themselves with data size.

On the other hand, compressing the textures and the cut scenes seems to be worth much more effort.

I would always favour robustness over size. It worries me when I see binary formats that are designed to fit a given C struct layout. That will really bite you later. And its where bugs can hide and, later, an attack vector. Best to go with nice formats that you read in and validate each and every load. Triply so if you start using user generated content or p2p.

I'm just a hobbyist who has looked at file sizes for the current spins on Glest and my own efforts. I see that Charles Bloom - someone who really made an impact on compression in the 1990s - then went to Oddworld. One wonders why compression wasn't a talked-up part of what he did there - you can draw the conclusion that if the top dog in the data compression field goes and does graphics engines for game company, rather than data compression, that data compression is not where its at. He probably cares more about load times in the gaming context? His blog is brilliant.

Compression is about data modeling. It is legal for all vertices to be in any random point in 3D space, but then your model would look like a porcupine. In real life, the actual position of a vertex - if you know those it is attached to - is fairly constrained and predictable. If you google "compress mesh" and such you find lots of academic papers, but I don't know anything mainstream.

I've played with making predictors. Its not so different from LOD makers really. It didn't seem to have much application - would people adopt a mesh format that was half as small again as existing ones LZMA2ed models?

share|improve this answer
It's not true that non-text formats compress much better - quite the opposite, in fact. On the whole, with a decent compression algorithm, a text-based format and a binary format containing the same information will compress to broadly the same size. – Kylotan Jun 21 '11 at 17:17
The other question of course is time. Generally it can take longer to compress and decompress a file if the compression is 'better'. This will make everything longer at some stage in the production and I think this is non-negligeable. I also think the real compression game for us has moved from the Disk to the RAM, and that formats with compression and no decompression overhead are the way forward :). (And thanks for the link :D) – Jonathan Connell Jun 22 '11 at 8:10

Rule 1) Only handle what you are designing for.

If you are developing a game where assets are being made by someone Other than you, then generally you will want to validate them. If they are only being made by you then it might be overkill to do upfront.

Secondly.. If you are running some sort of compression on your assets prior to use (I prefer in-memory expansion of pre-loaded data chunks because its where ya get the nice few second load times from :D), then you can have whatever it is that is compression or otherwise compiling your assets do the checks as well.

Remember Rule #1 ;) Too often people (read, programmers) try to handle every situation under the sun, because that is what we are taught.. All your application ever needs to handle is what it will run into.

As for a way to validate an overall asset set to make sure people havent screwed with it. Generate a hash value (Sha1, MD5, both?) and store it internal to your application. Then if the has value of your assets does not match what is stored, they are not running what you gave them.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.