Don''t forget geography... Add a geographical class and location structure to your list. This way if some thing has to occur at a church it will bind the generic geograpical class structure to the agenda, or if it has to happen at the church at the north side of Bum Town u can bind a geographical location structure to it.

-potential energy is easily made kinetic-

quote:Original post by Infinisearch
Don''t forget geography... Add a geographical class and location structure to your list. This way if some thing has to occur at a church it will bind the generic geograpical class structure to the agenda, or if it has to happen at the church at the north side of Bum Town u can bind a geographical location structure to it.

By using the word class and binding, it sounds as if you are introducing different programming paradigms to an existing paradigm. I am not sure exactly how you are envisioning this, but I see everything as working within the object/action/goal data structure and the agenda.

Can you (or do you even want to) rephrase this. I see what you are saying could be valuable, but think in terms of the existing data structures.



___________________________________

I''ve included geography in my design (nested locations), and made it so that locations can have affordances too - now I realise how I could use them... this stuff is great!

I hope I''ll have time tomorrow to finish my design, and post it up, it may provide a useful recapitulation of the whole topic.


People might not remember what you said, or what you did, but they will always remember how you made them feel.

quote:originally posted by bishop_pass
The dictionary defines agenda as: A series of things to be done. Items to be considered. Things to be done.

In addition to this i was adding time and other world state variables, and geographical considerations. They were ment to be used in addition to the generic object data structures that you proposed being in the goal structure.

quote:originally posted by bishop_pass
So, I propose that such goals which the NPC has are matched to 'generic' object data structures,....

Replace bind with matched, and replace class with generic. Bishop do me a favor and list out your basic data structures in one post, not whats inside them just the basic structure name and purpose. This way I can use your structure names, and vocab with my posts.

-Edit HTML Formating


-potential energy is easily made kinetic

Edited by - Infinisearch on January 24, 2002 9:26:52 PM

quote:Original post by Infinisearch
Bishop do me a favor and list out your basic data structures in one post, not whats inside them just the basic structure name and purpose. This way I can use your structure names, and vocab.

I'm not picking a bone with you. I am just trying to make sure you are not mixing the paradigm of C++ classes and additional data structures other than what I am thinking of, that is all.

What I am envisioning is custom designed data that is completely independent of structs, classes, etc. Less important at this point (in my opinion) is the exact form of the data internally, but the external specification of that data from a designer's point of view. I am also thinking of the internal representation though, and it more than likely takes the form of a frame (or semantic net) for the object/goal/action information, and a graph for the Agenda.

To answer your question on wording, here goes:

Agenda: an and/or graph of goals containing goals and also containing subgoals.

The Object Frame: a set of fields which define attributes of the Object.

The Process Loop: the iteration which occurs each cycle to sense objects, make changes to the Agenda, analyze the Agenda, execute actions, etc.


___________________________________



Edited by - bishop_pass on January 24, 2002 4:11:05 PM

[EDIT note: I have clarified this idea in my next post. Read this one for an overview, but don't get confused by the details, which may be a little confusing and not altogether consistent.]

I was thinking about BlocksWorld as an exercise to test planning ability. While BlocksWorld is considered a toy problem, it is also considered to be a a good test of an agent's planning abilities in a closed environment. And besides, blocks are classic and simple objects.

Getting BlocksWorld to work well is an exercise that forces you to focus on a design method to encode the data. And it forces you to sweat the details.

For those who don't know, BlocksWorld is a table with an assortment of colored blocks sitting on it. There may be one or two pyramids there as well. Blocks can be stacked on top of one another. No block can be stacked on a pyramid, but a pyramid may be stacked on blocks. There are some additional enhancements possible, such as certain large blocks allowing more than one block to sit on its surface, or allowing long blocks to span two blocks, making an arch.

The test is the ability of the agent to plan a sequence of actions to accomplish a certain goal, such as stacking the blue block on the red block, from an initial state where the blue block may already have other blocks on it, and the red block may be under some other blocks.

To create a planning agent that can do this with what we have benn discussing should be easy, if we develop the program correctly.

Here are some inital ideas regarding the BlocksWorld :

Proposed commands:

• Get a block.
  
• Put a block on another block.
  
• Set a block on the table.

Typical goals:

• Have the red block sit on the blue block
  
• Have no blocks be on the green block
  

For creating plans from the context of building knowledge which is object-centric , meaning new objects provide their own knowledge, there has to be goal and action fields which can link to one another by virtue of being matchable. By this I mean that a goal has to be able to match to a goal in an object frame, and provide a corresponding action to achieve that goal. That action becomes the new goal, which means that that new goal, which is an action, has to be matchable to the goal in possibly another object frame.

Goals are states. This means that goals correspond to getting the world in a new state. But goals are also actions. To execute an action is a goal to achieve another goal.

Let's say we have the goal to have the green block clear, meaning we wish no blocks to be on top of the green block. This is a state we desire the world to be in. Our goal is:
clear greenBlock.
We query the green block and look at its various goals. One of them is:
get onTop([ME],[OBJECT] to clear [ME].
We see that to satisfy our goal, we have a new action to do. This is our new goal. So, in the agenda graph, we have a subgoal which is:
get onTop([greenBlock],[OBJECT]).
Let's say onTop([greenBlock,[OBJECT]) evaluates to yellowBlock. So, really, our subgoal is:
get yellowBlock.
So, now we look at the yellowBlock object to find out how to satisfy this goal. We see:
clear [ME] to get [ME].
Now, we have a new goal, and it is:
clear yellowBlock.
Maybe the yellowBlock is alerady cleared, meaning there is nothing sitting on it. If that is the case, we can stop right here, and immediately fulfill our initial goal. So, all we have to do is:
get yellowBlock.

To make things more complex, let's assume that their might be a stack of blocks on the greenBlock and our agent can only hold one block at a time. If this were the case, our agent would need to set down one block before picking up another block. To do this, we need to provide a little more knowledge in the block data. We would have:
empty hand to get [ME]
And we would have:
set down object to empty hand.

Notice that we don't want the block to be set back down from where we just picked it up! We need to do a graph analysis to ensure that we don't do counter-productive actions.





___________________________________



Edited by - bishop_pass on January 24, 2002 11:07:37 PM

Ok, in my last post, I probably muddied the issue a little because I failed to mention constraints, and how they play into the semantics of what I described in BlocksWorld .

Look at the diagram below.



Each object would have several of these data structures: one for each action. One action may satisfy several goals. One action may require several constraints to be met before that action can take place.

Goals and constraints are world states. Actions create new world states which satisfy goals. Actions require certain world states called constraints before they can be executed.

Let's say our agent has a goal, and that goal is one of the goals listed in the diagram above. In order to acheive that goal, one of the solutions is to execute the action of the object that the above diagram is referenced by. Before that action can be executed, all of its constraints must be met. For each constraint that is not met, assuming the agent wants to accomplish its goal with the above action, the agent must first meet those constraints by making those constraints subgoals.

The syntax for goals, world states, and constraints is exactly the same. They are predicates. As constraints. they are interpreted as questions which query the world state. As world states, they are interpreted as fact. As goals, they are interpreted as desired world states.

Let's define a world state:
onTop(yellowBlock, blueBlock)
onTop(blueBlock, redBlock)
empty(hand)

Ok, we have a world where a yellow block is on top of a blue block which is on top of a red block. Our agent's hand is empty.

Here is a goal:
onTop(redBlock, blueBlock)

Now, let's look at some actions and their associated goals which change the world.

ACTION: get(block)
changes: NOT empty(hand), holding(block), NOT onTop(block, X)
constraints: empty(hand), NOT onTop(X, block)

In english the above translates to: The action of getting a block will change the world state to where the agent's hand is not empty, the agent's hand is holding the block, and the block will no longer be on top of any other thing. The action requires the world state where the agent's hand is empty and there is nothing on top of the block the agent wants to get.

ACTION: drop(block)
changes: empty(hand), NOT holding(block), onTop(block, table)
constraints: holding(block)

In english, the above translates to: The action of dropping a block will change the world state to where the agent's hand is now empty and the block is on the table. The action requires a world state where the agent is holding the block.

ACTION: put(block1) on (block2)
changes: empty(hand), NOT holding(block1), onTop(block1, block2)
constraints: holding(block1), NOT onTop(X, block2)

In english, the above translates to: The action of putting something on something will change the world state to where the agent's hand is empty, and the block in the agent's hand now is on the object the agent wanted to place the object on. The action requires a world state where the agent is holding block1, and nothing is on block2.

Now, going back to our original world state and our agent's goal of having the red block on the blue block, the agent can plan using the constraints and goals defined with each object. The agent wants the following goal accomplished:
onTop(redBlock, blueBlock)

From this initial world state:
onTop(yellowBlock, blueBlock)
onTop(blueBlock, redBlock)
empty(hand)

By examining the object's acheivable goals, it is clear that the put action will satisfy this goal. So, the question becomes a matter to see if the constraints of that action are met. In this case they are not. Therefore, those constraints become subgoals of our initial goal. The first part of the Agenda is built.

We now have these subgoals:
holding(redBlock), NOT onTop(X, blueBlock)

With those subgoals, we again examine the object data structures to see which actions can make those subgoals met. This process continues until an Agenda is built which provides a complete plan to satisfy our intial goal. At all times, the agenda is analyzed for contradictions, efficiency, etc. as mentioned in my initial post about the Agenda. The best plan at the time that the plan is finally built is then attempted. If at any time the world changes unexpectedly, the Agenda is changed to reflect this, as it is maintained during every turn.


___________________________________



Edited by - bishop_pass on January 24, 2002 11:03:58 PM

quote:Original post by Infinisearch
Oh and Gaiiden where can i get one of those smokin smiley faces?

It''s a staff-only icon, like Myopic''s rhino icon and Frizzlefry''s umm.. face icon (Dave said it was scanned off a Frizzlefry CD cover). It''s a smiley face on crack and while I don''t smoke or do drugs or anything, when I posted as a normal member I always used the "cool" smiley with the sunglasses. Well, when I became a staff member, it was replaced with this one and I was like - "Cool!!"

BP, it''s all looking good, though i don''t think i should comment yet. The question I do have is exactly what kind of um...system are we developing here? I mean are we coming up with a method that we can apply to specific circumstances, like an individual game with its own needs or sort of an engine that can handle anything through a scripted language? Did that make sense? Like a method we would apply to each individual game in a different way, with different specific objectives in mind, whereas an engine would be much more general and handle any goals we throw at it. I''m thinking engine due to all the general stuff getting kicked around but just wanted to be sure.

_________________________________________________________________

Drew Sikora
A.K.A. Gaiiden

ICQ #: 70449988
AOLIM: DarkPylat

Blade Edge Software
Staff Member, GDNet
Public Relations, Game Institute

3-time Contributing author, Game Design Methods , Charles River Media (coming GDC 2002)
Online column - Design Corner at Pixelate

NJ IGDA Chapter - NJ developers unite!! [Chapter Home | Chapter Forum]

Gaiiden, to me, the most desirable product would be an engine that allows designers to develop their own objects and goals and then use the engine to enable their agents to plan and act in their world effectively and realistically. A set of default knowledge could be included with the engine, such as basic object actions, goals, and constraints: such things like getting and dropping objects, moving from A to B, physical relationships such as containership, etc.

___________________________________