Transcript Introduction to MMOG

MMORPG Servers
1
MMORPGs Features












Avatar
Levels
RPG Elements
Mission
Chatting
Society & Community
Friends
Combat
NPCs / Monsters
Experience Points
Extended Game Contents
Online Customer Services (GM)
2
MMORPGs Technical Elements







Client-server Architecture
Servers
Network Bandwidth
Network Data Packet
Network Security
Graphics
Database
3
MMORPG Servers


Stand Alone Servers
Distributed System
4
Standalone Server


Using a Set of Large Servers as the Game
Servers
Each Server Plays as a Single Function
internet
Login server
Database
Game play
Community
5
Distributed System - Concept

Distributed PC Clusters
servers
internet
Database servers
servers
Game play servers
Login servers
6
Distributed PC Clusters



1-U Web Server Based on PC Architecture
Two CPUs
Two Network IPs
Net IP 1
Net IP 2
Internet
Internal LAN
1U server
7
Distributed System - Features

Distributed PC Clusters
– Two IPs





Scalability
Fault Tolerance
Load Balance
Dynamic Zoning
“Blade Servers”
8
Distributed System - Scalability



Regional Operation Consideration
Cost Effective
Flexible Capacity
Serve concurrent 500 users
Serve concurrent 1000 users
9
Distributed System – Fault Tolerance



All Servers Can Not Be Down in Anytime
For Distributed Servers, Every Job Must Be
Transferred Between Servers
For Standalone Server, Use Redundant Policy
10
Master server
!
Slave server A
Internet
Internal LAN
!
Slave server B
11
Master server
Internet
Internal LAN
X Slave server A
Slave server B
12
Redundant Policy
!
Server on duty
!
ZZZ
Server off duty
13
Redundant policy
X
Server off duty
Server on duty
14
Master servers
Internet
Internal LAN
Slave server A
Slave server B
.
.
15
Distributed System – Load Balance


Distributed MMOGs Always Do the Load
Balance by In-house Approach
Load ?
– CPU bound
– Memory bound
– Network bandwidth
1 server = 500 concurrent players
10 servers =
X 5000 concurrent players
! It’s very important to move the jobs
on a crowded server to another ones
16
Master server
Internet
Internal LAN
Slave server A
Slave server B
Load balance – case 1
17
Master server
!
Slave server A
Internet
Internal LAN
!
Slave server B
Load balance case 2
18
Master server
Internet
Internal LAN
Slave server A
Slave server B
Load balance case 2
19
Zone Concept




A “Zone” is Logically a Region of Game
Happening on Servers
We Always Map the “Zone” to a Physical 3D
Scene
A Zone is Not Really a Physical Hardware
Server
But a Software Region that the Players
Communicating Directly (in the same
memory block)
20
Master server
Internet
Internal LAN
Slave server A
Slave server B
21
Server A
Zone X
combating
Server C
messaging
NPC
Zone Z
messaging
Zone Y
transaction
Server B
22
Interaction within/between Zones (Game Play)

Within Zone
– Combating
– Chatting
– Transaction

Between Zones
– Messaging
– Transaction (remote)
– Banking
23
Server A
Zone Z
Zone X
Server C
NPC
Zone Z
Zone Y
If server B is over-loaded,
move the “Zone Y” or “Zone
Z” to an available server C
Server B
24
Load Balance Using Zone Moving



Under the Concept of “Zone Moving”, We
Can Move the Zones Between Hardware
Server to Achieve the Load Balance
But is This a Total Solution to Solve the Load
Balance ?
Condition :
If server A is over-loaded,
Zone X
Server A
the whole server is over-loaded
due that server A is occupied only
one zone.
Thinking :
Zone Y
Server B
“Can we divide the zone into
two or more ? “
Zone Z
Server C
25
Dynamic Zoning



Dynamically Adjust the Zones to Meet the
Loading Requirement
Moving Zones between Hardware
Divide the Zone into Small Ones According to
the Load and Move the Small Ones to
Different Hardware
26
Dynamic Zoning (1)





A “Zone” is Mapping to a Physical Scene or
Map (geometry)
A Zone is Composed by Several Groups
A “Group” is a Collection of Players
(Population)
All Players in the Same Group Running in the
same Process
Players in Different Group Communicate
between Processes
– Inter-process communication (IPC) ?
27
Dynamic Zoning (2)

Group is More Dynamic Based on the
Concept of Population
– Create
– Delete
– Move
28
Zone = A 3D Scene

A 3D Scene
–
–
–
–



3D models
Moving objects
NPCs
…
Zones are Physically Neighboring Together
Using Portals to Connect the Relationship
Player Travels between Zones
– Logout current scene and login to another
neighboring zone when stepping on the zone
portal
– Players will wait for a short moment during the
moving
29
Zone Portals
Portal
Portal
Zone Y
Zone X
30
Zone Portals
Portal
Portal
Zone Y
Zone X
31
Population Group





A Data Structure to Contain the Players
When a Player Logins into one Zone, He
Should Be Assigned into One Available
Population Group and Got the ID
Players Should Not Be Moved Between
Population Groups When He Is Staying in
this Zone
A Zone Can Be Divided into Several Groups
Group can be Created/Deleted/Moved by the
Servers for Load Balance
32
Players in a Zone
P5G1
P6G3
P1G1
P2G2
P7G2
P12G2
P5G3
Zone X
33
Server A
Zone X
Group 2 Group 1
When a new player
logins into Zone X, insert
the player into group 2 which
has space for new comer
Server B
34
Server A
Zone X
Group 3
Group 2 Group 1
But if there are no
groups with available space,
create a new group for new comers
Server B
35
Server A
Zone X
Group 6 Group 5 Group 4 Group 3 Group 2 Group 1
If the Zone X on Server A is full for new comer,
duplicate Zone X on Server B and
create a new group
for new players
Zone X (2)
Server B
36
Group 7
Server A
Zone X
Group 6 Group 5 Group 4 Group 3 Group 2 Group 1
Network communication
Server B
Zone X (2)
IPC
Group 8
Group 7
37
The Challenge of Dynamic Zoning

Physical Terrain and Models Are not Easy to
Divide Dynamically
– If your zones are coupling with the physical scenes,
to divide the geometric data in runtime needs some
specific algorithms for 3D scenes
– DO NOT do it
– Find a mechanism that makes the zone dividable
– And that is the “Population Group”


One Server Can Have Multiple Zones Running
One Zone Can Run on Several Servers
–
–
–
–
Hard to code
Duplicated memory on servers
Synchronization between servers
Data communication overhead
38
The Challenge of Dynamic Zoning (2)


Game Play Sensitive
Running Players in the Same Zone by
Multiple Processes
– Duplicated memory on the same server
– Synchronization between processes
– Data communication between processes

Players’ Attribute Data Should Be Classified
as :
– Frequently used between players
» Must be duplicated between processes
– Seldom used between players
» Send between players when necessary
– Locally used by player himself

Cross-platform Server API Design*
39