Good question!
Features:
- Minimize usage of the read and write datastore APIs so that API limits can be safely used
- This means combining several datastore entries into one store. Instead of having 1 entry for gold, and 1 entry for money, this system combines the overall entries together into a table, while providing an API that is acceptable to use and acts as if you had entries for each one.
- Furthermore, abstracting this API so that dependences aren’t required
- Detect load failures and prevent further
- Deal with the fundamental asyncronious component of DataStores
- Abstract away a dependence upon faulty datastore API such that you can reasonable deal with errors
- Ability to move from legacy system to this system
- Proper merging on substores and systems (SUBSTORES!)
- Proper write/change detection to minimize API calls
- Granular control on exactly what happens, including load process
Summary:
- Absolutely minimized read/write API uses (One on load, autosave time, 1 on leave)
- Ability to utilize with existing save system or save systems (Datastore2 tends to require migration)
- Substore API abstraction is clean
- Promises (Good API)
- Very granular control of behavior (more than datastore2)
- Handles load failures in an elegant way.