Sooo… jumping over from your other question on authentication.
!! Warning !! Looooonng technical / meta-physical piece of description / rambling coming on. Thou be warned!
There is an important difference to make between the “data” that makes up the state of your (game) world and the “data” that keeps track of the state of your (game) world. I know and admit that just writing that phrase does not necessarily clear things up (some might be more confused even… you have my sincere apologies), so I’ll try to illustrate & explain this as best as I can:
Data that makes up the state of your world
This can include, in a clearly non-exhaustive manner, things like the position of entities, player’s health, etc. This covers things as immaterial and global like the current weather in a region of your world to physical and local things like the content of a player’s inventory (I deliberately choose that last example). If you relate this directly to SpatialOS notions this basically targets all the components that you describe in you Schema files, multiplied by the number of entities that use each specific component. In sum… this is a very diverse set of data.
One thing though that characterises this set is that each element in it is poised to change quickly and continuously throughout the life-cycle of the deployment where they reside. Yet another, perhaps more fundamental, point is that without this particular set of data there is no world: this data is the world.
As a consequence of the two previous common characteristics this kind of data needs to be available quickly and at all times, potentially for all the workers running throughout your entire deployment running on multiple machines (which is after all the raison d’être of SpatialOS). This means this data is stored in memory (i.e RAM) distributed across the different nodes / servers of your deployment. This is done, not in the workers themselves but rather in the core part of our platform that also performs load-balancing, etc. Workers can fail, time-out, start, stop, pause without affecting the data-store. When a worker sends & receives component updates it’s talking to this inner layer of SpatialOS and not directly with other workers. On start a worker just receives a larger set of updates than usual as it does a full check-out of the components / entities in which it is interested.
When SpatialOS promises persistence it should be understood as in: "the data that makes up the state of your world will be available from the start of your deployment to its stop no matter what happens to the workers that simulate your world. Still, even if we implement multiple techniques to ensure that this data storage survives when all hell breaks loose, we are not sheltered from a potential major outage (e.g a cloud provider messing up the data-centre in which your deployment is running). To this effect, and for numerous other use-cases, there is the possibility to make so-called snapshots of your world which are basically a dump of the whole state of the world at a given point in time.
Such a snapshot can be used to boot a fresh deployment in the exact state of the old deployment when the snapshot was taken. This is another part of the persistence of your world that SpatialOS is all about: the entire state of your world can even survive death of the underlying deployment.
Now you may put forward that you also don’t loose your position, inventory and attributes when your favourite MMORPG’s servers go down for maintenance or crash but such worlds do not retain all data (the position and health of this NPC, the fact that the tree at location < X,Y,Z > has been chopped down).
For a more concrete illustration: most NPCs in such games are based on the well-known spawn cycle which mean that you don’t care about the state of any particular NPC before & after a server reboot. And… well… with SpatialOS we do care. This is one of the key elements with which we want to encourage people to play in order to invent completely new game mechanics and types. But now… back to snapshots…
Snapshots are a costly operation and should not be counted on to offer the possibility to, for example, roll back exact player transactions with respect to maintenance or other similar incidents. For similar reasons it is also not a very good design to store all of your data related to offline players somewhere a Schema in your world: it will only increase the size of the snapshots and the cost of making them without providing the proper guarantees for rollbacks. This type of guarantee should be provided with…
Data that keeps track of the state of your world
Not all data is born equal and there is no Universal Declaration of Data Rights. As a developer of an online game you are probably much more attached to the data that describes the attributes and belongings of your user’s characters than you are attached to the exact position of that chopped-down tree at < X,Y,Z >.
In a general manner, even outside of SpatialOS, as soon as you have such an element of data about which you care deeply you want something that:
- is written on disk and not in memory, preferably on multiple disks in multiple locations for redundancy.
- has access mechanisms that implement transactions correctly.
- (potentially) allows for rollback to a specific point in history.
… in other words an on-disk cloud-based transactional database.
This does not mean that the same elements can not also exist as temporary duplicates in your deployment as pieces of data that make up your world but you do want to back those temporary storages with a permanent one. The size of this should not be enormous even for huge deployments as the amount of data that you really care about is only a very small percentage of the total volume of the whole world state.
SpatialOS in not an on-disk database as I hope the first part of this waaaay too long post manages to explain. Maybe… in the future (no promises)… we may want to (no promises, again) to investigate such extensions. However in the meanwhile there is still a lot of fine-tuning to do on the current scope of SpatialOS and we do want to put our efforts where we believe that we can provide the greatest value to you as a developer. This means providing a platform that allows for small teams and even individual developers to very rapidly create and iterate on new innovative games that grow to the scale of what AAA studios do with a full network and infrastructure engineering team, or beyond.
Anyway… I’m signing off here (and if somebody knows the address for a rehab facility that treats people that write too long response posts, please forward ).