Collaboration

The most challenging aspect of this project is how to make collaboration seamless - and encourage it.

By limiting what users can change about their world, we would also limit how quickly they can learn. If we try to prevent users from messing up, we'll also probably be preventing them from learning anything.

The way around this is to give each user their own world(s), but allow each user's world to interact with the other worlds in certain predefined ways.

By doing this, users can have the freedom to experiment with everything, but only affect the 'main' world through the assistance of a 'lifebringer', who merges their changes into the main world.

In essence, we take the DVCS principle to a new extreme.

Changing your own world(s) is permitted very soon in the game, once you start training to become a 'Illusion caster'. You progress through different stages as you train, and soon you have full control over your own version of the world. You can invite others to read your 'book of illusions', but if they make changes, they will only affect their world.

In your own world, you are a 'Lifebringer' - you have the power to bring other's illusions to life within your own illusion. And you have the power to give the same power to others - you can let others write on some (or all) pages of your own book.

Each page represents a portion of the world. It could be an entire castle, a humble shop, or a single detail.
Each page has metadata, which determines who can change it. Users are grouped into 'roles', and each role has different abilities. 'Owners' can do anything, 'English teachers' can correct dialog only, etc… Actions are things like 'change all', 'change metadata', 'change text', 'change value'.
Metadata can be stored in the form file.txt.meta

Upstream changes

As each book is based on the book before it, changes upstream should naturally cascade downwards. Conflicts should be resolved by a human. Metadata can control which pages are automatically updated, and which are not

Data structures

An immutable Hash tree such as is used in Git would work, although recalculating hashes may be expensive for a deep tree. Merging should be fast, changes should be obvious.

Simple immutable data structures (such as those in Clojure) may also fit the bill, if they can be serialized properly. Technically, Confluently persistent data structures is what what we're looking for. And here's a PDF on confluent tries.

Volatile data

Some volatile data may be difficult to store in the structure. Will need to experiment.

External data

While the hash tree can store everything all at once, the 'head' points of the branches need to be stored somewhere. Each user has a set of branches, and each branch has a list of branhces it is 'tracking'.

Error handling.

When something goes wrong, the user can either try to debug it, or perform a rollback. In both cases, they should be able to look at what has changed since it last worked.

Organziation

/users/userid/