On 7/17/07, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
Hi,
There were some little interest for this in another thread here in boost. So, who has any experience in game programming, it would be interesting to layout some requirements for a new engine and complaints from other engines. See if we can find out how a game engine should really be.
I have some experience with PC and Playstation 2 games, teaching at Full Sail (http://www.fullsail.com) and working in industry. Not nearly as much as some contributors I imagine. I'm no longer in the game industry, but work with "game-related" technology on a daily basis with more serious end results... Some complaints I have about other engines are: - Ease of extending the engine. For instance, if a new algorithm is developed for interpolating between animations, it's not usually easy to integrate without redoing most of (or all of) the animation code. - Not supporting context changes in an optimal manner (determining least number of context change commands given a set of "renderables") - Being tied to custom containers and iteration techniques instead of having STL style iterators and STD library containers used. - Not being able to change the underlying containers at compile-time. e.g. the Scene Graph will always be a tree where children are stored in custom doubly linked lists, instead of the Scene Graph is templated on storage types, and you can make it a tree of vectors, or lists (much like Boost.Graph) I'm sure others will chime in with their own complaints, but I think a Boost engine should aim for as much compile-time flexibility as possible, paired with run-time flexibility, which I sounds like it would make heavy use of Fusion. For instance, I may want to specify a renderer at compile-time that always does 3 passes - depth only with opaque objects, then opaque objects, then alpha (translucent) objects. At run-time, if it's determined that the graphics hardware is too old to have support for 2x speed up in the depth only pass, we could switch to a renderer that only did 2 passes, opaque then alpha. Obviously the sorting mechanism for both passes would be different too (and templated). Front to back for depth only and opaque, then back to front for alpha. There are lots of levels to a game engine. Perhaps it would be wise to break it up into separate libraries. I can envision a single library just for dealing with the OS + graphics hardware (setting up the window, changing resolutions, changing bit depth, querying capabilities, etc), and another for higher level scene management, much like nVidia has a separate Scene Graph library. There would also be some sort of API that is agnostic between OpenGL and Direct3D backends. Lots to think about... --Michael Fawcett P.S. - Where does the math part fit in? Another separate math library? Needs to be heavily optimized for speed, vectors and matrices need to be guaranteed contiguous in memory, need support for row major vs column major... Create from scratch? Wait for the Matrix Template Library 4.0 which is "coming soon"? (I don't know if it does what is needed) Modify/Extend Boost.uBLAS and Boost.Quaternion?