How to store generic data in game database?

Question

To clarify things a bit: I want to create a kind of database for my game, that simply is a class that stores all game-state information like object positions, player scores, etc.

The main problem I am facing, that the whole game is to be scripted, to the level of the (lua)script controlling what members should the database have.

The reason for this is that I want to create a game that gives modders complete access to the game via lua scripting.(its one of the core features) For this to be viable I need to be able to add custom elements to the database.

I want to avoid using a 'real' database and roll my own solution.

For example I want to be able to do the following in the script file:

-- In function init...
Engine:AddStateEntry( "Score", TYPE_INT )

-- In function update...
Engine:SetStateEntry( "Score", 12 )

My engine would then synchronize data between players and render things accordingly.

How could I:

• Efficiently store arbitrary types of data?(including arrays)
• Set up custom interpolation functions

Efficiency and ease of use are my main priorities.(I dont care if the implementation is complex)

TL;DR: How to efficiently store arbitrary data that is defined by lua scripts and stored on the c++ side?

Answer 1

Seems like this is a matter of implementing an Entity-Component system?

Your "database", or game state, will be incredibly simple: it'll have a container for entities, and that's pretty much it. Each entity will have a unique id, and a container for components. Then, you run the entities through various systems.

So constructing the game would involve things like creating a player entity, world entity, camera entity, and so on. They're only shells, though, you need to add things like a collision component, physics component, control component, render component, to your player, and other entities.

Another important point, the components are 100% data, 0% functionality. Functionality comes from the systems.

To elaborate on the systems, they are like machines that take your list of entities as an input, they then make changes to the data, after which the entities go through the next system, and so on (or you can send an entity through all systems, then the next entity, then the next...).

Properly implemented, your gamestate/database will contain all your data, with functionality reserved to the various systems. And since entities are created as sets of data, using scripts to add entities, and components to those entities, is a trivial matter.

I could go pretty in-depth on the matter, or I could point you to this fantastic answer by Jon Purdy.

The important thing is abstracting the data from the functionality, and entity component systems are the typical way of achieving it. It's how Unity, for example, is built.