So You Want to Make a Networked Game

1
So You Want to Make a Networked Game
15-493 Computer Game Programming Lecture 19

• March 25, 2004
• M. Ian Graham
• Carnegie Mellon University

2
Networked Games

• Multiple players share the same game state
  between different machines over the network.
• Why?
• Think about the game first. Do we really need
  networking?
• How?
• If we do, how do we go about managing everything?
• Where are all parts of game state located, how do
  they change over time, and how is communication
  managed?

3
What is game state?

• Specifically, what state needs to be known by a
  given player?
• In an RTS, Player 1 doesnt care where Player 2s
  camera is pointing. (In an FPS it might matter)
• Figure out first what information players need to
  share.

4
What is game state?

• Shared info?
• Character actions (jump, move, fire missile)
• Character position, orientation, velocity
• Important events (deaths, explosions)
• Unshared info?
• Character animation details
• Window/camera configuration

5
Where is game state?

• Problem Client program needs to display
  believable information, yet all clients need to
  be synchronized in some manner.
• Where is the shared game state stored?
• Who is the authority on correctness of each piece
  of information?

6
Architectures

• Centralized (star topology)
• Often associated with client-state architecture
• Control of state is extremely easy
• Scales poorly
• Hierarchical (tree topology)
• High level of structure, centralized control
• Latency issues
• Bad data at a node affects whole subtree

7
Architectures

• Ring topology
• Scales better
• Info. propagation can be slow
• How to deal with untrusted peers?
• Decentralized
• All peers equal
• Fault tolerant
• Synchronization difficult, trust a problem

8
Architectures

• Centralized client-server model by far easiest to
  implement (and to debug)
• Much easier to reason with a central authority on
  all game state
• Further discussion here assumes this architecture
  but can be generalized to others as well

9
SynchronizationWhat information to transmit?

• State-based sync. versus event-based
• State-based
• Send relevant game state to clients at a fixed
  rate
• Transmit information such as player position and
  orientation, velocity, missile location and
  velocity, player health, etc.

10
SynchronizationWhat information to transmit?

• State-based sync. versus event-based
• Event-based
• Send events (or actions) to clients as they
  happen, and clients maintain local state by
  synching on event times
• Transmit information such as move left,
  shoot, explosion, player dies

11
SynchronizationWhat information to transmit?

• State-based synch. versus event-based
• State-based can perform better for twitch-based
  games like FPSes
• Event-based much better for games with more state
  and tolerance for slight delays (RTS, online RPG,
  etc)

12
When to communicateFrame-locking vs.
Event-locking

• Frame-locking
• Fixed time step for sending updates over the
  network, one update sent every n frames
• One clients sudden delay makes everyone stall
• Adaptively changing time step can smooth delays,
  but reduces responsiveness overall

13
When to communicateFrame-locking vs.
Event-locking

• Event-locking
• No fixed time step, events are sent as needed
• Can give server more authority Client sends an
  event request to the server, server approves and
  broadcasts to all clients
• Avoids slowing everyone down to slowest clients
  speed

14
TCP vs. UDP

• Most games use UDP to reduce latency
• For frame-locked (state-based) updates, its okay
  if an update is missed so UDP is an obvious
  choice

15
TCP vs. UDP

• For event-locked updates, the event contained in
  a single update is transmitted oncewe cannot
  miss an update.
• Can either use TCP or build retransmission (and
  packet ordering, if necessary) into our
  communications
• Opinions vary on which is the better
  approachusing TCP is definitely easier

16
Packing Information

• Sending state or event information across the
  network requires data serialization
• Items must be passed inside a single void buffer
• Important to specify different packet types and
  length information.

17
Packing Information

• Easiest to have a struct or class that represents
  a packet, along with packing and unpacking
  functions which serialize its data (move to and
  from a buffer)
• Endianness can be a concern
• See lab 3 code for examples of serializing game
  state

18
Hiding Latency Basics

• If the server must verify an event before any
  players execute it, then the player requesting
  the event will see a delay before it begins!
• How to hide this?

19
Hiding Latency Basics

• If the server must verify an event before any
  players execute it, then the player requesting
  the event will see a delay before it begins!
• Easy fix Just give UI/visual feedback that
  doesnt affect game state while waiting

20
Hiding Latency Basics

• If the server must verify an event before any
  players execute it, then the player requesting
  the event will see a delay before it begins!
• Slightly more involved Start event immediately,
  then make any necessary changes after server
  confirmation arrives

21
Example Walking
22
Hiding Latency Basics

• State-based updates For action games, game
  state has to change continuously, not in visible
  discrete steps. Any delays will cause visible
  pauses and make things unplayable.
• While waiting for a network update, make a
  prediction of future game state based on the
  current state.

23
Hiding Latency Basics

• While waiting for a network update, make a
  prediction of future game state based on the
  current state.
• If Player 2 has position P, velocity V, and
  acceleration A at time t0, then we can make a
  good guess where hell be at time t1
• Once we receive an update, change our state to
  reflect it

24
Hiding Latency Dead Reckoning

• Communication reduction strategy that both hides
  latency and reduces bandwidth consumption
• All clients run a rough simulation of the
  actual game state using a predetermined algorithm
  to predict future states
• An update is only sent out when the approximation
  differs from the actual state by more than a
  certain threshold

25
Hiding Latency Dead Reckoning

• What to do to the current state when an update is
  received?
• Simply overwriting the state can result in sudden
  jumps if the difference was large
• Many approaches interpolate between the current
  approximation and a new approximation based on
  the most recent update

26
Debugging

• is hard in networked games.
• Suggestions
• Make a debugging mode that will log all network
  communications sent and received by server and
  clientreading these can be excellent for sanity
  checking.
• Synchronization problems can be quickly detected
  by comparing checksums on the game state

27
Advice

• Use the Most Powerful Development Tool in the
  Cluster

28
Advice

• Think, plan and specify before you code!
• Short-sighted hacking is perhaps more disastrous
  (and harder to fix) in network programming than
  in any other area of development
• If you have a fully thought-through specification
  document for your network communications before
  you start coding, your life will be much easier.

29
Advice

• Specify, specify, specify.

30
Advice

• Sending commands (events) instead of states makes
  verification by a central server much easier.
• Have the server validate everything.
• Keep client IPs secret from each other unless
  doing a non-centralized architecture.

31
Advice

• De-couple networking code from game code.
• Having sockets or other API calls in the middle
  of high-level functions can make your life
  miserable when you need to change things.
• HandleEvent() is much more readable than a
  string of API calls
• Abstraction is your friend!

32
Advice

• Networking will deeply influence both your
  gameplay and the structure of your code. Get it
  working early or getting it to work with what you
  have already will be a nightmare.
• Do not try to add this functionality at the last
  minute!

33
Milestone 1 is Coming!!!

• April 6, a week from next Tuesday