Newsgroups: rec.arts.int-fiction
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!portc03.blue.aol.com!uunet!dca.uu.net!ash.uu.net!world!buzzard
From: buzzard@world.std.com (Sean T Barrett)
Subject: Re: [Inform] Nice simple straightforward question
Message-ID: <GIC6zC.B9M@world.std.com>
Date: Sun, 19 Aug 2001 22:40:24 GMT
References: <9kua39$1ei$1@news.panix.com> <20010819150224.01442.00000863@mb-ci.aol.com>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 112
Xref: news.duke.edu rec.arts.int-fiction:91315

OKB -- not okblacke <brenbarn@aol.comRemove> wrote:
>     It's looking more and more like a once-through "checklist" just isn't
>going to work.  It doesn't make sense to require the programmer to juggle
>things like room before, player before, and react_before to fit the world
>model, which is often the case now (i.e., things that people think "really
>should" go in a react_before wind up having to go in the room's before because
>of the way the checks are sequenced).
>     It seems like what we need is some kind of contiuum of checks in which
>order is not a concern.  (Actually, I think I just like the word "continuum".)
>The basic idea is this: if nothing says an action is supposed to fail, it
>should succeed.  Each check for failure should get its say, and THEN, after
>everything's done, we should worry about what error message to print.

The problem with the continuum of checks where order is not a
concern is that you either need two copies of your tests (one
which reports the error condition and one which prints the
error message), you need one copy with a global variable that
says whether to print or not (a la 'keep_silent'), or you need
the one place to be able to return both an error code and a
printable message. Since that printable message might want to
print things like the name of the object, it really needs to
return a little callable function which prints.

The first one is going to lead the bugs, the second one is an
ugly hack, and the third one isn't feasible in Inform--or Tads 2--
but it will be in Tads 3.

>If ANY of the checks came up negative, the
>action would fail, but only after all of this had been resolved would we get
>down to the task of sorting out exactly what caused it to fail and what message
>we should print.

Realistically, I suspect we'll still find problems with this task
of "sorting out...what message we should print". We can assign each
error a priority number, and print the one with the highest priority,
but then that's not much different from deciding what order to call
things in. (We could achieve it directly by having you call one function
to determine the calling order, then call in that order and
print-and-return-true like we do now.)  In other words, this is just
the same old n-ary dispatch problem: traditional object-orientation works
by pushing processing out onto ONE object, but the interaction of two
objects doesn't belong to just one object.

One thing I would argue for is more simulationism: putting all the work
(or more of it, anyway) in one place (e.g. the verb routine) can actually
allow the verb routine to work out the prioritizations of rules in a
much more natural way. We take this for granted with things like very
basic object manipulation; and this is how a lot of n-ary object
processing that isn't exception-driven works--there's a driver algorithm
which calls into all the involved objects to get at their properties.

On a certain level, some amount of error prioritization can be done
from a sort of simulationist perspective:

   That isn't an action that's feasible in any world.
   That isn't an action that the PC is willing to try.
   That is an action the PC thinks about trying, but realizes is doomed.
   That is an action the PC starts to try, but an NPC prevents it.
   That is an action the PC starts to try, but can't bring to fruition.
   That is an action that the PC brings to fruition.

Here, each of the items higher on the list would come first, because
they come earlier in the causal chain that allows the action to occur.
(Player conceives a rational action, PC considers it, PC attempts to
execute it, etc.)  But even there I've kind of arbitrarily decided
that NPCs influence "earlier" than other objects, or the order of decision
with the PC being scared to try something versus the PC realizing it
won't work.

I guess my design intent with the former is the NPC reaction stage
represents non-physical reactions--NPCs perceive the beginning of
the action and anticipate the outcome, and prevent it earlier, due
to anticipation--whereas the following stage represents physical laws
that purely follow from once you actually get to trying the action.

So that makes sense for

  > TAKE GLASS
  Bob grabs your hand. "Don't touch that!"

versus

  > TAKE GLASS
  It's nailed to the table.

but it leaves out a lot of subtle timing that's possible:

  > TAKE GLASS
  You reach out for it, but your hand bumps into an invisible
  wall of force surrounding it.

(Note the obviously desired priority relative to the above two.)

Do we want to track the "distance" at which the action fails?
Represent the time from starting the action as t=0, the time from
completing the action as t=100, and have each failure say "when"
the failure would occur?

And what about when the action is carried nearly to completion,
but *then* at the last minute the PC decides not to carry it out?

Or what about when you've carefully tweaked your numbers, and
reaction A always wants to happen at time 50 relative to everything
else, reaction B always wants to happen at time 75 relative to
everything else, oh, but in this one case, B wants to happen before A?
Now we need a special-case system for handling the special cases
not handled by the general system with which we'd tried to replace
the old special-case system.

Argh.

SeanB
