Hi all (once again) I'd like to thank you all for the helpful replies last time I posted, but unfortunately I'm still getting heavily bogged down in designing my code, rather than getting now to the nitty-gritty and just coding!! I did read some literature of MAS design & the excellent FEAR library, and am a bit confused about the difference between OOD and AOD (Agent Orientated Design), plus what is a 'body' class (just a mesh or sensing/movement code as well), and am still having problems producing good, extensible code. Could anyone help/advise please? Below I've got together some pseudocode to illustrate what I'm doing, if that helps at all? PSEUDOCODE ... class Body { Mesh mesh; Anim* anims; int Render(); int PlayAnim(); int StopAnim(); }; class Brain { State* states; void Think(); }; class ActorDef { String name; short ID; Brain* brain; Body* body; } class ActorInstance { ActorDef* actorDef; int xPos, yPos; State currentState; int CheckSenses(); int Update(); int Render(); }; END OF PSEUDOCODE ... Cheers Dan [edited by - djwarder on December 5, 2003 6:47:33 AM]

I''ve come to think of AOD as a particular way of doing OOD. Frankly, OOD has come to encapsulate so much it means almost nothing.

In FEAR, a component is a set of classes (representing the abstract interfaces, their implementations, the private implementation, the base data...). Then, an agent is a particular kind of component that has the ability to act over the world or other components (aka. agency). To do this, an agent requires an interface to a slave component which it can delegate tasks to. Non-agent components are leaves in the architecture hierarchy since they have no slave components.

I''ll talk about the Body class in the context of FEAR again The Body class contains the code needed to have a player in the game (could be human). In FEAR, it is in fact hidden from the Brain. The fact is the AI does not really care about rendering at all. All the Brain needs is a few more interfaces to the Body. In FEAR, these are called Backend interfaces (from the AI''s point of view), and consist of Motion Physical State, Vision interfaces, etc. This insight is where the beauty of the last iteration (0.3.x) of FEAR comes from; there is no need to distinguish a body from any other component except that it''s implementation is hidden within the game engine (platform). The number of core classes in the framework was reduced by almost half thanks to this...

See the Animat.h in FEAR, it''s a good starting point.

---

AiGameDev.com

Btw, it''s probably not necessary to write a framework just to implement a good demo. In fact, implementing the framework upfront (i.e. a foundation framework) will probably bite you. Even if you want to learn about AI software design, start coding your demo and see what you need and what can be factored out of the demo (i.e. a harvested framework).

It''s so easy to spend weeks on designing a framework upfront that isn''t much use...

---

AiGameDev.com

Your overdesigning from the looks of it. Your requirements dont really warrent such levels of complexity.

At the core of it an agent is composed of :

-evaluator function
-executor function

from expereince and research, agents also need to sense their enviroment and need to be able to be given commands.

So that should give u a basis for :

enum COMMAND_ENUM //command enum used to control agents.
{
CMD_MOVE_FORWARD,
CMD_STOP,
CMD_MOVE_TO_GOAL,
CMD_NULL
};

class Agent_Base
{
public:

Agent_Base(World* p_world) : m_p_world(p_world){}

//Accessor functions ...

void update ()
{
sense();
think();
act();
};

vitual void command( COMMAND_ENUM cmd )=0;

protected:

virtual void sense()=0;
virtual void think()=0;
virtual void act()=0;

World* m_p_world; // this is the world object the agent resides in...
Point_3D m_pos; //agents position
float m_dir; //agents orientiaton in degrees

};

that''s the fundemental agent base class. So, from your previous post, you want to make a crowd simulator. So a very simple agent would just move forward until it sees someone in front of it, and then stop, waiting for that blocker to move out of the way, and maybe if it waits long enough, tries to find a way around the blocker.

class Simple_Agent : public Agent_Base
{
public:

Simple_Agent(World* p_world) : Agent_Base(p_world), m_state(NULL){}

//redefine base class virtual functions here..

private:

enum STATE
{
MOVING,
STOPPED,
NULL
};
Agent_Base* m_p_blocker; //blocker if there is one
Vector_3D m_velocity; //velocity of agent, if moving
STATE m_state; //state of agent
};

The Simple_Agent redefines the command,sense,think,act functions in accord to its beahvior.

This is a very simple and somewhat restricted design, however before you jump right into a componetize agent framework and runtime composite entites, you might want to clarify the fundementals of what an agent is and does with these simple constructs. The power of a componentize framework, is the broarder range of available behaviors but at the cost of the complexity which arrises from that power.

Good Luck.

-ddn

Just a little answer to one of the questions above... ''what is the difference between OOD and AOD''?

The answer is best seen in an example architecture for AOD, namely the BDI Architecture, which stands for Belief, Desire, Intention. In this form of AOD you create an agent that has beliefs (things it knows), desires (things it wants to achieve - goals) and intentions (the plan it chooses to enact, given it''s beliefs, so as to achieve its desires). Designing your agent from this perspective is an example of Agent Oriented Design.

It really just gets down to perspective... thinking of agents when designing algorithms, creating agent data types and implementing agent-centric methods... as opposed to thinking of data, designing data-classification based data types and implementing data-centric methods.

There''s plenty of literature out there on AOD... but you don''t really need to read it unless you''ve got a LOT of spare time on your hands.

Cheers,

Timkin

Timkin: hmmm....

If the design of the software happens to create an agent, does that make it an Agent Oriented Design?

I''d say the design has to include different agents that collaborate to solve a problem, in the spirit of multi-agent systems. In BDI, this is not the case. There are components are datastructures and algorithms that cannot work without each other, and are not self-standing agents.

It doesn''t really matter either way, I''m just curious.

---

AiGameDev.com

quote:

---

Original post by alexjc
If the design of the software happens to create an agent, does that make it an Agent Oriented Design?

---

No, I wouldn't go so far as to say that any software agent arises from agent-oriented design. One could 'easily' build an agent that was perceivable as an agent, yet was just a cluster of modules interacting to produce that outward appearance, utilising just OO-design principles... heck, I've done this myself... the result was impressive and looked like an agent, but it wasn't built using AOD principles.

My understanding of AOD is that at the top level one has an agent and an environment, which interact only through an interface of actuators and effectors. This set is the domain. Just as OOD is a data driven design, I perceive AOD to be agent driven design. The principle should be to design an agent that embodies certain features that enable it to interact with its environment, to achieve some desired behaviour.

Therefore, in the case of BDI agents, the desired behaviour is that they achieve the goals that arise; either those they derive for themself, or those dictated by the designer/user.

I think my previous post wasn't very good at explaining what I meant by AOD (it was a bit rushed, sorry). Just because an agent has beliefs, desires and intentions, doesn't mean it was designed using AOD principles. However, using AOD principles to create software that has beliefs, desires and intentions is likely to result in the perceived software being labelled an agent (IMHO). Make sense?

quote:

---

Original post by alexjc
I'd say the design has to include different agents that collaborate to solve a problem, in the spirit of multi-agent systems.

---

BDI does not preclude multiple agents... it's just a model for a single agent... and it's just one model of an agent. There's no reason why an agent's intentions couldn't be dependent on the intentions of other agents.

Just a side point... I think if you asked 10 different people what they meant by AOD, you'd get 11 different answers.

Timkin

[edited by - Timkin on December 9, 2003 2:25:36 AM]

One could ''easily'' build an agent that was perceivable as an agent, yet was just a cluster of modules interacting to produce that outward appearance

Isn''t that an agent then Timkin? I fail to see the distinction. If something looks, acts and smells like an agent then it *is* an agent. (From a client''s perspective)

Surely if one designs a system oriented toward being an agent then that is AOD. How can it be anything else?




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

If someone is building an object (like a table), does that mean it's OOD?


Edit: I'm using extreme metaphores to argue that it's the principles at the heart of the design that characterize the approach, not the goal.

[edited by - alexjc on December 10, 2003 5:49:17 AM]

I agree with Alex on this one. fup, reread that line of mine that you quoted. Yes, I said it was an agent and I said it was perceivable as an agent... but that doesn't mean I built the agent with AOD principles, just that the end result of mashing some code together gave the outward appearance of an agent, in spite of the lack of AO-design.

I think that AOD, like OOD, is a perspective at the design stage, which dictates not only the relationships between levels of the code/algorithm, but also the range or permissible code/algorithms that could be applied. As such, a programme might be an agent by function, but not by design. I know this is a pedantic point and is probably irrelevant in the long run, but I think it's one worth recognising, mainly for the long term perspective of how we approach software engineering, as opposed to programming.

I'm not holding fast to my definition of AOD, so feel free to try and persuade me otherwise... but here are some questions for you to ponder while you try...

Is a state machine an agent? Is a heirarchy of state machines an agent? At what stage does said heirarchy become an agent? Does this answer change if my design is top down AOD or bottom up code mashing (till I get the desired result)?

Cheers,

Timkin

[edited by - Timkin on December 10, 2003 9:30:54 PM]