Presentation on MMOG architecture given to several app development groups interested in moving into the game design world. Much of this content was inspired by t-machine.org.
5. Game Loop
Receive player input
Process player actions
Calculate state changes
Apply state changes
Repeat
6. The Game Grows Up
single-player
multiuser domain > MUD
multiplayer online game > MOG
massively multiplayer online game > MMOG
7. MMOG is
session persistence 1000+ concurrents
single virtual world multiple client support
player interaction
8. Build an MMOG
3rd-party engine or in-house?
Self-hosted or gaming provider?
In-house servers or cloud?
Shared or dedicated hardware?
Shard or not-to-shard?
udp or tcp?
Peer-to-peer or server-client?
Virtualization or metal?
Client or server-side logic?
Chat or VoIP?
Windows or Linux?
MySQL or SQL Server?
9. Basic MMOG Architecture
Player client connects to Login server
Login Server provides authorization token
Copy of token goes to World Server
Player client handed off to World Server
World Server provides character data
World Server provides connection info for
Chat Server & Zone Server
Player client handed off to Zone Server
Zone Server handles gameplay in zone
World Server handles transition between
zones
11. Contrary to non-MMOGs
...the majority of MMOG development is
content
...the majority of MMOG development takes
place after launch
...MMOG core game logic will change
...MMOGs require massive quantities of
storage
13. "Content" is
Storylines (missions, quests, events)
3d areas (meshes, textures, logic)
Loot (item graphics, drop rates, item stats, etc.)
14. "Content" is not
Fancy graphics
Physics engines
AI
Core game rules
...which tend to make up the bulk of non-MMOGs
15. Rate at which players consume content
vastly exceeds the rate at which developers
generate it
eg. 50 developers generating content &
500,000 consuming it (and users are
sharing discoveries so consumption is
exponential)
17. Most MMOGs release new content every 3-
12 months
Releases are large: "miniature MMOGs"
(new 3d areas, quests, items, plotlines, etc.)
18. Underlying technology (engine) is usually
only updated when required by a content
change
Cutting-edge graphics are not a primary
selling point of MMOGs, unlike non-
MMOGs
19. MMOG development teams typically get
larger after launch (developing new content
& keeping the old content still working)
24. Progress of every player in an MMO needs
to be independently tracked (quests
completed, equipment they own, etc.)
25. 30GB+ every 24 hours, all of which needs
to be programmatically referenced
26. MMOG Design Considerations
How much effort is required to change an in-game item
How much effort is required to add (or remove) in-game items
How re-usable is the content
How much effort is required to re-use re-usable content
How much specialist knowledge is required to modify content and logic
How exportable is the data generated by playing the game
How analyzable is the data generated by playing the game
How much effort is required to modify core content
How much effort is required to change individual rules (and debug)
How many of the above can be made without a developer
Where can 3rd-party systems be used for server-side components
27. MMOG Design Rules of Thumb
Use non-proprietary databases for persistence
Use relational databases
Implement game logic as raw data rather
than compiled data
Use standard scripting languages where
possible
Intense testing during development
Even more intense testing after launch
28. The Future
Cloud is the hardware of choice
iPhone grows as gaming platform
Browser dwindles as gaming client
Ad-sponsored worlds
Educational worlds
29. The End
References
http://www.ibm.com/developerworks/library/ar-powerup1/
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/