Game Development Reference
In-Depth Information
any simple conversions. 1 The data are stored and displayed for the user in a way
that is most understandable. At runtime, when the field is set to a value, instead
of directly changing a value, a method is called. This method can then modify the
input data however is needed and then transform them before setting the internal
value at runtime.
Another benefit of this property system is that it decouples the implementation
from the interface. If the underlying implementation changes, properties can be
used as shims to convert existing data into the new format. These properties can
be made without modifying any tool or existing data.
One major issue with properties is that they add unnecessary overhead to
load time. An object with only data fields can be loaded with little more than
a memcpy() , but any properties called at load time would require an extra method
call. This can complicate serialization systems and significantly impact load times.
However, if properties are only used to transform the internal state of an object,
they can be moved into a conditioning step during the build. By moving the work
to build time, this system will not add performance impact during the load.
6.5 Robust Data
At load time, it is often easy to verify that data are correct, but once you have
data that are being created at runtime, this gets much more di cult. With instan-
taneous feedback, content creators will feel more comfortable testing the limits of
different systems. This type of experimentation should be encouraged, but some
experimentation can lead to unexpected edge cases. If a designer has access to a
field that may cause memory allocation, the engine must be very careful to fail
gracefully. At load time, engines can easily check budgets and fail to load if things
do not pass, but during real-time experimentation, a content creator may break a
budget. Here, if the system completely shuts down, it would give unwanted negative
feedback to the designer. Experimentation is dangerous.
Memory allocation is the simplest example of a failure case, but other cases
must be handled similarly. If a field cannot go below or above a certain value, the
runtime must be able to handle these changes gracefully instead of shutting down
because a user attempted to test the limits of a system.
Allowing the designer to try things is very important. At the same time, if the
data work while editing in real time, then it should also work after saving the file.
If a content creator has broken a budget or any rule of the system, it must be very
obvious that these changes will not work in the long term. The game should not
crash, but it should be extremely obvious that the user has made a mistake. In
many cases, simply telling the user may not be sucient. If something seems to
1 These conversions can include converting from degrees to radians or converting from one color
space to another. The most important rule is that the conversions must only depend on the input
data and not on any other state.
Search WWH ::




Custom Search