Database Management

The application uses two different databases for learning data and logging data.

Learning Data (static database)

Learning data comprehends all information needed to provide a correct learning experience for the players. This data is included with the application at startup.

This includes:

The data is compiled into JSON files contained inside the _manage/manage_Database/Datasets folder. The JSON files are loaded using the _manage/manage_Database/manage_Database scene, where consistency checks are performed and the database contents can be inspected. @todo: explain DataParsers too.

The database is converted from JSON to a set of custom assets (deriving from ScriptableObject) that contain a table of data, with one asset per data type. The contents of Database/DatabaseObjects** define the scriptable objects from which the custom assets are derived. These assets can be found in the Assets/Resources/Database folder. To perform the JSON-to-asset conversion, the DatabaseLoader scripts employs a *DataParser for each data type to load, which defines how to parse the JSON file into the corresponding data structure.

At runtime, Antura.Db.Database functions as an entry point for all the assets containing the data tables and is managed by a Antura.DatabaseManager instance.

@todo: describe Journey and MiniGame data?

Dynamic Data

Dynamic data is produced as the player uses the application and saved to the system’s memory at runtime.

The data is divided in several categories:

See the Logging document for further details on logging.


The database is implemented in SQLite. The SQLite database is loaded and connected to whenever a player profile is selected, and generated if non-existing. All communication with the SQLite database is performed through a Antura.Db.DBService instance, managed by the DatabaseManager. The structure of the SQLite database can be generated a runtime and this is controlled through the DBService.GenerateTable(bool create, bool drop), which can be updated to reflect any changes in the DB scheme. Note that any change to the database scheme must also prompt a sequential update of AppConfig.DbSchemeVersion for versioning to function correctly.

Profile API

The logging database supports multiple profiles. A profile can be selected using Antura.Db.DatabaseManager.LoadDynamicDbForPlayerProfile(int profileId), which loads (or creates if it does not exists) a database for logging data of the chosen player. Player profiles are also supported with:

Reading API

To read learning or logging data, a single entry point is used throughout the application. Antura.DatabaseManager is the entry point and can be access through the public field AppManager.I.Db.

The Database Manager provides several methods for each data type represented in the learning and logging data.

To access learning data, the following methods can be used:

To access logging data, the following methods can be used:

Writing API

To write to the database, the Database Manager provides the following methods:

Note that these methods should not be called directly and that all MiniGames should use the LogManager to indirectly write to the database. Note that the vocabulary data is static and thus not writeable at runtime.

Refactoring notes