Storage Design

We'll be dealing with lots of game state. Some can be relegated to the continuation, but much more must be stored in a manner that won't be messed up by code changes.

State needs to branch with code in most cases - we can't have certain kinds of state in the 'shared world' being affected by custom code. We also don't want to limit storage abilities of other coders.

Git has the ideal data model for branching and merging data, but it may not be thread-safe. We might have to modify libgit2 and/or use a custom, thread-safe library for modifying the git database.

What data shouldn't branch?

  • user profile information
  • list of user branches
  • chat rooms
  • messaging

How do we synchronize things like 'gold' without permitting exploitation? How can 'official code' in an unofficial world affect the shared world?

How about:

1. Official code (unmodified) affects the shared world.
2. Modified code affects the derived world. Before modified code runs, changes from the shared world are pulled and merged into the derived world. Changes are not commited back to the shared world.

+Ignore the rest of this page, it's being rewritten.


Here is a comparison of the leading noSql variants. BigTable excluded.
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Data storage scopes

(draft)

  • Module-local, character-local
  • Module-local, user-local - Not sure when/if this would be used
  • Module-local, shared - Values like the current high-scorer at a mini-game
  • World-local, character-local - Health and hit points, etc.
  • * World-local, user-local - ?
  • World-local, shared - Values like the last winner of the sheap-shearing competition, etc.
  • Global, user-local - E-mail address and preferences, Facebook permissions
  • Global, shared - Data like weaver-engine newsletters, shared libraries, etc.

Code storage scopes

There should be a method for inheriting code files from an existing world when creating a new one. It's important that we allow forking to work easily, both for localization and for our own development purposes.

  • Global (not sure)
  • World-local (Shared libs, main areas, module integration points)
  • Module-local
  • Module-local, user-local
  • User-local