Multiplayer NES Emulator Play Over a Network

1
Multiplayer NES Emulator Play Over a Network

• David Quaid and Andrew Flynn
• CS 78 Networks
• Professor Andrew Campbell

2
NES Multiplayer Emulator

• Used open-source java emulator that only
  supported single-computer functionality
• Supported multiplayer, but only two users using
  the same computer on the same system

3
Overview of original code

• NESCafe open source emulator
• Available at www.davieboy.net/nescafe/
• 48,000 lines of java code.
• Java Preprocessor used for C-style include
  directives
• Available at http//www.vortoj.com/sjpp/readme.htm
  l

4
The Problem of Synchronization

• Multiplayer video games have serious real-time
  demands.
• More than a few hundred mss delay means
  seriously compromised playability.
• Inherent Sources of Error / Lag
• Transferring information across a network is much
  slower than local computation.
• Internet traffic is bursty
• RTT is likely to change with time.
• No objective Frame of Reference
• Impossible to synchronize system clocks exactly

5
Design Philosophy / Principles of Multiplayer
Game Programming

• UDP only
• TCP retransmission is too late!
• Frequent / Redundant transmission of controller
  state used instead.
• Timer (rather than event) driven protocol.
• Periodic re-synching of relevant state
  information.
• Demanded by unpredictability in delays.
• Dont transmit deltas
• Button up / button down events are dangerous.
• Absolute States exchanged instead.

6
Design Philosophy Continued

• Problem Cant get rid of inherent lags
• Player 1 (Server player) always has the upper
  hand on game states and controller input
• Player 2 (Client player) still has advantage for
  own controller input
• Games likely to fall out of synch.
• Solution Estimate delays for other player, and
  introduce them locally.

7
Challenges Unique to NESCafe

• Low granularity of Game State
• Binary memory vs. Standard Object Oriented Design
• Saving and Loading States takes time
• 65-120 ms
• High potential for corruption of Game State
• CPU must be paused while loading and saving
• Cannot load new JoyPad states during Game State
  loads
• Solution Buffered JoyPads

8
Original Idea
9
Why original idea was abandoned

• Sending graphics across in the form video is not
  feasible. Screen size is 256x240, and 4 bits are
  required to represent color. So 4 256 240
  /8000 (bits per KB) 30K per frame. This is
  too much, even when compressed
• Reasonable playability would require 15 frames
  per second, which would require 500K/second.
• Not as challenging!

10
Revised Idea
11
Benefits of new idea

• Sending JoyPad and Game States requires much less
  bandwidth
• More multiplayer in approach since both players
  are running their own process.
• Gives a more level playing field between the two
  players

12
Theory Applied to PracticeOur strategy for
NESCafe

• Distinction between Server and Client
• Server (Player 1) Role
• Responsible for estimating RTT
• Sends JoyPad state at 10ms period
• Sends Game state at 1500ms period
• Client (Player 2) Role
• Does not initiate transactions
• Only responds to JoyPad states.

13
Packet Structure
14
Delay strategies

• Server keeps track of running RTT
• When server sends either Game State or JoyPad
  State, server waits ½ RTT so that server and
  client load the state at approximately the same
  time
• Additional delay for JoyPad input based on next
  expected send
• Uses Exponential Weighted Moving Average

15
Exponential Weighted Moving Average

• EstimatedRTT (0.875 EstimatedRTT)
  (0.125 SampleRTT)

16
Delay Strategies (cont.)

• Problem Because of bursty nature of internet and
  the uncertainty of estimating RTT, it is
  impossible to maintain perfect synchrony between
  server and client sending only JoyPad movements
• Solution Periodically send entire Game state
  information in order to re-synch two emulators

17
NESCafe states

• JoyPad State
• 1 byte of information
• 1 bit for each button on the JoyPad
• Bitwise operators determine which button is being
  pressed
• Game State
• Entire memory state of emulator
• Includes JoyPad, graphics, and place currently in
  game ROM
• Compressed size usually about 7K

18
Player 1 FSM
SAVING
LOADING
Do not transfer JoyPadBuf to JoyPad
Do not transfer JoyPadBuf to JoyPad
Put Player 1 JoyPad In JoyPadBuf
Put Player 1 JoyPad In JoyPadBuf
Save complete
Timer triggers load
Keep track of last Player2 JoyPad
Keep track of last Player2 JoyPad
Timer triggers save
Load complete
Normal Play
PLAYING
19
Player 2 FSM
Timer triggers load
PLAYING
LOADING
Do not transfer JoyPadBuf to JoyPad
Put Player 1 JoyPad In JoyPadBuf
Normal Play
Keep track of last Player2 JoyPad
Load complete
20
Lessons learned

• Maintaining synchrony is difficult to achieve in
  a real time playing environment
• UDP with redundant transmissions is better than
  TCP with retransmissions
• Local delays heuristic to synchronization
  (counterintuitive)
• FSMs are your friend (honest)

21
And the final lesson learned
22
(No Transcript)