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
Item-based systems are at the core of the game. We must handle this.
|
Large shared world
| Rank: 5
Multiple shared spaces roughly 100 sq km. Intended to support average 3000 players / map (30 / sq km). Populated areas will max 200 players / sq km in non-combat activity. Battleground and raid areas max 100 players / sq km with combat activity during events.
| 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
We have flexibility on how to achieve it, but we must have the "feel" of a large world with lots to do.
|
"Items are important
and ubiquitous"
| Rank: 4
Items are second only to character, but without items you really don't have much character. Inventory will be massive; nearly all game systems will interact. Lots and lots of state updates on the server; hopefully somewhat minimizing transfers to client. | 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
Essential to game play. The only wiggle room is probably in variety of items, but it won't be enough to really limit load. We have to get this right.
|
Unique character visuals
| Rank: 4
Large number of players * (Body Mod Slots + Character Creation Choices) = lots of stuff.
Mitigated a little by client-side pre-cacheing, and a little more by aggressive server-side distance culling.
| 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
Fortunately design and art is willing to give ground here. We want as much as we can get within reasonable tech limits. Plus, this is an area that's great for expansion after ship.
|
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
We need to scale, but we can make design concessions to get it. Distribute load based on functional responsibilities, orthogonal to game play and world geometry. Consider actor model for ease of single-threaded-ish implementation. | Rank: 4
Essential to be massive; but not essential to hide partitioning/sharding from players. Who wants to get to know that many people anyway?
|
Persistent mission state
| Rank: 3
Lots of data, but modified infrequently. Reasonably easy to optimize loading of a subset at any given time.
| 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
MMORPG, y'all. Story-based missions are where it's at.
|
Persistent character state
| Rank: 3
We can keep this fairly tightly scoped if we do it right. Most integration between characters and other game systems is above the persistence layer. Need to scale frequent writes, infrequent reads (assuming cache).
| Rank: 3
Probably some kind of key/value store for attributes. BLOBs seem attractive at first, but IMO they'll bite you in the ass later. Basic CRUD operations with a write-through cache on top - Redis, anyone?
| Rank: 5
If we don't get this right we need to go home.
|
Text and voice chat features
| Rank: 3
Text chat is fairly straightforward to scale up. Voice chat is a bigger challenge; consider a third party solution or cloud service only. | Rank: 2
Chat tech is generally well understood, with support from existing solutions if desired.
Integration with game features will be limited to global, regional, alliances, party, and private channels.
Just don't try to implement a custom XMPP server! Not worth it.
| Rank: 4
This is an MMO; we need people to interact and build community in the game. Need this for ship.
|
Persistent alliances
| Rank: 2
I'm arbitrarily deciding that alliances will be pretty tightly scoped. It will be focused almost exclusively on supporting social interaction and offline coordination of group play. Not tightly integrated with other game systems.
| 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
This is a feature that we can enhance after we launch the game. Deferring this until we have more players and a greater need for social integration is a reasonable tradeoff.
|
