Re: [boost] [rfc] Boost Graphic/Game Engine

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 
correctness.

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 
key.

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 
themselves.

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.

Thanks,

Michael Marcin