Downloaded 14 times
Uploaded byYan Cui
Building an MMORPG - Here be monsters
Yan Cui's document discusses the development and performance metrics of a social gaming platform centered around homestead farming and monster-catching. Key statistics include over 200,000 unique players and significant gameplay engagement, while addressing server management strategies, state handling, and the importance of analytics for continuous improvement. The document emphasizes the necessity for a flexible, data-driven approach to enhance player experience and support game updates.
More Related Content
![[Start] Playing](https://cdn.slidesharecdn.com/ss_thumbnails/start-playing-121117211541-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Building an MMORPG - Here be monsters
Building an MMORPG - Here be monsters
- 2. Name : YanCui Industry : Social Gaming
- 12.
- 13.
- 14.
- 24.
- 36.
- 37. • 200,000 uniqueplayers • 300,000 hours of game play • 100,000,000 server requests
- 38. • 45,000,000 itemsforaged • 1,000,000 butterflies caught • 4,000,000 seeds planted • 4,000,000 monsters caught
- 39. • 5,700,000 itemsbought • 24,000,000 items sold • 280,000 hours of time potion used • 526,000,000+ km travelled • around the earth 13,000 times...
- 40. • Bulk ofthe game developed by • 1 server developer • 2 flash developers • 1 producer and 2 game designers • Several artists
- 41. We have hadto find ways to solve problems effectively and efficiently
- 43. • States canbe BIG • Grow with content
- 45. • 1000s ofitems on homestead • Each item has some state
- 47. • Storage unitsadd 1000s more items • Players like to collect things ;-)
- 50. • A lotof states to track on character • 100s of items in backpack • 100s of quests/achievements • Players like to collect things ;-)
- 51. • Many actionsrequires both states at once • Operations are expensive • Best players get the worst latency
- 52.
- 53. • Stateless serverapproach + Easy to scale up and down + Scaling can be dynamic based on load + Every layer can scale independently
- 54. • Stateless serverapproach – Serialization/deserialization is heavy on CPU – Heavy load (1:1 read write ratio) on databases – High bandwidth usage – High latency
- 55. • Stateless serverapproach – Inefficient – Expensive
- 56.
- 57. • Traffic isbursty • Keep state on server during bursts = Less serialization & deserialization = Less load on database = Fewer server and database nodes =
- 58.
- 59. • Stateful serverapproach + 500% improvement on efficiency + 60% reduction in average latency + Fewer game servers + Fewer database nodes
- 60.
- 61. • Server affinity –Need to ensure server affinity during one burst – Need to route calls to affined server
- 62. • Load balancing –Some players are more active than others – Need to avoid hot spots
- 63. • Server hogging –Session lengths vary greatly – Need to avoid players hogging a server – Need to be able to scale down!
- 64. • Persist stateafter short inactivity • Move player to another server after persistence
- 66. • Scaling down –Need to gracefully drain player states – Need to be able to stop accepting new players
- 67. • Stateful serverapproach – Complexity + But worthwhile! + Others avoid scaling down to reduce complexity
- 68. • Progress tiedto most actions • Avoid scripting • Data driven
- 69.
- 70. EXP Item Gold QuestProgress Caught a Gnome
- 71. Level Up Quest Progress EXPItem Gold Caught a Gnome Quest Complete
- 72. Level Up Quest Progress EXPItem Gold Caught a Gnome Quest Complete New Quest
- 73. Level Up Quest Progress EXPItem Gold Caught a Gnome Quest Complete New Quest
- 74. Level Up Quest Progress EXPItem Gold Caught a Gnome Quest Complete New Quest Achievement Progress
- 75. Level Up Quest Progress EXPItem Gold Caught a Gnome Quest Complete New Quest Achievement Progress Achievement Complete
- 76. Level Up Quest Progress EXPItem Gold Caught a Gnome Quest Complete New Quest Achievement Progress Achievement Complete
- 77. Level Up Quest Progress EXPItem Gold Caught a Gnome Quest Complete New Quest Achievement Progress Achievement Complete
- 78. And that’s notall...
- 79. • 100+ actionsavailable in the game • Most can be tied to quests/achievements • Many yields rewards
- 80. • Triggered fromdifferent abstraction layers • Trapping controller • Level controller • ...
- 81. • Non-functional requirements •Analytics • Partner reporting • ...
- 83. • Message brokerpattern • Something happened, it’s a FACT • Caught a Gnome • Got some EXP • ...
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91. • Message brokerapproach + Simple + Flexible + Extensible
- 92. • Message brokerapproach – Requires large number of different facts + F# to the rescue!
- 94. • OK forsmall number of DU cases • 100+ actions available in the game
- 96. • Players lovequests
- 97. • Need regularcontent releases • Game is heavily data driven + No developer involvement for content changes • Tech team needs to be enablers
- 98. • Producers needability to • Plan changes weeks in advance • Quickly see and validate changes before release
- 99. • Game designersneed ability to • Work on changes in isolation • Quickly iterate and test changes in isolation
- 100. • QA needability to • Quickly switch between different changes to test • Smoke-test changes in live environment without affecting real players
- 101. • Server teamneeds ability to • Version data changes • Rollback/hotfix data changes with no downtime
- 102. We version controlour code, why not our data?
- 103. • Git +Git flow • Servers allow multiple data branches and switching between them
- 104. • What doour players like to do? • Every action in the game is recorded
- 105.
- 106. • Analytics isa key decision-making tool • A/B testing
- 107. • 150,000,000+ eventsrecorded in April • Several GBs of analytics data a day • Fast growing!
- 108. • Google BigQuery +Cheap + Fast + Scalable + SQL-like query syntax
- 109. • Google BigQuery –OLAP – Append-only
- 110. • What isour code doing?
- 111. • Monitoring • Notthe same as profiling • Should be always ON • Difficult to set up in large distributed environment
- 112.
- 113. • Method executiontime • e.g. IO, CPU intensive • Method execution count • e.g. service entry points • Error count • ...
- 114. • Amazon CloudWatch +Cheap + Supports alarms and notifications + Visualization tool
- 115.
- 117.
- 122. • Metrics areaggregated at instance level • Metrics gatherer has high concurrency requirement • F# agents to the rescue!
- 123.
- 124. Here Be Monsters http://apps.facebook.com/herebemonsters AOPand pseudo real-time monitoring with CloudWatch http://bit.ly/11GL3SQ http://bit.ly/10fe98N Building social games with a .Net stack http://bit.ly/ZKtHWb http://bit.ly/10CtyY9 F# Agents http://bit.ly/ZmXuEP http://bit.ly/17kjbam F# Deep Dives http://bit.ly/XZe10E