Game Development Reference
In-Depth Information
Desirable features of a build.
Provide granularity and allow executions on reduced sets of assets.
Allow quick iteration for the most common asset types or at least provide
alternative tools for them.
Signal any issues as early as possible. Any user should be able to understand
any errors, warnings, and important messages.
Handle broken or missing data. On any issues, a partial build may be a valid
result. A failed build should be the last option.
Design it to be resilient to machine failure. Hundreds of users may be relying
on the service, so on server failure, it must continue working even if it is in a
degraded mode.
Implement fine file control. Avoid
master files
that cannot be simultaneously
edited or automatically merged. They will become a bottleneck.
Design it to be extensible and scalable. Games are dynamic environments and
evolve over time. Expect new requirements at the final stages of the project.
Use conceptually simple models. It will allow more ecient execution, de-
buging, and maintenance. Remember that complexity has a direct impact on
development costs. Downtime and support also determine the final budget of
a project.
Do not reinvent the wheel. Use existing libraries, reuse modules, apply design
patterns and follow known good practices.
Optional features of a build.
Support changes in the file formats of input and output files. Otherwise, full
rebuilds may be required.
Reduce the overhead of the system. Allow fast starts and retries. Null builds
should be quick.
Ooad computation. Large sets of similar assets and complex or slow trans-
formations can be processed by
number crunching machines
or
computing
farms
.
Focus on eciency. Rely on advanced techniques such as caching, file reusing,
and proxying.
Provide methods to prevent pollution from broken or malfunctioning hosts
and tools to clean and purge caches.