Game Development Reference
In-Depth Information
In this context, multiple message categories need to be defined. Each infor-
mation displayed will fall into one of them. A trivial approach that is commonly
accepted classifies messages, in order of increasing importance, as
debug
,
verbose
,
information
,
warning
,
error
,and
fatal error
. Logs tagged using this simple method
can also be easily filtered.
1.7.2 Early Data Validation and Reporting
Early validation can improve the user experience in many ways. First, it will quickly
point out problems that otherwise would only be found after minutes or even hours
of computation. It can also give a better idea of if the build will finish successfully
or if fundamental pieces of data are missing or corrupted.
Ecient data validation may focus on metadata files: entity and hierarchical
data, compilation and run-time information, and gameplay balancing among others.
On the other hand, asset contents tend to be too specific for a generic system, and
they represent big volumes of data, so it is not always suitable for early validation.
As such, metadata can be processed using simple tests aimed at finding dupli-
cates and detecting missing references and assets, empty data records, inconsistent
hierarchies, files with unexpected sizes, or malformed XML data.
Even if early validation is not a complete solution and does not cover all possible
data paths, it can be complemented with asset data validation as part of the export
process. The next section explains this approach.
1.7.3 Prevent Data Corruption
Data corruption is always a possibility in a environment where files are edited
concurrently using tools that are under constant development. In the worst cases,
corrupted data can produce a meltdown of the whole system and bring the team
to a halt.
In order to limit the extent of the damage, local data validation must be per-
formed before metadata and assets can be submitted to the versioning system. In
some cases, the checks detailed in Section 1.7.2 will suce. In other cases, a quick
compilation at the time the asset is exported from the DCC will be beneficial.
However, the ultimate proof of damage is a full build. For eciency reasons, this
approach is not always feasible. In all cases, every check-in must be properly la-
beled, and in the event of data corruption, user builds can be forced to use the
latest data known to be safe.
Fixing corrupted data and eliminating build warnings are usually manual pro-
cesses. They need to be performed by staff capable of checking the integrity of
each file format and applying the corresponding updates. We encourage the use
of human readable formats such as XML that allow simple editing, ding, and
merging operations.
