Documentation as of February 10, 2016
EODB: Stable
NEODB: Currently in Detailed Implementation Testing.
- We're writing a demonstration game using NEODB.
- We will release the NEODB platform when the game is ready.
- NEODB owners will get the game (including all the source code and graphics) as part of their distribution.

Overview - EODB - Elenesski Object Database

Asset Store Link: https://www.assetstore.unity3d.com/en/#!/content/52209

The Elenesski Object Database (EODB) is a platform for saving and persisting objects from memory on to a local disk. It works by providing an in-memory database that you read/search/write objects from. A database can then be saved to disk with a single commit, enabling a single resource for loading/saving games. EODB works with objects allowing you to, on the fly, define what attributes of an object you want to persist including arrays, lists, dictionaries and other types in a binary format and reading them back from that format back into your objects.

This is how to see how to use the architecture for your game or app. EODB contains many more classes than are shown here. This diagram is simply to provide an overview.

EODB, an in-memory database

Overview - NEODB - Networked Elenesski Object Database

Asset Store Link: Coming Soon

NEODB is in testing/development and subject to change. (February 10, 2016)

NEODB is an extension for EODB. In order to use NEODB, you need to own EODB, because it uses the underlying EODB database to hold objects you extract from the network database. It provides a mechanism to store your data in a mySQL database on an SSL-enabled PHP server.

The hardest part about working with a remote database and the NEODB Server is that calls occur in the background to the server and can take a few moments to several seconds to complete. This means you have to code your game to be "doing something else" while making server calls. When the server responds, you get a success or a failure callback to identify the outcome of your call. Failures are usually configuration or Internet issues that cause the call to timeout. Success is everything that is not a failure. (See the "Network - Architecture" section for additional information.)

There is no way to predict how long it will take between the time you make the call to the time you get a response. Normally it's less than a seconds, but the distance to the server from the client affects time as well, if the connection between the user and the server is broken because part of the Internet or the ISP that hosts your server and database is down, the call might take more than a minute to time out.

When dealing with an external server/database a lot more things can go wrong, so NEODB's failure architecture consists of a hybrid "exception handler". This is a method that is called with an exception as a parameter. It's up to you to then evaluate the exception or throw it. Generally you code a single method to handle all exceptions with a scene with NEODB.

This is how to see how to use the architecture for your game or app. Encoding and all of the complicated asynchronous calling is handled transparently for you. You get the source code to see how it works, but generally you don't need to worry about how it's implemented to use it.

Important Notice NEODB does not encrypt the data it sends from the app to the server. It's is highly recommended that you use a server that supports SSL so that you can make calls to your server using HTTPS. Without SSL/HTTPS, any hacker betweeen you and the server can see the information you are sending. See the section "30 Network - Architecture", in the main menu, for additional information.

NEODB, networked object database