Quote:Original post by Rilbur
And here is the reason for our confusion, you were using it in the reusable sense, whereas I was using a more strict and limited sense.

And that's one of the problems with building an 'engine': it's a very broad and vague term. Some people would consider map-loading and game entity management part of their game engine, other people have different ideas about that. So don't just say: "I want to build a game engine". Only you know what that means - but often people who say this do not know what exactly they're going to build, because they think they need some kind of generic game engine because every game needs one, whatever it may be.

Now, if you would say, I'm going to build a 2D tile-based turn-based strategy game, then that's a lot more specific. Not only does it give you clear goal, it also gives other people an idea of what you're going to build - which allows them to give specific advice. And yeah, you're right about having various modules doing their own specific thing - there's libraries for physics, rendering, pathfinding, and so on.

In other words, 'engine' says as much as 'housing'. Do you live in an appartment, a stand-alone house, an iglo or do you have your own palace? Each will have different requirements and construction methods.

Quote:Original post by masterbubu
So I did homework, and read a lot of articles and few books around.
I have in mind a sketch of the total engine and how the components will communicate with each other. But I need little help to sharp things up:

I'm going to use message queue for the components communication, I'll use the "Command" pattern for the messages. Can anyone give me an example, how to use it
in a game?

The command pattern is pretty useful for editors, especially for undo/redo functionality, but for a game... why would you need such a messaging system? I mean, function calls are also a form of messaging, why would that not be sufficient for your game/engine? As for components, what sort of components are we talking about here?

The more specific you are, the more specific help you can get. If you don't know your requirements, you can't be specific, and you can't build a good system - because you have nothing to measure it's effectiveness against. So I'll have to ask, what exactly do you want your engine to do? For what kind of games will it be used?

Quote:Original post by masterbubu
This way the AI engine does not communicate with physics engine directly. This allows the components be undependable, so you can replace subsystem without effacing the others.

The idea behind interfaces is the same: if a subsystem provides a decent interface (classes, functions, expected behavior), then it's underlying implementation can safely be changed without breaking code that uses it, as long as the interface itself is not changed.

If I call renderer.DrawRectangle(x, y, width, height, color), then I don't care what renderer does under the hood. Perhaps it uses OpenGL, perhaps DirectX, perhaps software rendering? As long as it does what it's expected to do you can swap the underlying code without affecting the calling code.

In the end, you're going to have some sort of interface. Whether that's a direct code interface, or a more abstracted form of messaging, if you need to work with a subsystem you will need to know something. You'll just want to limit that to what's necessary.

Quote:My question was: how can I build such a message queue?

As an example, every time a collision occurs, the collision system could send a message to the collision message queue. This could be an object that describes what objects collided, their contact points, the forces involved, and so on. Another subsystem could check the queue and notice that a collision message was posted. It can then react to it based on the stored information. So yeah, as the name implies, it's a queue of messages.

Another approach would be to bind callback functions to certain events. Some code that needs to know about key presses from the input subsystem would tell the input subsystem: when this event type occurs, call this function. The calling code no longer has to poll for messages - instead, it will be informed whenever that event occurs.

In both cases, events or messages can be represented with classes. For example, a CollisionEvent could look like this:

class CollisionEvent{   CollisionObject* objectA;   CollisionObject* objectB;   Point collisionPoint;}

With the queue, you'd store them in a queue and you'll let other subsystems read from that queue. With a callback system, you send them directly to all subsystems that registered themselves (of course, they'll need to provide a function that accepts such an event object as an argument). With both approaches, other subsystems still need to know what sorts of events to expect, otherwise they can not meaningfully work with them.


As you can see, there are multiple approaches possible. Which one to choose depends on your requirements - so it really helps to be specific.