Gladius is comprised of several modules, almost all of which are implemented as extensions:
gladius-core provides the core functionality of the engine.
gladius-input provides player input functions.
library.
gladius-box2d provides physics via the box2d library.
Gladius uses an Entity-Component system to model the game world. In other words, behaviors, such as rendering graphics, computing physics, and playing sound, are defined by components. An entity is a collection of components, and represents something in the game world. A space is a collection of entities.
Components both perform some function and contain the state for that function. Entities are nothing more than dumb containers that manage their components, and don’t carry any state. Components can be configured and swapped around between entities.
The game loop in Gladius is split into three phases: input, update, and render.
The input phase is for reading input from various devices, including the keyboard, mouse, gamepads, etc. The gladius-input extension provides a set of input devices and convenient plumbing for retrieving the input state.
The update phase is for updating game state. This includes calculating movement, applying physics, performing collision checks, and other core game logic. During this phase he updater service provided by gladius-core will trigger an updateevent on every registered component.
The render phase is when graphics are actually rendered to the screen. Typically extensions like gladius-cubicvr will handle this phase.
A service is a collection of tasks that will be run during the game loop. A task is a function that is associated with a game loop phase and a set of tags. These tags are used to resolve dependencies between tasks; several tasks can be under a physics tag, while another task can depend on the physics tag so that it does not execute until all the physics tasks are complete.