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.