David Haley
Wizard
Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#16 id:13505 Posted Oct 7, 2008, 1:18 pm
|
There's no need to be hostile about this... it's just brainstorming and thinking about things.
effigies said:scripting NPCs to do different things based on conditions that are represented in game is really trivial in LP.
I don't think you quite understood what he was trying to do. It's not as simple as saying "if this, do x,y,z". He wants a larger scene to be scripted under a given condition, and that condition must remain true for the duration of the scene. The question is what should be done if the condition is violated halfway through the scene.
|
|
|
Silenus
Sorcerer
Group: Members
Posts: 253
Joined: Feb 26, 2008
|
#17 id:13565 Posted Oct 8, 2008, 1:54 pm
|
You might be correct David that I am taking the wrong approach to the problem and a planning agent of some sort might be a better approach. Unfortunately I do not know much about this approach. The cons here might be that it might be difficult for a person with limited coding experience to quickly decompose a problem into the relevant subtasks effectively- though perhaps a set of properly designed modules might be able to handle this but I am not sure. It might have a range of benefits as well though since you get truly intellgent planning agents capable of a wide range of tasks.
It may be that given how much branching factor there is in scenes with exceptions to the main flow in general that this problem is not solvable in a clean way. You may be able to guard against errors occurring in the main scene narrative by re-evaluating a modified version of the guard condition prior to each delayed action- in the simplest case the guard condition would be unchanged throughout the scene and just re-evaluated (and if something bad occurs throw an exception)- my more elaborate proposal might be that if some action alters the environment/state in some manner which violates the guard- since the action itself is known apriori in most cases would it not be perhaps possible to use some sort of post-condition to modify the guard? I am not sure to what extent such sophistication is needed though- I can think of certain cases such as a guard like "if some object is present" and the first action is get it (changes the environment state and re-evaluation of the guard clause would become inappropriate for subsequent actions).
Effigies- I know you could code a custom inheritable for this for specific cases but I am thinking in terms of a more general scripting mechanism (which could be an inheritable since as I mentioned earlier in the thread it could be a library) which can cope easily with a wide range of diverse situations allowing NPC's to have more dynamic behavior in general rather than having a predefined module with specific behaviors which something like say an innkeeper daemon would imply.
|
|
|
David Haley
Wizard
Group: Members
Posts: 6,874
Joined: Jun 30, 2007
|
#18 id:13568 Posted Oct 8, 2008, 2:05 pm
|
You would have to use fairly high-level constructs to make it easy for non-technical people to give planning directives. Fortunately, that might not be as hard as it looks. In the innkeeper scenario, you could say it like this:
1. Go to room X.
when complete:
2. Order the bread.
when complete:
3. Go to room Y.
You could replace "when complete" with whatever syntax you want, but except for the details of step 2, in the above five lines you have basically captured the entire high-level scene. The planner can figure out how to flesh out steps 1 and 3 pretty easily. The above doesn't capture the initial precondition or trigger, but I think the general idea is clear.
Basically, if you provide the high-level constructs and a simple syntax for specifying dependency chains, it's pretty easy to create simple scenes.
I would tend to agree that, for sufficiently complex scenes (where complexity has to do with branching), there might not be a clean solution, if cleanliness means simplicity of specification.
Simple planning agents are not that hard to write up. It depends on the richness of the environment in terms of what actions are available to the actors and how many consequences those actions can have, and furthermore to what extent the actors understand the consequences. If the goals are fairly simple, and the steps involved are pretty obvious, and finally you can limit the relevant universe to a small subset of the whole MUD world, planning becomes rather cheap. Unfortunately, IMO, it's pretty hard to search for planning code on the web since you tend to get academic work that is usually far more advanced than you (usually) need. You also tend to not find much introductory material.
If you have access to the book AI: A Modern Approach I would highly recommend it as a good introductory textbook to these issues. While it's not all about planning, they have quite a bit devoted to planning agents and how you could go about designing such systems. The book is not about implementation, though, and tends to stay at a fairly high level. I imagine that there are game programming books that discuss planning in more detail but I am not familiar with any.
|
|
|
Silenus
Sorcerer
Group: Members
Posts: 253
Joined: Feb 26, 2008
|
#19 id:13680 Posted Oct 10, 2008, 5:45 pm
|
Thanks. I will take a look at that. I am actually familiar with that title but only skimmed through some of the sections. When I was looking through it I was primarily interested in AI for board games and didnt really look at the chapter on planning. Do most of the techniques require some sort of theorem proving engine to actually process the results? I have been somewhat interested in resolution theorem proving and I guess it's an interesting issue if such a device could be used in certain mud applications specifically stuff like planning and natural language processing for command handling.
I guess any such "mud" would not really be very mud-like by current standards but could be quite interesting. I was thinking of making this a sub-system (a simple TP device) of my server project originally (getting off topic here I know).
|
|
|
|
|
