A DSGameEngine helper class
General Description:
In the Doom (Not 3) days they were called Wads. In the Blizzard world they are called MPQs. In the DarkStride world they are called Gobs. All three of these things are protocals for grouping together many files into a single file, much like PKZip. Imagine even a simple game like Doom (Still not 3) without its precious Wad files. There were over 1100 graphic files, 25 data files and another 300 sound files totalling around 56 meg of data. Distributing and storing close to 1500 files is a messy and insecure way of doing things. So instead a single file is created and all the other files are cramed inside of it.
Types Of Storage:
Type 1.) Binary files
This is your standard picture, sound or video clip. All of the data is stored as a stream which means the Gob file doesn't need to know anything about it other than it came from a file. The binary file is given a key when its added to the Gob, the key is used to later reference the binary file from within your code.
Type 2.) Data table files
Now lets say you needed to store the purchase price of every unit in your game. You don't want to hard code that kind of information in the code so instead you throw it into a flat text file for easy reference. Eventually you would likely add the text file into the Gob just like your pictures. Gob formats allow a better option. You can add a special table to the Gob file which acts much like a Database Recordset. You define new columns, there name and type, and then add rows of data into the table. The end result is a Database like collection of data without the overhead of Database drivers or third party packages. Stored in the Gob file like a binary file, the data table allows a great deal of game information to be stored inside the Gob without the programmer having to create a storage medium.
Type 3.) Sound files
Gob files now have integrated support for sound files. There are special warnings built into the system that helps you filter out files that won't meet DX's criteria.
Type 4.) Graphic Files
These are your basic BMP or JPEG. Storing things like a mesh or the more complex graphics (such as PDF or .X) fall under the binary file catigory. Graphic files check the textures for the powers of two problem and some other common texture mistakes. There is also built in support for background color alpha channels.
Type 5.) Borders
Building upon graphic files, borders are mearly a collection of graphics put together with some meta-data. Unlike the other types this is an internal Gob structure which has no meaning outside a Gob file. These borders can be loaded into the DSGameEngine and easily used to provide menus and forms with a stylist borders. (See Metal Marines for a good example). This allows simple modifications of the Gob file to allow "skins" for forms.
The Editor:
Though a Gob file can be completely minpulated using the DSGobFile and DSGobTable classes, a feature rich editor can be located in the downloads section. The Gob editor will allow you to add binary files and data tables into the Gob file, as well as re-extract them at a later date. You can also easily update a binary file in the Gob file from a new graphic with the click of a button.
What you shoulden't do:
Though the Gob file is a superb method of storing game information, I would discourage you from saving things like user preferences or saved games in the Gob file. At the very least that kind of information should be stored in its own Gob file that can remain fairly small. Imagine a user tryign to backup there saved games and finding that they have to backup the entire 200 meg Gob file in order to also backup there games and user settings. I guess the moral of the story is be careful about what dynamic content you store in the Gob files.
Copyright © by DarkStride All Right Reserved.
