Game Development Reference
In-Depth Information
6.3 Real-Time Communication
The first step to having a tool chain and engine communicate is the transport
layer. Depending on your requirements, there are a number of different options.
To maximize our cross-platform abilities, our transport layer was based on top of
TCP/IP. By using TCP/IP instead of named pipes, shared files, or any proprietary
communication systems, we were able to use the same code to communicate to a
wide variety of platforms, including Sony Playstation 3, Microsoft Xbox 360, PC,
Sony Playstation Portable, and Nintendo Wii. For platforms that did not have
native access to TCP/IP stacks, we were able to use a different transport but keep
the rest of the interaction the same. By separating the transportation from the rest
of the protocol, we were able to bring new systems online much faster and more
robustly.
On top of the communication layer, we needed a protocol to pass the information
from the tool to the console. Robustness and the capacity to be debugged are of the
utmost importance since this is a developer-only feature. For that reason, along
with simplicity, we used a simple string-based protocol. Whenever a field value
changed on the tool, the name of the object, the field that was changed, and its
new string value were sent to the game.
This concept of sending each individual field change message has a number of
major dependencies. First, the engine and the game must be referring to the exact
same information. If the tool and the engine do not refer to the exact same data
structures, this protocol will send information that is not relevant to the runtime.
By using the same object representation, neither the tool nor runtime code need to
write special case serialization routines.
6.4 Properties
In some cases, the format of the data file and the in-game representation might
not match. One case where this is most prevalent is when the runtime needs to
be optimized and change its internal representation of data. For example, at tool
time, it may be most convenient to have the tools and data files refer to percentage
of the screen instead of depending on the actual resolution of the back buffer. At
runtime, it may be important for the actual objects to refer to absolute pixels. It
would be counter-productive to force all data files to rely on the implementation of
the engine.
For these simple conversions, we can model certain fields after concepts from
C#. In C#, most data is set via a property. Functionally, a property is a con-
vention for representing “get” and “set” methods as fields. But by normalizing
our data and reflection system to support properties, we were able to abstract out
