***BANG*** excuse me a moment my brain exloded reading Bisop_Pass''s post... Ok, not quite what I was hoping to read at 9am in the morning.

Seriously though, its an intersting way of doing things. I''m just worried about the computational cost of implementing such a system.(*Begin Sarcasm* I mean after all its going to take processor time away from my incredibly photo-realistic 3D Engine! *End Sarcasm*)

Wondering waaay off topic for a moment, using these relations between "things" to do all the AI work, is probably ok for the simple descision making objects (by this I mean descisions like "The player is holding a match to me, do I catch fire?") for more complex NPC AI reasoning, it''s (unfortantly) computationally far to expensive at the moment. (I''ll apollogise to MadKeith now for turning this temporarily into the AI forum). Using these kinds of rules would create fully cognitive AI''s which would be absolutly brilliant, The problem with this approach is the sheer size of the "outcome tree" (basically a big tree that lists all the possible actions the AI could perform and thier outcomes) that the AI would need to search in order to come up with vaild move. The rules would have to form a part of the overall AI process.

Implementation wise Bishops_Pass do you see this being "interpreted" on the fly or "compiled" at load time, i.e. Would an instance of a wooden door "KNOW" (instantly) during the game that if the player held a match to it it should catch fire, or would it need to look through its inferences to find that fact out?


Also why hasnt this been done before?? Is it that the various approches are too complex, or expensive (computationally or time) or that people are too "afraid" to get that complex?? Which ever way you do it, it will (I think) add an extra level of complexity to the implementation...

NightWraith

Wav's quote :Divided into numbered sections for easy response

quote: Original post by Wavinator

1.[If this were communicated with drama and dialog, wouldn't it reinforce character, the game universe and role-playing in general?]

2[Now, is it only "interesting" but not "fun" because it's a loss situation, or because it's too detail specific? What if I said that the amulet was bloody? Or that your clothes were dirty and bloody?]


3.[(Oh, and I didn't say above that you wouldn't have defenses against these situations, only that they could exist without inflexible scripting) ]
--------------------
Just waiting for the mothership...

1. The game universe: yep, the more processes that are visible to the player in
a game, the better ie. fighting = gives you and enemies bloodied clothing.

So when the player sees an character wandering around with bloodied clothing
he realises that they have been in a fight.. and this allows you to combine
scripted characters (for special quests) and ones generated on the fly
seamlessly. It also generates SUSPENSION OF DISBELIEF.. ie. they may not
believe that the game is REALITY but they know that it has it's own rules and
believe that the character really has been in a fight.


2. Because it is a loss situation.
They could then wash it with their handflask from Vault 13 .

- If the player was all bloodied, they could be treated like a hero and sent for
some rest.. lay it on the line for the player!

Give them a pat on the back.
They are the hero of the day (?), they deserve to be made to feel good for
their heroic (combat with Lord. Meleagant) / clever (if they use cunning to get
it) etc. solution to returning the amulet.

3.You would need to visibly show the player that it was dirty (appropriate
feedback, stats have to be represented), not that I expect Wavinator wouldn't
show the player it was dirty..

Edited by - Ketchaval on March 14, 2001 10:20:15 AM

quote: Original post by NightWraith

Seriously though, its an intersting way of doing things. I'm just worried about the computational cost of implementing such a system.(*Begin Sarcasm* I mean after all its going to take processor time away from my incredibly photo-realistic 3D Engine! *End Sarcasm*)

As for implementation, remember that the system itself (minus the actual rules and knowledgebase which you must provide) is already developed. It is robust, efficient, and has been under development since 1983. It is public domain, and the complete C source is available. Yes, it would detract from the CPU resources for graphics. That is why publishers are shying away from using such a system. But for the hobbyist (or a network of hobbyists) who are more interested in breaking the mold of game development instead of propogating the current mold, I think this system bears further research.

quote: Original post by NightWraith
Wondering waaay off topic for a moment, using these relations between "things" to do all the AI work, is probably ok for the simple descision making objects (by this I mean descisions like "The player is holding a match to me, do I catch fire?") for more complex NPC AI reasoning, it's (unfortantly) computationally far to expensive at the moment.

Actually, it is very effective at more complex reasoning. The military has used the system to simulate 700 unique agents cooperating together to complete tactical air missions. There is no single AI which controls all the agents. Rather, each agent is given its own cognitive model and communicates with the other agents to complete the mission. Agents are given knowledge about missions, communicating needs to other agents, flying aircraft, interpreting information and proposing methods to accomplish the missions. These missions, in addition to the simulated agents, have real people in simulators that in general are not able to tell the difference between agents and other real people in the mission. Each agent has about 5000 rules in its production system.

quote: Original post by NightWraith
(I'll apollogise to MadKeith now for turning this temporarily into the AI forum). Using these kinds of rules would create fully cognitive AI's which would be absolutly brilliant, The problem with this approach is the sheer size of the "outcome tree" (basically a big tree that lists all the possible actions the AI could perform and thier outcomes) that the AI would need to search in order to come up with vaild move. The rules would have to form a part of the overall AI process.

As I said, the system has been demonstrated to operate efficiently even with a knowledgebase containing one million rules. I would not think of it as a tree, but rather an encoding of knowledge in which emergent behavior arises.

quote: Original post by NightWraith
Implementation wise Bishops_Pass do you see this being "interpreted" on the fly or "compiled" at load time, i.e. Would an instance of a wooden door "KNOW" (instantly) during the game that if the player held a match to it it should catch fire, or would it need to look through its inferences to find that fact out?

The system basically has a very effiecient rule matcher which is able to very quickly (in real time) determine all relevant and matching rules based on what it has in 'working memory' at any given time.

quote: Original post by NightWraith
Also why hasnt this been done before?? Is it that the various approches are too complex, or expensive (computationally or time) or that people are too "afraid" to get that complex?? Which ever way you do it, it will (I think) add an extra level of complexity to the implementation...

The main reason is the complete paradigm shift one must take to effectively learn how to program this beast. I'm still learning. Also, people only look ahead a few months and decide if they have to learn something that might be a little too slow on today's system then they won't bother. But if you started to learn it, and by the time you got good with it, we'll probably have another doubling in computer speeds.

Let me quote text on the home page of the system to better describe what it is and where you can find out more about it. Also, if you do look into it and find it daunting, I have essentially figured out the basic elements of programming it, so if anybody is more interested, I'm interested in discussing it more. I am in not affiliated with the project at all, it is just that in my search to harness existing publicly available AI technology, this system seems by far to have the most potential.

Soar is a general cognitive architecture for developing systems that exhibit intelligent behavior. Researchers all over the world, both from the fields of artificial intelligence and cognitive science, are using Soar for a variety of tasks. It has been in use since 1983, evolving through many different versions to where it is now Soar, Version 8.2.

We intend ultimately to enable the Soar architecture to:

1) Work on the full range of tasks expected of an intelligent agent, from highly routine to extremely difficult, open-ended problems.
2) Represent and use appropriate forms of knowledge, such as procedural, declarative, episodic, and possibly iconic.
3) Employ the full range of problem solving methods
4) Interact with the outside world and learn about all aspects of the tasks and its performance on them.

In other words, our intention is for Soar to support all the capabilities required of a general intelligent agent.

The ultimate in intelligence would be complete rationality which would imply the ability to use all available knowledge for every task that the system encounters. Unfortunately, the complexity of retrieving relevant knowledge puts this goal out of reach as the body of knowledge increases, the tasks are made more diverse, and the requirements in system response time more stringent. The best that can be obtained currently is an approximation of complete rationality. The design of Soar can be seen as an investigation of one such approximation. Below are the principles which are the basis of Soar's design and which guide its attempt to approximate rational behavior.

1) The number of distinct architectural mechanisms should be minimized. In Soar there is a single framework for all tasks and subtasks (problem spaces), a single representation of permanent knowledge (productions), a single representation of temporary knowledge (objects with attributes and values), a single mechanism for generating goals (automatic subgoaling), and a single learning mechanism (chunking).
2) All decisions are made through the combination of relevant knowledge at run-time. In Soar, every decision is based on the current interpretation of sensory data, the contents of working memory created by prior problem solving, and any relevant knowledge retrieved from permanent memory. Decisions are never precompiled into uninterruptible sequences.

Soar




Edited by - bishop_pass on March 14, 2001 11:19:27 AM

Edited by - bishop_pass on March 14, 2001 11:22:39 AM