Hi,

I'm experimenting with class design at the moment to improve my design skills and understanding. This is fundamental to a project I'm currently working on, and I've come across a problem for which I can think of multiple solutions, but cannot seem to figure out which one is most appropriate or best.

I've created a movement system that follows a principle of "Intentions". An object can express an intention to do some event, for instance a player may intent to move forward. For this I use a few classes:


GameObject: An interface for any object in the game. It contains a few functions such as update, draw, setPosition, getPosition, etc.
GameEvent: An interface for any type of in-game event. This can be a movement event, an interaction event or any other event.
Intention: This is a singleton class which allows an object to express an event as such: Intention::express(GameObject*, GameEvent*)

When expressed, it is checked if the event that the object wants to do is legal, e.g. CollisionDetection for a movement event. To me this seems like a very sensible and natural design. The problem is however that each event will be destroyed after execution, because the event occurred. Because of that, my movement code disappears as well. The solutions I can see are as follows:

1. Have a MovementManager class (or something like it) that handles the movement of all the objects. When a movement event is executed, it simply gets added to a list in the movement manager class, and it will be updated until the intention is revoked (e.g. the player releases the key).
2. Have the movement event set the Velocity in the GameObject, and just update the objects position in the update method. This wouldn't really be flexible, and it would also take away several advantages of the design.
3. Change the EventManager class to instead of destroying an event, keeping it until it is destroyed: Very inflexible, would limit the types of events that can be used.
4. Your suggestion?

I can't seem to come up with the best way to handle it, and if my design is rubbish according to you, I'll be happy to hear why you think it is, and which solution would be better.

Thanks in advance.

Sorry if I misunderstood (only have time to skim your post), but I think you should have a physics class somewhere listening for these events.

So basically, you'd have objects that publish events to a message queue somewhere that show what they intend to do. Movement for example from an object that can move.

You would then have manager classes of various sorts that have hooks into the message queue that either listen for specific types of messages (movement) or from certain objects (player). These classes would then decide what to do with the global pool of messages. The physics class might be the only one that cares about movement messages, so it could then remove them from the queue when it's done processing a move request. It would grab a reference to the object requesting the move (stored in the message body somehow, pointer, handle, whatever) and if the move is valid, update its position for the next frame. Otherwise, it might just drop the message and possibly notify the object that sent it the message that the move was bad. Could do this directly by the reference or with another message, depending on if other subsystems need to know about it.

Sounds like a reasonable approach I'll give it a try and let you know how it works out.

Performance wise I have no idea how that would work in practice. I suspect that this is how things are done on large scales though (i.e. server side collision management in an MMO), but that would be widely distributed across many processors.
[/quote]
Only one way to find out