So I have some questions. First, some background. I consider my self a Novice programmer. I've been coding in *some* way since I was 9 (25 now). But after leaving Web Development / System Design, I went back to my dream of Game Development and started back with Java. Then trying to follow my ultimate goal, went to the LOVELY C++ language. Now I'm not GREAT at all in C++ since I'm trying to learn as I go, but I can follow the basic programmers theories.
Now my issue is I'm trying to write a mostly basic 2D engine for Cross-Platform game dev in C++ using SDL. I have boost waiting, but I'm waiting for the absolute time where I'll need it before exponentially extending my code base. My goal with this is to have something.... headless? I dunno if that's the word, but basically I want this engine to work almost in a Java libgdx way of only needing to extend/inherit the needed base classes to get something hopefully AA game worthy out of it (not AAA). But in researching the ECS idea of Entity-Component-Systems it seems to be the best bet. I don't really want any game specific logic in the engine, the engine should just handle the memory accesses and what not.
So to explain it better. In trying to implement the ECS system I went to using a handle type system. Which is basically a Handle Manager that dishes out uint32's (unsigned int's) for a "handle", and stores the pointers to that object in a vector for hopefully easier memory management if I need to move objects around in RAM (and hopefully that vector helps boost cache speeds and limit cache misses). NOW, the thing I'm confused about, because all the research points towards theory instead of actual code implementation, is that:
- Entities should just be ID's and a holder of some sort, and Components should just be data/properties describing it. Finally Systems should actually dish out the logic in doing what-ever-it-is that the components want it to be. Whats the proper way to have the components interact with each other? And to register to the systems? Ex. A render component will need a position component to know where to render to correct? And a potential Fustrum Culling method might need both? Whats the best way to go about it?
- Is this an efficient to do it in this way at all? In the way that if my "game" is inheriting a base-class that just starts up SDL (window and renderer), saves some needed classes for file streams, entity manager, state engine etc. And the only thing really needed to "override" is the initialization and cleanup methods? Then inheriting a "state" base-class that adds itself to the state machine and overriding the init, cleanup, execute, event handler, etc methods? The states are then in charge of maintaining their own entity/handle systems and passing this to the "global" (in the sense of it's the main game object's property) render systems? I'm confused on how this should all be mapped together.
- Finally, to wrap all of these together, whats the best OOP/ECS fashion to connect all of this without breaking all the "rules" and creating debug/memory leak nightmares (ie: singletons and such).
I'm hoping that if we can get enough ideas and such that this might serve as a helpful incite for other beginners on how to implement these types of systems. I'll post my code too when I get it working (I'm all for open-source). And sorry to ramble if I did.