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