Game Development Reference
In-Depth Information
based on any of these properties. The library of available assets was rarely up-
dated, making the information it contained potentially out-of-date and unreliable.
The tech art team at Volition determined that at minimum, an updated solution
would require the following fundamental feature criteria:
A new in-house tool was required, built specifically for asset tracking.
This tool had to automatically catalogue and update asset information.
All metadata needed automated recording and perpetual updating.
Full search and retrieval implementation for users was required.
Unforeseen feature additions were expected; therefore, the tool set had to be
capable of rapid, modular development and iteration.
3.3 Automatically Building an Asset Database
Using the Xbox 360
First, some up-front explanation: all Volition game assets are exported from
content-creation applications (such as 3ds Max) into a proprietary cross-platform
XML format and then optimized down into platform-specific binary formats. This
process is required in order to author platform-independent tools that operate at
the XML level. A typical asset begins it lifecycle in the content-creation appli-
cation, is exported to cross-platform proprietary XML, and then optimized into
platform-specific binary data and loaded by the game. We decided to incorporate
an additional step into this process in order to automate submission of asset infor-
mation into a MySQL database that was set aside especially for tracking assets as
soon as they were produced. This step would typically occur after the optimization
step, when the content creator submits the source files, cross-platform XML, and
platform-specific binary files into source control.
This worked as follows: when an asset was added or even modified within Per-
force (our source-control software), a PC functioning as a dedicated asset-tracking
machine detected the addition or alteration. This PC immediately queued the asset
to be copied to a local networked Xbox 360 running a lightweight version of the
game's rendering engine as a separate executable. This program, called the Asset
Viewer, displayed the asset on the screen in isolation. Simultaneously, the Asset
Viewer collected technical metadata, including an average of the asset's rendering
expense, its final post-optimization polygon count and memory footprint, material
information such as texture resolution and shader usage, and if any errors were
detected at any point while attempting to gather these values. Running the As-
set Viewer application on an actual Xbox 360 console ensured that collected data
would be as accurate as possible, having been derived from the physical console
CPU and GPU. If the process completed without errors, the Xbox 360 returned
