Assumptions for MMORPG Feature Impact Assessment
The feature impact assessment for the MMORPG game design requires a number of assumptions that aren't documented in the main posts or in the "reference problem statement" for the game. I've provided them here to serve as a rationale for impact rankings that I chose.| Feature | Size | Complexity | Importance |
|---|---|---|---|
| Persistent item state | Rank: 5 Ubiquity and importance of items will make for large numbers in inventories and various game systems. Expect high frequency of both reads and writes. Caching definitely going to be needed. Again, Redis perhaps. | Rank: 5 Huge variety of items with modifiers/enhancements/persistent effects means key/value store over table storage. Also, BLOBs not worth the trouble; too likely for object attributes to change. Economy, player trades, missions and other use cases where items are transferred between owners will require transaction support. | Rank: 5 |
| Large shared world | Rank: 5 | Rank: 5 Using non-contiguous shared maps, with instanced spaces for certain missions and group activity. Will need lots of testing and iteration of visibility vs. performance using various terrain geometry scenarios. Also, need to do serious investigation on NPC populations vs. players. Probably need some "clever tricks" to make things feel right. | Rank: 5 |
| "Items are important and ubiquitous" | Rank: 4 | Rank: 5 What can I say? Items touch everything: combat, crafting, economy, visuals, missions, and world interaction. (repeated from character visuals) Need a good - no, great - visibility and distance culling system. Also may need server-side LODs (not graphical, but governing number of item slots that may be visible to others). Need to work with client devs on pre-caching of items in the client. Also need general item/object catalogue for classifying what objects can be seen at what locations and/or with which NPCs to minimize load, because we can't really do that with Player characters. | Rank: 5 |
| Unique character visuals | Rank: 4 | Rank: 5 It will be a challenge to get the variety we'd like without overwhelming bandwidth with state updates. Need a good - no, great - visibility and distance culling system. Also may need server-side LODs (not graphical, but governing number of item slots that may be visible to others). Need to work with client devs on pre-caching of items in the client. Also need general item/object catalogue for classifying what objects can be seen at what locations and/or with which NPCs to minimize load, because we can't really do that with Player characters. We have to insist that all behavior/game play item stuff is fully decoupled from the visual stuff so we can aggressively fall back if needed. | Rank: 3 |
| Large number of players | Rank: 5 We want thousands of concurrent users. This drives all aspects of scale in all systems. Need careful attention to data serialization and network optimization at the low level. State updates will be constant, both between server and clients and also between server-side processes, and persistent storage. At higher levels, we need to distribute load laterally across an undetermined number of services and hosts. This will also require the ability to scale laterally as well. No single points of failure or bottlenecks, please! This is what puts the "M" in MMO. | Rank: 3 | Rank: 4 |
| Persistent mission state | Rank: 3 | Rank: 4 Mission data is almost surely graph-based. Note fairly tight integration with items and other systems that use them; need to make sure we cleanly decouple mission and item state. Probably key/value store, *maybe* BLOB if absolutely necessary, but try (hard) to avoid. Versioning essential from the start; don't cobble it on later. | Rank: 4 |
| Persistent character state | Rank: 3 | Rank: 3 | Rank: 5 |
| Text and voice chat features | Rank: 3 | Rank: 2 | Rank: 4 |
| Persistent alliances | Rank: 2 | Rank: 3 Limited scope limits complexity automatically. Mostly basic table-oriented persistence required; small number of push notifications e.g. player joined/left, fairly basic tech. | Rank: 3 |
Return to Know what to Build: Assessing Impacts.