Game Development Reference
In-Depth Information
5.4.1 Use of a Real Database
One possible consideration is using a real database system instead of raw files as
a metadata storage. It has some benefits. A database will be generally more
reliable and things like differential update can be handled automatically because
most databases support the concept of transactions and the differential backup. In
the case of tags, by using a database system, sharing can be dealt with naturally
without relying on a VCS. It may be slow in overall operations, considering the
relative cost of database operations in comparison to the raw file operations. This
may be worth pursuing.
5.4.2 Build-Time Generation
In order to minimize the waiting time, asset databases can be generated with each
daily build. So, if one gets the latest build, metadata databases will be ready for
use and require minimal waiting for gathering only metadata for the users custom
assets. Further in this direction, one can even try a submission-time database build.
In other words, asset databases are rebuilt every time there is a new data commit
to the repository.
5.4.3 Metadata-Aware Format Design.
If you have the luxury of redesigning or changing file formats for each asset type
and associated export pipelines, you can make gathering of metadata more ecient.
For example, in the header part of each asset file, you can allot a special block that
contains metadata for the asset in an optimal layout. Then, without loading an
entire asset, the system can collect the metadata very quickly by reading just that
header block. To accomplish that, the export pipeline must update that metadata
header section properly every time while exporting an asset.
5.4.4 Thumbnails
In relation to the metadata-aware format design, the thumbnail images of assets
can also be considered for special treatment. Usually, the assets in the editor are
representedbyathumbnailimagethatdescribesitproperly(see
Figure5.4)
.Fora
texture, it'll be the image of the texture itself; for geometry, a rendered shot of it;
for a material, a rendered shot of a primitive geometry with that material applied;
etc.
Saving these thumbnails in a proper resolution with other metadata won't be
feasible in most cases, considering its huge storage consumption. But if you save
only the low-res version of it and can devise an ecient storage scheme for them
separately from other metadata, storage may become feasible, and then it'll pro-
vide the instant (although low-res) display of the thumbnail for all assets instead
