CSE 381 – Advanced Game Programming Multiplayer Gaming

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