Messages can be an important part of your game. They are quite easy to use but they have their issues as well.
What are the benefits of messages?
easy to setup
flexibel to use
[LIST]
no need to worry if there is an recipient and how many
no need to worry who send a message from where
no need to worry inter-scene communication
can be filtered by subject
it is save - messages do not get lost e.g. after scene change or when multiple messages are received
up-to-date - messages lives for one frame only (no queuing of outdated messages)
[/LIST]
But there are also some disadvantages:
can transfer strings only
relatively slow (when used in 1:1 communication) compared to property copy
multiple messages can be received at once - which might require Python code
it is possible to send the value of a proberty - but not to save it in another property via logic bricks.
difficult to track what messages are in the queues
it is not possible to save messages in a save/load system
What information can a message carry?
String - Iit might be difficult to evaluate the string (Python controller needed)
True/False - True = message received / False = no message
[LIST]
can be used to trigger specific tasks (e.g. a Python controller)
can be used for simple counters
can be used to synchronize multiple independent objects
[/LIST]
When to use messages?
when the recipient is not known - or we do not care
[LIST]
example: send the health of the player
[LIST]
there can be one or more GUI elements listen
there can be a game flow elements listen (for respawn)
[/LIST]
when the sender is not know - or we do not care
example: collecting coins
[LIST]
each coin is sending a message when collected
a counter object is counting the received messages
[/LIST]
when the sender and the recipient are in different scenes.
to carry temporary information over to the next frame (e.g. on scene switching)
example: you can send a message “game continues” - scenes from a newly started game wouldn’t get such a message
when it is important to catch every message
when copying properties the previous value is overwritten (no history)
when using messages all messages are available and can be used to produce the desired results
[/LIST]
When is it better not to use messages?
when it is a 1:1 communication with known participants (better use property copy)
when to much messages are floating around
when complex data should be transferred
when you need Python code already (and you know the recipients)
Any ideas to improve the use of messages?
Write down what messages are send and what purpose they have (you can use a text block for this documentation). If you use Python code to send messages such socumentation is a MUST DO. Otherwise no one knows where this messages are coming from.
1.1 - added MessageAnalyzer.py to the group (for group instantiation)
This is a small module that allows you to print messages received while the BGE is running. Because of the nature of the BGE it is not possible to receive messages that are sent directly to a specific object.
The attached file contains a test scene so you can see the MessageAnalyzer in action.
The test object sends some short messages. You can read details in the AAREADME.
The MessageAnalyzer runs in BGE 2.49 and BGE 2.5x
Output of a test run:
the format is:
<subject>: <body>
Installation (for temporary usage in your file):
A)
- link Szene "_MessageAnalyzer.lib"
- add instance "MessageAnalyzer" to your scene
B)
- link Group "MessageAnalyzer"
- add instance "MessageAnalyzer" to your scene
C)
- link Object "MessageAnalyzer_"
important: If you link rather than append, the MessageAnalyzer will not be loaded if you do not distribute the MessageAnalyzer.blend file. This comes quite handy as you usually do not want to distribute such object with your game.
Together with the MVC (model-controller-view) concept it makes your logic very flexible.
You can exchange each part with another one without the need to change the remaining parts. The only condition is that the interfaces should not change.
@fullgrown31: you know I’m still preparing the text resource four you. It will follow the same principles. But it includes a bit more (multilanguage, wrapping, scrolling). Please take this as an example to understand how you can do things. It is also not necessary to do this in Python. Logic bricks works quite well (but you can’t access message bodies with it). Especially at the model part Python helps very much.
e.g. Model
Your text (the model) is a dictionary of text snippets:
Controller
The controller deals with the user input (or other events). Dependent on the input and the model it delivers the data (text) to the view.
The delivery can be a message:
#Assumptions:
#input is a textKey in a property "textId"
#this controller works with a controller id to distinguish from other text sources
controllerID = "DialogText"
text = myTextModel(key)
GameLogic.sendMessage(controllerID, text)
View
You can have as much viewers as you like. You can easily replace them. You do not even need one.
Each viewer needs to listen to a message with a specific subject. The subject should match the controllerID if the text source.
The text to display is in the body part of the message.
messageSensor = ...
text = messageSensor.bodies[0] # take only one message (the first one)
#Bitmap text:
own["Text"] = text
#Font object (>=2.5x)
own.text = text
Messages can be very usefull vor realtime text. And not just with that.
Together with the MVC (model-controller-view) concept it makes your logic very flexible.
You can exchange each part with another one without the need to change the remaining parts. The only condition is that the interfaces should not change (the message format).
@fullgrown31: you know I’m still preparing the text resource four you. It will follow the same principles. But it includes a bit more (multilanguage, wrapping, scrolling). Please take this as an example to understand how you can do things. It is also not necessary to do this in Python. Logic bricks works quite well (but you can’t access message bodies with it).
Example (There are much more possiblilities to do that)
Model
Your text (the model) is a dictionary of text snippets:
Controller
The controller deals with the user input (or other events). Dependent on the input and the model it delivers the data (text) to the view.
The delivery can be a message:
#Assumptions:
#input is a textKey in a property "textId"
#this controller works with a controller id to distinguish from other text sources
controllerID = "DialogText"
text = myTextModel(key)
GameLogic.sendMessage(controllerID, text)
View
You can have as much viewers as you like. You can easily replace them. You do not even need one.
The viewer does not care where a controller is or how many of them exist.
Each viewer needs to listen to a message with a specific subject. The subject should match the controllerID if the text source.
The text to display is in the body part of the message.
This message format is the interface to the controller.
The viewer can easily sense fro new messages with a filtered message sensor.
messageSensor = ...
text = messageSensor.bodies[0] # take only one message (the first one)
#Bitmap text:
own["Text"] = text
#Font object (>=2.5x)
own.text = text
its considered bad form to cross post the same thing on multiple threads, just make a new thread in #game-engine:game-engine-support-and-discussion with your question. while monster isnt around here anymore, theres plenty of knowledgeable people here.
