The proper programming model for IF
Default User
interesting I thought I'd extract it and give it its own due.
Andrew Plotkin wrote:
> Here, ChicagoDave <david.c...@gmail.com> wrote:
> > Isn't that part of the problem though? IF isn't really OO. It's a
> > batardization of OO for the specific intent of developing IF games.
>
> Isn't what part of the problem?
>
> (My feeling is that OO was never the right model for handling IF, but
> that's a different discussion.)
I guess I'm a bit surprised to hear that, as it seems to me that IF is
the sort of problem that almost cries out for an OO approach. What
would be a better programming model for IF?
I've done a game in C, which wasn't OO really at all, other than
structs for rooms, but in later years I was never really that satisfied
with the overall programming model.
Brian
--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)
Andrew Plotkin
> This came from a different thread, and as it was something I found
> interesting I thought I'd extract it and give it its own due.
>
> Andrew Plotkin wrote:
>
> > Here, ChicagoDave <david.c...@gmail.com> wrote:
> > > Isn't that part of the problem though? IF isn't really OO. It's a
> > > batardization of OO for the specific intent of developing IF games.
> >
> > Isn't what part of the problem?
> >
> > (My feeling is that OO was never the right model for handling IF, but
> > that's a different discussion.)
>
> I guess I'm a bit surprised to hear that, as it seems to me that IF is
> the sort of problem that almost cries out for an OO approach. What
> would be a better programming model for IF?
It turns out that not only is it a different discussion, it's an old
one. :) Rather than repeat myself, I shall point you at my post from
last June:
<http://groups.google.com/group/rec.arts.int-fiction/msg/e3c8050014911b45>
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.
Chris Pickett
> >
> > I guess I'm a bit surprised to hear that, as it seems to me that IF is
> > the sort of problem that almost cries out for an OO approach. What
> > would be a better programming model for IF?
>
> It turns out that not only is it a different discussion, it's an old
> one. :) Rather than repeat myself, I shall point you at my post from
> last June:
>
> <http://groups.google.com/group/rec.arts.int-fiction/msg/e3c8050014911b45>
Hey, what do you think of AIFT? Yeah, it's pretty simple, but is it a
good basis for something?
Chris
Samwyse
> Here, Default User <defaul...@yahoo.com> wrote:
>>I guess I'm a bit surprised to hear that, as it seems to me that IF is
>>the sort of problem that almost cries out for an OO approach. What
>>would be a better programming model for IF?
> It turns out that not only is it a different discussion, it's an old
> one. :) Rather than repeat myself, I shall point you at my post from
> last June:
> Conclusion: a next-stage IF system requires the ability to treat all
> conditional customizations as first-class objects, with direct control
> over how conflicts resolve. "Object orientation" just isn't a useful
> model, because the problem involves sets of predicates, not single
> objects.
I just want to point out that treating all conditional customizations as
first-class objects does tend to imply an OO approach, just not one that
existing languages are well able to handle.
Chris Pickett
> Andrew Plotkin wrote:
>
> > Conclusion: a next-stage IF system requires the ability to treat all
> > conditional customizations as first-class objects, with direct control
> > over how conflicts resolve. "Object orientation" just isn't a useful
> > model, because the problem involves sets of predicates, not single
> > objects.
>
> I just want to point out that treating all conditional customizations as
> first-class objects does tend to imply an OO approach, just not one that
> existing languages are well able to handle.
Why OO and not, say, functional?
Chris
samwyse
> Samwyse wrote:
> > I just want to point out that treating all conditional customizations as
> > first-class objects does tend to imply an OO approach, just not one that
> > existing languages are well able to handle.
>
> Why OO and not, say, functional?
Because IF is all about the side-effects?
Zarf pointed out elsewhere in his post that TADS-3 models things
slightly better than Inform, via verify() and check() methods, which I
expect is the better way to go. Things are easier to analyze as they
become more data-like and less code-like. So, verify() and check()
become more useful as they become more like Prolog predicates and
therefore more "functional". Unfortunately, the actual action routines
are more intractable; I can't see them easily becoming less code-like.
Customizations are the worst because they break the boundries. You can
go through the library and catagorize all of the actions into groups
like "sensory", "internal-state-changers" and "world-tree rearrangers",
however much of the fun of IF arises from authors inventing new actions
and changing existing actions to break those categories.
Andrew Plotkin
> Chris Pickett wrote:
> > Samwyse wrote:
>
> > > I just want to point out that treating all conditional customizations as
> > > first-class objects does tend to imply an OO approach, just not one that
> > > existing languages are well able to handle.
> >
> > Why OO and not, say, functional?
>
> Because IF is all about the side-effects?
>
> Zarf pointed out elsewhere in his post that TADS-3 models things
> slightly better than Inform, via verify() and check() methods, which I
> expect is the better way to go.
Only in the sense that two fixed levels is better than one fixed
level. Both are static approximations of what I want.
I don't believe that saying something is a "first-class object" implies
an OO approach. The point of functional languages is to treat
functions and closures as first-class objects. If you want to call
that "OO", then you've watered the term down to uselessness.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation,
it's for one reason: they don't feel like it. Not because you're patriotic.
samwyse
Andrew Plotkin wrote:
> Here, samwyse <sam...@gmail.com> wrote:
> > Zarf pointed out elsewhere in his post that TADS-3 models things
> > slightly better than Inform, via verify() and check() methods, which I
> > expect is the better way to go.
>
> Only in the sense that two fixed levels is better than one fixed
> level. Both are static approximations of what I want.
At the risk of being pointed to archived JPEGs of blackboard
scribblings, what exactly are you looking for in your calculus?
> I don't believe that saying something is a "first-class object" implies
> an OO approach. The point of functional languages is to treat
> functions and closures as first-class objects. If you want to call
> that "OO", then you've watered the term down to uselessness.
I don't view the two as competing descriptions. Functional programming
sort-of predates OOP. (Yes, I know LISP had OOP fifty years ago and FP
derives from LISP, but FP initally concerned itself with proving
correctness and in the early years was much more about simple
mathematical functions such as you'd write in FORTRAN 77.) Inform
adopted OOP for "nouns" to IMHO great success even though there are
only two places that you need it: "Mass" objects (money, sand and
water, where dynamic creation/destruction is useful) and objects with
shared behavior (Rooms, Props and NPCs, where a templating mechanism is
worth the extraneous class object that gets created).
However, Inform doesn't use OOP for actions, which causes a lot of
difficulties. TADS does, but I believe that its model leaves a lot to
be desired. If/when someone develops a good model for actions, then
functional programming can be added to the mix and implementing things
like HELP BOB OPEN THE BOX or THREATEN TO KILL THE HOSTAGE will be
trivial.
ChicagoDave
any current programming platform/syntax/compiler/library and implement
something resembling an IF system.
But what are the requirements? How can we be sure that we have the
right tool if we don't even all agree on the requirements of an IF
system?
I say as a community we should try to define a detailed requirements
document and _then_ have the "which tool" discussion.
David C.
samwyse
> I still think this is putting the cart before the horse. You can pick
> any current programming platform/syntax/compiler/library and implement
> something resembling an IF system.
>
> But what are the requirements? How can we be sure that we have the
> right tool if we don't even all agree on the requirements of an IF
> system?
The best way to determine the requirements is, unfortunately, to
implement a system, then implement several games, and finally see where
the shortcomings are to be found. Here's my take on where we've been.
In the beginning was the Adventure era, with objects and actions that
could be combined via the classic two-wod parser. TAKE KEY. OPEN DOOR.
Next came the ZORK era, where actions accepted multiple nouns: TAKE
ALL. OPEN DOOR WITH KEY.
NPCs were around since the beginning, but only later in Suspect did the
concept of talking to them appear. Still this was just an extension of
the preceeding. ASK BOB ABOUT THE VICTIM.
Then came the first "functional operator", a way to take any existing
command and modify it into something subtly different. BOB, OPEN DOOR
WITH KEY.
The last three step all occured during the Infocom era, which was
followed by a long period of experimentation. Much literary progress
was made, but little technical progress. Inform and TADS introduced
classes to better organize objects. TADS started to make actions into
full-fledged objects.
Some work has been done with goal-seeking agents, but nothing so
impressive that it's been added to any base IF system. I've done a
little research into additional functional operators (ASK BOB TO DO
SOMETHING, HELP BOB TO DO SOMETHING, THREATEN TO DO SOMETHING), but
just enough to conclude that they require a massive rewrite of the
Inform library. AFAIK, no one's looked (much) at applying goal-seeking
to the player (GO BACK TO THE CAVE ENTRANCE). Erasmatron has carefully
mapped some dead-ends; the jury is still out on Facade. Today, IF
command stuctures mirror imperative CLI commands; point-and-click games
mirror drag-and-drop GUI commands. What would a work of IF look like
if it were based on a search-engine model? Would conversational NPCs
seem more realistic with a game-specific copy of Wikipedia backing them
up?
What do the rest of you think?
Mark J. Tilford
>
>
> ChicagoDave wrote:
>> I still think this is putting the cart before the horse. You can pick
>> any current programming platform/syntax/compiler/library and implement
>> something resembling an IF system.
>>
>> But what are the requirements? How can we be sure that we have the
>> right tool if we don't even all agree on the requirements of an IF
>> system?
>
> The best way to determine the requirements is, unfortunately, to
> implement a system, then implement several games, and finally see where
> the shortcomings are to be found. Here's my take on where we've been.
>
> In the beginning was the Adventure era, with objects and actions that
> could be combined via the classic two-wod parser. TAKE KEY. OPEN DOOR.
>
> Next came the ZORK era, where actions accepted multiple nouns: TAKE
> ALL. OPEN DOOR WITH KEY.
>
> NPCs were around since the beginning, but only later in Suspect did the
> concept of talking to them appear. Still this was just an extension of
> the preceeding. ASK BOB ABOUT THE VICTIM.
>
> Then came the first "functional operator", a way to take any existing
> command and modify it into something subtly different. BOB, OPEN DOOR
> WITH KEY.
wrt these last two points, there's the robot near the Alice section of
Dungeon / Zork II.
> The last three step all occured during the Infocom era, which was
> followed by a long period of experimentation. Much literary progress
> was made, but little technical progress. Inform and TADS introduced
> classes to better organize objects. TADS started to make actions into
> full-fledged objects.
>
> Some work has been done with goal-seeking agents, but nothing so
> impressive that it's been added to any base IF system. I've done a
> little research into additional functional operators (ASK BOB TO DO
> SOMETHING, HELP BOB TO DO SOMETHING, THREATEN TO DO SOMETHING), but
> just enough to conclude that they require a massive rewrite of the
> Inform library. AFAIK, no one's looked (much) at applying goal-seeking
> to the player (GO BACK TO THE CAVE ENTRANCE). Erasmatron has carefully
> mapped some dead-ends; the jury is still out on Facade. Today, IF
> command stuctures mirror imperative CLI commands; point-and-click games
> mirror drag-and-drop GUI commands. What would a work of IF look like
> if it were based on a search-engine model? Would conversational NPCs
> seem more realistic with a game-specific copy of Wikipedia backing them
> up?
>
> What do the rest of you think?
>
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
ChicagoDave
constructed with a set of goals cannot be implemented properly. Now I
agree that you can't think of everything and
there will be portions that need to be refactored along the way, but
it's my belief that we have never sat down and examined the
communication aspects of IF as well as we should before implementing a
system.
Of course there are different roads you can travel. It seems Facade and
Erasmatron tried to get into the emotional interpretations of
conversations, but I'm not sure I'm interested in that road. I'm more
interested in the straight linguistic aspect of IF. Any emotional
aspects should be something offered by the author.
But that leaves an enormous opportunity to redefine how lingusitics
(cross/language) can be implemented and a more complex command
structure developed. I'd be curious to see a discussion on how to
separate the language input from the command interpretation. Inform
does this to some degree, but it would be interesting to see this be
the foundation of an IF system.
The first phase of design would be to define a language parser that
could be mapped to command structures, but leaving the mapping as an
abstract interface.
David C.
Andrew Plotkin
> I appreciate the history, but I don't buy for a second that a system
> constructed with a set of goals cannot be implemented properly. Now I
> agree that you can't think of everything and
> there will be portions that need to be refactored along the way, but
> it's my belief that we have never sat down and examined the
> communication aspects of IF as well as we should before implementing a
> system.
This discussion has gone at cross purposes. When I talk about what I
want in an IF system, I am talking about a system that will solve *the
problems that I have* when I write IF. You want to design a new kind
of game, based on a new communications model, go ahead. That's a
different problem, and once you know what it is, you'll have to go
through three generations of tools to solve it right -- just like
current IF.
I'm interested in looking at the tools I'm using, figuring out what
they do, and making a tool that does that cleanly and easily. As
opposed to the poorly-thought-out ("Object oriented code is the best
representation for everything!") tools I have now.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Just because you vote for the Republicans, doesn't mean they let you be one.
Samwyse
> When I talk about what I
> want in an IF system, I am talking about a system that will solve *the
> problems that I have* when I write IF. You want to design a new kind
> of game, based on a new communications model, go ahead. That's a
> different problem, and once you know what it is, you'll have to go
> through three generations of tools to solve it right -- just like
> current IF.
Ditto, except for one minor change below.
> I'm interested in looking at the tools I'm using, figuring out what
> they do, and making a tool that does that cleanly and easily. As
> opposed to the poorly-thought-out ("Object oriented code is the best
> representation for everything!") tools I have now.
Whereas I'm interested in looking at the tools I'm using and making a
tool that does what I want cleanly and easily. As opposed to the
poorly-thought-out ("Object oriented code still isn't used as the
representation for everything!") tools I have now.
P.S. Al has just today reminded me of how much I love MassNoun. I
still haven't found a use for it, but it's a great to have that
particular arrow in the quiver.
ChicagoDave
on the current designs of these IF tools. I believe that if we attacked
an IF system as we would any other software engineering, and not in a
vacuum, we might come up with a modular, easily expanded, and easily
tooled platform.
If people keep going off to their hidey holes and building IF tools in
secret, we end up with a singular vision. I respect that there are a
few people that can develop broadly acceptable toolsets, but the fact
remains that without a more open development and without a well thought
out design, the resulting IF tools are going to have the same exact
problems that any current toolset has. Most will be okay with it, but
some will want to change it. And if they can't change it in a way
that's elegant, they will start complaining that we need a new IF
system and the whole conversation will start over.
I'm not interested in as you say a new conversation model. That's just
one design point. I'm interested in openly designing an IF system based
on requirements.
David C.
Chris Pickett
I think some language-agnostic reusable components would be really
neat. It would reduce the overhead in experimenting with new designs.
Besides, if they are small things, more people are likely to agree that
they are needed. This is really the best thing that modularity gets
you, IMO.
For example, an English parser that everybody could "just use" to get
canonical forms of commands. Start with two words as a target. Yes,
the parsing problem has been discussed to death in years past, but
doesn't that mean it should be a standard thing by now... and I for one
would definitely have an immediate use for such a thing.
I'm sure there are other reusable elements out there... things that
might not even occur to you if you look at current toolkits. Again,
just as an example, maybe NPCs could be separate players manipulating
the same narrative with commands... and thus be implemented using an
external AI module as a basis.
As for the core language, I think of it as "just another module", and
(IMHO) it should just be enough to support a cycle of prompt, user
input, internal processing, output. Even the concepts of rooms and
objects should go in a library written in the language. This might
help lift certain thinking patterns, e.g. that IF should consist of
moving objects between rooms. And it might make it easier to try out
new languages, because your problem is now, "How can I implement the
libraries of this other language in my own new language?" instead of
"what IF-specific features should my language support?.
Then there's the whole discussion of internationalization -- maybe it
now seems more reasonable to have an external system if the goal is to
provide greater flexibility in toolkit design.
And finally, there could be greater use of existing tools. Sure, Java
may not be everyone's cup of tea, but things like SDL can be nice for
games, and flex+bison, SableCC, and antlr are much better than trying
to write a parser by hand.
But, the actual outcome of this discussion seems likely to be that
there was a discussion. So hopefully someone just picks a small
isolated piece and starts working on it...
Chris
Kevin Forchione
news:dqsn8m$a55$1...@reader2.panix.com...
> Here, ChicagoDave <david.c...@gmail.com> wrote:
>> I appreciate the history, but I don't buy for a second that a system
>> constructed with a set of goals cannot be implemented properly. Now I
>> agree that you can't think of everything and
>> there will be portions that need to be refactored along the way, but
>> it's my belief that we have never sat down and examined the
>> communication aspects of IF as well as we should before implementing a
>> system.
>
> This discussion has gone at cross purposes. When I talk about what I
> want in an IF system, I am talking about a system that will solve *the
> problems that I have* when I write IF. You want to design a new kind
> of game, based on a new communications model, go ahead. That's a
> different problem, and once you know what it is, you'll have to go
> through three generations of tools to solve it right -- just like
> current IF.
>
> I'm interested in looking at the tools I'm using, figuring out what
> they do, and making a tool that does that cleanly and easily. As
> opposed to the poorly-thought-out ("Object oriented code is the best
> representation for everything!") tools I have now.
What aspects of representation does OO not model well for IF, and what kind
of model would suit those aspects better?
--Kevin
Mike Roberts
> If people keep going off to their hidey holes and building IF
> tools in secret, we end up with a singular vision.
I assume you're not talking about tads 3 here, as it's actually had a rather
open and non-secret development process - a small but open and active
community has been involved in that for the last several years. It might
still represent a singular vision to some extent - any community certainly
self-selects for people whose interests are reasonably well aligned - but I
certainly wouldn't have come up with half of the ideas in the system on my
own.
> I respect that there are a few people that can develop broadly
> acceptable toolsets, but the fact remains that without a more
> open development and without a well thought out design,
> the resulting IF tools are going to have the same exact
> problems that any current toolset has.
I have two quibbles with that. First, there's no reason to think that more
one-man-show tools would yield the *exact* same problems the current
toolsets have - I mean, you can hardly argue that the existing toolsets
themselves all have exactly the same sets of flaws. (The sets overlap, yes,
but they're not identical.) Any new tool is likely to solve some of the
current tools' problems and invent a bunch of new ones, no matter what its
development process. Any bold new approach is even likely to reinvent a
bunch of the problems the existing tools have already solved, since the
existing tools are double or triple refinements of earlier tools based on
their same approaches.
Second, it's not clear to me that this community is large enough for a more
open development process to make much of a difference in actual practice.
For one thing I'm just not sure the constituency for any particular bold new
approach is large enough that an open process will differ substantively from
the standard SHH ("secret hidey-hole") process. For another, it's not clear
that the community has enough system programmer types to make actual
development collaboration happen, so again, the actual process will probably
look a lot like SHH, with one guy doing the programming and a dozen or two
collaborating on the design. For yet another, experience here has been that
the only way to get a project off the ground is to stop talking about it and
go do it, which is probably why SHH is so typical around here.
--Mike
mjr underscore at hotmail dot com
Mike Roberts
> Here, samwyse <sam...@gmail.com> wrote:
>> Chris Pickett wrote:
>> Zarf pointed out elsewhere in his post that TADS-3 models
>> things slightly better than Inform, via verify() and check()
>> methods, which I expect is the better way to go.
>
> Only in the sense that two fixed levels is better than one fixed
> level. Both are static approximations of what I want.
Let me just clarify what's going on with the tads3 phases, for those not
familiar with the model. It's not quite what Zarf is thinking of in terms
of phases, but it's a step in that direction.
Tads2 has two phases - "verify" and "do". The reason to separate them was
an observation I made early on in the design, about a common motif in
writing the parser and writing verb handlers. Let's start with an exmaple:
suppose you were to write a simple, straight-line, non-OO verb handler for
OPEN. It would go something like this:
if object is not an openable sort of object
stop with error "That's not something you can open.";
if object is already open
stop with error "The door is already open!"
set object state to "open"
say "Okay, <the object> is now open."
Now suppose you were to write the part of the parser that tries to decide
which object to choose for an OPEN command, when there are multiple objects
around matching the vocabulary words (say, "OPEN DOOR" when there's a GREEN
DOOR that's already open, a RED DOOR that's currently closed, and a DOOR
BELL):
if object is not an openable sort of object
mark it as "very unlikely"
if object is already open
mark it as "pretty unlikely"
otherwise
mark it as "likely"
My observation was that the first couple of conditions look the same in the
verb handler and in the parser object chooser. I further observed that the
verb handler tends to print error messages on the branches corresponding to
the various "unlikely" branches in the object chooser. So, I decided I'd
pull that part out and call if the "verify" phase, and to save work you'd
just have to write it once, the first way - as in the object handler. The
rest would be the "do" handler. At execution time, to carry out the
command, the system would first call the "verify" code, then the "do" phase.
In addition, when the parser wanted to choose from a set of ambiguous
objects, it would just call the "verify" phase - and it would hide all the
output, but note whether or not output was attempted. If any output
occurred in this mode, the object chooser would mark that object as
"unlikely"; if no output occurred, it would mark it as "likely".
Tads3 takes almost the same approach, but it restores the "very" vs "pretty"
levels of unlikeliness (plus several more) that went missing in the tads2
model. Because of the weird hidden-output-equals-unlikely model in tads2,
there are only two possible levels of likeliness ("likely" and "unlikely"),
but in practice you really do want "very" and "pretty" and others. Tads3
restores the extra information without any big change in the overall model.
You still write a single "verify" handler, but now you add the likelihood
information alongside the error message:
if object is not an openable sort of object
stop with error level "very unlikely" message "That's
not something you can open.";
(The actual tads3 code is a bit more syntactically convenient, and of course
the messages are fully externalizable for internationalization purposes. An
actual example would look like this:
if (isOpen)
illogicalAlready(&alreadyOpenMsg);
)
Tads3 also adds two new phases: "preconditions," which specifies a set of
conditions (like "must be open first" or "must be reachable") that must
exist *and* which the system can attempt to bring about automatically via
implied sub-actions; and "check," which is to enforce any additional ad hoc
conditions. So tads3 really has four fixed phases.
Tads3's separation of the "check" phase from the "action" phase is the thing
that's most along the lines Zarf has in mind, I think. *Originally*, the
extra "check" phase was added only for overridability purposes - in
particular, it was so that game authors could more easily override the
conditions on an action without having to rewrite the action execution
itself. If the "check" and "action" phases *weren't* separated, and you
just wanted to override one small part of a condition to the action, you'd
have to rewrite the whole action enactment routine as well, and that routine
is nontrivial for some actions. However, the separation has the extra
benefits Zarf is getting at.
In particular: the reason to add phases is that you want to insert condition
checks or action modifications that come from other objects in the system,
without having to rewrite any monolithic block of code anywhere. The more
phases you have, the more opportunities you have to slot in an extra
condition or modification at precisely the right point in the processing.
I think Zarf's idea of turning command processing into a series of
first-class condition objects is interesting, although I think the ideal
might be a hybrid - a combination of phases like we have now and first-class
condition objects. The thing is that probably 90% of cases are actually
pretty easily handled with the Inform or Tads styles of routing things
around to involved or nearby objects, so I think you want to augment rather
than replace this kind of model. A slight rethink of the phase model would
help a lot, I believe - my current thinking is that you need phases for
physical plausibility (sense-related things like making sure objects are in
sight or touchable), motivational checks, physical preconditions, physical
interferences (from other objects), action, and after-the-fact side-effects.
Zarf will probably say that I'm missing the point by enumerating a bunch of
new phases, that the point is that you always need one more phase so the
real solution is to make the phase system infinitely extensible, and that's
probably true. But if it's true that the ideal would be a hybrid model that
retains some of the existing phase mechanics, improving the phase system
would still be desirable.
It also occurs to me that if the problem with phases is that you always want
one more, maybe the solution is to give game authors an easy way to add new
phases. You always want one more than the number in the library, but
certainly for any given *game* there will be some number N that's enough.
If N turns out in general to be roughly equal to the number of objects in
the game, or even worse the number of object pairs or object tuples, a phase
model will obviously be impossibly inefficient, and a condition model would
be better. But my intuition is that N would turn out to be relatively small
in most cases, so maybe it's worth experimenting with.
Andrew Plotkin
>
> Now suppose you were to write the part of the parser that tries to decide
> which object to choose for an OPEN command, when there are multiple objects
> around matching the vocabulary words (say, "OPEN DOOR" when there's a GREEN
> DOOR that's already open, a RED DOOR that's currently closed, and a DOOR
> BELL):
I have never been convinced that this is an important role for the
parser to spend work on. But this may just be because Inform 6 mostly
doesn't do this work, and when it does, it does it badly. :)
> I think Zarf's idea of turning command processing into a series of
> first-class condition objects is interesting, although I think the ideal
> might be a hybrid - a combination of phases like we have now and first-class
> condition objects. The thing is that probably 90% of cases are actually
> pretty easily handled with the Inform or Tads styles of routing things
> around to involved or nearby objects, so I think you want to augment rather
> than replace this kind of model.
What I'd like to believe (but have not been able to demonstrate) is
that if you really have a first-class first-class-condition system --
heh -- then the existing model of objects and standard phases will
fall out as a more or less trivial subcase.
If I ever prove this belief, I'll be sure to let you all know. :)
> It also occurs to me that if the problem with phases is that you always want
> one more, maybe the solution is to give game authors an easy way to add new
> phases.
Certainly.
I'm also not fixed on the idea of "phases" as a simple ordered list of
operations. How about a *partial* order?
That is: When I'm writing code, I want to specify this check before
that check, and this other check after another one. But if I come up
with a new test, do I need to create a new phase and a position in the
list? Maybe the compiler can deduce where to fit it in. Maybe the
compiler can prove that it doesn't matter where it fits in -- it's
orthogonal to the existing tests.
And if neither of the above is true, maybe the compiler can work out
the simplest question it needs to ask me to resolve the ambiguity:
"Should I check the player's unwillingness to touch slimy frogs before
or after the player's unwillingness to go wading out into the swamp?"
Ask that, add the answer to the code model, and continue.
Such are my dreams.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a warrant,
it's for one reason: they don't feel like it. Not because you're an American.
Samwyse
> When I'm writing code, I want to specify this check before
> that check, and this other check after another one. But if I come up
> with a new test, do I need to create a new phase and a position in the
> list? Maybe the compiler can deduce where to fit it in. Maybe the
> compiler can prove that it doesn't matter where it fits in -- it's
> orthogonal to the existing tests.
>
> And if neither of the above is true, maybe the compiler can work out
> the simplest question it needs to ask me to resolve the ambiguity:
> "Should I check the player's unwillingness to touch slimy frogs before
> or after the player's unwillingness to go wading out into the swamp?"
> Ask that, add the answer to the code model, and continue.
And I'm working (very slowly) on ways for the player to modify that
entire system at run-time. When you have NPCs, they should be able to
react at various points through those phases, and the player should be
able to abort the process before the end. A player's command "OFFER TO
ENTER THE SWAMP" could impact the that last resolution process, at least
for a few turns. It could also trigger responses from NPCs similar to
the command "ENTER THE SWAMP", without the player actually leaving the
current location.
BTW, my conceptual model for all of this are games based on negotiation
with NPCs. Performing certain actions influences the NPCs, while
offering to do them triggers similar influences without performing the
action. (At least right away. Reneging on an promise would also
influence the NPCs, usually in a way the player wouldn't like.)
Kevin Forchione
news:U5zAf.12804$_S7....@newssvr14.news.prodigy.com...
> It also occurs to me that if the problem with phases is that you always
> want one more, maybe the solution is to give game authors an easy way to
> add new phases. You always want one more than the number in the library,
> but certainly for any given *game* there will be some number N that's
> enough. If N turns out in general to be roughly equal to the number of
> objects in the game, or even worse the number of object pairs or object
> tuples, a phase model will obviously be impossibly inefficient, and a
> condition model would be better. But my intuition is that N would turn
> out to be relatively small in most cases, so maybe it's worth
> experimenting with.
The simple solution would be, I think, to model this on something like
PreinitObject. So we have the phases as they exist, but the addition of
phase objects and their execution order is under the author's control.
--Kevin
Kevin Forchione
The TADS model is command-driven, but what you're suggesting here seems to
be something different. For instance, <<go west>> where west would place the
player in the swamp could reasonably have a phase that checks whether the
player has the right "tolerance" level to enter the swamp at this point in
game state, but the check of the player's tolerance of slimy frogs would
require the phase to check for the presence of slimy frogs at the
destination, and then the assumption is that though the action doesn't
involve touching, going to the swamp will increase the chance of touching a
slimy frog. Based on that example, you'd have to weigh out the phobias, and
the likelihoods and come up with a risk-based model. And of course you'd
probably have to weigh player character knowledge into the calculation.
At that point the game begins to feel like it's playing against the game
world as though it were a sentience separate from the player.
--Kevin
Samwyse
> The simple solution would be, I think, to model this on something like
> PreinitObject. So we have the phases as they exist, but the addition of
> phase objects and their execution order is under the author's control.
The problem that we want to solve is having too much stuff that's forced
to be under the author's control. Right now, as works of IF become more
complicated, authors face a combinatorial explosion. Every new verb
that gets implemented has to work correctly with every object, and every
new object with every verb. If you drop anything while juggling all of
those combinations, the game has a bug.
Samwyse
> The TADS model is command-driven, but what you're suggesting here seems to
> be something different. For instance, <<go west>> where west would place the
> player in the swamp could reasonably have a phase that checks whether the
> player has the right "tolerance" level to enter the swamp at this point in
> game state, but the check of the player's tolerance of slimy frogs would
> require the phase to check for the presence of slimy frogs at the
> destination, and then the assumption is that though the action doesn't
> involve touching, going to the swamp will increase the chance of touching a
> slimy frog. Based on that example, you'd have to weigh out the phobias, and
> the likelihoods and come up with a risk-based model. And of course you'd
> probably have to weigh player character knowledge into the calculation.
>
> At that point the game begins to feel like it's playing against the game
> world as though it were a sentience separate from the player.
I believe that the issue is with disambiguation. So to use a contrived
example, if there were two paths going west and the player said GO WEST,
the parser could use the fact that one led to a swamp full of slimy
frogs and the other to a gazebo set for high tea to decide which is more
likely, based on whether the player's character is a character from Jane
Austin or Dennis the Menace.
ChicagoDave
> the only way to get a project off the ground is to stop talking about it and
> go do it, which is probably why SHH is so typical around here.
Being someone interested in IF system development, but not having the
experience with the fundamentals, I'm sort of playing catch-up here. I
should probably be on the T3 mailing list and be reading all of the
discussions. I _am_ on the z-machine/Inform-maintenance mailing list
and follow every thread.
Has this phased command structure conversation ever happened on the T3
list or somewhere else? This is the sort of thing I like to see
discussed.
But there are many many other topics in IF system development that
could be construed as "design" or "requirements gathering" and these
things could be organized in some form of documentation so that we have
some central point of knowledge.
Imagine a textbook. The textbook is entitled, "Interactive Fiction
System Design and Development"
What would this book contain?
Do we know what the chapters might be?
If we know any of the chapters, how thorough a narrative could there be
for those chapters?
If we have chapters that have rock solid imperative data, can we get
the narrative _and_ design patterms?
I'm just asking that we try to create such a thing.
I'd like to order a copy.
David C.
steve....@gmail.com
Mike Roberts wrote:
> Andrew Plotkin wrote:
> > [T]wo fixed levels [of command resolution] is better than one fixed
> > level. Both are static approximations of what I want.
>
> Let me just clarify what's going on with the tads3 phases, for those not
> familiar with the model. It's not quite what Zarf is thinking of in terms
> of phases, but it's a step in that direction.
I made the same gesture last time we discussed this:
http://groups.google.com/group/rec.arts.int-fiction/msg/d686ec24b8cb2a49
But Andrew is not suggesting a model that can be understood in terms of
phases, but only in terms of rule-based logic programming. I love and
respect his devotion to this intuition, but I challenge it as I did
last time we discussed this:
http://groups.google.com/group/rec.arts.int-fiction/msg/059289a15a35d585
Andrew never answered that one, but nevermind.
The kind of logic programming problem we're imagining here is already
very common in other fields: there's no need to invent any significant
algorithm-technology. This well worn ground has been infrequently
visited by the IF designer not because the ground is infertile, but
because the problem domain does not require so complex a solution.
Andrew writes:
> > How about a *partial* order?
This invokes another very well known group of algorithms. The question
remains: what's justifying the application? Theoretically, it's great;
but without any compelling practical need....
-C
"sounds like expert systems crap,
who wants to code in that?"
Drakore
> Just because you vote for the Republicans, doesn't mean they let you be
> one.
Let me guess, they rejected your application?
Drakore
"Drakore" <dra...@comhem.se> skrev i meddelandet
news:mVNAf.43003$d5.1...@newsb.telia.net...
Oops! "having *voted* for them"
-- Drakore
"When you leave the liberal plantation, the Democrat man hates you, and all
the blacks who are on the plantation hate you and they call you an Uncle
Tom. They say, 'you Uncle Tom nigger you, that's all you are."
Rev. O'Neal Dozier
Andrew Plotkin
> Kevin Forchione wrote:
>
> > At that point the game begins to feel like it's playing against the game
> > world as though it were a sentience separate from the player.
>
> I believe that the issue is with disambiguation. So to use a contrived
> example, if there were two paths going west and the player said GO WEST,
> the parser could use the fact that one led to a swamp full of slimy
> frogs and the other to a gazebo set for high tea to decide which is more
> likely, based on whether the player's character is a character from Jane
> Austin or Dennis the Menace.
I did not mean to talk about disambiguation (although I'd try to solve
disambiguation problems via the rule mechanism once I had it). And I
don't intend to put the player in the position of trying to solve the
game world as a puzzle. I want to address very common IF
implementation issues. (See example below.)
I am looking for the most intuitive way to model the design of my
games. And believe me, this is *the way I model my games* --
translating my rule concepts into Inform 6's action model is the
secondary, and rather clumsy, stage of implementation.
Steve Breslin wrote:
> but I challenge it as I did last time we discussed this:
> http://groups.google.com/group/rec.arts.int-fiction/msg/059289a15a35d585
> Andrew never answered that one, but nevermind.
I have no clear answer. If I had an answer, I would have implemented
it last year.
> The kind of logic programming problem we're imagining here is already
> very common in other fields: there's no need to invent any significant
> algorithm-technology. This well worn ground has been infrequently
> visited by the IF designer not because the ground is infertile, but
> because the problem domain does not require so complex a solution.
Doesn't it? There's a standing bug in _Dreamhold_ (which I don't
really intend to fix, because it's not worth the effort) where you can
poke at the fireplace while seated in a chair. Simple conditional:
while you're seated, you can't reach the fireplace or anything in it.
Another conditional: when you touch the fire, you say ouch.
How to resolve this conflict? The "phase" solution would be to divide
all actions into a "reaching" phase and a "doing" phase -- this is
what TADS does, under different names -- and decide where every bit of
code belongs. This feels horribly overweight to me. (And Inform's
ObjectIsUntouchable mechanism is horribly difficult to use
consistently. I didn't even try.)
What I *want* is to just *decide which rule takes precedence*, and
tell the compiler that, and then it's all sorted out.
Similarly: Inform 6 has a standard library implementation of darkness.
It has the world-model effects that you'd expect from an Infocom-era
game: you can't examine anything, things outside your inventory are
out-of-scope, movement calls a custom hook routine (which can be set
up to feed you to a grue, or whatever).
Now say the description of a bell (when you're holding it) is "The
bell chimes softly." This description should not be interfered with by
darkness. How do you do this in Inform? Well, Inform darkness works by
an ad-hoc "phase" system in the Examine action: the Examine action
checks for darkness, and then invokes the object's description
property. You can customize this at the Examine level (before the dark
check) or at the description level (after the dark check.)
But this means learning library trivia. Library trivia *sucks*. It's
hard to learn and easy to get wrong. (Ask an Inform author what the
difference is between a before:Examine rule and a description
property. Not too many will answer "darkness". 'nuff said?)
(And note: it's a real nuisance to add a third phase -- particularly
if you already have a bunch of working code that customizes behavior
at various levels.)
A correct model, in my view, would have *one* way of customizing
everything. You'd add an "examine bell" rule, just like all your other
"examine this" and "examine that" rules. And then you'd say, this rule
(unlike most "examine" rules) takes precedence over darkness. End of
implementation.
Naturally, it's *possible* to set up strict phases in this model. In
fact it is a superset of the phase model -- that much I can prove. (You
can define a behavior as "do P1, then do P2, then do P3." Then,
instead of overriding this master rule, you customize the behavior of
P1 or P2 or P3. There's your phases.) But you don't *have* to organize
anything this way.
This is why I keep coming back to this idea: it's demonstratably more
powerful, and all the examples I come up with are simpler, than the IF
tool I'm using now. The question is whether I have a model that
includes all my hand-wavy examples, without getting complicated again.
(Note: I am not currently in a position to devote serious time to this
problem. I was last year, and I started to implement something, but it
didn't get done.)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation,
it's for one reason: they don't feel like it. Not because you're patriotic.
Poster
> "Drakore" <dra...@comhem.se> skrev i meddelandet
> news:mVNAf.43003$d5.1...@newsb.telia.net...
>> "Andrew Plotkin"
>>
>>> Just because you vote for the Republicans, doesn't mean they let you be
>>> one.
>> Let me guess, they rejected your application?
>
> Oops! "having *voted* for them"
I too thought that sig line was rather strange, too, as it's an obvious
non-sequitur.
-- Poster
www.intaligo.com/ -^-^-^- Inform libraries and extensions!
www.intaligo.com/building/ *- B U I L D I N G -* Dark IF.
Kevin Forchione
> How to resolve this conflict? The "phase" solution would be to divide
> all actions into a "reaching" phase and a "doing" phase -- this is
> what TADS does, under different names -- and decide where every bit of
> code belongs. This feels horribly overweight to me. (And Inform's
> ObjectIsUntouchable mechanism is horribly difficult to use
> consistently. I didn't even try.)
>
> What I *want* is to just *decide which rule takes precedence*, and
> tell the compiler that, and then it's all sorted out.
The question seems to be, who *decides* which rule takes precedence? In the
simple case, an author or library programmer must decide the precedence
order of these kinds of rules, though once they are decided upon then the
execution of the rules is automatic. If, on the other hand, the system is to
somehow decide the precedence of these rules, then the author or library
programmer is still left with the task of working out the meta-precedence.
There's no escaping a human decision in the process.
But in terms of mechanism, this is where my suggestion of something similar
to the PreinitObject model would be of use. In that model the author can
suggest execBefore and execAfter lists that cause the PreinitObjects to be
executed in some sequence, though the order of that sequence is a relative
one. An author adding a new rule would need to assign whether the rule is to
be executed before or after another rule (or if left unassigned then the
order of execution is arbitrary).
As a prototype, the TADS 3 system could be modified via library extension to
do just this. The approach would be a hybrid, as Mike suggested, since it
would maintain the pre-condition, verify, check, and action stages, but
within those stages would be a mechanism that executed a series of objects,
each of which would have veto power over the continuation of the process,
and each of which could be evaluated for levels of "likeliness". What you'd
have would be a collection of pre-condition rules, verify rules, check
rules, and finally action rules. Authors could then simply add, modify, or
remove rules as they pleased. Perhaps I'll play around with this if I get my
other "LispTads" project further along...
--Kevin
ChicagoDave
hardest time wrapping my brain around. It's what I call the "turn
process". I've had trouble even trying to break down the process of a
turn without arbitrarily adding hooks for things. But from these last
two posts, it seems to me that we're talking about something like a
deck of cards. The cards are stacked a certain way and that's the way
they will execute unless something inserts or removes cards from the
deck.
So the player's interactions can insert or remove cards.
Each daemon or NPC can insert of remove cards.
Of course it would seem that interactions from the PC, NPC's, and other
daemons are all going to require some sort of mechanism to regulate te
insertion/deletion process. This is obviously where disambiguation and
other "problems" come in to play.
Would this be a fair assessment of this particular issue in IF
parsing/execution?
David C.
Andrew Plotkin
> I think this exactly the portion of an IF system that I have had the
> hardest time wrapping my brain around. It's what I call the "turn
> process". I've had trouble even trying to break down the process of a
> turn without arbitrarily adding hooks for things. But from these last
> two posts, it seems to me that we're talking about something like a
> deck of cards. The cards are stacked a certain way and that's the way
> they will execute unless something inserts or removes cards from the
> deck.
>
> So the player's interactions can insert or remove cards.
>
> Each daemon or NPC can insert of remove cards.
No.
That might be available as an advanced mechanism, but the primary goal
is for the *author* to insert and remove cards. (And he's not viewing
the system as a deck in which to insert things. The compiler
*generates* a deck -- i.e., an order of operations.)
You're talking about having the operations rearranged during play.
That's unnecessary for most IF situations. It would be unnecessarily
confusing for that to be the primary mode of game construction.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't subjected you to searches without a
warrant, it's for one reason: they don't feel like it. Not because of
the Fourth Amendment.
ChicagoDave
Based on what I want (as the author) and what I want a particular pc,
npc, or daemon to do, i can regulate the insertion or deletion of
cards.
I wasn't considering the deck of cards the primary system construct. I
view the metaphorical deck of cards as the state if the IF engine
before handling things the author has implemented.
David C.
Daryl McCullough
>That might be available as an advanced mechanism, but the primary goal
>is for the *author* to insert and remove cards. (And he's not viewing
>the system as a deck in which to insert things. The compiler
>*generates* a deck -- i.e., an order of operations.)
I think that the metaphor of the card game is kind of interesting,
but it's a very complicated card game. It starts off with the player
character playing his card (that is, choosing an action). The other
cardplayers (objects in scope, in the Inform model, or first-class
conditions in your model) may either remove cards from the "trick"
or add cards to it. The winner (or winners?) get to choose what the
effect of the hand is.
Okay, I don't think that metaphor helps much. But I'm not sure
that it boiling down to ordering of conditions is exactly right,
either.
Let's exand on your example of poking a fire. Let's suppose
we have the following rules:
1. You can't poke anything if you are sitting down.
2. An exception to rule number 1 is if you are holding
a long stick.
3. You can't poke the fire if the grate is closed.
4. If you succeed in poking the fire, you will burn yourself.
5. An exception to number 4 is if you poked the fire from a
safe distance using a long stick.
How would these rules be stated, and how would they be ordered
to get the desired effect? I don't see a nice, principled way of
handling exceptions and exceptions to the exceptions. Inform
doesn't allow exceptions to exceptions: If some react_before
disables an action, then the action can't be re-enabled
by another react_before.
--
Daryl McCullough
Ithaca, NY
Kevin Forchione
news:dr1km...@drn.newsguy.com...
I agree. Even if you created an object whose react_before processed a set of
rule_objects they would have to be ordered in some fashion, and their
response to their a query on their rules would most certainly have to be a
simple choice of "let me handle it", "no comment", or "stop the process".
Of course the example above all deal with conditions of reachability. There
are probably ways of addressing reachability that would serve to resolve
this particular issue. For instance, one could modify the world model so
that a long stick is essentially a sense-passing portal between chairs and
the outside world... but these issues are going to involve sets of
relationships, and as of yet we have no adequate modeling of "nearness" or
"farness" in world models, except for some modeling of distant objects.
Objects that are inside of a room have no spatial relationship to each
other, and if we use the containment model alone we get some strange
results. If I drop a book onto the floor while sitting in a chair, can I
pick it back up?
One solution to this, of course, is the use of compound rooms. Locations
joined by sense passing mechanisms, so that they are themselves the measure
of proximity. Anything within that location is "reachable", anything outside
of that location requires a special device that serves as a sense-passing
mechanism (a long stick, for instance). In that way, dropping an object from
a chair means that it can be picked up, while throwing a book at the mantel
of the fireplace means that I cannot (assuming the chair and the fireplace
occupy separate locations within the compound room).
This is something that TADS 3 can model very well, but it's still a matter
of the rules and mechanism of the world model and Inform could do it as
well, once the mechanisms for sense-passing and containment adequately
accommodated compound locations.
--Kevin
Dan Shiovitz
Daryl McCullough <stevend...@yahoo.com> wrote:
[..]
>Let's exand on your example of poking a fire. Let's suppose
>we have the following rules:
>
> 1. You can't poke anything if you are sitting down.
> 2. An exception to rule number 1 is if you are holding
> a long stick.
> 3. You can't poke the fire if the grate is closed.
> 4. If you succeed in poking the fire, you will burn yourself.
> 5. An exception to number 4 is if you poked the fire from a
> safe distance using a long stick.
>
>How would these rules be stated, and how would they be ordered
>to get the desired effect? I don't see a nice, principled way of
>handling exceptions and exceptions to the exceptions. Inform
>doesn't allow exceptions to exceptions: If some react_before
>disables an action, then the action can't be re-enabled
>by another react_before.
I think you're underestimating the amount of compiler support and
library rewriting that could be done here. Like, it seems pretty
workable to code this as
if verb == ##Poke && noun == fire then
"Ouch! You burned yourself!";
sit_poke_rule: if verb == ##Poke && player.position == sitting then
"You can't poke anything when sitting down!";
if verb == ##Poke && stick in player then
bypass sit_poke_rule;
if verb == ##Poke && noun == fire && grate.closed then
"You can't poke the fire when the grate is closed.";
if verb == ##Poke && noun == fire && stick in player then
"You poke the fire safely.";
If desired you could condense some of these rules, of course, allowing
for sub-ifs. But this set almost solves your problem. I say "almost"
since there are some cases of ambiguity here where it's not clear
which rules should apply. It seems obvious that one rule is that
conditions that are strict supersets of other conditions override them-- so
the first rule is overridden by the last two, and the third by the
fifth. The third rule references the second, so presumably it should
have higher priority than it. But there are also cases like the first
two rules where it's not obvious which should apply. But, like Andrew
said, the compiler can detect this and print an error message --
"unclear precedence between rule ___ and rule ___, insert statements
to resolve" and you can rewrite as
poke_fire_rule: if verb == ##Poke && noun == fire then
"Ouch! You burned yourself!";
sit_poke_rule: overrides poke_fire_rule
if verb == ##Poke && player.position == sitting then
"You can't poke anything when sitting down!";
or something similar. Naturally this looks like a big jumble of rules,
but I assume in practice there'd be additional syntactic sugar to make
most of the rules you write look pretty much the same to how rules get
written now:
Object fire
! for these rules, the "noun == this object" is implied
##Poke, grate is closed: "You can't poke the fire when the grate is
closed."
##Poke, stick in player: "You poke the fire safely.";
##Poke: "Ouch! You burned yourself!";
The advantage here is basically that the compiler is checking harder
about ambiguities, and there's a defined way for deciding which rule
overrides which -- if you want examining this object to override the
standard darkness rule, you can specify that.
>Daryl McCullough
--
Dan Shiovitz :: d...@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW
Andrew Plotkin
> Andrew Plotkin says
>
> >That might be available as an advanced mechanism, but the primary goal
> >is for the *author* to insert and remove cards. (And he's not viewing
> >the system as a deck in which to insert things. The compiler
> >*generates* a deck -- i.e., an order of operations.)
>
> I think that the metaphor of the card game is kind of interesting,
> but it's a very complicated card game.
Yeah, it's not the metaphor I really want to explain to the designer.
> Okay, I don't think that metaphor helps much. But I'm not sure
> that it boiling down to ordering of conditions is exactly right,
> either.
Well, ultimately it has to: all our IF machines are single-threaded.
(And I see no value in going to a multi-threaded model.) The final
program is going to go through a bunch of code in some order. But this
should be the compiler's problem, not the designer's.
> Let's exand on your example of poking a fire. Let's suppose
> we have the following rules:
>
> 1. You can't poke anything if you are sitting down.
> 2. An exception to rule number 1 is if you are holding
> a long stick.
> 3. You can't poke the fire if the grate is closed.
> 4. If you succeed in poking the fire, you will burn yourself.
> 5. An exception to number 4 is if you poked the fire from a
> safe distance using a long stick.
>
> How would these rules be stated, and how would they be ordered
> to get the desired effect?
It looks straightforward to me. Let me rewrite it -- into pseudocode,
because I'm not worried about syntax at this point, and yes I am
waving my hands about a lot of details. Please bear with me.
The library will be set up with the convention that actions like
"touch", "take", "push" have a "reach" stage followed by a "result"
stage. (I'm not opposed to phases as a design pattern! I just think
that the designer should be able to talk about them directly, rather
than looking up what hook the library calls at each stage.)
To recast this in the language of conditionals: the "touch" action is
defined as "if reachable, then touch-result". And "touch-result" is
defined (in the library) as { print "You feel nothing special." } And
"reachable" is simply defined as { true }, because by default you can
reach anything in scope.
I want this "poke" action to work like "touch", but with an optional
second object. So I define that. To make things easier in the default
case, the poke-result invokes touch-result.
Now:
if (player in chair && noun == fire)
then handle reachable as "You can't reach that."
if (player in chair && noun == fire && second == stick)
then handle reachable as { true }
if (grate closed && noun == fire)
then handle reachable as "The grate is closed."
if (noun == fire)
then handle touch-result as "Ow."
if (noun == fire && player in chair && second == stick)
then handle touch-result as "Sparks fly up."
This is a direct rephrasing of your rules, considered one at a time.
(The author *wants* to consider them one at a time -- the last thing
he needs is to have to handle the combinatorial explosion in his brain
before he can start writing code.)
Now notice what we've got: rule 2 is logically stronger than rule 1.
The compiler detects this, and infers that you intend rule 2 to be an
*exception* to rule 1 -- so check that first. Similarly, rule 5 is
obviously an exception to rule 4.
(Rules 1,2,3 and rules 4,5 are independent sets, because the former is
about "reachable" and the latter are about "touch-result". No
conflicts there.)
The ordering of rule 3 is not obvious to the compiler -- it's neither
strictly stronger than nor weaker than either of the first two rules.
So the compiler throws a query: where does it fit in with the first
two? And I answer, it has lower precedence than both. Now the compiler
knows how to generate the code for "reachable".
I've made things easier on myself by relying on the library pattern of
"reach, then do". I wouldn't *have* to do that. I could define all
five rules in terms of "touch-result". Then I'd have to make an
additional declaration to the compiler, of the form "these first three
rules take precedence over the others." Same final result.
(Note that I am not trying to simplify the syntax here. An obvious
course would be to allow nested conditionals, ie:
if (noun == fire) then {
handle touch-result as "Ow."
if (player in chair && second == stick)
then handle touch-result as "Sparks fly up."
}
This is just syntactic sugar, but convenient for making several rules
about the same object -- which of course is a common case.)
> I don't see a nice, principled way of handling exceptions and
> exceptions to the exceptions. Inform doesn't allow exceptions to
> exceptions: If some react_before disables an action, then the action
> can't be re-enabled by another react_before.
You are correct: I neatly set up your example so that I wouldn't run
into this problem. (The general problem: Can you override an exception
to go back to the original behavior? If so, what if another rule
overrides *that* and says "use the original behavior"? How do you let
the designer express which he means by "the original"?)
I don't see a nice way to handle it either. But it's a lovely language
design problem, isn't it?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.
Kevin Forchione
<snip>
Interesting. Of course it would be nice if the compiler sorted this out, but
you could do the same by simply running your source code through a
pre-compile (or translation) step that analyzed it and then either
re-ordered the code or, if the code were encapsulated in objects, provided
them with a ranking integer value. The chief issues would then be the
algorithm for computing rule-strength based on the precedence of logical
operators and their occurence within the rule.
If the rules are encapsulated in objects then ambiguities can be resolved by
use of an execBefore/execAfter tag applied to ambiguous cases. In that case
the code itself doesn't even need to be shuffled, simply a property added to
the object definition indicating the rule_order. Classes of rules could then
be developed for handling separate actions.
>> I don't see a nice, principled way of handling exceptions and
>> exceptions to the exceptions. Inform doesn't allow exceptions to
>> exceptions: If some react_before disables an action, then the action
>> can't be re-enabled by another react_before.
>
> You are correct: I neatly set up your example so that I wouldn't run
> into this problem. (The general problem: Can you override an exception
> to go back to the original behavior? If so, what if another rule
> overrides *that* and says "use the original behavior"? How do you let
> the designer express which he means by "the original"?)
>
> I don't see a nice way to handle it either. But it's a lovely language
> design problem, isn't it?
Yep.
--Kevin