Vol. 3 Iss. 1 - April 2001

To All Space Wasters Out There

By Sane <sane@telia.com>

Note: Most of this article was written in December 2001. Now I've got a bigger hard drive, and some stuff I mention was new back then but isn't anymore. The article is still not redundant, just thought I should make these notifications.

Note: In this article I will mention negative sides of a couple of games, but that doesn't mean I dislike them, in most cases it's rather the opposite actually.

The problem

Lately I've been noticing a negative trend in the QB world. People are wasting loads of disk space for no good reason, and sure, people generally have more disk space than earlier, but still there's a big enough amount of reasons why you shouldn't waste space.

First of all, it slows down at least some parts of your programs a lot. Disk accessing is very slow when compared to a lot of other things.

Secondly, people won't download your stuff. Unless you get publicity to your game (or whatever you've done), most people won't waste the time downloading it in case it's too big, especially not the <=56k people. Sure, Zeta is large, but it's also got a lot of good publicity, so the size doesn't hurt it much (although I think they could've made it a good bit smaller)

Thirdly, at one point there's no more disk space. If your game wastes space, and the player has to choose between keeping your game and installing Counterstrike, what do you think he/she'd choose? Not very likely the game you've made... I for one run out of disk space all the time, and the big QB games, no matter how good they may be, often are the first to be deleted.


Now you know why there's a problem, although you might not think so, and now I'm gonna suggest some solutions to avoid space wasting.

Don't use PRINT/INPUT for file input/output. PRINT always writes numbers in string form, so that for example 127 needs three characters instead of the one character that would be needed if you instead used the ASCII number. PRINT also puts "" around strings, and spaces between all numbers. Another thing, although it's related to speed rather than space, is that binary access is faster than random/input/output/append access. As an example: when unpacked and with levels compiled, the 3D action game series ATTE, that's really awesome in every other aspect (when comparing to other finished QB games, not engine demos), takes about 30 megs per game, and after looking in the data files, I guess about half of that space is taken by spaces. Apparently the author used PRINT/INPUT for all the file accessing, which made it take somewhere around 15 megs (my guess) more space than needed...and still there's a lot more that could be done to make it more size efficient.

Another thing you should do is to make your file format more effective. Don't write INTEGERs or LONGs if the possible values are within the range of 0-255 and so on. Try to find better ways of storing the larger chunks of data in the format, like a map for example.

If you're using large files you should try to find a way of compressing them, and if I get enough response about it this issue, I will start a series about different kinds of file compressing.

I hope at least someone had use of this article. Please write to sane@telia.com and tell me if you thought this article sucked, was useful, made you think differently or if you just agree/disagree :)