• entries
    383
  • comments
    1075
  • views
    352479

Message Passing Yet Again

Sign in to follow this  
Trapper Zoid

88 views

I'm a bit stuck at the moment on deciding a core part of my code architecture; the message passing system. I was looking at message passing just before I headed overseas, and I want to try it out in this project. But while I think I grasp the basics from what I've read here and in other places on the internet, I'm still unsure on a few details.

For example:

How decoupled should my program be?
If I take the message passing paradigm to the extreme, I should have every module intercommunication done via messages. However, should it get as far as even the hardware specific modules, or just the game ones? Is there any advantage for having, for example, the video system for displaying sprites on the screen handled purely by messages? And if so, how would this work in practice, given the asynchronicity of message passing?

Message Passing Interface
I'm still undecided about exactly what the interface for passing messages should be. The tricky part is deciding what parameters to pass. My instinct is to define a function for message passing that takes a message type id (probably a string) and somewhere between two to four ints or doubles as parameters. But there are probably a few cases where I want to send large amounts of info in a message, such as a string. I don't want to send a pointer in a message as it becomes ambiguous who has control over the memory. I suppose I could split a large data structure like a string up into chars and send them individually with an ordering number to reconstruct them at the end, but that seems a bit messy.

I suppose if I was a bit more experiences with networks, operating systems or windowing systems I'd be better able to decide the internals of the system, but at the moment I'm operating mostly blind. From what I've read every messaging system is different depending on the people who wrote it, so I guess I'll make some decision on what form the message passing will take by the weekend and get my first version of this up and running. Admittedly, I'm mostly posting this just to help work through the problem myself in my mind as I further search for nuggets of wisdom on the internet.

But if there's any suggestions for those two specific questions I've got, or another further advice or pointers to tutorials on message passing systems, I'd be grateful.


Additional: I notice if you search gamedev.net for "message passing", most of the first page links are to my own journal. Not really that much help [grin]


Additional 2: Thinking about it a bit more, maybe what I really need to do is throw a few more hours into figuring out the architecture skeleton and how modules communicate with each other.
Sign in to follow this  


3 Comments


Recommended Comments

Correct me if I'm wrong, but isn't the whole message passing thing just a more expensive way of calling publicly available functions? I mean, the modules are right there. On the same EXE. Both approaches will have to deal with the same issues, so why not take the obvious route?

Share this comment


Link to comment
In essence they are similar. But message passing has a few advantages. It promotes loose coupling (that is: different modules do not depend on the internal details of each other), which helps keep everything contained and easier to debug. It's also very easy to write stub modules; they just ignore any messages they get. Agent based A.I. techniques work very well with message passing too. Plus if I ever wanted to move towards networked or distributed programming I'd need to be good with messaging.

The downsides are the restrictions on how information can flow between modules, and possibly a performance hit (I don't know how much this would be). Plus ensuring that you have a good design for the messages.

I don't actually know if this is a good approach or not to take for this game, but I really need to try a few new architecture design techniques so I decided to heavily use message passing in my next game. It's more for a learning exercise than for practical reasons. However there's a bunch of things I want to try that really lend themselves well to loosely coupled modules communicating via a message pump. And I'd like the experience of "thinking via message passing", as it helps present new ways of solving problems.

Share this comment


Link to comment
After having worked with very abstracted message passing systems before I've come to the opinion that they're basically an OOP-ified GOTO.

When you're deep in the bowels of one module, and you suddenly need to trigger an event or action deep in another module it's very tempting to just use a message to bridge the gap. You end up with very tightly coupled modules and an interface which is far from abstracted. But because it 'looks OO' no-one complains or questions that possible it might be a bad idea.

Worse, because implementations almost always operate though a single central message pump/router you loose all context in the original message thrower, and it ends up at the receiver regardless of their context too. You end up with lots of special case 'if' logic on the receiving end as you try and reconstruct the context that the message was triggered from as you try and figure out what exactly you should be doing for this particular variation of this message.

As an extra bonus, debugging becomes more awkward as you've got to step though all your message routing calls all the time. Trying to use the same messages for networking sounds like a nice bonus, but it isn't going to fly. Local messages often have subtle dependancies or go horribly wrong when they arrive late, or out of order, or when another message gets dropped. A good networking layer has to have a certain amount of slack in it (ie. this type of message may get dropped, or this type may arrive out of order) in order to get good performance, dealing with this in a local messaging system is not going to happen.

These problems are not impossible to resolve (especially if you're very strict with your message usage) but the whole thing tends to fall into the trap of being very, very tempting to use in inappropriate ways (some of them non-obvious until much later). If you're going to have a message passing system it's probably best to keep them isolated within their modules (ie. a messaging system entirely within the GUI module is almost certainly a good idea, but shouldn't leak out into the rest of the game).

Share this comment


Link to comment

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