Jump to content

  • Log In with Google      Sign In   
  • Create Account


GDC = AI_Fest; while(GDC == AI_Fest) {CheerWildly();}


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
71 replies to this topic

#61 IADaveMark   Moderators   -  Reputation: 2299

Like
Likes
Like

Posted 18 March 2004 - 05:23 AM

quote:
Original post by Anonymous Poster
Ack... one-hour talks in a dark room about AI just suck.


So do people who do anonymous drive-by postings about things they obviously don''t like.

Dave Mark - President and Lead Designer
Intrinsic Algorithm -
"Reducing the world to mathematical equations!"

Sponsor:

#62 ddn3   Members   -  Reputation: 1244

Like
Likes
Like

Posted 18 March 2004 - 07:17 AM

I have something running which is similar to what alexjc describes, a pure event driven reactive agent design ( well almost, still have some test code in there which polls ). Some observations, you don''t nessecarly need to use an oracle to capture events which are pertient to the AI. Events are generated within the subsystems already, most of the time they serve multi purpose. An event indicating collision with another object is used by the collision routines, however having the AI hook into those events, now it can be collision aware. It will have to filter such event so it won''t be innudated. Within a purely event driven architecture, there will be a profusion of events, which can be hooked and rerouted to the AI.

That''s not so say an occasional oracle here or there isn''t bad. I do have an world handler object which manages all AI sensory information and AI combat results. Much more efficent than polling, for large number of agents ( 100+ ).

Though I''m seeing purely reactive agents just being driven by the immeidate events, don''t seem very smart. Even though they respond to threats and show some imputus toward events, their behaviors overall are disconnected, stateless. To complete the sense of them being aware and intelligent, there needs to be anditional layer. Perhaps a super-brain which forms overarching plans and retains memories. Though it wouldn''t be on an per agent basis, rather it would be a group contoller. Perhaps that is where Timkins AI comes into play. Using a SPA architecture would be approriate here, but not at the individual agent level. If individual agents did use SPA, coordinating them would require inter-agent communication and a host of other techniques (agent-reflection, meta agent-modeling etc..)

Good Luck!

-ddn

#63 alexjc   Members   -  Reputation: 450

Like
Likes
Like

Posted 18 March 2004 - 12:11 PM

Arguably ddn, you''re just using the PA of "SPA" . But it sounds like an elegant design to me!

I think we''re done here



AiGameDev.com: Artificial Intelligence from Theory to Fun!

#64 Timkin   Members   -  Reputation: 864

Like
Likes
Like

Posted 18 March 2004 - 06:55 PM

quote:
Original post by alexjc
Oh, I wasn''t defining sensors. I was trying to understand Timkin''s approach

I see a sensor as a generic concept, which can translate into poll-based queries or event-driven messages...


I think you''re reading too much into what I wrote Alex. I''m not trying to tie down the exact implementation of the sensor or its exact architecture, merely its function relationship between the environment and the agent.

Think of the sensor as an interface between the agent and the environment. Its role is to translate environmental events into messages appropriate to the agent... but further to this, is should also filter events/messages based on the agents state, intentions and actions. This could be a two stage process, if one chose to implement it that way.

I see the issue of whether the sensor is a polling inteface or message-passing interface as less relevant to the functionality of the sensor. I could certanily envisage an agent that utilised both polling and messaging sensors.

Does this make it more clear?

Timkin

#65 alexjc   Members   -  Reputation: 450

Like
Likes
Like

Posted 18 March 2004 - 09:26 PM

quote:
Original post by Timkin
I see the issue of whether the sensor is a polling inteface or message-passing interface as less relevant to the functionality of the sensor. I could certanily envisage an agent that utilised both polling and messaging sensors.

Does this make it more clear?



To some extent. I understand that in theory you just want to model data flow, whether it''s being pushed by the engine or pulled by the agent. However, I''m not sure it''s possible to disregard the implementation that easily, as it has fundamental ramifications on the design of the agent itself. The agent''s implementation MUST either poll or handle events, so your scheme needs to fit into that somehow.

I was trying to get the implementation clear because of these limitations. I think you''re on to something, but the devil is in the details!

Alex



#66 Timkin   Members   -  Reputation: 864

Like
Likes
Like

Posted 20 March 2004 - 03:29 PM

quote:
Original post by alexjc
However, I'm not sure it's possible to disregard the implementation that easily, as it has fundamental ramifications on the design of the agent itself. The agent's implementation MUST either poll or handle events, so your scheme needs to fit into that somehow.



Ah... now I see the way through to explaining this... the sensor itself can either poll or accept messages from the environment... whereas the agent would be better to just handle messages from the sensor.

Why is this any different than just an agent accepting messages from the environment? Predominantly because the sensor can also filter information, either by passing only information that fits a certain schema (like enemy spotted, but ignore friendly spotted), or by focusing information depending on the agents state and/or focus. We might expect a badly wounded agent to not see an enemy while it is rushing toward a health pack. However, it might be nigh impossible to ignore the ambush waiting around that health pack. This filtering can be performed as a dependent function of the agent's state.

Such sensors would also permit reactive agents built solely on messaging systems to be able to implement active information gathering via polling sensors.

One could also envisage heirarchically layered sensors, designed to extract and filter information from outward layers, depending on the state of the agent and perhaps even the state of other sensors. So the 'enemy spotted' scenario might be accomplished by two layered sensors... an outward visual sensor that identifies all objects of relevance in the game and an inward filter sensor that isolates and identifies only enemy agents.

Of course, adding extra layers usually adds complexity to a system. However, such sensors would provide a clear mechanism for emboddying the 'Oracle' mentioned earlier and provide a centralised manner for handling information transfer to the agent. Writers of physics engines need only specify how information is emmitted from an event. The task of how this information is perceived by agents now falls to the designer of the sensor set for a given agent. How that information is then utilised by the agent finally falls to the designer of the decision modules. Separating the three seems to me at least to provide some clear design and programming task boundaries which generally makes software engineering easier.

Of course, I've not implemented this idea, so I could be wrong!

Cheers,

Timkin

[edited by - Timkin on March 20, 2004 10:34:17 PM]

#67 alexjc   Members   -  Reputation: 450

Like
Likes
Like

Posted 23 March 2004 - 04:33 AM

Timkin. The concept of filtering seems like an orthogonal issue. You can filter information just as easily with messages or queries. For the polling approach, you just have a small 'if' section that checks for certain data fields. With messages, you'd just put that code inside a proxy that serves as an intermediate layer between the source and destination of the message. The idea of hierarchical sensors can also be applied to both paradigms -- just like C4.


The essence of the idea you describe is in the client/server design. The AI (client) can upload a small part of it's code into the game engine (server) to send back information as necessary. I'm pretty sure there are many ways of doing this, but I've tried two so far -- with mixed results.


  1. Have a small sensor script designed with the AI that is run on the server at regular intervals, and passes messages back.

  2. During initialization, have the AI perform polled queries and get the server to remember the parameters instead of returning a result (this is a special setup phase). The server then knows that the AI wants that information on a more regular basis, and can send it along in messages.



Either approache is at the extreme end of the same scale; at one end, you have full sensory functions implemented with a powerful scripting language, and at the other end you use simple data sent as parameters understood by the engine.


The problem with the scripts is that the engine cannot really "understand" what's in the sensory function. The best strategy for the server is to just execute the scripts regularly and hope for the best. So in theory, this is no more efficient than a polling sensor based system.
On the other hand, when the server receives parameters for a sensory query, it knows exactly what they mean as the implementation is designed to implement these queries. This allows the engine to "understand" the parameters, and use any form of optimisation implemented by the coder.

So by chosing a format for expressing your sensor functions, you're trading off efficiency for flexibility. I wonder what kind of compromize is the most useful

Alex


AiGameDev.com: Artificial Intelligence from Theory to Fun!

[edited by - alexjc on March 23, 2004 11:33:53 AM]

#68 IADaveMark   Moderators   -  Reputation: 2299

Like
Likes
Like

Posted 25 March 2004 - 03:21 AM

Well, you guys will be pleased to find out that we covered polling vs. event driven in Brian Stout''s roundtable yesterday. The official roundtable answer was "hybrid" or "it depends".

Dave Mark - President and Lead Designer
Intrinsic Algorithm -
"Reducing the world to mathematical equations!"

#69 fup   Members   -  Reputation: 463

Like
Likes
Like

Posted 25 March 2004 - 04:34 AM

no surprises there then eh.

Are you recording the roundtables this year dave?


My Website: ai-junkie.com | My Book: AI Techniques for Game Programming

#70 IADaveMark   Moderators   -  Reputation: 2299

Like
Likes
Like

Posted 25 March 2004 - 03:29 PM

No, I haven''t been able to. Sorry. Eric said he was thinking about doing his but another moderator told him that obvious recording devices tend to shut people up. (well... except me)

Dave Mark - President and Lead Designer
Intrinsic Algorithm -
"Reducing the world to mathematical equations!"

#71 fup   Members   -  Reputation: 463

Like
Likes
Like

Posted 25 March 2004 - 07:16 PM

doh!

"told him that obvious recording devices tend to shut people up"

I guess that is a good point!

How are you finding it this year then Dave? Is it as good as it looked on paper so far?



My Website: ai-junkie.com | My Book: AI Techniques for Game Programming

#72 IADaveMark   Moderators   -  Reputation: 2299

Like
Likes
Like

Posted 26 March 2004 - 03:14 AM

Fan-freakin-tastic! To go from Brian Reynolds - "How AI enables designers" straight to Peter Moleyneux - "AI and Game Design" is a little like bar hopping for the AI guy!

Dave Mark - President and Lead Designer
Intrinsic Algorithm -
"Reducing the world to mathematical equations!"




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS