Game Development Community

Handling Content Packs and different Directory Formats

by Randy Hearn (Magnum) · 10/12/2008 (1:29 pm) · 9 comments

The past week or so I have been working to build a small collection of items to place in levels so demos give a little more depth. Sure I can do what I need, which is programming with simple boxes, circles and such. But part of game play does include the artwork and making the game move and feel and reflect the artwork. As an example, making a character climb a ladder you can do without a building or later. But, you will not know if it looks "Real" until you actually place a ladder with rungs and a building for the character to climb (no, I am not working on that - yet!).

So I bought a few of the content packs from the GG store and setoff to build a small map so I can test weapons and player movement. One thing I found after I got the packs is reading through a few of the recent posts, was a complaint that some of the packs had each object in separate directories. Sure enough I downloaded one and they were, and the directory structure was completely different from the new TGEA structure. So does that make the pack useless? Of course not. Two things are important here. One is the artist needs to keep all the files in one directory so they can export the object as well as the textures, map, and modeling formats all at the same time. For me, in developing a game, having everything in a single directory saves me time in map creation as well as prevents duplicate textures.
So how do you solve this dilemma? Well, for some of you more savvy computer users, the answer may be obvious, others may not, so I decided to show one way how I do it. The answer is in the ZIP file.

I use WinZip to unzip the files. And below are the steps involved in doing that.. Including pictures!

NOTE: This process is the same for DTS,DIF,JPG,PNG or any files in a ZIP.

First below is the directory setup for TGEA. Which is different than most of the Content pack directories since they are mainly setup for TGE or the old TGEA directory structure. To move DTS files create a sub-directory under shapes to identify the pack name. Here I created a dir called WarehouseDist where I will store all the Warehouse District DTS files. If you want to break it further down which I will do later, is had a sub directory for shapes and interiors.
i60.photobucket.com/albums/h15/kd4vcu/torque/pack1-1.png
OK the following steps will depend on the tool you use to unzip the pack, but all should have similar functions. I use WinZip, so I will show that one. The first step is after you open the ZIP file is to search all the file for all files with the *.dts extension.
i60.photobucket.com/albums/h15/kd4vcu/torque/pack3.png
Once you find all of the files, be sure to select them all. For DTS,DIS,MAX or other formats you can pretty much select them all regardless of directory. You can use this same process to later move the texture files as well searching for *.jpg or *.png, depending on what the pack was created with. Just be careful when you use these generic image formats, that you be selective and remove any that are not in a shapes or interior folder. You could easily pick image files used for the creation of example HTML files or documents, and while it won't hurt to move them. You just don't need to them and creates wasted space on the drive.

Also, you want to make sure to skip any sky/ground cover/water or other directories and separate them out.
i60.photobucket.com/albums/h15/kd4vcu/torque/pack4.png
Ok the next step is to select the output directory and which is where most people stop at. However, move over the advanced tab and check the box to prevent the files from being expanded into the path they were zipped up with. This will place all of the files into the root directory you are unzipping to.
i60.photobucket.com/albums/h15/kd4vcu/torque/pack6-1.jpg
Doing this you may get a file exists message. For DTS and DIF shapes I generally look at each one and manually determine to replace, or rename the file as something else. This lets me know of duplications. For DTS/DIFs in you should really have no problems, but as you can see it can happen. So I elected not to overwrite and took the file with the earliest modified date. For textures you can simply so No To All and ignore duplicate names.

i60.photobucket.com/albums/h15/kd4vcu/torque/pack7.png
So does it work? Yep.. Just start TGEA and start placing objects and only having to click one directory to have all the objects listed. (ok, just placed a few, wasn't trying to artistic about it).

i60.photobucket.com/albums/h15/kd4vcu/torque/pack9.png
Just a tip for those who may have never taken the time to see what options were actually available with their ZIP software.

And some packs come with example missions and I realize that doing this will require the .mis files to be edited. I generally have to do that anyway as they very seldom match the structure I already have.

#1
10/12/2008 (2:19 pm)
The paths are only illustrations for how someone GG decided to organize things, each developer should set up their directory structure in a manner that is most intuitive to them. Keep in mind that when you modify the paths that the scripts that reference those shapes will have to be modified also. There's more than just .mis files that will need to be changed.

But nice trick with winzip by the way. I usually just copy/paste where I want things to go.
#2
10/12/2008 (2:56 pm)
Yes, that was part of what I tried to note. So far every example or pack I have downloaded has had to be edited since the structure doesn't match the directory :( No big deal... Open all the files up in torsion or word editor and do a global "find and replace".. :)
#3
10/12/2008 (3:50 pm)
Some years ago I was playing a bit with "Vampire: The Masquerade - Redemption" and its editor set...

The nice thing was that it used .nob archives (they were simply normal .zip archives, not compressed and with the extension changed to .nob) to organize the assets... It was very simple to add your own content and download and install other user-made content...
Pratically you had to create an empty duplicate of the directory structure and place your own files in the righ place based on the content type (shapes in 3d dir, scripts in scripts dir, sounds in sounds dir etc...)
... then you had to zip the "head" dir without compression and manteining the path structure (not full path but relative path), rename the file with .nob extension instead of .zip and place that file inside the main directory...
Then the executable read the content of the .nob file and its internal directory structure and manage all the files inside as they are in the specific directory...

Using a similar approach in Torque would be nice...

Unfortunately I'm really more on the artistic side than on the coding side (wich is an art too!) and so I don't know how to implement a similar system...

If some talented coder read this maybe can take this as inspiration for a resource that behave in this way or similar ;-)

JoZ
#4
10/12/2008 (3:54 pm)
Before I became an employee, I was thinking about working on something similar to what you stated JoZ. My initial attempt at the concept was released in this resource: Environment Package Save/Load System.

This resource allowed level editor to save and load various environment and weather systems to save time when creating multiple maps that share similar FX. I'm sure this could be expanded to fit your needs.
#5
10/12/2008 (6:29 pm)
@Joz/Michael

The only problem with that approach is the content packs would have to be packaged up before hand, and I haven't read the whole resource. But, having in a plan ZIP files means I can move then to my constructor directory or wherever I want. Zip files allow that option.
#6
10/13/2008 (9:00 am)
Maybe I have to explain better the approach of V:TM-R ...
It has all the assets packed in a zip archive (just rename to *.nob instead of *.zip)... When you want to add something you can create a folder and inside it replicate the exact folder structure of the game (that you can also look at opening the original .nob file that ships with the game)... zip that folder chosing the option to mantein the internal dir structure... rename your "XYZ.zip" (example name) to "XYZ.nob" an place it...

A) ...in the main dir of the game

or...

B) in a subfolder, for example "myGame", in that case you have to run the executable with the arument "
executable.exe -user "myGame"

Now in both cases the engine read the content of your new created .nob file and its inner directory structure, acting as all the files in the .nob archive are placed in the proper directory where they have to be...

And since you can add all the .nob archives you want, also placing all inside the same directory, the advantage is that you can manage your addictions really easy, making simple add and delete content and mantein a division between the content of the various pack you have...

Many ways to polish such approach with advantages and disadvantages can be found obviously...

But what I was just suggesting was a way to approach loading of "extra" content (that require of course an engine modification... the details of a similar mods may vary...)

Your resource its a different thing, is a very good and simple way to manage the adding of a content pack with the engine as we have it...

I can't see which problem you want to outline in your previous post, I'm not telling you're wrong just I didn't understand .

I specify since I'm not english mother language, so I don't know how my words could sound... maybe for the same reason I didn't understand your previous post so I ask you to explain it better, like you have to speak with someone really stupid... (LOL)

And maybe also for the same reason my explanation of the approach of V:TM-R could sound not clear...
If so, my excuses ;-)

JoZ
#7
10/14/2008 (2:05 pm)
JoZ,
Torque already does exactly what you are describing with .zip files (easy enough to track down and change that to .nob or .foo or .bar in the source code if you would like). I believe it also handles compressed .zip files.

It will treat the name of the .zip file as the "folder" that all of the files and folders inside the .zip are contained in.

For example, I could zip up the scriptsAndAssets folder in a TGEA GameExample (preserving the folder hierarchy) and replace the scriptsAndAssets folder with a scriptsAndAssets.zip file. As long as they are named the same then the engine will treat the .zip file as a "folder" named scriptsAndAssets and you GameExample will continue to work properly.

The only caveat is that you have to leave the files in the executable folder (game's root folder) like main.cs and OpenAL32.dll unzipped. But, other than that, you can zip up and folder in your game structure and use the zip as a replacement.
#8
10/14/2008 (2:25 pm)
Hi Matt! :-)

Tnx for for the trick I really wasn't aware of that!

So I think it would be not so difficult to look in the source code to implement it a bit different, so that I can have it reading all .zip files contained in a certain directory (or specified in a certain .cs file, not sure wich approach would be better...) and treat the content as it would be contained in a certain directory instead of treating as it would be contained in a folder with the name of the .zip file... The advantage I see in such approach is that you can add many .zip files and find all the content of "zip1.zip/shapes" and "zip2.zip/shapes" under the shapes directory in the editor... And so simplifying tha way of managing the add or delete of packs (as long as they don't require specific engine modification, as for example the magnific FPS Env pack...) ...

Just a question... to do such modification which source files do you think I have to look at?

Many tnx for the great hint!

JoZ ;-)
#9
10/14/2008 (8:26 pm)
@joz,


Sorry, I thought I had posted a response. Your English is fine:) I think we are talking about similar things here. I was just talking about how to get the current content into your game, where you and Micheal were referring a way to actually manage it through the game.


@Matt...

Thanks for the tip as well. I was not aware of that either, but something to consider for a later project:)