Distributed MMOG Game Engine

1
Distributed MMOG Game Engine

• Eric Brooks, Peter Noyes, James Seidel
• Computer Science 189A
• January 20, 2004

2
The Computer Game Industry

• Trend in gaming currently moving toward MMOG
  (massively multiplayer online gaming)
  environments
• So what's an MMOG? A Massively Multiplayer Online
  Game is one in which there is a persistent world
  online that exists whether or not you as a player
  are participating in it. Your own character
  develops over time (or your empire grows over
  time), and while you control your own destiny,
  you share the world with any number of other
  players -- all with their own agendas, desires,
  and neuroses. (www.gamespy.com)
• Popular games may have upwards of 200,000
  subscribers
• Current systems allow for up to 2,000 concurrent
  users in a world
• Market for MMOG in U.S. reached 600 Million in
  2002
• Everquest alone takes in 4 Million per month

3
Issues with Current Architectures

• Bandwidth
• For most subscription based massively multiplayer
  (MMP) games, bandwidth limitations are not based
  upon physical limits rather they are based upon
  bandwidth costs. This means that proper bandwidth
  management translates into real dollars in a very
  big and measurable way. (www.gamasutra.com)
• CPU
• As games grow increasingly larger, much more
  processing power is needed.
• Storage
• Maintenance
• Scalability

4
Trends

• Movement toward distributed environment to handle
  increasingly complicated games.
• Central servers replaced with clusters of servers
• Some Drawbacks Include
• Must be able to accommodate situation of absolute
  peak connection times, so resources may sit idle
• Poor implementations of distributing regions of
  the map, so that moving about in the world is not
  seamless

5
Our Solution

• An untapped resource for game processing is the
  client computer
• Gamers purchase increasingly better hardware
• Gamers on broadband connection
• Use the client computer to help distribute the
  bandwidth and CPU loads placed on the server
• Client/Server vs. Peer-To-Peer
• The Client/Server approach is the most logical
  way to attack the problem of implementing an
  MMOG, a persistent game state is difficult to
  maintain in a strictly Peer-To-Peer approach
• Current Peer-To-Peer games are restricted in
  size, because current approaches involve all
  peers maintaining own state of entire world, and
  all peers must be in communication with everyone.
  (Example Age of Empires)
• We propose a hybrid of the two, a central server
  to maintain the global world, but with ability to
  pass ownership of regions to clients

6
Solution Diagram

• Possible configuration during game play
• Computers 1 3 are in charge of zones
• Computers 1 and 2 have zones which are neighbors
• Computer 4 is not acting as a zone server

7
Implementation

• Divide map into zones, each zone contains
  processing control over all game objects
  contained within the zone
• Each connected computer has capability to take
  ownership of any number of zones, acting as a
  sub-server
• The Client will only interact with zones that are
  part of the players sphere of influence, so
  clients will interact with the computers in
  charge of the appropriate zones, instead of the
  central server in many cases, which helps
  distribute bandwidth away from the server
• Zones maintain lists of neighboring zones, so
  that messages can be sent if zones influence the
  game state of its neighbors
• Zone division is a recursive process so one high
  load zone can be split and passed to more clients

8
Implementation cont.

• Still have a central authoritative server for
• Creating snapshots of the entire world as
  sub-servers synchronize zone data, at a
  configurable time interval
• Maintaining list of connected clients
• Processing zones that are not under control of
  sub-server
• In case of a complete sub-server crash, zone will
  be recovered by one of two means
• Attempt to recreate zone data based upon cached
  user input at the game client level.
• If client data was lost due to the crash, it will
  be possible to roll back the game state to the
  last known snapshot available on the server as a
  last resort.

9
Implementation cont.

• To demonstrate the technology we will implement a
  tank combat simulation game on top of the
  distributed architecture.
• Game Overview
• Isometric viewpoint (simulated 3D)
• User has control of individual tank
• Giant Map to exemplify our distributed game
  engine
• Object of game is to increase skill points over
  time by defeating other tanks, finding hidden
  items in the game and completing missions.

10
Milestones
11
Tests Results

• Goal For End of Class
• Show that system reduces the amount of bandwidth
  placed on the central server by having clients
  accept processing responsibility
• This will be accomplished by have the option of
  having the central server process all zones, and
  measuring traffic at the server