1 / 28

CSE 381 – Advanced Game Programming Multiplayer Gaming

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.

sandra_john
Download Presentation

CSE 381 – Advanced Game Programming Multiplayer Gaming

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CSE 381 – Advanced Game ProgrammingMultiplayer Gaming Doom, by Id

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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)

  8. 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

  9. 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?

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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.

  15. 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

  16. 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

  17. 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

  18. 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.

  19. 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)

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. 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

More Related