Abuse Video Game Demo

Abuse Video Game Demo

The following demonstrates how Thinstall can package any game application into a single file, protecting the data contents and presenting a professional image to the end user. This demo also demonstrates Thinstall's built-in Installer which can add Start Menu shortcuts, Desktop Shortcuts, and Control Panel Uninstall capabilities.

Downloads:

Abuse - Packaged with Thinstall (2.4 MB)
This single EXE can be run directly from an internet Link. Thinstall's
virtual file system makes the game think all of the files have been extracted to
the hard drive, however the install process is a single copy-file operation.

ZIP of orignal files and Thinstall project (2.8MB)
Contains the original data files needed to run the game.

Screen shots

Thinstall for Game Developers
During my 10 years as a commercial game developer, every video game that I have worked on has had its own proprietary file packing scheme. File packing has always been a low priority, but essential tool for game developers. Each file packer had its own pitfalls, usually because the amount of time spent on the file packer was time taken away from the game. Before I get into the pitfalls, I'd like to talk first about why I always used a file packer.

Why most big commercial games use file packers:
There are many advantages for using a file packer in a game. The primary reason is load-speed. Often games have thousands of files, and the game must read a good percentage of those during its first load. When the operating system performs a file load it often must perform several file seeks on the hard drive just to locate the file data. By packing the data into a single file and caching the file offsets in a big block, much of the hard drive seek time is eliminated. File packing can speed up a game's load time by an order of magnitude. Some other reasons I use a file packers:

Smaller install size. Even without compression, a 1000 packed files will occupy much less hard drive space because Windows stores a lot of extra information about each file and pads the file size to the hard drive block size (512 bytes?).

When Doom came out with its WAD files, I knew I wanted the same in my first games. Seeing all the game's files on my hard drive spoils some of its magic. By looking at your files, users could easily uncover all the games secrets and Easter eggs - but if it is packed, the user will want to keep playing and exploring to see if they have found everything.

Data protection. Packing our game data helps prevent data theft. We were usually more scared of publishers ripping us off than users. We assumed that a clever hacker could probably reverse engineer our format and take our data, as they do with all of id software's games. This is a sign your game is popular and selling well, so that doesn't bother me immensely. But when we sent a demo to a publisher, we didn't want them to have full access to our bitmaps, sounds, models, etc. Possibly they might decide to can the project, say they own all of the data, and hire a different development team to finish the work using the data you so graciously gave them. It may sound a bit paranoid, but I have actually seen this happen.

Less technical support issues. If our games have only one or two files then there are a lot fewer things that can go wrong on the end user's machine. Game users like to play with your data, and often the changes they make to your data can cause it to crash or do weird things. Also, the more files you have the more chance there is a game might accidentally delete something.

CDROM seek times. Games that play directly from the CDROM (mainly console) will highlight the incredibly slow seek times compared with a hard drive. To speed up a CDROM game load time, it is important to arrange data file in the order they will be read to prevent as many seeks as possible. Unreal Tournament PS2 version went from a 5-10 minute load time to a 30 second load time by rearranging the file data during the packing process.

In house development. During the development of the game, it is easier to keep a working version if everything is packed together. Simplifying the process of getting a new working version is essential when dealing with artist, play testers, sound people, and other programmers.

Some of the problems I faced from "home brewed" file packers, and how Thinstall solves these problems.

Home brewed file packers always require a new API for programmers to use when opening, read, and closing files. While this is not a huge concern, it is one more thing for new programmers to learn when they join the development team.

Thinstall works at the lowest level possible on Windows, so programmers can continue to use all the functions they are used to. An unpacked game can be converted to a packed game with no source changes or recompiles. For example, programmers can use fopen(), open(), CreateFile(), creat(), etc. to open files and fread(), read(), ReadFile(), and _lread() to read from the file.

Home brewed file packers are not able to pack data files used by external libraries or DLLs. For example if your game wants to play an mp3 file with a spiffy mp3-playing library, you must obtain the source for the mp3-library and modify it use your file API. This can be error-prone, and in some cases the source code is just not available.

Because Thinstall intercepts file activity at a very low level, it transparently allows external libraries and DLLs to read from the virtual file system. This permits almost any game to be packaged as a single EXE no matter what tools and libraries it uses.

We always said we would add compression "eventually", but we never did. Not one single project that I've worked on has used file compression. This is strictly for the reason that the development time could not be justified.

Thinstall has transparent decompression built in. Thinstall decompresses 64k blocks of the file at a time as the application tries to read the file. Thinstall's decompression is incredibly fast assembly and barely more expensive than a straight memory copy. The advantage of loading compressed data, is that reads will be accelerated due to the fact that less work is being done by the hard drive which is much slower than decompression.

Home brewed file packers always had bugs and are not properly tested. Debugging these problems often could eat many days off of the development schedule.

Thinstall's core file reading and packing is well tested in hundreds of applications.

Some games did not allow loading from external files, which meant repacking the game data every time something changed. With larger games, the packing process could take 5-15 minutes.

Thinstall allows the game to read from both the external filesystem and the internal package archive. Developers can even override individually packaged files simply by placing the file at the appropriate location on their hard drive. This is ideal for work in a team environment. For example, the artists can have a single EXE of the game and then replace individual textures or models on their hard drive without having to regenerate the package. Once they are satisfied with their work, they can copy their artwork files to the main package repository where it will be included in the next package build.

Home brewed file packers are not able to pack DLL files. The window operating system does not provide any way to load a DLL other than directly from disk. Often our games were separated into DLLs to enforce modularity and to speed up the recompile and link process. At the end of the project, there was no time allocated to move everything back to a static EXE and if we stuck the DLLs in our file pack, the system wouldn't be able to load it.

Thinstall replaces the Windows operating system loader and loads DLLs directly from a package file without extracting them to disk. There is a lot of magic going on here.