Boost logo

Boost :

From: Michael Marcin (mmarcin_at_[hidden])
Date: 2007-07-17 18:04:02

I think the biggest problem with existing game engines is that they
are... well big.

I really like the idea of building games out of libraries that work well
together to form emergent behavior.

For true flexibility and portability it should be adaptable to run well
on a software rendered ARM mobile device, a PS3 cell architecture, and a
modern multicore PC.

Error handling must be robust and should use modern facilities. Classes
and algorithms should document on their exception guarantees. The
strong guarantee should be the target of all classes and only weakened
when deemed too restrictive of performance or implementation.

A strong logging facility is crucial to easy debugging and verifying

Concurrency support is crucial. The free lunch is over. This is one area
where most current game engines fail horribly providing only O(1) or
O(K) concurrency. 0(N) concurrency support should be targeted.

Extensibility without direct source modification should be possible.
Possibly through scripting (maybe Python or Lua) or plugins like the SoC
extensions project will provide.

Tools should be able to be supported without adding needless complexity
and overhead to the final product and without a large amount of
duplicated code and logic. Reflection and serialization support here are

Documentation needs to be easy to write, easy to maintain, and up to
date. Examples in documentation need to be tested via automation.

Matrix and vector libraries would be helpful. They should optionally be
able to take advantage of concurrency or specialized hardware. They
should work with any type modeling a Real concept (fixed-point,
floating-point, large numbers, etc) and should have well specified
overflow, underflow, and precision loss handling so they can be used in
application with large areas and for physical simulations.

2d and 3d rendering libraries and abstractions should be provided with
optional hardware optimization support.

There are many more interesting libraries that could be created but a
full game engine sounds monolithic. Every real world game engine I've
used so far is just that. But there are dozens of new libraries that
could work well together to form game easily that are generally useful

There will probably be some concern for developing code that works well
on closed systems that are used for game development. I don't feel
availability will be much of a problem but licensing and NDAs might
become an issue. This needs to be seriously looked at.

An interesting route would be to create examples of how to wire existing
libraries such as Boost.Python, Boost.Asio, Boost.GIL, etc together to
form a simple game with minimal special case code. These examples could
be the base for real games.


Michael Marcin

Boost list run by bdawes at, gregod at, cpdaniel at, john at