but more interestingly I think that this architecture can easily be adapted to non-gaming / business applications, and even to general applications.
That is to say, the wider software development community could benefit from advances in this direction, as much as game developers, or more.
The amount of sourcecode contained in this project gives no indication to the amount of effort and number of iterations required to produce it.
This implementation of DOD-ECS is the product of a long series of failures and wrong turns, many resulting from my own assumptions, my programming habits, and just the way I've been conditioned to think about code in terms of objects instead of functions and data.
Having said all that, the resulting source is not too bad, considering it has to work on MSVC 2010, which has no support for things like variadic templates, things that would have helped me, had I chosen a more modern compiler, and the underlying design is sound in theory.
There were some points that came up late in the development where I realized that I could save on some internal lookups by deliberately allowing some data fields to belong to more than one component - to have some redundant copies of data can actually be good for performance.
I didn't have time to experiment with all of those ideas, so more performance can still be had, I'm sure of that.
There were entire systems omitted from this project that would be must-haves in any game engine, however they were outside of the scope I'd set for myself
within my original proposal: I wasn't setting out to create a game engine, the whole idea was to create a game logic system that can still play nicely within existing engines, while leveraging them for things like resource handling, but not relying on them for frame processing.
In retrospect, my implementation smells suspiciously like the guts of Gamebryo - that engine is highly data-driven, and the data is chock-full of various IDs, I suspect that Gamebryo's internal design shares features with my implementation of DOD-ECS.
I'm glad I chose this project as I've learned a lot about hardware-friendly and data-centric approaches to programming, and furthermore, I can actually see myself using this stuff as an alternative to licensing a full engine. I found that making a DOD-ECS application was a lot like making a sandwich: you have to think about what fillings you want on it, what order you'd prefer them in, and whether any of your ingredients bring their own requirements (maybe some pickled tomato relish). The ability to slap together a very specific game engine with just the needed functionality, and have everything in a game data-driven including the engine itself, is just too enticing to not follow up.
