This looks good, thanks! I’ll experiment and report back.
1 Like
Seems to me like an action-based rulebook producing a number would be a handy way to express these things. Trouble is, action-based rulebooks act on the current action, not a stored action. But if we stow the current action variables and replace them when we’re done…
lab is a room.
box is a container in lab.
tray is a portable supporter in lab.
the player holds the duck.
Definition: a thing is droppable rather than undroppable if the player carries it.
to stash the/-- current action variables: (- @push act_requester; @push action; @push noun; @push second; @push self; @push multiple_object_item; -).
to restore the/-- current action variables: (- @pull multiple_object_item; @pull self; @pull second; @pull noun; @pull action; @pull act_requester; -).
Definition: a thing is takeable rather than untakeable:
if it is carried or it is the player, no;
if it is portable and it is touchable, yes;
no.
The current action name is an action name that varies.
The current action name variable translates into Inter as "action".
A linkable-action is a kind of thing.
A linkable-action has an action name called act.
A linkable-action has a text called label.
A linkable-action has a text called command.
Some linkable-actions are defined by the table of linkable actions.
Table of linkable actions
linkable-action act label command
taking-link taking action "take it" "take"
dropping-link dropping action "drop it" "drop"
link-score is a rulebook producing a number.
[ for each action name, have a `first` rule returning 0 if it doesn't meet criterion ]
first link-score taking an untakeable thing: rule succeeds with result 0.
link-score taking the tray: rule succeeds with result 50.
link-score taking: rule succeeds with result 10. [generic, recapitulates "priority"]
first link-score dropping an undroppable thing: rule succeeds with result 0.
link-score dropping: rule succeeds with result 10.
last link-score: rule succeeds with result 0.
table of commandbar scores
consideration (linkable-action) score (number)
with 10 blank rows.
link-limit is always 4.
when play begins:
stash the current action variables;
repeat with t running through visible things begin;
repeat with this-action running through linkable-actions begin;
now the noun is t;
now the second noun is nothing;
now the current action name is the act of this-action;
let result be the number produced by link-score;
if result is 0, next;
choose a blank row in the table of commandbar scores;
now consideration entry is this-action;
now score entry is result;
end repeat;
let count be the number of filled rows in the table of commandbar scores;
if count > 0 begin;
say "for [t]:[line break]";
sort table of commandbar scores in reverse score order;
if count > link-limit, now count is link-limit;
repeat with j running from 1 to count begin;
choose row j in table of commandbar scores;
say "[label of consideration entry] -> [command of consideration entry] [t] (score: [score entry]) [line break]";
end repeat;
blank out the whole of table of commandbar scores;
end if;
end repeat;
restore the current action variables;
I wanted to store the results in the table of commandbar scores, per my suggestion above. But if we were looping through a table of linkable actions, we couldn’t work with a second table within that loop, so I do create linkable-action as a kind of object. But we can stall use a table to quickly define a bunch of linkable-actions. We then loop through the linkable-action objects themselves, not through the table.
It’s a toss-up whether to implement criteria as first rules as I did above or to make them another property on linkable-actions as we’d been discussing above.
This is pretty neat!
A question, so far as setting the score in a rulebook, I see the benefit of changing these scores on the fly. This seems more elegant than having a table entry. However, I have wondered about authors visualizing all of this stuff, and while we could have a debug command that prints through every object and score/priority, seeing table contents while coding might be easier.
Not that I have a hard line on this! The current state of my project includes a hyperobject has a number called priority.
I only had a vague idea of what your initial suggestion might look like, so it’s very helpful to see it fleshed out. Thank you!
Having spent a bit of time with this, it works well! I’m still wrapping my head around the construction, but I think I’ll get there. This allows me to get here:
to decide if ( h - a hyperobject ) is relevant to ( t - a thing ):
if the criterion of h applied to t is true:
decide yes;
What I would really like to do is something like:
A possibility is a kind of concept.
A possibility has a description of things called the criterion.
The verb to apply to means the criterion property.
Applicability relates a possibility (called X) to a thing (called Y) when Y matches the criterion of X.
The verb to be applicable to means the applicability relation.
Ranking is a possibility-based rulebook producing a number.
The object being considered is a thing that varies.
Which doesn’t currently work because of problems with descriptions in object properties. But then you could write the taking option is a possibility that applies to portable things and the list of possibilities that are applicable to the current focus and ranking the taking option when the object being considered is a treasure: decide on 50 and so on.
concept is an Inform 11 thing, isn’t it? Are concepts objects? Or something else?
In current development Inform, what will be Inform 11, there’s an abstract object kind that is, itself, a kind of object. concept is a specific subkind of abstract object that’s used in the dialogue system. So abstract object is probably ideal as the parent kind for possibility. (Is it meaningfully distinct from just making it a subkind of object? Not really… but it provides a little emphasis on the idea of “doesn’t correspond to something tangible in the setting”.)
I just created I7-2700: Compiler accepts creating a property of kind description of <values> but balks at assigning to it for this, but I’m not sure if it addresses the whole scope of the problems you’re thinking of, @Draconis. If you have a chance, could you please review it and comment?
2 Likes
Commented! I’m pretty sure this is an issue with the source text parser, not with the compiler, because assigning the property at runtime works fine. It’s just not very elegant, and the reason to use descriptions is for natural-language elegance.
2 Likes
In particular, for those not following the Jira tracker, this works fine:
A possibility is a kind of object.
A possibility has a description of things called the criterion.
Foo is a possibility.
To assign (D - description of things):
now the criterion of foo is D.
When play begins: assign portable things.
3 Likes