battleMETAL - Why Quake / Darkplaces - Part 2 - File management / File type loading

Files and their management; kind of important

This post was a bit late, things are getting a little busy around here.

One aspect about game coding that I like to pay attention to is file loading and management. Now this may seem like an obvious thing for any application, but one could be surprised at the variety of management strategies. Some games will hardcode data files to be loaded in a certain order. Other games may keep all their files compiled into the game itself. Quake uses what is called a Virtual File System, it sounds complicated but it boils down to this: When the game Quake runs, it treats its home folder like, say Windows, treats a folder. Quake knows how to dive into folders to get files, create new files. It has a set of file types that it can read and has loose preset folder structure.

Darkplaces really just extends the file types that Quake can load, mostly for modernization, but this also has an impact on other game aspects like graphics. Darkplaces allows for higher resolution images to be used, higher-poly models, and cleaner sound formats. Quake’s organizes these files pretty much for the programmer. Yes a programmer can extend the folder structure to their heart’s content, but that should only really be a last resort. An example of this automatic organization would be loading menu graphics.

/Quake/id1/gfx/

If we break this down, we see that id1 contains all of the game files that Quake needs to run, and that the menu graphics are then packed into the /gfx/ folder. This paradigm is also used for models with the /progs/ folder. An interesting note about the /id1/ folder, this is just for Quake’s game files. Modders wanting to make their own games and mods, can easily make their own separate folder such as /battleMETAL/ and then Quake / Darkplaces can switch between the two folders during runtime. This allows users to seamlessly switch between their favorite mods without too much interruption of gameplay. The caveat for my game, battleMETAL, however is that it's a total conversion which precludes compatibility between Quake’s settings and battleMETAL’s. So for my game, I stash everything in the id1 folder with the assertion that a user should not try to run both Quake and battleMETAL in the same install.

Why does this stuff matter? It makes management of dozens of game files easier and reduces to the amount of file loading that the programmer has to write themselves. Most game assets for Quake are loaded in the game code through the following functions precache_sound, precache_model, precache_pic. Even better, the textures for models are precached when their parent model object is, thus reducing the number of precache calls. This makes adding new content super easy as well. The built-in file loading code of Darkplaces knows how to process any of the files that are added through a precache call.

The final piece of this good feature is, we have all these files, how do we package them nicely for a release? Once again, Quake and Darkplaces have an easy answer. Within the game’s asset folder, Darkplaces can read and open .pk3 files. ‘Pak’ files are just a .zip file that has been renamed. This allows the developer to keep the release version of the asset folder clean. By naming pk3 files in successive numbers - PAK0.pk3, PAK1.pk3, the developer can actually split up game assets. Now, why would anyone want this? Think about it this way, if the developer splits game models into PAK1 and sound effects into PAK2, the developer can then patch the models by simply releasing a ‘new’ version of PAK1 with the new models. This siloing of resources is incredibly handy.

In conclusion, Quake / Darkplaces file-folder system implementation is clean and performant. It is useful at-scale, during development and is savvy in its organization for release. This is a strong reason to use Darkplaces as a game engine for simpler game making.