1 / 36

Online Games: Networking and Data Management

Online Games: Networking and Data Management. Why do we “network” games?. Playing by yourself is NO FUN! Adds social dimension to gaming But … we have the complexities of distributed computing From a systems perspective:

leah-buckley
Télécharger la présentation

Online Games: Networking and Data Management

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. Online Games:Networking and Data Management

  2. Why do we “network” games? • Playing by yourself is NO FUN! • Adds social dimension to gaming • But … we have the complexities of distributed computing • From a systems perspective: • “How do we cope with these physical restrictions, while developing and running our game?”

  3. Taxonomy MMOGs Everquest, WoW Degree of distribution Turn-based Civ, Poker Cooperative Halo, Battlefield 2 Twitch games Doom, etc. Degree of interaction

  4. Lecture Outline • LAN + Internet play • Latency • Scalability • Data management • Tools • Data-driven games

  5. Networked Game “Data” Shared game world

  6. LAN Game Anatomy Client Server Snapshot Physics Physics AI State State AI UI …

  7. “The Duel”

  8. “The Duel” Server time

  9. “The Duel” Server work time

  10. “The Duel” Server work time

  11. “The Duel” Server work time

  12. “Massively” Multiplayer • Network latency • E.g. Current TCP/UDP • NYC => Seoul, Korea ~ 150ms one-way • At best speed of light constraint between players: • NYC => Seoul ~= 11000km/c ~= 36ms • Scalability issues • Load balancing • Data dissemination

  13. Network Latency • Two components: • Last-link latency • Server-server latency • Last-link latency is hard to cope with: • Cable-modem => exchange • But no other route…

  14. Dead Reckoning • Predict to overcome latency! • Prediction models: • Newtonian (linear) • Not everything can be predicted … • Developer must think about consequences of failed predictions

  15. “The Duel” Revisited Server time

  16. “The Duel” Revisited Server predict time

  17. Dead Reckoning (in more depth…) • Videos

  18. Data Consistency • Client “cache” • Static data consistency is easy…. • Dynamic consistency is harder… • Ownership issues • “Interest” management

  19. Fairness Models • Who is right, the shooter or the victim? • What are other scoring models? • E.g. everything hurts a lot at first…

  20. Growing the System • Recap the LAN setup: • Suppose we want 1000 players… Client Server

  21. Scalability: Load Balancing • Zone partitioning • Each server may be distributed as a cluster • Server placement and geographical partitioning helps…

  22. Scalability: Data Dissemination • All about saving bandwidth • Tree network between zones • i.e. pub/sub system • Zone transitions: • Artificial impediment to gameplay • “Content-based routing” and “profiles”

  23. Data Dissemination: “Hotplugging” • Open, dynamic systems • Recently attempted by: • WoW • Star Wars Galaxies • Should be seamless!

  24. PlanetLab 645 nodes, 305 sites

  25. Data Management • “What kinds of data are used to build and run games?” • Content: • Visual: models, animations, artwork • Audio: effects, speech, languages • Contextual: plot, missions • Game logic: • Player profiles, inventories, etc. • NPC AI state. • Transient: • Chat, VoIP

  26. Data Management Tools • Expressive, “declarative” approach • High-level triggers and rules • Distribution transparency • Clear-cut specification of game behaviour • Modular frontend and backend extensibility • Automated resource optimization • Scalable • Adaptive • Tolerant to failures

  27. Dataflow Programming • Flow-based representation of program • Based on events and triggers • Game logic defined as triggers • E.g collision induced events • Gameplay from “queries” over events • Supports roles • E.g. “tell me when there are 5 players near my flag”

  28. Dataflow Programming • Borealis Demo • Other distributed middleware kits: • Demonware, Quazcal, ReplicaNet • Opensource: MASSIV, Worldforge

  29. Dataflow Programming • What are good primitives for games? • E.g., collision detection, path planning, etc. • Class-specific primitives? • E.g buy/sell items • Come up with a high-level game template

  30. Data-driven Gaming • Let’s use the data out there! • Content, plot and script generation. • Game “embedding” • Splinter Cell, Battlefield 2 • The Sims • Civilization • “Alternate reality” gaming

  31. Mobile Gaming • Sensors/actuators • Power concerns • Wireless connectivity • Connection range • Interruptions • Data mules • GPS • Camera phones • Google Maps

  32. Data-driven Gaming classify Pirate raid { Mission objective Coastal map Data sources Game level Game entities

  33. Data-driven Gaming Pipeline • Acquisition • News feeds (RSS/Atom) • Integration • Duplicate elimination • Event classification • Morphing • Introducing “dissimilarities” • Consistency checking • Deployment

  34. Conclusions • Latency causes inconsistencies in any distributed game. • Scalable infrastructures to sustain game growth • Data management tools, describing a high-level game representation • Sources of game data

  35. Thanks! yna@cs

More Related