I have set up the basic building blocks for native packaging within Doomsday 2.
The guiding principles for this design are maximal utilization of existing functionality — FS2, Record and Doomsday Script — and keeping everything simple yet flexible.
- FS2 is relied on for the “concrete” manifestation of a package: folders and files. Basically any folder with the
.packfile extension can be a loadable package, as long as the metadata requirements are fulfilled. Furthermore, since FS2 is a virtual interpretation of data residing elsewhere, Doomsday can interpret any available data as a package at runtime, regardless of its actual format and location. Recordis where all the metadata is stored, perhaps as key/value pairs or scripts.- Doomsday Script can be used to perform load/unload actions, or any other scriptable functionality. Since all metadata is in records, DS is able to access all of it without restrictions.
In combination, these make for a flexible and powerful package mechanism that should serve all the possible use cases that we’ll have for packages.
I see packages as a very fundamental concept when managing a system like Doomsday or, analogously on a larger scale, a Linux distribution. They bring the right level of modularity so that game assets and other components can be isolated from each other, and thus manipulated as independent entities.
Packages can also be stored in larger repositories, for instance on the internet, and since they can have (globally) unique identifiers, there is no confusion as to which package is being referred to. For instance, the latter case is required to solve a long-standing issue of knowing which packages were used at the time when a game was saved, so that later on the same ones can be used when the game is loaded (possibly on another machine or installation of Doomsday).
The so-called “resource packs”, or more accurately packages containing rendering or audio assets, are an important subcategory of packages. These should not be confused with the more general concept of a package, though: an asset package is merely a package that contains one or more assets, however not all packages contain assets.
When it comes to conflict resolution between package contents (something that Snowberry is currently responsible for), the key is for the metadata of a package to identify the assets contained in the package so that Doomsday can check that two or more loaded packages don’t provide the same ones.
While the plan is for packages to be identified using a reverse domain name notation (e.g., net.dengine.renderer), something else is needed for identifying assets. One possible approach would be to use Doomsday resource URIs for this; this would enforce validity of the used identifiers while avoiding the issue of multiple “namespaces” for identifying which asset is which.