Brick is a cross-platform 2D-compositing game engine.
- Written in modern C++.
- Platform portability layer to allow easy portability across multiple platforms.
- Designed to allow game logic in straight C++.
- Integrates with the Bullet physics engine.
Development is currently focused on reaching production readiness on iOS via OpenGL ES.
Brick uses a variation on the model-view-controller design to enforce a strict separation between the game objects and the graphics.
The world model is responsible for iterating the simulation frame by frame. It is a container of a mindless collection of objects that move only as a result of the physical laws of the universe.
For example, a spaceship models the behaviour of a real spaceship: it has a position and will move in space with a certain direction, velocity, etc., obeying physical laws of nature. It will also generate events when it collides with other models in the space. However, the model will never perform any actions on its own that aren't purely reactions to its environment.
The world model is divided into several kinds of objects:
Physical objects such as "spaceship" and "bullet". Physical objects have position, direction, velocity, etc.
Metaphysical objects such as "levels" and "players" that have no physical presence. These exist for storing world state as well acting as containers.
For example, a player's "lives" may be represented as metaphysical objects that are created or destroyed according to the game's progress. Metaphysical objects also act as logic gates controlling the iteration of the world.
Controllers supply the behavioural logic that drives the simulation.
Controllers observe and interact with the game model through events and direct actions on the model objects. For example, a spaceship controller will control a spaceship, telling it to change direction, shoot, etc.
Controllers can also manage "intrinsic" behaviour. For example, a spaceship may have a certain amount of fuel. As long it burns fuel, it has propulsion, affecting acceleration; the model can track fuel usage and cease to accelerate once fuel is depleted.
Controllers also mediate between the game model and external input from the keyboard, the mouse, touch screen, network etc., in order to interface with the player.
Controllers may communicate with other controllers; for example, there might be a
PlayerController that accepts keyboard/mouse input and which are translated into commands to the spaceship controller, which in turn controls the spaceship model.
Rendering and animators
Animators mediate between the data model and the renderer. Animators know how to translate game objects into visual, renderable objects.
Animators are specific to the renderer. For example, an OpenGL game will require a set of animators that know how to draw using OpenGL. Porting such a game to a different technology requires writing a new set of animators.
Animators typically have a 1:1 relationship with game models (and that relationship is typically pre-registered so that when a model is created, a corresponding animator is also instantiated), but this is not a requirement; for example, a particle system animator can be created that generates hundreds of visual objects that have no counterpart in the game model.
The renderer renders the game world. The renderer and the animators co-operate closely to manage the visual objects in the game. Brick currently supplies an OpenGL renderer and a bunch of animator classes to render sprites and so on.
Forming the backbone of the world model and animation system is a simple event system that allows models and animators to listen to changes and react to them. For example, adding a new model object to the world will typically also create a corresponding animator.