So I'm using Allegro 5 to write a game. I wanted to know what exactly what goes into the Engine itself and how all the different components interact. The way I was originally doing it I had a Game Object that brought everything together such as the Input Object, Graphics Object, etc. That's nice and all but I don't feel as though a single Object should control everything. So that led me to do some research and I came across using a Messaging System to communicate between different objects. Here's how I would implement this:
I'd have a Messaging class that handles all messages between the Objects. The Messaging class would have a method with two template classes and one int or string as parameters to handle the communication. First template class would be the sender. Second would be the recipient. And the string would be used to index through a container holding all of the objects to identify the desired recipient. Does this sound like a good starting point? I've been trying to implement this but it's never been turning out right. I can't seem to create a suitable messaging system mainly because I never have before. And because like I said above, I don't really know what classes actually need to communicate. This will be my first "thought-through" game.
A wise poster once told me, "do whatever you need to do to make the game". At this point you have no idea what even constitutes an engine in the first place, don't worry about how to do it right. I guarantee you will do it wrong and rewrite it a few times, but it will be much more beneficial to you than getting it right from the start.
I guarantee you will do it wrong and rewrite it a few times
L B, the amount of correct in that collection of words...
My level editor isn't a general purpose engine, it's made pretty specific towards making levels for just my game. However, I've rewritten the thing three times now. Probably will finally settle down on this one, as I'm happy with it. Three times though, full rewrites. Not " I'm going cut part of this out and redo it", I mean I full on dropped the whole thing and started over.
Oh trust me I've made quite a few and I always run into complications down the road because things seem like they fit together at the start, but later on everything falls apart.
Yeah, that's where one practice of making software called modularity fits in. Nowadays I try to write my code so that things have a reasonable amount of independence, and don't assume too much on how they'll be used. You can accidentally end up creating a god class, or a perhaps a system that is really painful to change due to really tight connections between parts of your program.
That's exactly what happens. I end up making each different component rely to heavily on other components and before you know it everything relies on everything else basically. I want things to be as decoupled as possible but somehow everything ends up getting tied together.
The idea that I have come across with making game engines is this: Make games, not engines. Just make sure to make it modular, so you can separate the various classes and it still works fine. This means that eventually the games that I make become faster and easier, because I can just pull out ready-made classes that I have made in previous games, and maybe modify them a bit to fit in with the overall theme of the game.
You have to make more than one game before you can understand what code makes up the "engine" and what code doesn't. NT3 is exactly right: don't focus on "engine", you will live an unhappy life.
Just because it's 2d doesn't mean you can't spend an enormous amount of time working on it. If you wanted to make an engine like Gamemaker, you'd be in a for very long project. I think people take the "2d is simple" thing too far. Relative to 3d yes it's easy, but it's still not a simple walk in the park. (Of course this can depend on your lib, difficulty of pure openGL vs a lib like Allegro/SDL/SFML is noticeable)
Keep your engine focused on making the game you want, as L B said, you need more experience before you can make general purpose ones in a well manner.
Thank you everyone for the input. And yes, Austin, I agree. I should of worded that differently. What I meant was, that I'm not planning on going over-the-top with it.
If you want to learn the ins and outs of a game engine, I'd say wait till you are a fairly comfortable with c++ and then pick up a book called Game physics engine development by ian millington.