Database Reference
In-Depth Information
Locations
The various locations in which characters and items might find themselves such as rooms,
halls, etc.
Another consideration when designing the persistence backend for an online game is its flex-
ibility. Particularly in early releases of a game, we might wish to change gameplay mechanics
significantly as players provide feedback. When implementing these changes, being able to
migrate persistent data from one format to another with minimal (or no) downtime is essen-
tial.
The solution presented by this use case assumes that the read and write performance is equally
important and must be accessible with minimal latency.
Schema Design
Ultimately, the particulars of the schema depend on the design of the game. When designing
ourschema,we'lltrytoencapsulateallthecommonlyuseddataintoasmallnumberofobjects
in order to minimize the number of queries to the database and the number of seeks in a query.
Encapsulating all player state into a
character
collection, item data into an
item
collection,
and location data into a
location
collection satisfies both these criteria.
Character Schema
In a role-playing game, then, a typical character state document might look like the following:
{
_id
:
ObjectId
(
'...'
),
name
:
'Tim'
,
character
:
{
intrinsics
:
{
strength
:
10
,
dexterity
:
16
,
intelligence
:
17
,
charisma
:
8
},
'class'
:
'mage'
,
health
:
212
,
mana
:
152
},
location
:
{
