Application

The nebula application layer provides high level application utilities, such as gameplay systems.

Game system

Nebula uses a database oriented approach to storing game entities and their respective properties.

The entity system currently consists of a couple of databases, the most important one being the world database.
The world database contains all entity data for active entities.
Properties are what define the entities' data. When an entity is created with a unique combination of properties, a new table will be created in the world database. These tables are referred to as entity "Categories".
Entity behaviour and logic is expressed via "managers" and "processors" that query the database for entities that fulfill certain property requirements, and then process each entity based on their properties states.

Entities, Blueprints and Templates

Entities are simply integer identifiers that are mapped to a category, and row within the category table. Entities are commonly created by instantiating data-driven blueprints and/or templates.
Blueprints are essentially category descriptions that just describe a named collection of properties.
Templates are derived from blueprints and describe specific property values for an instantiation of a entity.
Lets take an example:
We declare an "Orc" blueprint that consists of four properties: Position, Health, Stats and Target.

• example_blueprints.json:

  {
      "blueprints": {
          "Orc": {
              "desc": "A mean and green orc.",
              "properties": [
                  "Position",
                  "Health",
                  "Stats",
                  "Target"
              ]
          }
      }
  }

Each and every instantiation of this Orc would have the same values (default set by the property definition) but we might want to have multiple different types of orcs. This is where we can use templates.

• templates/Orc/orc_soldier.json:

  {
      "blueprint": "Orc",
      "properties": {
          "Health": 100
          "Stats": {
              "Strength": 75.0,
              "IQ": 85
          }
      }
  }

• templates/Orc/orc_brute.json:

  {
      "blueprint": "Orc",
      "properties": {
          "Health": 250
          "Stats": {
              "Strength": 120.0,
              "IQ": 44,
              "isLarge": true
          }
      }
  }

Instantiating these templates will automatically set the defined properties to a specific value.
Note that we don't need to overwrite all default property values in our templates.

Properties

Properties are the main way to describe an entity's state.
Properties are usually declared and defined via .nidl files (Nebula intermediate definition language) and compiled into C++ code via an IDL compiler.
All properties must be trivially destructible and trivially copyable. Note that it can still define a constructor or have initilizers in the declaration. The NIDL specification can be found here: Nebula IDL
Properties can also be created explicitly via the Game API's CreateProperty function or the MemDb::TypeRegistry::Register (typesafe) function. When explicitly creating a property, you can choose to flag the property with various flags. These flags can for example alter the lifetime of the property, allowing certain managers to clean up external resources before an entity is fully destroyed.

See also

Game::PropertyCreateInfo

Game::PropertyFlags

MemDb::TypeRegistry::Register

Game Managers

Managers are defined via a simple function API. They are meant to care about "specific global stuff" and should be defined by applications to implement globals aspects of the application (mainly global game play related). Managers should be created and triggered by game features. Their frame event functions are invoked when the gameserver triggers the game feature.

See also

Game::ManagerAPI

Base Game Feature

The BaseGameFeature is integral to the Nebula entity system and sets up the entity, blueprint and time managers. These managers supply the runtime with the core management needed for the entity system, and this feature should most likely always be attached to the game server upon application startup.

Graphics Feature

The GraphicsFeature automatically sets up the core rendering subsystem and initializes tons of boilerplate so that you won't have to. The feature also creates a number of useful properties and managers that allow you to easily render models, animations, particles etc.

See also

api.h
Game
BaseGameFeature
GraphicsFeature
PhysicsFeature
MemDb
Base Game Components