The structure of a Chilli Source app is fairly simple. An app is described as a hierarchical series of modules, each of which handles a specific piece of functionality. The following UML diagram demonstrates the basic structure of a Chilli Source app:
Application
The Application class is essentially the root class for the entire app; it is the root of the module hierarchy. It is responsible for creating and owning systems and creating the initial state, but typically doesn’t do much else.
States
A State describes a single section of an app, for example the main menu, a character creation screen, or the main game scene. A State creates and owns systems much like the Application does. All States contain a Scene – a system for managing the currently active game objects which will be updated and rendered.
States are contained in the state stack, which is controlled by the State Manager. Only the state at the top of the state stack is active; the rest are dormant until the state on top is popped. This allows, for example, a pause screen to be pushed over the game state. The game is resumed from where it left off when the pause screen is popped.
Systems
Systems are discrete modules that describe a single piece of functionality. The majority of the engine’s features are systems. Model Provider, Video Player and Accelerometer are all systems. There are two types of system: App Systems and State Systems.
App Systems describe functionality that applies to the entire app such as the Texture Provider, State Manager or Task Manager. App Systems are owned by the Application and live for the entire life cycle of the app. Typically there will only be 1 instance of an App System.
State Systems describe functionality specific to a State, such as the Scene or game specific systems such as a health manager or an enemy spawn controller. State Systems are owned by a state and live just for the life cycle of that state. Typically a state will only have 1 instance of a State System, but other states may also have their own instances.
Entities and Components
An Entity represents a single object in the game world. Entities consist of a transform describing their position, size and orientation and a series of Components that describe their behaviour. They can also contain a hierarchy of child Entities which inherit their parents transform. This allows for the creation of complex objects from a series of Entities. An example of this might be a car Entity: it could have child Entities for the body of the car and each wheel. This enables them to move independently of each other to simulate suspension, yet move together when moving the car as a whole.
When working with Entities, composition is favoured over inheritance. This means that Entity should never be inherited from. Instead functionality should be added by attaching Components. Components describe functionality specific to a game object, for example the AI of an NPC, the players health or an instance of a model. Typically Components will only operate on the Entity or in conjunction with sibling Components. This allows functionality to be shared among similar entities, for example all enemies might use the same health component but have different AI Components.
Components can be added and removed from Entities at any time, allowing an Entity to change over time. This allows things like swapping the AI on an enemy from aggressive to fleeing when on low health.
Most of an applications gameplay code will exist in Components or Systems. Although they may sound similar there is a conceptual difference between Components and Systems. Components tend to act at a lower level i.e. on a single entity. Systems usually act at a higher level often on multiple entities or multiple components. A good example of this would be in a physics system where the system is responsible for updating all the physics components and the components are responsible for manipulating their entities.
Entities are added to the game world through the Scene. Entities can be added and removed from the Scene at any time.