I was having a discussion on the chat with error and thought I'd ask for Input. ZoomBoy:: I've been reading about some bad AI where an enemy gets shot but the guy standing next to him ignores it. I'm thinking of doing a message system that might handle that. Any Thoughts? error:: like an intelligent bounding box of the enemy that if another enemy inside he gets alarmed??? ZoomBoy:: that's one approach but I'm thinking that each turn the enemy will scan a list of events error:: you have a round based game?? I thought a Doom-like... ZoomBoy:: what difference would it make round vs. Doom? In Half-life you could kack a guard and the guy standing next to him would ignore it. error:: zoom, take the middle of your enemy and mark it with a variable ZoomBoy:: yes middle? his stomach ? or use his position as a centre error:: zoom, sure, take a 3d bubble and form radius around him accordingly, a databubble. Of course now add a condition-check and you are done ZoomBoy:: footfall is different from an arrow through the head error:: ok, then the enemy AI has to be event based and not reaction based, meaning the environment has to be counted into it too, will be a good game, but i promise you a lot of work.. ZoomBoy:: Yup, hoping to solve most of that with an EventList messaging system error:: zoom, for example if the enemy trips in one of your traps the enemy might be able with enough time to free his buddy ZoomBoy:: for that type of response I'll probably want a stack that stores action after action So what would be in the messages? Duration? Effective radius? Response-type? Visual only? Aural only? Any links? class EventList { list >EventMessage< EvList; long TurnCount; int TestList(Actor *pReceiver); // Scans through list looking for messages int DeleteOldMessages(); } class EventMessage { int SourcePositionX, SourcePositionY; // tells where the event happens int EventRadius; // the area that people can respond to int EventType; // Sound/visual/someone being hurt Actor *pGeneratedBy; // Usually someone creates an event int CreatedBy; // This is for events that are pumped onto the list or triggered by a triggerpoint EventMessage(int HappensX, int HappensY, int Radius, int EType, Actor *pSender) EventMessage(int HappensX, int HappensY, int Radius, int EType, int evTrigger) } ZoomBoy A 2D RPG with skills, weapons, and adventure. See my character editor, Tile editor and diary at Check out my web-site And some good 3D resources as well. Edited by - ZoomBoy on 4/18/00 6:07:38 AM Edited by - ZoomBoy on 4/18/00 6:10:17 AM

Any comments?

Interesting...
I''m part of a team doing stuff like this - my idea would be - a message is a message, it gets sent to all those that are interested in hearing it. For instance, a "deaf" entity would never receive messages that have to do with aural events.

I''m not sure exactly what you intend to do however, perhaps I4m not reading carefully enough, or perhaps you should explain more.

#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

Each frame or phase(not EVERY but often enough) each active entity examines the linked-list of messages available and sees if there is any event that would interest them or is targeted to them on the list.

Events would be put on the list whenever anything happens to create an event. Walking would create 2 or 3 sound events. SomeOne calling out for help would be another event.

ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, Tile editor, diary, 3D Art resources at
Check out my web-site

Okay, so every time certain actions occur they generate an event. A shot being fired, a radio call for help, a footfall in a corridor. These events can be visual, aural or based on taste and smell if you like (seriously). The events are all contained on a stack processed every frame (or once every several frames if it makes sense for speed) by every character in the game. Obviously the effect a footfall has depends on the state of the character and their aural perception. One type of character might have scripted C/A rules to deal with any footfall with a cautionary check (a guard type) others would ignore it (perhaps a scientist or bystander). Certain events would remain on the events list (a smell trail for a tracker dog to follow) others would only last one frame (a single step).
And like MadKeith said, if you can''t perceive an event you''d ignore it.

Basically sounds like a good, simple system.

Mike

The way I had thought of doing it before, was using "listeners" for events.

Objects register as "listening" for aural events, or visual events , or anything. Then if one of those events occurs, the server passes the event to all the objects listening.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

I also started a conversation with _dot_ about this
dot:: event driven systems seem to be the hype lately
ZoomBoy:: not HYPE, man just Happening dooood Seriously though, it seems to be a solution for better AI responses
dot:: zoom: hmmm
dot:: that''s more complex than it seem
ZoomBoy:: I think putting events onto the EventList is simple but the analysis of the messages and programming a correct response(maybe a stack of responses) is where the major problems will be
dot:: the event is in-built i believe, yes/no? I mean event system is in built to the world?
ZoomBoy:: yes into the world using mapinfo and actor onfo
ZoomBoy:: For responding to someone''s cry for help push on stack: ExamineAbilitytoRespond, FindPathtoMessenger, DoPathtoMsgSender, HelpMsgSender
dot:: hmm...responses should be events too ... hmmm ... no wait, events -> generate responses for next actions -> next frame, do actions -> generate events
dot:: why would you need a stack of responses?
ZoomBoy:: It really depends on how long it takes to calculate a response
dot:: doesn''t matter how long, a response is still a frame
ZoomBoy:: It might not apply to a Half-Life game but for turn-based, which mine is going to be, it would be suitable
dot:: blah, every game is turn base in a sense, maybe framebase
ZoomBoy:: hmmm.. let''s say there is a call for help placed on the eventlist
dot:: yes
ZoomBoy:: During the helpers turn, he decides to help(ExamineAbilitytoRespond) and FindsPathtoMessenger which generates a path
dot:: ok
ZoomBoy:: he starts on his path but doesn''t get there(doesn''t have enough movement)
ZoomBoy:: hmmm I suppose he could do a list of stuff all at once but then another message comes from someone else
dot:: which might disrupt his current action..?
ZoomBoy:: does he bounce back and forth or prioritize OR do the stack he has
dot:: so you mean he has a list of duties that are prioritized
dot:: it has to depend on the character''s personality and his ''interest'' If he is the indecisive character, he would bounce back and forth each time he hears an event
ZoomBoy:: so a stack would be better to examine his choices
dot:: yes i suppose so
ZoomBoy:: and sort them when he gets a new event or to ignore when he''s got TOO much to do
dot:: he can''t really ignore some stuff
ZoomBoy:: and a stack would be better to prioritize
dot:: it would be better to prioritize them and ignore the lower piorities
ZoomBoy:: Ah yes, add a field for priority. Being Attacked while doing other jobs would be priority 1
ZoomBoy:: thanks it''s starting to become clearer
dot:: no, thank you, this messaging event is interesting
ZoomBoy:: so I better learn to do a stack hehe
dot:: but the whole system is too vague, there are issues like distance, visual, and who knows what that haven''t come in, heh
ZoomBoy:: So identify the features of a message: such as radius, who it would be targeted to, duration
ZoomBoy:: messagetype
dot:: duration...? for eg, in the case of help, i wouldn''t know, but shouldn''t help exist at the moment of calling? I can''t seem to think of messages/events that last longer than a turn/frame
ZoomBoy:: For Now neither can I. Except maybe a general alert but maybe that can be handled a different way, an easier way
dot:: heh, for future purpose they say
dot:: but now, for example a scream, it does generate two events doesn''t it?
dot:: if I slash you, I get to see you hurt and also get to hear your scream
dot:: but having two messages would result in duplicates
dot:: and there are cases when it''s 1,1 or 0,1 or 1,0 incident
dot:: for eg, back facing you, you got slashed, i only hear
ZoomBoy:: yes, but you''d have to learn how to sort out what''s important. Maybe have a general variable that says you are in combat
dot:: a message identifier?
ZoomBoy:: a message-TYPE identifier
dot:: hmm
ZoomBoy:: you''d also delete messages after each frame
ZoomBoy:: ahh I see your point about the message-identifier NUMBER
ZoomBoy:: a unique message but of the same type that you already have on your stack hmmmm
dot:: maybe have each message is identified by a catagory furthur, like audio, audio/visual, or visual? hmmm
ZoomBoy:: yes maybe physical trapdoor opens, earth moves but maninly visual and aural
dot:: do you have actors check the list, or have the list calls the listeners
ZoomBoy:: right now I''ll be having the actors check the list but I''m just starting so haven''t gotten that figured out
dot:: it might be better to have system calls listeners i suppose
dot:: each listener decide what he wants to listen for, audio or visual, or both
dot:: and when you post an event, you tell the system what kind it is
dot:: and when the system processes, it goes through the listener list
dot:: and check the listener on what he wants to process, and only pass messages of interest
ZoomBoy:: yah that centralization would save a lot of cycles
dot:: and it can help ensure listeners handle unique message, no duplicates
ZoomBoy:: YES!! really unique messages

And so it goes


ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, Tile editor, diary, 3D Art resources at
Check out my web-site

quote: Original post by MadKeithV

The way I had thought of doing it before, was using "listeners" for events.

Objects register as "listening" for aural events, or visual events , or anything. Then if one of those events occurs, the server passes the event to all the objects listening.

~ Mad Keith ~

Yes, a centralized system would be better than maybe with targeting messages

ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, Tile editor, diary, 3D Art resources at
Check out my web-site

So the basic message-transmission system is fixed now - using listeners.

The server could do some kind of preprocessing as well - like passing messages to nearer listeners before handing them to ones further away, or having a cutoff at a certain distance.

The clients are then responsable for reacting to messages, and sending new ones.


#pragma DWIM // Do What I Mean!
~ Mad Keith ~
**I use Software Mode**

Very interesting... I too am working along these lines (Sup MadKeith)... I hadn''t thought about leaving the event messages around though. Alternatively, here''s what I *have* thought of...

If you''ve got more then a few AIs in the game, it''s going to start hitting your CPU hard for every AI in the game (even if you cull deaf AIs out of the sound events ...etc.) to examine every event that occurs every frame. Here''s my solution. Use some intellignet algorithms to target specicific AIs. It uses a bit more memory (must duplicate the message for every interested AI), but saves on mememory (very few AIs get messages they don''t care about). Here''s an example...

Object1 says "I hate you. You must die."

This generates a .speak. message.

The game engine then uses a simplistic A* algorithm to propogate the sound through the map until it dies out.

The A* algorithm finds Object2 and adds the .speak. message to it''s incoming queue.

Similarly, lets try another example...

Object1 lights a torch.

This generates a .light. message.

The game engine then uses a line of sight algorithm to propogate the light through the map.

The line of sight algorithm doesn''t find any other objects. End of story.

I think you get the idea... If you don''t have many AIs, this might be a waste of time, but in my project I foresee thousands of AIs throughout the world, with very few of them at any one place, so this saves me a *lot* of processing.