Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Brick is a 2D game engine in C++ for multiple platforms, including iOS. Under early development.
C++ Objective-C++ C Objective-C
tree: a1fb1cf77c

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.


Brick is a 2D game engine under development. It's written in C++ and intended to be portable across multiple platforms. Development is currently focused on reaching production-readiness iOS.


Brick as an engine uses a variation on the model-view-controller design to enforce a strict separation between the game objects and the graphics.

Game model

The game model (corresponding to the "model" in MVC) is managed by a class called World.

The world is a graph of objects mixing semantic nodes (such as "Level" and "Player") and physical objects (such as "Spaceship" and "Bullet").

The world's primary responsibility is iterating the simulation frame by frame, part of which involves making sure that the game's physical laws are enforced across all objects.

The game model contains purely passive objects with no internal intelligence; game objects simply drift within the world, subject to the world's physical laws. For example, a spaceship model will move in space with a certain direction, velocity, etc., and will generate events when it collides with other models in the space. However, the model will never perform any actions on its own.


Controllers supply the game logic. 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 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 talk between themselves; so the spaceship controller might receive commands from a player controller that handles input events.


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, but this is not a requirement. Animators often don't have a corresponding game model object; for example, a particle system animator can be created that creates hundreds of visual objects that have no counterpart in the game model.

For convenience, animators can be pre-registered so that the engine can instantiate an animator automatically when a game model object is created.


The animation handles the mapping between game objects and animators, as well as the iteration of the animators. The animation is essentially a convenience class that makes it easier to write different renderers without having to reimplement a lot of animator management code.


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.


Something went wrong with that request. Please try again.