Multiplayer Gaming and Networking

• Multiplayer notes
• Networking
• Update models
• Data crunching
• Sockets, TCP and UDP
• Common libraries

• Event timing
  • Turn based
  • Real time

• Player relation
  • Same machine, shared I/O
  • Individual machines, network-connected

• Shared inputs
  • One input used in turn
  • Multiple inputs

• Visuals
  • Full screen
    • Complete visibility (e.g. Monopoly)
    • Player funneling (“blanket” or virtual cage)
    • Turn-based screen
  • Split screen (e.g. racing)

• Connection models
  • Broadcast
  • Peer-to-Peer
  • Client/Server

• Important factors
  • Connection complexity
  • Bandwidth
  • Asynchronous scenarios

• The OSI model and mapping to games
  • Application (Input updates, State updates → Game events)
  • Presentation (Serialization, buffering → Game packetization)
  • Session (Sockets → Connection and data exchange)
  • Transport (TCP, UDP)
  • Network (IP)
  • Data Link (Ethernet/MAC)
  • Physical (Wired, Fiber, Wireless)

Input reflection

• All inputs are shared via network, and each client reflects them

• Requires
  • Low and consistent latency
  • All clients in sync
• Synchronizing difficulties
• Rigid rules on randomness

State reflection

• Client transmits local changes of the objects (e.g. position)

• Always arrives “late” to other players
• A trick is to use prediction algorithms
• Filter which objects to transmit and how much detail
• Filter the update rate depending on object importance or location

• Some techniques
  • Dead reckoning
    • Use the last known position, orientation, acceleration to predict current position
    • Assumes no (drastic) changes in acceleration
  • AI Assist
    • AI sets waypoints to NPC's
    • Waypoints may change more often than updates, could cause wiggling → use a minimum commitment time
  • Arbitration
    • Used when prediction goes wrong and things go out of sync
    • Dictator-like: clients forced to take the server's view
    • Relaxed dictation: clients delay some critical events to reduce impact

• Buffering
  • Gather sufficient data to compensate networking overhead

• Serialization
  • Convert game information to network-efficient, serialized data

• Encryption
  • Needed for privacy and anti-cheating reasons

• Compression
  • Compromise between packet size, bandwidth and processing overhead

• TCP
  • large data transmissions
  • guaranteed in-order delivery, including packet resend
  • Connection-oriented
  • stream-to-packet-to-stream

• UDP
  • “single-shot” transmissions
  • no guaranty delivery or order
  • no connection state → connectionless
  • simplified headers, no resends → better latency, better bandwidth

• TCP
  • Create a listening socket on the server, bind it to a given adapter and port
  • Create a connecting socket on the client, and provide the server address and port
  • The listening socket gets the connection request, and establishes the connection
  • Client and server may now send and receive data

• UDP
  • Create a listening socket on the server, and set it to receive a packet
  • Create a connecting socket on the client
  • Client sends a packet to a server (address and port), server receives

• Common libraries
  • Sockets (BSD, Winsock, …)
  • ENet - http://enet.bespin.org
    • Thin, simple and robust network communication layer on top of UDP
  • Boost::asio - http://www.boost.org
    • Cross-platform C++ library for network and low-level asynchronous I/O programming
  • RakNet - http://www.jenkinssoftware.com
    • Cross-platform networking engine for game programmers
    • Low- to mid- to high- level
    • Widely used with Ogre
    • Indy and commercial licenses