Game Development Reference
In-Depth Information
ceedings paper (mentioned in the references), TCP's guarantee system running at
the same time as UDP increases the number of UDP packets that are lost. A fur-
ther issue is that even though the movement data may not be critical, and thus it
makes sense to send it via UDP, we still need some way of knowing the order of
the packets. Without any knowledge of ordering, if position B is received after po-
sition C, the player will incorrectly be moved to an old location.
Most games tackle this problem by using UDP, but then adding on a custom layer
of reliability for the packets that need it. This additional layer can just be added at
the start of the UDP data section—think of it as a custom protocol header added
on. The minimum amount of data needed for basic reliability is a
sequence num-
ber
, which tracks which packet number it is, and then a bitfield for acknowledge-
ments. By using a bitfield, a particular packet can acknowledge several packets
at once, rather than needing to individually acknowledge each packet. This sys-
tem also has flexibility, because if something truly does not need reliability or se-
quence information, it can besent without that, as well. The actual implementation
of this system is beyond the scope of this topic, but a good starting point is the
Tribes
whitepaper in the references.
As mentioned before, UDP is the predominant protocol used for real-time games.
Almost all FPS, action-oriented, RTS, and any other networked games that have
time-sensitive information use UDP. It is also for this reason that almost all net-
working middleware designed for games (such as RakNet) only supports UDP.
Network Topology
Topology determines how the various computers in a networked game session are
connected to each other. Although there are a large number of possible configur-
ations, most games support one of two models: server/client or peer-to-peer. As
with many decisions, there are tradeoffs and benefits of both approaches.
Server/Client
In a
server/client
model, there is one central computer (the
server
) that all the
other computers (the
clients
) communicate with. Because the server is commu-
nicating with every client, in this model it is desirable to have a server with more
bandwidth and processing power than the clients. For example, if a client sends
10KBps of data over the network, in an eight-player game that means the server
must be able to receive 80KBps of data. This type of model is often referred to as
a hub-and-spoke model, because the server is the central hub that all of the clients
connect to, as in
Figure 12.7
.
