Cse 381 advanced game programming multiplayer gaming
Download
1 / 28

cse 381 - PowerPoint PPT Presentation


  • 327 Views
  • Uploaded on

CSE 381 – Advanced Game Programming Multiplayer Gaming. Doom, by Id. Life Before Networked Gaming. Play against your own scores Play against AI Play against other players taking turns Play against other players via a split screen. Life After Doom.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'cse 381 ' - sandra_john


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Cse 381 advanced game programming multiplayer gaming l.jpg

CSE 381 – Advanced Game ProgrammingMultiplayer Gaming

Doom, by Id


Life before networked gaming l.jpg
Life Before Networked Gaming

  • Play against your own scores

  • Play against AI

  • Play against other players taking turns

  • Play against other players via a split screen


Life after doom l.jpg
Life After Doom

  • Doom was not the first, but it changed everything

    • gaming communities

    • multiplayer cultures

    • coincided nicely with Internet boom & graphical computing

  • Significant Ancestors of DOOM multiplayer:

    • PLATO games

      • Empire, based on Star Trek

      • SPASIM

    • MUDs


Empire 1973 l.jpg
Empire (1973)

  • John Daleske & Silas Warner of Iowa State

  • Gameplay

    • supported up to 32 players working in teams

    • screen updates once every 10 seconds

    • your view is of space quadrants

    • you have weapons like phasers

    • goal is to drop armies on every planet in the universe


Spasim 1974 l.jpg
SPASIM (1974)

  • Originally “Space Sim”

  • Also for PLATO system

  • Jim Bowery w/ Universities of Iowa & Illinois

    • He’s offering $500 to anyone who can find an earlier multiplayer FPS:

      • http://www.geocities.com/jim_bowery/spasim.html

  • Used a first person perspective

    • players flew around in space

    • others appeared as wireframe ships


Star vs mesh topologies ref http www webopedia com quick ref topologies asp l.jpg
Star vs. Mesh Topologies(Ref: http://www.webopedia.com/quick_ref/topologies.asp)

  • Star (client/server) Topology

    • All devices are connected to a central hub (server)

    • Nodes communicate across the network by passing data through the hub

  • Mesh (peer to peer) Topology

    • every node has a connection to every other node in the network.

    • provides faster communication

    • burden on clients to enforce application rules

    • minimize size of messages


What data l.jpg
What data?

  • What is communicated across networks?

    • player locations

    • player states

    • player appearance

    • player orientation

    • voice communications

  • Note: send the minimum amount of data necessary

    • minimize data type sizes (bytes are nice)


Bottom line l.jpg
Bottom Line

  • Networked games must be:

    • fast

    • reliable

  • Which should be used (client/server or peer-to-peer) for MMOs?

    • it depends, but mostly client/server

  • Architectures in use:

    • pure client/server

    • pure peer to peer

    • hybrid client/server & peer to peer


Multiplayer issues l.jpg
Multiplayer Issues

  • Latency

    • a difficult issue in multiplayer games

    • How do you handle communication delays?

    • Where is the delay?

      • lag is commonly due to overloaded networks

  • Cheating

    • How do you ensure fairness?

  • Subscriptions

    • How do you ensure only paying customers are playing?


Decisions to make l.jpg
Decisions to make

  • What service provider do you want the connection to use?

  • Will you be “hosting” this connection or will you connect to an existing session?

    • a first host connection must accept the incoming network data from the other peers

    • a first host starts the session


Other networking topics l.jpg
Other Networking Topics

  • Questions for a reliable gaming network:

    • How often should data be sent?

    • How do you handle lost clients?

    • How do you handle lost host clients?

    • How do you handle slow clients?

    • Peer-to-Peer/Client-Server combinations


Server game state l.jpg
Server Game State

  • Server maintains database of:

    • server control objects

      • “true” game state of various objects (player/object locations, player/object states, etc.)

    • connections

  • Continuously, the Server:

    • Collects input from connections

    • Updates control objects according to input

    • Sends updated game state on a need to know basis


A networked game is its traffic l.jpg
A networked game is its traffic

  • Some networked engines have built-in demo recording options

  • How?

    • log all network communications. Why?

    • play back a game for a demo

    • in effect, a game is its network traffic and the state changes it causes


Common strategies l.jpg
Common Strategies

  • Player data sent to server:

    • user input (moves, firing, etc) on timed basis (ex: 30 times/sec)

    • if no input (player idle), little if anything will be sent

  • Server data sent to player

    • world game state (other player & enemy locations & states)

    • on a timed basis

  • Huge amount of data in the world game state. Many efficiencies required:

    • Ex: string tagging, game data masking, ghosting, triggers, etc.


String tagging l.jpg
String tagging

  • String data can eat up network bandwidth

  • Solution? Networked String Table

    • keeps track of strings sent to/from clients

    • most strings of data (i.e. player names) are transmitted only once between clients & the game server

    • if a string that has already been transmitted needs to be sent again:

      • a tag is sent instead of the full string

      • tag is a number that identifies the string to be used

      • so the full string need not be sent again

  • Obviously this won’t work for chat


Game data masking l.jpg
Game Data Masking

  • A network game efficiency

  • Servers maintain info about what data has been changed since last broadcast to clients

    • masks on server keep track of this

  • Server will then only send data that has changed in next broadcast

  • Server will then reset


Masks l.jpg
Masks

  • Ex: let’s use a 32 bit mask for a control object

    • 10111011011011011111111011101100

  • What might these numbers represent?

    • each number represents a piece or pieces of game data

    • 0 means it hasn’t changed, 1 means it has

    • don’t send the data that’s 0

  • How many control masks do we need?

    • one for each game object that clients might need to know about

  • How many bits should it have?

    • one bit for each variable the clients might need to know about


Example mask l.jpg
Example Mask

  • 10111011011011011111111011101100

  • Control object is evil boss:

    • first bit is position

    • second bit is orientation

    • third bit is state (living or dead)

    • fourth bit is animation state

    • etc.


Server handling masks l.jpg
Server handling masks

  • Each loop on server:

    • Reset all masks to all 0’s (0000…000)

    • Collect all input from clients

    • Update appropriate variables

      • player input, physics, AI, etc.

    • For variables with mask bits, if updated, set bit to 1

    • Send game state to players, only sending data with 1s in game mask (they’ve changed since last frame)


Ghosting l.jpg
Ghosting

  • Info sent to clients to be precisely matched to what they need

  • Why?

    • so that no excess bandwidth is wasted

  • Server maintains the authoritative game state for every object in the simulation

  • Sends objects to individual clients based on "only send the data the client requires"

  • NOTE: each client will receive their own custom packet


How does ghosting work l.jpg
How does ghosting work?

  • Server maintains a list of all objects important to each client

  • How does it do that?

    • a scope check

    • Where’s the player camera?

    • What might be near it?

  • During each network update cycle, for each client:

    • Performs a rapid scope check

    • Collect the data we need to tell the client about

    • Builds an update packet

    • Transmit the packet to the client

  • Obviously, this can be combined with game data masking


Determining scope l.jpg
Determining Scope

  • Based upon frustum:

    • field of view for player

    • visible distance for the mission

    • traverse the Scene Graph and mark each object that can be viewed

  • For Real Time Strategy Scoping:

    • determine the visible/not visible state of all units in the mission based on friendly unit locations and visibility ranges

    • construct a list of all visible units per client

    • scope the entire list of visible units to that client


Benefits of ghosting l.jpg
Benefits of Ghosting

  • Minimize the amount of update traffic

  • Security that clients only have what they should have

    • clients shouldn’t have “out of game” knowledge

  • Prevent collusion

    • a game hacker tactic where two players share the information about the simulation they have

    • How do we prevent it?

      • use unique ghost IDs for each player

      • when a new object comes into scope for a specific client, the server assigns a GhostID to this object, and only tells the client what it's unique GhostID is

    • clients cannot share GhostIDs without the server’s involvement

    • the client is never told the actual server ObjectID of the newly scoped object


Obviously there is a huge burden on the server l.jpg
Obviously there is a huge burden on the server

  • It had better be efficient

  • Obsess over every last bit sent to clients. Why?

    • because you may have lots of clients

  • Packing/unpacking data into/from a bit streams

    • many compressions techniques available

      • for strings of 1s and 0s

    • only use the # of bits necessary for the data sent

      • ex: 1 bit for a boolean, 6 bits for an integer storing 43

    • this is a computing trade-off for lower bandwidth


Triggers l.jpg
Triggers

  • Common events & reactions built into a game engine

  • Ex:

    • player walked into room, so close door behind him

  • Opportunity:

    • help clients know game state without having to be told by server


Common types of triggers l.jpg
Common Types of Triggers

  • Common Types:

    • area triggers

      • collide with an area in the world

      • 3D box

    • animation triggers

      • used to synchronize environment effects with animations

        • e.g., footstep sounds with walking animations

    • weapon state triggers

      • dictate what to do when a weapon is firing, loading, etc.

    • player event control triggers

      • lets client act on certain input before server approval


References l.jpg
References

  • ClassicGaming.com: PLATO Ain’t just Greek

    • http://www.classicgaming.com/features/articles/computergaminghistory/index5-2.shtml

  • GameSpy: The History of MUDs

    • http://archive.gamespy.com/articles/january01/muds1/index.shtm

  • MSDN: Windows Sockets 2

    • http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/windows_sockets_start_page_2.asp

  • Webopedia

    • http://www.webopedia.com/TERM/W/Winsock.html


References28 l.jpg
References

  • Torque/Networking

    • http://tdn.garagegames.com/wiki/TorqueNetworking

  • Torque/Networking/Making a Ghostable Object

    • http://tdn.garagegames.com/wiki/Torque/Networking/Making_a_Ghostable_Object

  • Introduction to Network Programming Concepts

    • http://opentnl.sourceforge.net/doxytree/introprogramming.html


ad