Game Development Reference
In-Depth Information
6.7 Copying Data
Whenever possible, do not copy memory at runtime. Whenever data is copied,
there is a disconnect between the input value and what is actually being used. In
some cases, this is necessary, and the runtime system that does the copy will need
to keep track of it so it can replicate any changes made by the content creator.
However, this can be complicated and error prone. In many cases, the copy can be
avoided completely.
6.7.1 Caching
Game developers are obsessed with performance. One way to speed up code is
to cache intermediate values. But are these caches necessary? Is it possible to
recalculate when needed? Or can a property be made so that the copy occurs
whenever the user modifies the data? By utilizing a property system, the data will
be recached when needed without having to have a specific caching system.
In some cases, caching on first use is better than caching when set. In these
cases, the value may be a true cache with only some of the values cached at a time,
so doing this at load time is not viable. In these cases, the cache logic needs to be
slightly more robust. Data, which in the past could be assumed immutable, can
change at any time. When setting a field of an object during communication, it
may be important to also mark that entire object as “dirty.” By doing the heavy-
handed marking of “dirty,” the cache system will have little work to do but will be
able to correctly handle the case of data changing in real time without adding a
significant overhead to the caching system.
6.7.2 Data Reuse
One important feature of real-time editing may be to set hit points or positions of
entities. What should the system do if the runtime needs to edit these fields? An
entity may move during the game. The value specified at load and the value while
running the game may not match. What should happen if the tool needs to change
these values? The object is not in a consistent state anymore. Should the tool reset
the value of the entity? Should the value be ignored? These questions depend on
the game and the needs of the user.
The easiest way to answer these questions is to clearly separate the starting data
from the data that are modified at runtime. At first, this may seem inconvenient and
wasteful, but it does have a number of advantages. Most obviously, it removes the
question of what should happen. The tool is only modifying the starting position
of an entity, not moving the actual position. If the game is actually running, then
you wouldn't expect the tool to change these values.
There are also secondary advantages to separating this data. Multithreaded
code can be synchronized more easily, and network communication is less heavily
taxed when dealing with separate mutable and immutable sections.
