Just to be clear: this has nothing to do with the "component based" pattern, I'm referring to single object game entitys (the player / Party members / enemies and so on). I have been reading M.Buckland's "Programing Game AI by Example"- and although I have problems with some of his programing idiosyncrasies (singletons for almost EVERYTHING, and Way to many templated classes, so on and so on), but his ideas for the most part seem useful. He sets up the message system for entity's communicating with each other by sending "telegrams" to each other. each telegram has the sender's ID, the receiver's ID, a time-stamp, and (here is where I have the problem) an enumerated message field, and a void*. It seems to me that one could end up with a massive enumeration of message types and then all your entitys would need to know about it just in case they get a telegram with msg_UnrelatedToMeEntirely message in it. Obviously you could have 'default' case in your switch statement, but thy would still need to know the full enumeration. I can see how you could simplify / generalize this for some occasions; like msg_AytackedWithSpecial, and then having more info pointed to by the void*, rather than msg_AttackedWithFireBall, msg_AttackedWithRock, msg_ AttackedWithSlowingSpell etc. I was also thinking of using a similar messaging system, or perhaps the very same messaging system to take care of some of the user interaction, such as sending a msg_MoveToPosition message to a character that the player is controlling. My another gripe I have with the enumerated message type is that it lends it self to spaghetti code switch statements. Well- was hoping for your comments and what methods you all have found ideal for inter- entity communications.

I have the same book and am using the system in my current casual game, and works great! But since my/my company's future games are going to be a bit bigger, etc. I'm already thinking about updating this message-system. Indeed, because of the same reason you state above.

Maybe combining it with some kind of factory kind of system to work around the lists of case-statements that will arise when the amount of messagetypes increases. Though that's something that just pops up at the moment.

But on the other hand, since messages are handles by the statemachine's (at least that how I'm using it, like Mat used it in his book's "Raven"), the bigger the game, the more state's you'll have, divided over all kinds of classes.
Maybe you could just use this system and add a GameNameMessages namespace. In that way you can declare the messagetypes in the header-file of the class it's (mainly) used for.

Personally I like his way of template programming, it's really nice object-oriented programming. I wish I could apply it myself, though I do know exactly what he's doing where and why.

So, I don't now yet exactly if I want to change the system, and if I do, it'll be not much I'd change. So I'm also interested in other people their opinion on this matter :)

(aside about Buckland's book: honestly the thing that bothers me most is the abundance of singletons... the only reason the template thing gets to me (I think) is because I don't feel anywhere near as confident with my meta- programing chops as in other areas...and I know I probably should be templating things, but haven't pushed myself to.)

About Messaging systems: Right now I just have them all in one enumeration thats in its own header file. And for the time it works fine. I just worry about it ballooning into something horrendous later. About states handling the messages: I actually have a 2 stage handler where the Entity may take the message and do something, and then NOT pass it on to its current state. This too is working fine for the time.


Thanks for the comments BigDplayboy Its good to know that others are using the Buckland book successfully / happily . I am using his examples for a bunch of jumping off points in my game.

-vs

I am still learning and reading out of books myself, so take this with a grain of salt. Also my main programming is with &#106avascript, however I can usually port most c++, c#, java, etc into what I need.

The way I am handling AI is with action Objects and methods which make a sort of event que. Something like issuing a moveTo(target) command would be an actual Object class. The way it gets to the object would be an over-ridden 'update()' method. In the end, a tank, or a foot soldier, or an airplane all get to the target in different ways, but they all must 'moveTo' the target.

So I would create a 'moveTo(target)' class. You could overload this with several contstructors like a 3d Vector, a game object, or entity. Perhaps even an area in the game. That is all up to you.

Inside the moveTo() class, you would have the update() method. This is where you perform the actual unique method of travel. For a tank it could be to turn toward the target, move forward at whatever speed. For the airplane it would be whatever for flying, then for a foot soldier it could include things like staying away from bombs or whatever.

In each game unit, you would basically have an update que.

if(updateQue.isNotEmpty())
{
for(int i1=0;i1<updateQue.size();i1++)
{
updateQue[i1].update();
}
}

So you could just do something like this:

tank[1].updateQue.add(new moveTo(gameArea[5]));

or

footSoldier[3].updateQue.add(new moveTo(footSoldier[2]));

or

airplane5.updateQue.add(new moveTo(controlTower[0]))

Of course you would also want to remove this from the updateQue when the task has been performed or interrupted, etc.

I would have to agree with you though, an enumeration for communication does seem a bit... stringy.

By the way, the use of singletons isn't a bad approach. It is quite good to load a singleton of items or characters, and then just create a new character[4] instead of having to load it at the moment of creation, in my opinion.