-
Notifications
You must be signed in to change notification settings - Fork 0
Message Handling
Well-designed games tend to be event driven. With event handling, entities can make their usual business until an event message is broadcast to them. Then, if that message is pertinent, they can act upon it. Intelligent agents can use this technique to communicate to each other.
At a core level, a message is a number or an enumerated type. However, the key is that these numbers have a shared meaning among independent systems, thus providing a common interface in which events can be communicated. At a higher level, a message is contained inside a data structure carrying some additional information such as a sender, a recipient, a time stamp, and possibly some extra data depending on the message itself. This data structure is called telegram. Basically, there are two types of telegrams:
- Immediate Telegrams: They are immediately sent to the recipient. There's not much to say about these messages since their use is rather intuitive.
- Delayed Telegrams: They store the time at which they should be delivered. That way the routing system that receives these message objects can retain them until it's time to be delivered, effectively creating timers. These message timers are best used when a game object sends a message to itself, at a later time, to create an internal event timer.
The idea is that you can send a telegram to any agent or system in your game.
For example, if a character strikes an enemy, the message Attacked
could be sent to that enemy and the enemy could respond appropriately to that message event. By having game objects communicate through messages, deep and responsive AI can be achieved fairly easily. Moreover, the technique of messages makes it easy to keep most behaviors event-driven, which is important for efficiency reasons.
The creation, dispatch, and management of telegrams is handled by the singleton class MessageDispatcher.
Whenever an agent needs to send a message, it calls MessageDispatcher.dispatchMessage() like that
MessageDispatcher.getInstance().dispatchMessage(
delay,
sender,
recipient,
messageType,
extraInfo);
where delay is expressed in seconds. The MessageDispatcher uses this information to create a Telegram, which it either dispatches immediately (if the given delay is <= 0) or stores in a queue (when the given delay is > 0) ready to be dispatched at the correct time.
If you send a message without specifying the recipient the message will be dispatched to all the agents listening to that message type. Agents can register and unregister their interest in specific message types. The following methods allow you to manage agent's interest.
// Lets the agent listent to msgType
MessageDispatcher.getInstance().addListener(msgType, agent);
// Removes msgType from the interests of the agent
MessageDispatcher.getInstance().removeListener(msgType, agent);
// Removes all the agents listening to msgType
MessageDispatcher.getInstance().clearListener(msgType);
// Removes all the agents listening to any message type
MessageDispatcher.getInstance().clearListener();
To prevent many similar telegrams bunching up in the queue and being delivered en masse, thus flooding an agent with identical messages, you can control time granularity. Delayed telegrams having the same sender, recipient and message type are considered identical when they belong to the same time slot. If time granularity is greater than 0 identical telegrams are not doubled into the queue. The following code sets the time granularity to 1 second.
MessageDispatcher.getInstance().setTimeGranularity(1.0f);
Of course, the time granularity will vary according to your game. Games with lots of actions producing a high frequency of messages will probably require a smaller slot. The default granularity is 0.25, i.e. a quarter of a second. To eliminate time granularity just set it to 0.
The queued telegrams are examined each update step by the method MessageDispatcher.dispatchDelayedMessages() which checks the front of the message queue to see if any telegrams have expired time stamps. If so, they are dispatched to their recipient and removed from the queue. The following call
MessageDispatcher.getInstance().dispatchDelayedMessages();
must be placed in the game's main update loop to facilitate the correct and timely dispatch of any delayed messages.
When a telegram is received by an agent, its method handleMessage(telegram) is invoked. This method returns a boolean value indicating whether the message has been handled successfully.
IMPORTANT NOTE:
- Pooling: Keep in mind that telegrams are pooled so to limit garbage collection. Also any telegram is automatically released to the pool as soon as it has been dispatched and the handleMessage method of the recipient agent has returned. This means that you should never keep a reference to the telegram.
-
Developer's Guide
- Introduction
- Setting up your Development Environment (Eclipse, Intellij IDEA, NetBeans)
- Creating, Running, Debugging and Packaging your Project
- Working from Source
- The Application Framework
- A Simple Game
- File Handling
- Networking
- Preferences
- Input Handling
- Memory Management
- Audio
-
Graphics
- Configuration & Querying Graphics ??
- Fullscreen & VSync
- Continuous & Non-Continuous Rendering
- Clearing the Screen
- Take a Screenshot
- Profiling
- Viewports
- OpenGL ES Support * Configuration & Querying OpenGL ?? * Direct Access ?? * Utility Classes * Rendering Shapes * Textures & TextureRegions * Meshes * Shaders * Frame Buffer Objects
- 2D Graphics * SpriteBatch, TextureRegions, and Sprites * 2D Animation * Clipping, with the use of ScissorStack * Orthographic camera * Mapping Touch Coordinates ?? * NinePatches * Bitmap Fonts * Distance field fonts * Color Markup Language * Using TextureAtlases * Pixmaps * Packing Atlases Offline * Packing Atlases at Runtime * 2D Particle Effects * Tile Maps * scene2d * scene2d.ui * Table * Skin
- 3D Graphics * Quick Start * Models * Material and environment * ModelBatch * ModelBuilder, MeshBuilder and MeshPartBuilder * 3D animations and skinning * Importing Blender models in LibGDX * 3D Particle Effects * Perspective Camera ?? * Picking ??
- Managing Your Assets
- Internationalization and Localization
- Utilities
-
Math Utilities
- Interpolation
- Vectors, Matrices, Quaternions
- Circles, Planes, Rays, etc.
- Path interface & Splines
- Bounding Volumes ??
- Intersection & Overlap Testing ??
- Tools
- Extensions
- Artificial Intelligence * Message Handling * State Machine
- gdx-freetype
-
Physics
* Box2D
* Bullet Physics * [Setup](../Bullet Wrapper - Setup) * [Using the wrapper](../Bullet Wrapper - Using the wrapper) * [Using models](../Bullet Wrapper - Using models) * [Contact callbacks](../Bullet Wrapper - Contact callbacks) * [Custom classes](../Bullet Wrapper - Custom classes) * [Debugging](../Bullet Wrapper - Debugging)
- Using libgdx with other JVM languages
- Third Party Services
- Articles