i've been thinking and researching about "game engines" recently. i know! bad me! i should be building games, not engines! <g>. but i have a number of titles in the works and am looking to streamline the development cycle.
i currently have a low level in-house "game parts" library that provides graphics, audio, timers, dice, etc.
i have a second library that implements an "entities list", movement, collision, and AI which i'm redesigning for use in future titles.
i've been thinking of redesigning as a component entity system such as:
array of locations, array of rotations, array of world transform matrices, etc.
and a main loop like:
there would be lists of different entity types, such as players, enemies, missiles, dropped objects, etc. terrain and static objects (buildings, etc) would be handled separately. objects used for scripting such as triggers would also be handled separately.
i suppose an entity would just be a list of indexes into the appropriate arrays.
nice and L2 friendly - so far so good.
but in the big picture, graphics will still be the bottleneck.
i mean, the game with the most entities in the way of just players, enemies, missiles, etc. these days is probably the Total War series, with about 2000 combatants active at once.
which makes me think:
for a _PC_ (consoles may be different), FLEXIBILITY ASIDE, the performance gain alone for a c-e system may not be worth the hassle, compared to say, an array of entity structs where each struct holds all components, and one array for each entity type.
i can understand its appeal when dealing with c++/oo syntax issues, but given that a typical game will have at most 2000 or so dynamic entities, with one or two basic types in all cases ("target" - a player or enemy, and "missile" for games with non-instant missile weapons), the performance gains don't seem worth it, especially compared to the performance overhead of drawing 2000 entities! <g>.
note that my current "entities library" uses arrays of entity structs with all components in a struct, has two lists of entities: static and dynamic, and is implemented with C code, so no c++ syntax issues. also, i don't really care about the flexibility of C-E systems (being able to add/ remove components from entities on the fly, letting non-coders define entities via tools, etc). so i'm really only interested in c-e for the performance gain of L2 friendly data layout.
and from that standpoint, the c-e optimization seems like overkill. optimizing the iteration and processing of targets, when drawing targets is the bottleneck. time better spent on shaders i would think.
of course, once you've optimized all your drawing, and your "total war killer" that does 10,000 guys at once still runs too slow, then it might make sense as a desperate attempt to get a few more clock cycles and maybe therefore a couple more fps.
but until you reach that point, it doesn't seem to make sense to use it, EXCEPT as a way to deal with c++ syntax issues and to allow non-coders to edit entities.