Sign in to follow this  

Messaging capabilities between game Entities

This topic is 3577 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm reading Programming Game AI by Example by Mat Buckland, and he introduces a Messaging System to be used by all the Entities to enable communication between practically anything in the game. If you're not familiar with what I'm describing, here's an idea of how it works: - Everything in the game is derived from a base class Entity and therefore they all have a unique ID (int). - A Telegram class is created which is sent by an Entity to an Entity, and contains the unique ID's for the sender and recipient, as well as a message type (an enum). Each Telegram has a dispatch delay (i.e. immediately, 30 seconds, etc). - A MessageDispatcher (Singleton) class handles all the Telegram (messages) requests and dispatches them appropriately. - Each Entity that can receive a message has an appropriate HandleMessage() function which (in the text) delegates the task to the Entity's current state. - Each state must provide a "what-to-do" for each possible message type (which is an enum) Here are some examples of use the author provides: - A wizard throws a fireball at an orc. The wizard sends a message to the orc informing it of its impending doom so it may respond accordingly, i.e., die horribly and in magnificent style. - A football player makes a pass to a teammate. The passer can send a message to the receiver, letting it know where it should move to intercept the ball and at what time it should be at that position. - A grunt is injured. It dispatches a message to each of its comrades requesting help. When one arrives with aid, another message is broadcast to let the others know they can resume their activities. - A character strikes a match to help light its way along a gloomy corridor. A delayed message is dispatched to warn that the match will burn down to his fingers in thirty seconds. If he is still holding the match when he receives the message, he reacts by dropping the match and shouting in pain. Okay, now that we should be on the same page, I'd like to get other peoples opinions on the use and power of a system like this. From the text, it seems to be a very powerful option to allow for events to take place in the game. This system is only shown between classes that derive from the base Entity (therefore an EntityManager has unique IDs to each of them), allowing for messages to be sent to siblings. If this system were to be used on a larger scale, perhaps not everything in the game that you would want to allow communication between is derived from the same base class, and therefore would have a different Manager storing unique IDs. This problem seems to be simple to solve. Another possibility for expansion of a system could be creating various subclasses of Telegram, each with different enumerations of their possible messages (rather then using a single Telegram class with a very large enumeration of all the message types). This seems like it may be a good option when introducing a new message type to prevent having to add another switch case in EVERYTHING that handles messages. Then again, I have a suspicion that this system could get out of control (cumbersome and tedious) very fast when you have to deal with a lot of different messages. Anyways, you get the point. My mind has run off with all sorts of seemingly powerful capabilities. My question is, do you use a system like this? How is yours different? Is there a commonly used system such as this amongst large scale games? Small scale games? Anybody know any other articles about a system like this? [Edited by - Shakedown on March 2, 2008 4:34:07 PM]

Share this post


Link to post
Share on other sites
Your examples are pretty specific to Ai programming, which is not my area of expertise. However, I can mention how I do it:

Quote:

- A wizard throws a fireball at an orc. The wizard sends a message to the orc informing it of its impending doom so it may respond accordingly, i.e., die horribly and in magnificent style.


The character object posts a message to the message queue, that it has created a fireball. Your game logic procedure, which scans each message in turn, then broadcasts messages to the appropriate systems. The projectile system needs to know that a new projectile has been created.

The wizard does not directly communicate to the Orc that it has been hit by a fireball. However, your Ai system may have a messaging system to enable "Trash Talking" whereby the wizard sends the message "LOL OWNED UR GONNA BURN" and the Orc shouts profanities in response, but that is part of the cinematics.

The physics system is in charge of what projectiles have hit what characters, and on contact between the orc and the fireball, will post a message saying "set fire to character #08768".

The character class will know if its on fire and can shout profanities, run around aimlessly, or (if its an intelligent AI) stop, drop, and roll to try to extinquish the flames. It chooses the animation to run, chooses the sounds to play, etc.

Quote:

- A football player makes a pass to a teammate. The passer can send a message to the receiver, letting it know where it should move to intercept the ball and at what time it should be at that position.


Sounds good to me.

Quote:


- A grunt is injured. It dispatches a message to each of its comrades requesting help. When one arrives with aid, another message is broadcast to let the others know they can resume their activities.


This can be done the same way as the "telegram system", or alternatively you could use a "Pheromone system" whereby a "message" object is created that all the other characters can see. Then, any character with the "field medic" ability (for example) that reads the message might create a different "pheromone" to say that its out of action while it does CPR on the injured character.

Quote:


- A character strikes a match to help light its way along a gloomy corridor. A delayed message is dispatched to warn that the match will burn down to his fingers in thirty seconds. If he is still holding the match when he receives the message, he reacts by dropping the match and shouting in pain.


This can be done using a "match" object. You simply say match.light(), and the match will create a "light" object. You update all your "match" objects in a loop.

When the match detects that it is used up, it sends the message (possibly directly to the character, or possibly to a global message loop) to say that
a) I just burned your finger.
and
b) Draw some smoke and extinguish light source #1293


In terms of message types, I do not use enums for the reason that they are hard coded. Instead, I use an std::string as well as an index. Its got me a little criticism in the past but that's my particular method.

Share this post


Link to post
Share on other sites
Quote:
Then again, I have a suspicion that this system could get out of control (cumbersome and tedious) very fast when you have to deal with a lot of different messages.

Anyways, you get the point. My mind has run off with all sorts of seemingly powerful capabilities.

My question is, do you use a system like this? How is yours different? Is there a commonly used system such as this amongst large scale games? Small scale games? Anybody know any other articles about a system like this?

No two systems are alike. Build something you think you will like for your game. Be prepared to change it over time.

I've worked on several AI systems for very different purposes. A few were similar to what you described, and they mostly worked okay for their situation. And every one of them evolved significantly between their initial concepts and shipped implementation.

Yes it is common to have a message bus, broadcasts, listeners, or similar ways to pass the message around. It is also common to queue them up over time, and have ways to remove messages when they are no longer relevant. It is also common to not do any of that, instead having every object work off a collection of simple state machines.


The system you described is reasonably close to what is used in many games. Some difficulties you didn't fully address are messages that expire, handling messages that are or become irrelevant, spatial broadcasts or spatial delays between entities (we hate the word 'entity' around here....) and handling a series of events that need to be passed back and forth between systems.

As you mentioned, it might be overkill. I don't know your situation or game. Some games really need that kind of system. Others really don't.

Never underestimate the power of a collection of state machines when it comes to AI. Google searches to help are "FSM" "Finite state machine", and "AI state". They are very tiny, require only a few bytes per entity (as you called it) to track their AI information, can be processed very quickly, are easy to debug, are easy to profile, and are all round good citizens in the programming world. All college graduates should have studied them for a few months, and they are well understood. There are many good articles on this board, in Gamasutra, in the Game Programming Gems books, and anywhere else that good AI programming is discussed. They are probably also covered in your book.

In my current game, we've got about 15 different AI state machines. Each of those runs another set of about 30 different response behavior state machines. Those consume only four bytes in state variables and four pointers to game objects. The result is an incredibly complex behavior that is still manageable and takes very little time or space.

A good system will also include many choke points, that will help both for debugging and tuning. There are many times you WANT messages to be dropped. For example, you will often want to limit the frequency that events are triggered, limit the number that an 'entity' is aware of, limit the number in the queue, and limit them for many other reasons. Also, be sure to include lots of debug information that can be switched on/off at run time. AI can be horrible to debug since it is in constant flux.

Share this post


Link to post
Share on other sites
It seems as perhaps this sort of system is only used for communication between NPCs? I mean, you wouldn't want to use this system for sending messages from the player's character to anything they interact with in the world, would you?

Quote:
Original post by speciesUnknown

The wizard does not directly communicate to the Orc that it has been hit by a fireball.


Sorry if I was unclear, but the wizard does not directly communicate to the Orc. But, the wizard does have a handle on the Orc that is is sending the message to, and therefore it can retrieve the Orcs unique ID. Then, the wizard creates a Telegram, and provided the Telegram with the wizards unique ID, and the Orcs unique ID. Then the Telegram is handled by the MessageDispatcher, which sends the Telegram to the Entity with unique ID that was provided in the Telegram (the Orc).

In this fashion, the wizard does not directly communicate with the Orc, but the wizard must know about the Orc.

Quote:
Original post by speciesUnknown

The physics system is in charge of what projectiles have hit what characters, and on contact between the orc and the fireball, will post a message saying "set fire to character #08768".


Is this the most common way of handling collision detection; allowing the physics engine (which is a component of your entire game engine) to check for collisions and handle them accordingly (i.e. post message saying "set fire to character #445)?

Quote:
Original post by frob

Never underestimate the power of a collection of state machines when it comes to AI. Google searches to help are "FSM" "Finite state machine", and "AI state". They are very tiny, require only a few bytes per entity (as you called it) to track their AI information, can be processed very quickly, are easy to debug, are easy to profile, and are all round good citizens in the programming world.


Right. As I mentioned, the Entities delegate the task of handling the messages to their current State. The idea proposed in the book is to use the Message System on conjunction with FSM's. As you could imagine, the two together would provide for some powerful AI. Each particular State would define the actions to take in response to each type of message received.



Share this post


Link to post
Share on other sites
I think your second and third examples are good examples of when to use a messaging system. However I dont think the first and last should rely on mesaging.

Quote:
A wizard throws a fireball at an orc

what if the orc moves out of the way, what if there is an object obstructing the line of sight to the orc?

Quote:
A character strikes a match to help light its way along a gloomy corridor.

What if the player lights the match then drops it? His fingers will still burn?
What if the player then lights a match and dies?
What if the player lights a match, puts it out, then 25seconds later lights another match, he will receive a message in 5 seconds which will burn his fingers!

These examples should rely on logic to determine when these events should be triggered.

Your fireball for example should be an object which has a velocity and checks each frame for a collision, that way you never have to worry about all the what if scenarious.

As mentioned previously your match should also be a seperate object encapsulating timer logic, that way you could create 10,000 matches and put them out, and not have to track which message relates to which match etc.

There are lots of other things which could bite you, like objects being removed before messages are delivered, messages never being delivered, game being paused , or quit. The list goes on :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Shakedown
It seems as perhaps this sort of system is only used for communication between NPCs?


No, the beauty of such system is that it can be used as a means of communication between any two entities, not necessarily AI-related, let alone NPCs. Look into game programming gems series for more info. Check the post by Antheus at the end of this thread for more info.

Share this post


Link to post
Share on other sites

This topic is 3577 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this