I guess I should do some more research regarding that. Although, I just liked the idea of inheriting from a base "empty" game object. It makes it easy to have lists of GameObjects. Also, all of my components inherit from a Component class which makes it possible to AddComponent() and GetComponent(). That way, a user of the game engine could create a new type of component and easily add that to any game object. However, I may be over complicating that as well...
Honestly, it sounds like you are over-engineering this... Forgive me if I'm wrong, but the impression I'm getting here is that you're writing the engine before the game.
Never do this. Just don't. What you should do instead, is write a game, and while writing that game, write its engine. At the same time (Or even, write a game, and then refactor the engine out as you go).
Then, after you're done, that engine can then be extracted and made to be more generic. This is basically how every engine used in the game industry was made (although in many cases the game the engine was written with never shipped).
Trying to make a generic engine from the start will be worse in basically every measurable way. It will take longer to write, take more code, use more memory, and be slower...
Again, sorry if I misjudged your comments. Anyway. On to what you said specifically:
Having an empty base object so you can have lists of GameObject (presumably lists of `GameObject*` in reality) is basically going to destroy performance and the cache. A reasonable rule of thumb is that a read from memory will take about 100 times longer than, say, a float multiplication, unless you know it will be in the cache. Then, to operate on these game objects, you'll probably use virtual methods. Another rule of thumb is that vtables are basically never in the cache (and they're also unpredictable branches).
Really what you want to have is several flat arrays of the data each part of the engine needs to operate on. This is also good from an encapsulation standpoint, because then each part of the engine only can see what it needs, and not necessarily the whole game object. Then, the way you'd implement a component system in this style is that you'd make that array the canonical place the data lives.
This can work well for some games but isn't worthwhile for every game. (Generally I actually think the biggest benefit is that it makes gameplay and tools for non-developers easier to write.)
> Forgive me if I'm wrong, but the impression I'm getting here is that you're writing the engine before the game.
Your impression is a little wrong, see below.
> Never do this. Just don't. What you should do instead, is write a game, and while writing that game, write its engine.
I'm not making a game. We have an OpenGL Game Engine class in my Game Programming program at college. I'm creating my game engine with the idea that someone could simply include it as a library and then use its features to develop a game. This Game Engine class is now over, however, I'm still developing my engine purely for personal learning purposes. Yes, I am creating demos to test features of my engine, but I'm not writing anything that would be considered a game.
Regarding the rest of your comment, I totally agree and understand what you are saying. This actually makes sense, however, it's just not the way that we've been taught so far in my program. Being a student, we are familiar with the practices that our teachers use. This makes us somewhat close minded, but it's really nice when people (like you) give a completely different way of doing something.
Thanks for the help! I'll look into these different methods of structuring my engine.
Examples != a game, and given that scenario, I would recommend trying to make a game at this point, but I'll leave it be.
And that's fair. I didn't think this way until after working in industry for a while, and my code from when I was at school was very high level and OO.
If you're interested, Mike Acton (lead at insomniac, and one of the smartest people in the industry) had a good talk in CPPcon that you can find online about Data Driven design[0], which is basically what I'm talking about (he's a bit more extreme than I am). I'd also recommend looking at his 'Typical C++ Bullshit' slides[1] for a shorter and more amusing take on the issue.
I guess I should mention... I did write a maze game for a final project in a different class with it. This semester, I was one of the few that actually wanted to work hard on my engine. I just find it really fun because there's so many problems you have to think about when developing an engine, and even more solutions. It's very rewarding for the brain.
This semester, I used an app to keep track of how much time I put into every class.
- game engine: 106 hrs
- AI: 10 hrs
- physics: 10 hrs
- ogre: 12 hrs
As you can tell, my game engine was the thing I worked nearly every day on, mostly late at night. If I took an assumption about my class average on hours put into their game engines, I'd say a safe guess is around 15 hours if we don't include my time and the 2 others who also put an insane amount of time into their engines (it was pretty much a competition between 3 friends to outdo each other).
Back to making my maze game... We had the entire semester to work on either a solar system or a maze game. I pumped out the maze game in 3 hours with my engine on the day it was due. The thing is, I was confident with my engine. I put so much work into it, and I understand how it worked under the hood, that I knew I could produce something very fast and easily with it.
The game itself was simple. Have a first-person camera walk around the maze, pick up a key, and then go to the maze exit and open the door. Even though I did it in 3 hours, I also included the ability to pick up a gun, attach it to the camera like an FPS; added a skybox; added a simple sin wave twirl for objects sitting on the ground; and a few other small details here and there.
Anyways, sorry I went on for a little bit there. I'm just really happy with how much my engine is progressing, but it still needs a lot of work and polish. I'm way more open minded now after this discussion. I feel confident about not needing inhetitance now, especially since I feel like in a couple months I might port everything to Rust.
I also realize that it was very risky leaving that project until the last minute. If I ran into an issue, it could have severely messed up my mark. Making a game at the same time as an engine does indeed help with the engine development, I see the benefits of doing so. When I get a chance to continue working on it, I will probably continue developing the maze game along side it.
Anyways, thanks for those links, I'll be checking them out tonight!
