Game Development Reference
In-Depth Information
performing tasks like opening files and allocating memory. The game view and game
logic talk to each other through an event system, as described in Chapter 11,
“
Game
Event Management.
”
If you guessed that the socket classes belong in the application layer, you
d be exactly
right. They are similar to files, really, in that they provide a stream of data your game
can use. Sockets also tend to be slightly different on Windows and UNIX platforms,
which is another good reason to stick them in the application layer.
I provided an important diagram in Chapter 2,
'
“
'
”
to describe how
the logic/view architecture could easily support a networked game. Figure 19.1 shows
this diagram again so that you don
What
s in a Game?,
'
t have to go all the way back to Chapter 2.
Figure 19.1
A remote game client attaching to a server.
Recall that this game architecture supports game logic and multiple views of that logic.
These might include a human player view, an AI player view, and a remote player
view. The events that are being generated by the authoritative machine acting as the
game server can be serialized, sent over the Internet, and reconstructed as the same
events on the remote machine. The remote machine can also send events in the form
of game commands, like
“
fire my 105mm cannon at the n00b,
”
back to the server.
While this high-level explanation seems easy, the reality is, as always, a bit more
complicated. I
'
ll take you through the whole thing, step-by-step. I
'
m going to break
'
this job into four pieces so your brains don
t explode.
n
Packet Classes:
Create objects to handle packets of data that will be sent and
received through socket connections.
n
Core Socket Classes:
Create base objects to handle client connections.
n
Core Server Classes:
Create base objects to handle server connections.
n
Wire Socket Classes into the Event System:
Create an event forwarder that lis-
tens to events locally and sends them on to a remote computer.
