Sign in to follow this  

Game unit "communication"

This topic is 4777 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

Hi, i have a question about game unit communication. For example there is a geme world with a lot of game units of different types, which should be able to communicate. The communication system should allow to add new objects without rebuilding all other objects. THe first solution, i see, is a message queue like windows messaging, but a little bit different. Each game object generates event messages and stores them to a message queue. Then each other game object, while its own active time periode, takes messages from the message queue and handles these. But there is two problems. It is impossible to determine the life cycle of each message (how long these should be stored in the message queue). And second problem is the time limitation. Therefore the question is how it was done in serious games? Is there some articles about my problem? Thanks ans sorry for my very bad english, I hope you can understand me. Thanks a lot

Share this post


Link to post
Share on other sites
Your english was fine. No problems there. But I didn't totally understand how you were going to use it. But I'll attempt to help anyway.
Okay 1 simple kind of message: direct from unit to another.
Each unit has their own message stack for receiving personal messages. So if a message goes directly to 1 or a few units then put that message in their stack & they can pop it off when they read it
However if you're sending to a massive collection of units (like every unit in the game) then you probally want to use a global list instead.
Create a fixed size array 16 or 32bit large. & create another single variable that points to the next space (@ the start it will point to index 0). When global messages come in put it where the index variable points & then increment it(the index). When you eventually reach the array limit just loop back round to 0 again, & begin overwriting the old messages.
Give each unit in the game their own index variable that should also be 0 @ the start, & whenever you want the unit to check for another message:
compare the units message index with the global index. If they match then no new messages have been received & stop.
As long as they dont, increment the units index (wrapping round @ the end) & read & process that message in the global list.
No need to timeout or expire messages, Just hope none of the units get more than 16/32bit behind on the messages else they'll miss a load.

As for 'serious games' (bah if there is such a thing) I'm not sure. I'm not sure exactly what the purpose is so it's hard to try & determin companys solutions. If you could explain abit more I could try my best to help

Share this post


Link to post
Share on other sites
I currently use messages for all sorts of things within my game. Everything from one sentry telling another sentry where the play is, to the game engine telling the sound manager to mute. And it works like so:

I have a message struct, and a Message Manager class. Each entity in the game has a unique ID, and there are a set of reserved ID's for the game systems (input manager, game engine, sound manager, etc). So anything can send a message to anything else - all it needs is the right ID number. To send a message you just fill out a message struct and pass it to the message manager. Most messages are sent immediatly, but i also included a sendAtTime() function which will hold a message till a specific time. This means there is only one queue of messages held within the message manager. Most messages are sent instantly however which simplifies the whole thing. All my game objects have a recieveMessage() function, so when needed the message manager uses the reciever ID in the message struct to find the right entity and then just passes the message. You can pass messages for anything once the system is setup.

Share this post


Link to post
Share on other sites
to ProPuke

what i whant is something like "Settlers", but a little bit expansible. It means i will at first time create a base for a game and then expand it through additional plugins. It means that later i will provide for example a pack with plugins which describe a brand new type of game units with new AI, capables and so on.

Then i can add a new entity, let say, a "calendar" which can send to all units an new event "christmas" and all units wich capable to celebrate this event, will go home with theyr familys and drink wine. :)

So, i wish some thing universally. Therefore i thing the solution like described by kaysik is that what i whant.

to kaysik

Does, described solution, really work in your game? :)

Does your message queue pass messages to your game objects or the game objects take messages from the queue and process them?

And i'm still confused about the time limitation. Because a game is a RTS, then you have to limit somehow the time of message processing in order to let other parts of game engine do theyr work? Or i'm wrong there?

Thank a lot


PS
It is very very nice if there is somebody who can listen to me. Then i don't have to talk all the time only with myself. :)

Share this post


Link to post
Share on other sites
What most games do is update all units at the same time, during a "time step".

Messages are typically sent to all units within a certain radius, or to a specific unit, or to all units matching some criteria (such as being of a certain type or belonging to a certain player).

The two ways of doing it are to pre-filter messages when they are sent, and keep a message queue per unit, or to let each unit see all the messages, and filter itself. Typically, the message queues will only be vectors of pointers for efficiency, and the messages will all live in one global vector; at the end of each step, all messages that existed at the beginning of the step are deleted, and all messages that are posted during the step are inserted to the queue.

You always want there to be one step latency between sending a message and other units receiving it -- else you'll get really weird gameplay bugs, not to mention networking will be much harder.

Share this post


Link to post
Share on other sites
Quote:
Does, described solution, really work in your game? :)

So far yes my solution seems to be working great :P However I haven't tested it under heavy loads and its not finished - but so far its working better than expected and i can't see any major problems.

Quote:
Does your message queue pass messages to your game objects or the game objects take messages from the queue and process them?

My message manager singleton takes the messages and passes them directally to the reciever object. The objects themselves never have direct access to the message queue - all they have is the one recieveMessage() function which is only ever called by the message manager. As most messages are handled imediatly in my system and never stored I haven't bothered to give objects access to the message queue but you could add that quite easily. If you were going to have most/all messages sent with a dealy then adding the ability to peak at the message queue might be handy.

Quote:
And i'm still confused about the time limitation.

I know what you mean about limit message processing time, but for most messages your just setting a flag or something simple rather than doing any major processing. If you need todo lots of work you can just have the message function set a flag, and then do the actual work in your update function. For path finding you could do this: Object gets a "Got to here" message, and in the acceptMessage() function saves the position, clears the current path and sets newPath to true. Then in the update functio you check newPath and start pathfinding. Then you have to make your update pause if its taking to long but thats got nothing todo with the messages and you'd have todo that anyway. If you keep your message processing functions small then adding messages to your game shouldn't add much overhead and is very usefull.

The system can be very easily expanded to include groups, or sending to locations close to a specific spot as someone mentioned. Another good improvement would be message classes, so you can write general handlers, and also specific ones if needed but I'm not that far yet.

Share this post


Link to post
Share on other sites

This topic is 4777 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