Guncho

    "Boxworld" by Nate Cull

The story headline is "An interactive laboratory".

[A Planner test/demonstration realm for Guncho, based on Planner and Alchemy by Nate Cull, incorporating bug fixes and suggestions from Josh Lawrence. Feel free to steal code, this is an open demo.

The major changes so far from Planner v1 (some caused by changes to I7 since 2006, some needed for Guncho):
* 'Carry out someone trying something' changed to 'Instead of someone trying something' to avoid a compile syntax error
* the object 'no-token' as an initial value in the goal table to avoid compile type error (the 'plan' column needs to be able to take any kind of planning-token, not just planning-relations).
* angle brackets in comments removed to avoid Guncho compile errors (Guncho)
* DOCUMENTATION sections removed (Guncho)
* Includes and version stamps for library modules removed (Guncho)
* Library modules changed to Volumes within a single source file (Guncho)
* Sections used as standard unit within Volumes (Guncho)
* ECHO command imported from Fairhaven (Guncho)
* PLANS JUSTIFY added - tracks back goal chain from action (assuming the goal fired is in fact the last line in the goal table) to toplevel goal
* real-time events added (Guncho)
* debugging real-time events
* west portal back to Fairhaven Library

Todo:
* bug: Bob doesn't cope with being given the basket - he senses things inside it as not being touchable.
* bug: reporting Bob opening the cupboard doesn't work with 'for the first time'

]

Volume 1 - Planner

Section - Definitions and Globals


Planning-token is a kind.

No-token is a planning-token.

Planning-relation is a kind of planning-token.

Planning-action is a kind of planning-token.

No-action is a planning-action.
Success-action is a planning-action.

Planning-marker is a kind of planning-token.

No-plan is a planning-marker.
No-step is a planning-marker.
Plan-pending is a planning-marker.

No-object is a thing.

Table of Goals
Parent  Plan    Step    Token   Param1  Param2
0   0   0   no-token    no-object   no-object
with 20 blank rows


The planning actor is a person that varies.

The requested relation is a planning-relation that varies.
The requested param1 is an object that varies.
The requested param2 is an object that varies.

The planned action is a planning-action that varies.
The planned param1 is an object that varies.
The planned param2 is an object that varies.

The desired plan is a number that varies.
The desired step is a number that varies.
The desired relation is a planning-relation that varies.
The desired param1 is an object that varies.
The desired param2 is an object that varies.

The suggested token is a planning-token that varies.
The suggested param1 is an object that varies.
The suggested param2 is an object that varies.

The working plan is a number that varies.
The working step is a number that varies.

Planner verbosity is a number that varies. Planner verbosity is 0.

The action success flag is a number that varies.



Section - Main Routines

[This is the main entry point for calling Planner. It will find an action that satisfies the desired relation/object/object triad, and then attempt to execute that action.]

To have (A - a person) plan an action for (C - a planning-relation) with (P1 - an object) and (P2 - an object):
    if debugging planner, say "Planner: starting planning for [A].";
    if debugging planner, say "Planner: testing goal 1: [C] [P1] [P2]: [run paragraph on]";
    change the planning actor to A;
    change the requested relation to C;
    change the requested param1 to P1;
    change the requested param2 to P2;
    change the planned action to no-action;
    change the planned param1 to no-object;
    change the planned param2 to no-object;
    if goal C with P1 and P2 is true begin;
        change the planned action to success-action;
        if debugging planner, say "true, no work to do[line break]";
    otherwise;
        if debugging planner, say "false, generating plans [run paragraph on]";
        clear the goal table;
        choose row 1 in the Table of Goals;
        change the Token entry to the requested relation;
        change the Param1 entry to the requested param1;
        change the Param2 entry to the requested param2;
        change the Parent entry to 0;
        change the Plan entry to 0;
        change the Step entry to 0;
        expand goal 1;
        advance all goals;
    end if;
    if debugging planner begin;
        if the planned action is no-action, say "Planner: no action chosen";
        otherwise announce "Planner: say [the planned action] [the planned param1] [the planned param2]";
        say "[paragraph break]";
    end if;
    execute the planned action;



[The core loop. Fill up the goal table line by line, reading goals as we come to them, considering each one, and if we can't satisfy it then spawning new subgoals and adding them to the end of the table. If we can fully satisfy a goal, then we end and return the action of that one as our chosen action.

My terminology is a little confusing as I sometimes use the words 'plan' and 'goal' apparently interchangeably. That's because of the way the data is stored. Let's have some definitions:

A Goal is a triad of Relation, Object, Object. (The Cat Is-on The Mat). It represents a piece of world state that we are actively trying to make true. Goals are related to one another in a tree structure. There is a top-level Goal which may have multiple child goals, and so on.

A Plan is a set of (Goal, Goal, Goal... Action). If every goal, evaluated in sequence from left to right, is true, then the actor should take the suggested Action.

So every Goal can have multiple Plans, and every Plan can have multiple Goals.

You'd think the best way to store this would be with a tree structure: Goals spawning Plans spawning Goals and so on. And you'd probably be right. But since we don't have dynamic memory allocation and can't easily do trees, we use a table instead. And each row of that table indicates *both* a Goal *and* a Plan, depending on context. Somewhat confusing. That is to say:

* The top row indicates the top-level Goal.
* All new rows added to the table indicate separate Plans which are suggested as ways of satisfying outstanding Goals.
* We examine each Plan, checking each of its Goals, and eventually we either return an Action, or stop at a Goal which is blocking us. When that happens, we mark up the table row to now indicate a *Goal*, and continue on.

So as we go on, each line in the table that we've visited consists of a Goal. Lines that we've added but not yet visited indicate unevaluated Plans.

Each row has:
* Parent -the Goalrow which this is a plan or goal for
* Plan - the Plan number of the Parent goal which this is a plan for
* Step - (once we've turned from a Plan to a Goal) the Step number of this Plan at which we stopped evaluating because we found a not-currently-true Goal or an Action
* Token - either an Action or a Relation, or else a Marker (a kind of note-to-self used for internal communication between the Planner routines)
* Param1 - the first Object of the Action or Relation - only set once we have a Goal or Action
* Param2 - the second Object of the Action or Relation - only set once we have a Goal or Action

Adding new Plans for a Goal I have called Expanding.
Scanning a Plan, checking each of its subgoals, I have called Advancing.

]

To advance all goals:
    repeat with G running from 2 to the number of filled rows in the Table of Goals begin;
        advance goal G;
        if an action was planned, change G to 9999;
    end repeat;


[Advancing a Goal: Here we're scanning through each item in the current plan, checking what we've got, and if it's a subgoal, testing if it's true or not. If it's false, then we check if it's unique (ie, not listed as one of our prior goals). This prevents endless recursive loops - we deal with each goal once and only once, regardless of how many parent goals need it. If it's an action, we return that as our choice - this means we pick the first action that we find, ie, the action with the smallest number of goal-expansion steps. This should generally mean we take the shortest path toward getting our way.

To read each Step, we call the 'planning' rulebook, passing the desired relation/object/object and the desired Plan and Step through the 'desired...' global variable block. We increment Step each time. We stop once we don't get a response from the rulebook. This means that plans need to use consecutive Step numbers starting from 1. The rulebook will be hit once for every Step, plus once for counting Steps, of every Plan, plus one more for counting Plans. So if a plan requires expensive calculations, it is a good idea to test that 'desired plan' is set to the plan number before you run the calculation, or you'll be running it lots of times and throwing the result away.

]

To advance goal (G - a number):
    choose row G in the Table of Goals;
    let our parent be the Parent entry;
    let our plan be the Plan entry;
    change the suggested token to the Token entry;
    change the suggested param1 to the Param1 entry;
    change the suggested param2 to the Param2 entry;
    choose row our parent in the Table of Goals;
    let our relation be the Token entry;
    let our param1 be the Param1 entry;
    let our param2 be the Param2 entry;
    let the final step be 0;
    if debugging planner, say "Planner: reading goal [G] (plan [our plan] for goal [our parent])[line break]";
    repeat with Sx running from 1 to 9 begin;
        suggest a goal for our relation with our param1 and our param2 for plan our plan at step Sx;
        if the suggested token is a planning-marker begin;
            change Sx to 9999;
            choose row G in the Table of Goals;
            change the Token entry to no-plan;
            change the Param1 entry to no-object;
            change the Param2 entry to no-object;
        end if;
        if the suggested token is a planning-relation begin;
            if debugging planner, say "Planner: testing step [Sx]: [suggested token] [suggested param1] [suggested param2]: [run paragraph on]";
            if goal suggested token with suggested param1 and suggested param2 is false begin;
                if debugging planner, say "false ";
                if goal the suggested token with the suggested param1 and the suggested param2 is unique begin;
                    if debugging planner, say "and unique, generating plans [run paragraph on]";
                    choose row G in the Table of Goals;
                    change the Token entry to the suggested token;
                    change the Param1 entry to the suggested param1;
                    change the Param2 entry to the suggested param2;
                    change the Step entry to Sx;
                    change the final step to Sx;
                    change Sx to 9999;
                    expand goal G;
                otherwise;
                    if debugging planner, say "but duplicate, cancelling plan[line break]";
                    choose row G in the Table of Goals;
                    change the Token entry to no-plan;
                    change the Param1 entry to no-object;
                    change the Param2 entry to no-object;
                    change the Step entry to Sx;
                    change the final step to Sx;
                    change Sx to 9999;
                end if;
            otherwise;
                if debugging planner, say "true";
            end if;
        end if;
        if the suggested token is a planning-action begin;
            if debugging planner, say "Planner: testing step [Sx]: [the suggested token] [the suggested param1] [the suggested param2]: action[line break]";
            change the planned action to the suggested token;
            change the planned param1 to the suggested param1;
            change the planned param2 to the suggested param2;
            choose row G in the Table of Goals;
            change the Token entry to the suggested token;
            change the Param1 entry to the suggested param1;
            change the Param2 entry to the suggested param2;
            change the Step entry to Sx;
            change the final step to Sx;
            change Sx to 9999;
        end if;
    end repeat;


[Expanding a Goal: Here we are just dropping new empty lines onto the goal table to indicate Plans we have yet to explore. About all the information we need is the Parent and Plan entries. The rest we will look up in the Parent row once we get there.]


To expand goal (G - a number):
    choose row G in the Table of Goals;
    let our relation be the Token entry;
    let our param1 be the Param1 entry;
    let our param2 be the Param2 entry;
    repeat with P running from 1 to 9 begin;
        suggest a goal for our relation with our param1 and our param2 for plan P at step 1;
        if the suggested token is no-plan begin;
            [we've run out of plans]
            change P to 9999;
        otherwise;
            [add new goal, checking for out of space]
            if the number of blank rows in the Table of Goals is greater than 0 begin;
                [add a new goal, as just a parent/plan/step entry]
                let the last row be the number of filled rows in the Table of Goals;
                increase the last row by 1;
                choose row the last row in the Table of Goals;
                change the Parent entry to G;
                change the Plan entry to P;
                change the Step entry to 1;
                change the Token entry to plan-pending;
                change the Param1 entry to no-object;
                change the Param2 entry to no-object;
                if debugging planner, say "[P] [run paragraph on]";
            otherwise;
                if debugging planner, say "Planner: goal table is full, ignoring new goal.";
            end if;
        end if;
    end repeat;
    if debugging planner, say "[line break]";




Section - Rulebooks


[This is where you put rules to generate plans. Sample rules for general situations are defined in 'Basic Plans'. You may need to use procedural rules to override basic rules with more specific ones for your game. IE, if there are particular objects that can only be obtained through solving a puzzle or manipulating a machine, you may need a specific plan for 'being-in' or 'being-touchable' for that object.]

Planning rules is a rulebook.


[This is where you put rules to test goals. Normally this would be a simple check against an I7 relation or property, and does not often need to be overridden.]

Planning-testing rules is a rulebook.


[This is where you put rules to execute actions. Normally this would be a simple call of 'try the planning actor trying .action.'. Then you would create 'report .actor. trying .action.' rules to have custom descriptions of what your particular actor is doing.]

Planning-acting rules is a rulebook.


[If the top-level goal tests as true, a 'success-action' action gets returned and this rulebook gets called. There is no more work for Planner to do, the actor has succeeded in their longest term goal. This might mean an actor needs to change their condition, or a scene change happens.]

Planning-success rules is a rulebook.


[If no action can be suggested toward the top-level goal, a 'no-action' action gets returned and this rulebook gets called. The actor is currently frustrated, blocked or baffled somehow. Generally this indicates that something the author didn't expect happened, and a new plan needs to be written to cover this situation.]

Planning-failure rules is a rulebook.


[If Planner returned an action, but when the actor tried to execute it (usually with 'trying...'), the I7 action failed. (Currently this condition happens if no 'Carry Out' rule ran.) This also generally indicates an incomplete set of plans, or an unexpected situation. ]

Planning-acting-failure rules is a rulebook.




Section - Planning Routines


To suggest a goal for (C - a planning-relation) with (P1 - an object) and (P2 - an object) for plan (P - a number) at step (Sx - a number):
    change the desired relation to C;
    change the desired param1 to P1;
    change the desired param2 to P2;
    change the desired plan to P;
    change the desired step to Sx;
    change the suggested token to no-plan;
    change the suggested param1 to no-object;
    change the suggested param2 to no-object;
    follow the planning rulebook;

To really suggest (T - a planning-token) with (P1 - an object) and (P2 - an object):
    change the suggested token to T;
    change the suggested param1 to P1;
    change the suggested param2 to P2;

To plan (P - a number):
    change the working plan to P;
    change the working step to 0;
    if the desired plan is the working plan, change the suggested token to no-step;

To suggest (T - a planning-token) with (P1 - an object) and (P2 - an object):
    increase the working step by 1;
    if the desired plan is the working plan and the desired step is the working step, really suggest T with P1 and P2;

To suggest (T - a planning-token) with (P1 - an object):
    suggest T with P1 and no-object;

To suggest (T - a planning-token):
    suggest T with no-object and no-object;




Section - Executing Actions


The successful-action rule is listed after the check stage rule in the specific action-processing rules.

This is the successful-action rule:
       if the actor is not the player, change the action success flag to 1.

[Instead of someone trying doing something:
    change the action success flag to 1;
    continue the action.]

To execute the planned action:
    if the planned action is no-action begin;
        follow the planning-failure rules;
    otherwise;
        if the planned action is success-action begin;
            follow the planning-success rules;
        otherwise;
            change the action success flag to 0;
            follow the planning-acting rules;
            if the action success flag is 0, follow the planning-acting-failure rules;
        end if;
    end if;


Section - Utility Routines


To decide whether goal (C - a planning-relation) with (P1 - an object) and (P2 - an object) is unique:
    repeat through the Table of Goals begin;
        if the Token entry is C and the Param1 entry is P1 and the Param2 entry is P2, decide no;
    end repeat;
    decide yes;

To decide whether an action was planned:
    if the planned action is no-action, decide no;
    decide yes;

To decide whether a goal was suggested:
    if the suggested token is a planning-marker, decide no;
    decide yes;

To clear the goal table:
    repeat through the Table of Goals begin;
        blank out the whole row;
    end repeat;

To decide whether goal (C - a planning-relation) with (P1 - an object) and (P2 - an object) is true:
    change the desired relation to C;
    change the desired param1 to P1;
    change the desired param2 to P2;
    consider the planning-testing rules;
    if rule succeeded begin;
        decide yes;
    end if;
    decide no;

To decide whether goal (C - a planning-relation) with (P1 - an object) and (P2 - an object) is false:
    if goal C with P1 and P2 is true, decide no;
    decide yes;



Section - Debugging Verbs

To decide if debugging planner:
    if planner verbosity is 1, decide yes;
    decide no;

Enabling the planner verbosity is an action out of world.
Understand "plans on" as enabling the planner verbosity.
Understand "plans" as enabling the planner verbosity.
Carry out enabling the planner verbosity:
  change the planner verbosity to 1;
Report enabling the planner verbosity:
  say "Planner will now show debugging messages. Type 'plans off' to run silently, or 'plans list' to show the current planning table.";

Disabling the planner verbosity is an action out of world.
Understand "plans off" as disabling the planner verbosity.
Carry out disabling the planner verbosity:
  change the planner verbosity to 0;
Report disabling the planner verbosity:
  say "Planner will now run silently.";


Dumping the planner table is an action out of world.
Understand "plans list" as dumping the planner table.
Carry out dumping the planner table:
    let G be 0;
    repeat through the Table of Goals begin;
        increase G by 1;
        say "Goal [G] (parent [the Parent entry] plan [the Plan entry] step [the Step entry]): [the Token entry] / [the Param1 entry] / [the Param2 entry][line break]";
    end repeat;

Justifying the current goal is an action out of world.
Understand "plans justify" as justifying the current goal.
Carry out justifying the current goal:
  let G be the number of filled rows in the Table of Goals;
  while G is greater than 1 begin;
    choose row G in the Table of Goals;
    say "Goal [G] : [the Token entry] / [the Param1 entry] / [the Param2 entry] to make [line break]";
    let G be the Parent entry;
  end while;
  choose row 1 in the Table of Goals;
  say "Goal 1 : [the Token entry] / [the Param1 entry] / [the Param2 entry][line break]"


Volume 2 - Basic Plans


Section - Relations

Being-in is a planning-relation.

Planning-testing when the desired relation is being-in (this is the basic testing being in rule):
    if the desired param1 is in the desired param2, rule succeeds;
    rule fails;

[Using 'best route' for now. For more complex pathfinding through lockable doorways, we may need to do things the
hard way.]

Planning when the desired relation is being-in and the desired param1 is the planning actor and the desired param2 is a room (this is the basic travel with best route rule):
    plan 1;
    let here be the location of the planning actor;
    let the way be the best route from here to the desired param2;
    let the next room be the room the way from here;
    if the next room is a room, suggest doing-going with the way;
    rule succeeds;


Planning-testing when the desired relation is being-in and the desired param1 is a portable thing and the desired param1 is not a person and the desired param2 is a room (this is the basic dropping objects in rooms rule):
    plan 1;
    suggest being-carried-by with the desired param1 and the planning actor;
    suggest being-in with the planning actor and the desired param2;
    suggest doing-dropping with the desired param1;
    rule succeeds;


Planning when the desired relation is being-in and the desired param1 is a portable thing and the desired param2 is a container (this is the basic putting things in containers rule):
    plan 1;
    suggest being-carried-by with the desired param1 and the planning actor;
    suggest being-open with the desired param2;
    suggest being-touchable-by with the desired param2 and the planning actor;
    suggest doing-putting-in with the desired param1 and the desired param2;
    rule succeeds;



Being-open is a planning-relation.

Planning-testing when the desired relation is being-open (this is the basic testing being open rule):
    if the desired param1 is open, rule succeeds;
    rule fails;

Planning when the desired relation is being-open and the desired param1 is openable (this is the basic opening rule):
    plan 1;
    suggest being-unlocked with the desired param1;
    suggest being-touchable-by with the desired param1 and the planning actor;
    suggest doing-opening with the desired param1;
    rule succeeds;

Being-closed is a planning-relation.

Planning-testing when the desired relation is being-closed (this is the basic testing being closed rule):
    if the desired param1 is closed, rule succeeds;
    rule fails;

Planning when the desired relation is being-closed and the desired param1 is openable (this is the basic closing rule):
    plan 1;
    suggest being-unlocked with the desired param1;
    suggest being-touchable-by with the desired param1 and the planning actor;
    suggest doing-closing with the desired param1;
    rule succeeds;

Being-locked is a planning-relation.

Planning-testing when the desired relation is being-locked (this is the basic testing being locked rule):
    if the desired param1 is not lockable, rule fails;
    if the desired param1 is locked, rule succeeds;
    rule fails;

Planning when the desired relation is being-locked and the desired param1 is lockable (this is the basic locking rule):
    plan 1;
    suggest being-carried-by with the matching key of the desired param1 and the planning actor;
    suggest being-touchable-by with the desired param1 and the planning actor;
    suggest doing-locking-with with the desired param1 and the matching key of the desired param1;
    rule succeeds;


Being-unlocked is a planning-relation.

Planning-testing when the desired relation is being-unlocked (this is the basic being unlocked rule):
    if the desired param1 is not lockable, rule succeeds;
    if the desired param1 is unlocked, rule succeeds;
    rule fails;


Planning when the desired relation is being-unlocked and the desired param1 is lockable (this is the basic unlocking rule):
    plan 1;
    suggest being-carried-by with the matching key of the desired param1 and the planning actor;
    suggest being-touchable-by with the desired param1 and the planning actor;
    suggest doing-unlocking-with with the desired param1 and the matching key of the desired param1;
    rule succeeds;


Section - Finding Objects


Being-visible-by is a planning-relation.

Planning-testing when the desired relation is being-visible-by (this is the basic being visible rule):
    if the desired param2 can see the desired param1, rule succeeds;
    rule fails;

Planning when the desired relation is being-visible-by (this is the basic finding visibility rule):
    plan 1;
    suggest being-touchable-by with the desired param1 and the desired param2;
    rule succeeds;


Being-touchable-by is a planning-relation.

Planning-testing when the desired relation is being-touchable-by (this is the basic being touchable rule):
    if the desired param1 carries the desired param2, rule succeeds;
    if the desired param2 cannot touch the desired param1, rule fails;
    if a person encloses the desired param1, rule fails;
    rule succeeds;

[If it's loose in a room, go to it.]

Planning when the desired relation is being-touchable-by and the holder of the desired param1 is a room (this is the basic touching loose objects rule) :
    plan 1;
    suggest being-in with the desired param2 and the holder of the desired param1;
    rule succeeds;

[For containers and supporters, find the outermost one. Make sure containers are open. In case the triggering
mechanism of a container is elsewhere or requires finding a key, require it open before finding it - the standard
openability plans will require touchability anyway.]

Planning when the desired relation is being-touchable-by and the holder of the desired param1 is a container (this is the basic touching contained objects rule):
    plan 1;
    suggest being-open with the holder of the desired param1;
    suggest being-touchable-by with the holder of the desired param1 and the desired param2;
    rule succeeds;

Planning when the desired relation is being-touchable-by and the desired param1 is a thing and the holder of the desired param1 is a supporter (this is the basic touching supported objects rule):
    plan 1;
    suggest being-touchable-by with the holder of the desired param1 and the desired param2;
    rule succeeds;

[There's always two sides to a door, so we have to run two parallel plans. Whichever side is reachable and closest
will be the one we go to.]

Planning when the desired relation is being-touchable-by and the desired param1 is a door (this is the basic touching doors rule):
    plan 1;
    suggest being-in with the desired param2 and the front side of the desired param1;
    plan 2;
    suggest being-in with the desired param2 and the back side of the desired param1;
    rule succeeds;

[For now we'll treat visibility like touchability, since a touchable thing is always visible.]


Being-carried-by is a planning-relation.

Planning-testing when the desired relation is being-carried-by (this is the basic being carried rule):
    if the desired param2 carries the desired param1, rule succeeds;
    rule fails;

Planning when the desired relation is being-carried-by and the desired param1 is portable and the desired param2 is the planning actor (this is the basic carrying rule):
    plan 1;
    suggest being-touchable-by with the desired param1 and the planning actor;
    suggest doing-taking with the desired param1;
    rule succeeds;

Being-worn-by is a planning-relation.

Planning-testing when the desired relation is being-worn-by (this is the basic being worn rule):
    if the desired param2 wears the desired param1, rule succeeds;
    rule fails;

Planning when the desired relation is being-worn-by and the desired param2 is the planning actor (this is the basic wearability rule):
    plan 1;
    suggest being-carried-by with the desired param1 and the planning actor;
    suggest doing-wearing with the desired param1;
    rule succeeds;

Being-not-worn-by is a planning-relation.

Planning-testing when the desired relation is being-not-worn-by:
    if the desired param1 is worn by the desired param2, rule fails;
    rule succeeds;

Planning when the desired relation is being-not-worn-by and the desired param2 is the planning actor:
    plan 1;
    suggest doing-taking-off with the desired param1;


Section - Actions


Doing-going is a planning-action.

Planning-acting when the planned action is doing-going (this is the basic executing going rule):
    try the planning actor trying going the planned param1;


Doing-opening is a planning-action.

Planning-acting when the planned action is doing-opening (this is the basic executing opening rule):
    try the planning actor trying opening the planned param1;


Doing-closing is a planning-action.

Planning-acting when the planned action is doing-closing (this is the basic executing closing rule):
    try the planning actor trying closing the planned param1;


Doing-taking is a planning-action.

Planning-acting when the planned action is doing-taking (this is the basic executing taking rule):
    try the planning actor trying taking the planned param1;


Doing-dropping is a planning-action.

Planning-acting when the planned action is doing-dropping (this is the basic executing dropping rule):
    try the planning actor trying dropping the planned param1;

Doing-putting-in is a planning-action.

Planning-acting when the planned action is doing-putting-in (this is the basic executing inserting rule):
    try the planning actor trying inserting the planned param1 into the planned param2;

Doing-locking-with is a planning-action.

Planning-acting when the planned action is doing-locking-with (this is the basic executing locking rule):
    try the planning actor trying locking the planned param1 with the planned param2;


Doing-unlocking-with is a planning-action.

Planning-acting when the planned action is doing-unlocking-with (this is the basic executing unlocking rule):
    try the planning actor trying unlocking the planned param1 with the planned param2;


Doing-wearing is a planning-action.

Planning-acting when the planned action is doing-wearing (this is the basic executing wearing rule):
    try the planning actor trying wearing the planned param1;


Doing-taking-off is a planning-action.

Planning-acting when the planned action is doing-wearing (this is the basic executing taking off rule):
    try the planning actor trying taking off the planned param1;


Volume 3 - Game

Section - Setup


Echoing command is a truth state that varies. Echoing command is true.

Setting command echo on is an action out of world applying to nothing.
Understand "echo on" as setting command echo on.
Carry out setting command echo on: now echoing command is true.
Report setting command echo on: say "[bracket]Command echo is now on. Inform commands will now display >like this.[close bracket]".

Setting command echo off is an action out of world applying to nothing.
Understand "echo off" as setting command echo off.
Carry out setting command echo off: now echoing command is false.
Report setting command echo off: say "[bracket]Command echo is now off. Presumably you have a MUD client which displays your typed lines.[close bracket]".

After reading a command: if echoing command is true, say ">[the player's command]".


Player joining:
  say "Welcome to Boxworld. This is a demonstration and testbed for Planner. Now compiled for 5Z71. Realtime support is now turned on, at the moment this means that the tracing verbs PLANS ON/OFF do not work, which is probably no great loss, but PLANS LIST (dump the plan table) and PLANS JUSTIFY (show the reasoning behind the currently chosen action) do. ECHO ON/OFF toggles Zork-like command echo.";

Player joining:
  if exactly one PC is connected, request real-time events every 10 seconds.

Player leaving:
  if exactly one PC is connected, stop real-time events.


Section - World

The Factory is a room. The description of the Factory is "A pristine factory floor with gleaming robotics hardware all around. A ramp leads east and another south. A roller door labelled 'Fairhaven' is open in the west wall."

Before going west in the Factory:
  say "You close the book, your research complete.";
  send the player to "Fairhaven";
  stop the action.

The Library is east of the Factory. The description of the Library is "Walls are stacked floor-to-ceiling with shiny data cassettes."

A metal table is a supporter in the Library.

A plastic bench is a supporter in the factory. "A plastic bench, in glowing Moonbase Retro, fills half of the room."

A bucket is an open container on the plastic bench.

A storage unit is a closed openable container in the factory. "A gleaming storage unit quietly blends into the corner."

A plastic bag is a closed transparent portable openable container on the metal table.

A Chinese puzzle box is a locked lockable closed openable portable container in the plastic bag.

A pinch of ginger is a portable thing in the puzzle box.

A wicker basket is an open container in the storage unit.

An onion, a tomato, a stick of celery, a lemon and a banana are in the wicker basket.

Nanites is a thing.

Procedural rule when the desired relation is being-in and the desired param1 is nanites and the desired param2 is the bucket:
    ignore the basic putting things in containers rule;

Planning when the desired relation is being-in and the desired param1 is nanites and the desired param2 is the bucket:
    plan 1;
    suggest being-in with the onion and the bucket;
    suggest being-in with the celery and the bucket;
    suggest being-in with the banana and the bucket;
    suggest being-in with the ginger and the bucket;

To decide whether soup is brewing:
    if the onion is not in the bucket, decide no;
    if the celery is not in the bucket, decide no;
    if the banana is not in the bucket, decide no;
    if the ginger is not in the bucket, decide no;
    decide yes;


Real-time event when soup is brewing:
    tell "SCIENCE occurs." to everyone who can see the bucket;
    repeat with item running through things in the bucket begin;
        remove item from play;
    end repeat;
    now nanites is in the bucket;

The Alcove is a room.

The Alcove is south of the factory. The description of the Alcove is "A tiny niche lasered out of asteroid rock, which opens out to the north."

A brass hook is a supporter in the Alcove. "Screwed into the stonework with grim determination is a shiny brass hook." The brass hook has carrying capacity 1.

A silver key is on the brass hook. The matching key of the Chinese puzzle box is the silver key.



Bob is a person in the factory. "The robot Bob potters around his domain."

Procedural rule when the desired relation is being-in and the desired param1 is a person:
    ignore the basic dropping objects in rooms rule;

Real-time event:
    have Bob plan an action for being-in with nanites and the bucket;



Section - Custom Actions

Doing-asking-for is a planning-action.

Planning-acting when the planned action is doing-asking-for:
    try the planning actor trying asking the planned param1 for the planned param2;

Planning rule when the desired relation is being-touchable-by and the desired param2 is the planning actor and a person (called the owner) encloses the desired param1:
    plan 1;
    suggest being-touchable-by with the owner and the planning actor;
    suggest doing-asking-for with the owner and the desired param1;


[Allow giving objects to actors.]

The block giving rule is not listed in any rulebook.


Section - Custom Messages

Instead of Bob trying asking a PC for something:
  change the action success flag to 1;
  tell "Bob says: 'Request: actor: [the noun]: provide object: [the second noun].'" to everyone who can see Bob;

Planning-failure:
  tell "Bob says: 'Error: no known action Malfunction! Malfunction!'" to everyone who can see Bob;

Planning-success:
  end the game saying "Experiment complete";

Planning-acting-failure:
  tell "'Bob says: 'Error: unexpected response to action. Danger! Danger! My arms are flailing wildly!'" to everyone who can see Bob;

Report Bob trying opening the storage unit :
  tell "Bob opens the storage unit, revealing [a list of things in the storage unit]." to everyone who can see Bob;
  stop the action;