I7 - Frustration with Object Relationships
Jeff Nyman
(compared to, say, TADS 3) but I have a feeling I'm missing something
obvious. I'm not so much asking for any help here as I know the situation
and what to do about it. But I'm curious if people have elegant solutions.
Say you have this:
<code>
The Study is a room.
A container called the rolltop desk is in the Study. It is lockable. It
is openable. It is closed.
</code>
With just that, here's what you get when you try to unlock the desk:
<game output>
>UNLOCK DESK
(with the rolltop desk)
(first taking the rolltop desk)
That's unlocked at the moment.
</game output>
That strikes me as a ridiculous assumption by Inform. I realize it's picking
the only object in the room, but why? It would seem that a logical "realism
rule" (as Inform calls them) would indicate that a thing can't be unlocked
by its own self.
Now, add a glass bottle to the room:
<code>
The Study is a room.
The glass bottle is in the Study.
A container called the rolltop desk is in the Study. It is lockable. It
is openable. It is closed.
</code>
Now, try to unlock the desk again. You get this:
<game output>
>UNLOCK DESK
(with the glass bottle)
(first taking the glass bottle)
That doesn't seem to fit the lock.
</game output>
Basically, I know you can use things like this:
<code>
Does the player mean unlocking the desk with the desk: it is unlikely.
Does the player mean unlocking the desk with the bottle: it is unlikely.
</code>
But is that the best way to do this? That would seem to mean I have to
constantly be thinking of all these ways that Inform might treat various
object relationships rather than having some of those relationships handled
for me based on "smart" world modeling. So the upshot (it seems) is that I
then have to put various rules like this all over my code.
For example, if I carry the glass bottle to another room that has a locked
wooden crate, Inform will also assume I might want to unlock that with the
glass bottle, meaning I need another rule but this time for the wooden
crate.
This all gets frustrating because I feel like I have to baby-sit Inform for
everything because I'm not sure when it's going to try to figure things out
on its own and when its not and I think that's partly because the world
model is largely an empty slate, but not quite entirely. These are just
simple things that I'm getting "stuck" on, so I'm really worried about
building a full game when the situations get more complicated. I don't mind
adding these "helper" elements once in a while but, at first glance, it
seems I have to be considering that kind of thing all over the place.
What am I missing?
- Jeff
Lem Signwriter
> <game output>
> >UNLOCK DESK
> (with the rolltop desk)
> (first taking the rolltop desk)
> That's unlocked at the moment.
> </game output>
>
> That strikes me as a ridiculous assumption by Inform. I realize it's
picking
> the only object in the room, but why?
This arises from a particular Informish subtlety. From the Index tab:
Unlocking something with something (past tense unlocked it with)
"open [something] with [something preferably held]"
"unlock [something] with [something preferably held]"
The (non-obvious) problem here is that Inform doesn't have any rules to
cope with "unlock [something]": the "...with [something]" is *not*
optional. Inform is attempting to turn a fragmentary unlock command into
one it can understand, and with only one object in the game to choose
from - well, there's no solution that a human would regard as optimal.
First, you want to add:
<code>
Understand "unlock [something]" as unlocking it with.
</code>
Now "UNLOCK DESK" gets you "You must supply a second noun." That's not
ideal, but it's closer:
<code>
A key is a kind of thing.
Rule for supplying a missing second noun while unlocking something with:
if the number of touchable keys is greater than 0 begin;
change the second noun to a random touchable key;
say "(trying [the second noun])";
otherwise;
say "You've got no keys!" instead;
end if.
</code>
> This all gets frustrating because I feel like I have to baby-sit
Inform for
> everything because I'm not sure when it's going to try to figure
things out
> on its own and when its not and I think that's partly because the world
> model is largely an empty slate, but not quite entirely. These are just
> simple things that I'm getting "stuck" on, so I'm really worried about
> building a full game when the situations get more complicated. I
don't mind
> adding these "helper" elements once in a while but, at first glance, it
> seems I have to be considering that kind of thing all over the place.
>
> What am I missing?
Once again, the real problem is the difficulty of finding the
information you need in the documentation, particularly when you're not
sure what it is you're looking for.
Having to add an "understand" line with a deliberately-missing second
noun for a built-in verb is - how shall I put this? - somewhat obscure.
The only reason I know is that I figured this out the hard way when I
was working out how to disambiguate the second noun for a custom verb.
(The *other* solution, specific to this particular problem, is:
Include Locksmith by Emily Short.
But you don't learn nearly as much by doing that.)
Lem Signwriter
<code>
Does the player mean unlocking the desk with the desk: it is unlikely.
Does the player mean unlocking the desk with the bottle: it is unlikely.
</code>
I don't think "it is unlikely" will prevent the parser from picking that
object if it's the only (or least worst) choice.
(I'm struggling with something vaguely similar right now: wearing
something is defined as "wear [something preferably held]", and "it is
unlikely" will *not* make the parser consider a held item less likely
than an unheld one.)
Jeff Nyman
news:f0qeba$ojg$1...@aioe.org...
[... lots of helpful stuff snipped ...]
Thanks for this. I now understand where I was getting tripped up.
Unfortunately this is just another one of those things that keeps me from
working with Inform. That's, of course, my issue and not any one else's, but
I'm starting to appreciate the differences between the various languages and
the world models they provide "out of the box," as it were.
When I import this very same example into TADS 3, for example, I have no
issues at all. Now, granted, what TADS 3 may be doing behind the scenes is
just as (or even more) "complicated" than the rule I have to set up with
Inform, but, from an authoring perspective, I don't have to deal with it
until and unless I want to override it.
Maybe I'm not looking at it right. I'm really trying to give Inform 7 a
chance but I constantly run into what are, for me, frustrations.
- Jeff
villagedweller
I think with the bottle, in all fairness to inform, it doesn't know
what a desk or bottle is, and even if it did have a knowledge of
containers that made them unlikely to be used as keys, this could
cause all sorts of problems to someone who wanted to use a container
as a key.
For the desk, though, and the notion of unlocking something with
itself generally, that does seem silly. I tried making the desk fixed
in place, and it still tries to take it, and not being able to take
something should be a big clue that it can't be used as a key. Those
seem like reasonable checks to institute as part of unlocking. Which
you could write yourself, but I would tend to agree that they should
have been implemented with unlocking in the first place.
Jeff Nyman
news:1177603331.6...@n35g2000prd.googlegroups.com...
> I think with the bottle, in all fairness to inform, it doesn't know
> what a desk or bottle is, and even if it did have a knowledge of
> containers that made them unlikely to be used as keys, this could
> cause all sorts of problems to someone who wanted to use a container
> as a key.
Right -- but the fact that Inform has no knowledge should, I would think,
mean it errs on the side of caution; i.e., *not* trying to use a bottle as a
key when it has no idea what it is. Why assume this thing you're carrying
can be used to unlock anything at all?
In the case of where someone wanted to use a container as a key, it could be
specified as a key type object or as a special type of object. This would be
a case of what I was talking about: the defaults act largely as people would
expect. When this is not going to be the case, hook into the object and
change its behavior. For example, TADS uses KeyedContainer,
OpenableContainer, LockableContainer, etc.
I think from an authoring perspective, I prefer when the world model is
already populated with things that tend to, on average, "make sense" and
then allow me to hook into instances of my objects when what normally makes
sense doesn't in the context of my world. I know Inform allows that as well
but I guess I'm just finding it really clunky and I'm not always finding it
consistent. I'm still working out how much of that is just my own ignorance
and how much of that is fact about Inform.
- Jeff
Neil Cerutti
> "villagedweller" <village...@googlemail.com> wrote in message
> news:1177603331.6...@n35g2000prd.googlegroups.com...
>> I think with the bottle, in all fairness to inform, it doesn't
>> know what a desk or bottle is, and even if it did have a
>> knowledge of containers that made them unlikely to be used as
>> keys, this could cause all sorts of problems to someone who
>> wanted to use a container as a key.
>
> Right -- but the fact that Inform has no knowledge should, I
> would think, mean it errs on the side of caution; i.e., *not*
> trying to use a bottle as a key when it has no idea what it is.
> Why assume this thing you're carrying can be used to unlock
> anything at all?
Because the player provided nothing else to go on. If I command
a one-year old to "eat", and she's holding nothing but a plastic
car...
Maybe what we're seeing here is over-simplification of the
disambiguation situations. Inform perhaps should not use the same
rules for when an ambiguous word is provided and for when the
word is completely omitted. That's the solution to the problem
that was presented (by finagling the grammar), but it might be a
general issue. "OPEN" is another verb that authors often complain
about in testing their one-room knock-off games.
Does TADS handle the two cases differently? If so, is it done
with extra grammar, or with bifurcated disambiguation rules?
--
Neil Cerutti
The Rev. Merriwether spoke briefly, much to the delight of the audience.
--Church Bulletin Blooper
JDC
I would use a rule for supplying a missing second noun. Section 17.24
of the docs has an example specifically to do with unlocking.
-JDC
Lem Signwriter
> Maybe what we're seeing here is over-simplification of the
> disambiguation situations. Inform perhaps should not use the same
> rules for when an ambiguous word is provided and for when the
> word is completely omitted. That's the solution to the problem
> that was presented (by finagling the grammar), but it might be a
> general issue. "OPEN" is another verb that authors often complain
> about in testing their one-room knock-off games.
I7 seems to aim to be a cultural institution, and the attitude of that
institution is that there is More Than One Way To Do It for any
interesting problem. Rather than making any one way canonical, the
extension authors can solve any given problem (a thorough treatment of
lockable objects, say) *every* possible way.
(That's why Locksmith is distributed with but not integrated into I7.)
Unfortunately, I7 is sufficiently young that a fair number of the
available extensions are solely concerned with filing the rough edges
off list-writing and suchlike (not that they're any less valuable for
that!) - and I wonder if the whole aura of Formal Ratification Process
around making extensions public isn't going to scare people off
publishing half-hour works of genuine but extremely focused utility.
Short answer: if locked things are important to your game, you're not
*expected* to use vanilla I7 to implement them; and so the vanilla
implementation is never going to be just right.
(That's why Locksmith, while not integrated into I7, is distributed with
it.)
Jeff Nyman
news:slrnf31pgd....@FIAD06.norwich.edu...
> Because the player provided nothing else to go on. If I command
> a one-year old to "eat", and she's holding nothing but a plastic
> car...
I get the point but, on the other hand, since the player provided nothing
else to go on, I would tend to think Occam's Razor kicks in: do the thing
with the fewest possible assumptions. In this case, that would be nothing.
Or, rather, ask the player what they want since they specified nothing.
> Does TADS handle the two cases differently? If so, is it done
> with extra grammar, or with bifurcated disambiguation rules?
To be honest, I'm not sure of all the details. I'd have to look. That being
said, perhaps that's also part of my point: I generally don't have to worry
about what TADS is doing behind the scenes until I have an odd situation
that I need to handle differently. When I do have such a situation, I can
tie the handling of that to one object (or one class of objects) and have it
dealt with all the time.
I'm trying to determine to what extent Inform can do that. I can see that I
can write rules and I can even generalize them to a certain extent, but I
have to do that a lot it seems. For example, here was Lem's suggestion:
<code>
A key is a kind of thing.
Rule for supplying a missing second noun while unlocking something with:
if the number of touchable keys is greater than 0 begin;
change the second noun to a random touchable key;
say "(trying [the second noun])";
otherwise;
say "You've got no keys!" instead;
end if.
</code>
That's a good solution for what I was dealing with. Now, what if I have
other things that lock and unlock but without keys? Or that lock or unlock
with some other type of object? Do I have to write this kind of rule for
each of those situations, but replace "random touchable key" with the other
type of object that can lock and unlock?
Hmmm. As I write this out, I guess I see my issue is mainly that everything
has to be separated from the objects that you're dealing with. The rules,
for example, while *applying* to a given object (or class of objects) aren't
actually part of that object in the code itself.
- Jeff
Khelwood
wrote:
I don't know if it would help in this case, but it would be helpful if
Inform (6 and 7) provided a way to explicitly invoke the ask-for-an-
object feature, but it seems to be buried too deep in the parser-code
to get at it.
Jeff Nyman
news:1177610651.9...@b40g2000prd.googlegroups.com...
> I would use a rule for supplying a missing second noun. Section 17.24
> of the docs has an example specifically to do with unlocking.
Thanks. I didn't see that originally. So tying together what that section
says and Lem's idea, I try this:
<code>
Rule for supplying a missing second noun while unlocking:
if a random key (called target) is carried begin;
change the second noun to target;
end if;
if the number of touchable keys is greater than 0 begin;
change the second noun to a random touchable key;
say "(trying [the second noun])";
otherwise;
say "You've got no keys!" instead;
end if.
</code>
That seems to work moderately well. Can I generalize that further? Right now
it ties everything to key objects. So if I have another type of thing that
isn't unlocked by keys, I would need another rule like this. What I'm trying
to do is get as generalized as possible.
Overall all, though, this has helped. I guess it's debatable how much you
want in your world model. Personally, if I was a new author, I wouldn't want
to have to worry about the code I just put together above. Others, however,
may feel that even that much is assuming too much on the part of the IF
system. I think either is probably fine -- as long as its consistently
applied.
- Jeff
Jeff Nyman
using, I'd like to generalize the idea of "does the player mean." I try
this:
<code>
The Study is a room.
A key is a kind of thing.
The glass bottle is in the Study.
A container called the rolltop desk is in the Study. It is lockable. It
is openable. It is closed. It is scenery.
Does the player mean unlocking when the noun is not a key: it is very
unlikely.
</code>
Note that last line. However, when you play this you get:
<game output>
>unlock desk
(with the glass bottle)
(first taking the glass bottle)
That's unlocked at the moment.
</game output>
Not quite the effect I was hoping. My hope is that since the glass bottle is
not a kind of key, the "Does the player mean" rule would not try to use the
glass bottle (or anything else in the room if it's not a key), since it's
"unlikely" that this is what the player meant. (I can see this might help me
simulate TADS' logicalRank property.)
- Jeff
Krister Fundin
"Neil Cerutti" <hor...@yahoo.com> skrev i meddelandet
news:slrnf31pgd....@FIAD06.norwich.edu...
> Maybe what we're seeing here is over-simplification of the
> disambiguation situations. Inform perhaps should not use the same
> rules for when an ambiguous word is provided and for when the
> word is completely omitted. That's the solution to the problem
> that was presented (by finagling the grammar), but it might be a
> general issue. "OPEN" is another verb that authors often complain
> about in testing their one-room knock-off games.
>
> Does TADS handle the two cases differently? If so, is it done
> with extra grammar, or with bifurcated disambiguation rules?
Quick briefing:
Yes, there's extra grammar for matching lock/unlock commands with
no specified key. (After all, some locks don't require keys.) For things
that can be locked/unlocked with a key, the direct object (a.k.a the
noun) would ask the parser for a second object. But that's mostly an
internal detail.
The thing that causes TADS 3 not to pick a desk or such is that all
objects, unless they say otherwise, are considered illogical for the
purpose of unlocking something. The parser looks through all objects
in scope in order to find the most logical candidate. If there is no
logical candiate, or if there are several that are equally logical, then
the parser will ask the player instead of choosing a default.
The part which decides on logicalness in the same in both cases,
except that an object can refuse to be chosen as a default even though
it's a logical candidate (to stop the parser from solving puzzles
automatically, for instance).
I think Inform could be changed to work similarly. The difference is
not really that large. The main problem is that it's too confident in
believing that it can pick a good default object. It should simply give
up more often.
-- Krister Fundin
Lem Signwriter
> Thanks. I didn't see that originally. So tying together what that section
> says and Lem's idea, I try this:
>
> <code>
> Rule for supplying a missing second noun while unlocking:
> if a random key (called target) is carried begin;
> change the second noun to target;
> end if;
> if the number of touchable keys is greater than 0 begin;
> change the second noun to a random touchable key;
> say "(trying [the second noun])";
> otherwise;
> say "You've got no keys!" instead;
> end if.
> </code>
>
> That seems to work moderately well. Can I generalize that further? Right now
> it ties everything to key objects. So if I have another type of thing that
> isn't unlocked by keys, I would need another rule like this. What I'm trying
> to do is get as generalized as possible.
My "random touchable key" wasn't intended as production code -
naturally, you'd really want to pick a key that the player already has
for preference. And there's a bug in your code above: after changing
second noun to target, it always falls through and changes it again if
there are any touchable keys. Also, to quote the docs: "Unexpected
results may follow if there is nothing in the game which fits the
description[.]" In a test game with no keys in, picking a random one
will return "nothing" - hence my testing for numbers greater than 0.
With that in mind:
<code>
Rule for supplying a missing second noun while unlocking:
if the number of keys carried by the player is not 0 begin;
change the second noun to a random key carried by the player;
rule succeeds;
otherwise;
if the number of keys in the location of the player is not 0 begin;
change the second noun to a random key in the location;
rule succeeds;
end if;
end if;
say "You have no keys!"; rule fails.
</code>
The moral of the story is obviously that Emily Short wrote Locksmith so
I'll never have to do this myself, because clearly I'm not up to the task!
Krister Fundin
"Jeff Nyman" <jeff...@gmail.com> skrev i meddelandet
news:crOdncvyJJPYZa3b...@comcast.com...
> Does the player mean unlocking when the noun is not a key: it is very
> unlikely.
Changing "noun" to "second noun" might do the trick ;-)
-- Krister Fundin
Lem Signwriter
> A related question, so I'll throw it here. With the above logic I've been
> using, I'd like to generalize the idea of "does the player mean." I try
> this:
>
> <code>
> The Study is a room.
>
> A key is a kind of thing.
>
> The glass bottle is in the Study.
>
> A container called the rolltop desk is in the Study. It is lockable. It
> is openable. It is closed. It is scenery.
>
> Does the player mean unlocking when the noun is not a key: it is very
> unlikely.
> </code>
>
> Note that last line. However, when you play this you get:
>
> <game output>
> >unlock desk
> (with the glass bottle)
> (first taking the glass bottle)
> That's unlocked at the moment.
> </game output>
>
> Not quite the effect I was hoping.
Quite.
The root of the problem is that while vanilla I7 knows that objects can
be locked, its concept of "key" is limited to - well, here's the docs again:
"[A lockable thing] can have a matching key, which must be another thing."
As far as it's concerned, there's no reason why the bottle couldn't
unlock something. (That's why I introduced the "A key is a kind" business.)
Saying that it is unlikely the player means an object which isn't a key
does affect the parser's decision, but only if it has a choice between a
key and a non-key thing. There's no point where the parser decides "all
the other things I can try that with are too unlikely" - it just takes
the most likely of all the possible things. If its choice is limited to
unlocking the desk with the desk or the bottle, it decides the bottle is
more likely than the desk, and tries that.
Now, if you had a glass bottle and a key called the glass key, and typed
UNLOCK DESK WITH GLASS, Inform would follow you perfectly: keys are more
likely than non-keys.
Emily Short
> I think from an authoring perspective, I prefer when the world model is
> already populated with things that tend to, on average, "make sense" and
> then allow me to hook into instances of my objects when what normally makes
> sense doesn't in the context of my world. I know Inform allows that as well
> but I guess I'm just finding it really clunky and I'm not always finding it
> consistent. I'm still working out how much of that is just my own ignorance
> and how much of that is fact about Inform.
>
> - Jeff
I can't speak to the other possible frustrations, but the particular
thing you're talking about is part of the underlying parser model and
has been irritating people to some degree or another since Inform 6:
if Inform can only find one direct object in scope for an action, it
*will* slot that into place; this occurs before you get to any action-
specific I7 rules, though there are (as people have pointed out) some
ways to kind of work around it.
There is a pending suggestion that this parser behavior be changed in
general; I don't know that the suggestion has been ruled on one way or
the other. It's something that I rarely tend to notice in released
games because usually there are too many things in scope to trigger
this particular problem; but that doesn't mean it shouldn't be
addressed, of course. However, ye list is long...
Lem Signwriter
> if Inform can only find one direct object in scope for an action, it
>
> There is a pending suggestion that this parser behavior be changed in
> general
<code>
Last before rule: if the noun is the second noun and the noun is not
nothing, say "That seems unlikely." instead.
</code>
I love I7 sometimes.
(Now somebody will point out to me the perfectly good reason why
sometimes that won't work.)
Khelwood
> On 2007-04-26, Jeff Nyman <jeffny...@gmail.com> wrote:
>
> > "villagedweller" <villagedwel...@googlemail.com> wrote in message
In T3 at least there's a verify stage where objects are declared
logical or illogical for actions, so it doesn't make assumptions that
apply an action to an illogical object.
Blank
it's just that different languages will provide different areas of
frustration.
Inform has traditionally provided a very 'light' world model, and the
assumption behind this seems to me to be that if each author builds the
custom handling required by that particular game, then at least they'll
know how their world model works, and the mechanics of such bespoke
world models will each be the best/most efficient for its particular game.
T3 on the other hand provides a single sophisticated model which is
designed to be flexible and customizable, but pays for that with
increased complexity.
I find when I'm writing in I6 or I7 I spend a lot of time writing
experimental code to try and get the behaviour I want. (Or suppress
default behaviour I don't want.)
By contrast when I'm writing in T3 I spend most of my time hunting
through the documentation to find the doesExactlyWhatIwant() macro.
I guess I'll just have to keep hammering away at each language until it
becomes transparent.
(I'd like to thank the T3 team for adding a built in editor to the
Workbench - I never could manage to get a separate editor to understand
the error report from the compiler, so I had to jump to the line number
by hand. Not a huge inconvenience, but all mental overhead was unwelcome
when I was pushing my wetware to the limit. The extra documentation on
how to use the debugger is very welcome, too.)
jz
Jeff Nyman
news:4631c8da$1...@news.kcl.ac.uk...
> T3 on the other hand provides a single sophisticated model which is
> designed to be flexible and customizable, but pays for that with increased
> complexity.
Interestingly enough, for me, I actually find TADS 3 less complex. Why?
Because I ultimately find it more understandable *because* of how flexible
and customizable it is.
That said, I'm used to so-called "traditional" programming languages that
have syntax and structures like TADS 3 (i.e., Java, C#, etc.) So that's
probably a large part of my conceptual hurdle. The other part of that, of
course, is that I don't like disassociated code (even if only by
appearance). All of my career has taught me programming in a style where you
encapsulate common elements together in one "object" and then generalize
that. Inform presents a very different model, of course, and allows (doesn't
encourage maybe, but allows) you to write very, very sloppy code.
With TADS 3, even if I did have to hunt down, as you say,
"doesExactlyWhatIwant()", at least when I find it, its clear to my *why* it
works, *how* it works, how it's going to work with the interpreter, and how
I might generalize or override that functionality. That's not always the
case for me with Inform 7, I'm finding.
Part of my problem often isn't finding what to do in the language, it's not
trusting the "language", by which I often mean ultimately how the parser
works. For example, this issue I brought up here with Inform: when the
system seems to act inconsistently in some cases, that worries me. Now,
granted, I understand why this happened and I see the Locksmith extension
and all that good stuff. But when even simple things like what I was trying
throw up obstacles, I get nervous about when I get to more complex things.
Inform 7 is still developing so I realize I'm being a bit unfair in
comparing it to TADS 3 in some ways. That said, as Emily mentioned in her
post, this issue of the first direct object being found and slotted carried
over from Inform 6 and I guess it's a lot of that "holdover" stuff that
frustrates me about Inform. I find I spend more time having to deal with
things that I feel should be part of the "system" (i.e., libraries, world
model, whatever). I think I got spoiled, for lack of a better term, by TADS
3 and its vast world model, which, while complex, is ultimately
understandable in an easily compartmentalized manner.
> I guess I'll just have to keep hammering away at each language until it
> becomes transparent.
Yeah, that's what I'm trying with Inform 7 as well. Basically what I do is
code up example ideas in both Inform 7 and TADS 3 and see what happens. It's
definitely interesting to have two such different languages to play with.
- Jeff
Blank
> "villagedweller" <village...@googlemail.com> wrote in message
> news:1177603331.6...@n35g2000prd.googlegroups.com...
>
>> I think with the bottle, in all fairness to inform, it doesn't know
>> what a desk or bottle is, and even if it did have a knowledge of
>> containers that made them unlikely to be used as keys, this could
>> cause all sorts of problems to someone who wanted to use a container
>> as a key.
>
Yes. To put yourself in Inform's position, try using ROT13 on a room
description. :)
> Right -- but the fact that Inform has no knowledge should, I would think,
> mean it errs on the side of caution; i.e., *not* trying to use a bottle as a
> key when it has no idea what it is. Why assume this thing you're carrying
> can be used to unlock anything at all?
>
> In the case of where someone wanted to use a container as a key, it could be
> specified as a key type object or as a special type of object. This would be
> a case of what I was talking about: the defaults act largely as people would
> expect. When this is not going to be the case, hook into the object and
> change its behavior. For example, TADS uses KeyedContainer,
> OpenableContainer, LockableContainer, etc.
>
> I think from an authoring perspective, I prefer when the world model is
> already populated with things that tend to, on average, "make sense" and
> then allow me to hook into instances of my objects when what normally makes
> sense doesn't in the context of my world.
The trouble is, what "makes sense" depends on context:
Imagine you have a dining room. One dining table, one dining chair. If
you sit in the dining chair, it makes sense that you can reach what's on
the table, yes?
With Inform, that's what happens. With T2 you have to include the table
in the "reach list" of the chair, or the player is told it's "out of
reach." (I may not have that exactly right, it's been awhile.) So,
Inform got that right.
But now imagine a large bedroom, with curtains on the window at the
other end of the room. The defaults for I6 meant that the player now had
ridiculously long stretchy rubber arms since he's able to draw the
curtains while lying on the bed. Here the T2 defaults "make sense."
> I know Inform allows that as well
> but I guess I'm just finding it really clunky and I'm not always finding it
> consistent. I'm still working out how much of that is just my own ignorance
> and how much of that is fact about Inform.
>
> - Jeff
>
>
The trouble with trying to build a "smart" world model is that you have
to introduce a lot of complexity in order to *fake* that smartness.
(It's important not to forget that the system is still just a dumb
bucket of bits.)
Really such "smartness" is just a lot of special case coding, so it's
fine for dealing with whatever the library authors have already
anticipated, but the moment you want to do something unanticipated - oh
baby. You've now got a whole lot of built-in assumptions that don't
match what you want to happen. (i.e. The Micro$oft User Experience.)
I've found that for a beginner (me) preventing the library from doing
unwanted stuff is a whole lot more difficult than adding complexity
where I want it because it means digging down through layers of coding
that have been written for maximum performance - which usually means
sacrificing comprehensibility. As a novice coder I often found the
library's code completely baffling and would give up - either rewriting
that bit of the game to conform to the library's expectations, or more
usually just abandoning it and starting a new project. At least when I
wanted the world to be more complicated I could usually cobble together
something that worked, kind of.
(Mind you when I look back at my past coding efforts I'm irresistibly
reminded of some of Prof. Pat Pending's wackier inventions.)
A dumb world model is much easier to write in, because you don't get the
library butting in so much, but it's not fun to play in because the
player then has to spend much of the game explaining the obvious to the
parser, so you get exchanges like:
>Eat banana
But you're not holding the banana.
or
>Take racket
Which do you mean, the tennis racket or the cats' chorus?
So any library/system is going to be a compromise between the
preferences of the authors vs the players.
Having said all that, at the moment I'm trying to learn T3. I'm prepared
to put up with all the complexities of sense handling and a lot of
twisty little classes all slightly different in return for sophisticated
support where I *do* want it: the elegant ActorState system for writing
npcs.
**Sinks from sight beneath a glowing, writhing mass of T3 code**
--jz
Blank
> On 2007-04-26, Jeff Nyman <jeff...@gmail.com> wrote:
>> "villagedweller" <village...@googlemail.com> wrote in message
>> news:1177603331.6...@n35g2000prd.googlegroups.com...
>>> I think with the bottle, in all fairness to inform, it doesn't
>>> know what a desk or bottle is, and even if it did have a
>>> knowledge of containers that made them unlikely to be used as
>>> keys, this could cause all sorts of problems to someone who
>>> wanted to use a container as a key.
>> Right -- but the fact that Inform has no knowledge should, I
>> would think, mean it errs on the side of caution; i.e., *not*
>> trying to use a bottle as a key when it has no idea what it is.
>> Why assume this thing you're carrying can be used to unlock
>> anything at all?
>
> Because the player provided nothing else to go on. If I command
> a one-year old to "eat", and she's holding nothing but a plastic
> car...
>
> Maybe what we're seeing here is over-simplification of the
> disambiguation situations. Inform perhaps should not use the same
> rules for when an ambiguous word is provided and for when the
> word is completely omitted. That's the solution to the problem
> that was presented (by finagling the grammar), but it might be a
> general issue. "OPEN" is another verb that authors often complain
> about in testing their one-room knock-off games.
I think it's partly a historical difference between the TADS and Inform
world models. In the TADS library there has always been a class of
things which can be unlocked without a key, whereas the Inform library
has always regarded something that can be unlocked without a key as
synonymous with opening it.
I remember reading the complaint of a habitual player of Inform games
who got stuck in a TADS game because the french windows were described
as 'locked' - which to the Informant necessarily implied the presence of
a key somewhere.
jz
Jeff Nyman
> The trouble is, what "makes sense" depends on context:
Agreed. This is largely what TADS 3 is built on. You've probably seen it,
but this talks about that a bit regarding what "logical" means:
http://www.tads.org/howto/t3res.htm
As the article states, "Here's the key: 'logical' means what the player
thinks it means." This is what attracted me to TADS because it seems that
the development system as a whole is forcing me, as an author, to also think
as a player.
> Imagine you have a dining room. One dining table, one dining chair. If you
> sit in the dining chair, it makes sense that you can reach what's on the
> table, yes?
Not necessarily, no. If I sit at one end of *my* dining table I can't reach
something on the other end without getting up. (Unless I have an incredibly
small table.) So....
> With Inform, that's what happens. With T2 you have to include the table in
> the "reach list" of the chair, or the player is told it's "out of reach."
> (I may not have that exactly right, it's been awhile.) So, Inform got that
> right.
I disagree that Inform got that right, necessarily. Clearly this is just
opinion. But, to me, Inform (by what you said) makes an assumption that is
not necessarily warranted. The Inform documentation says that it makes the
least possible assumptions based on consistency with the world model. The
least possible assumption would be not assuming the size of the table or the
placement of the chair.
> But now imagine a large bedroom, with curtains on the window at the other
> end of the room. The defaults for I6 meant that the player now had
> ridiculously long stretchy rubber arms since he's able to draw the
> curtains while lying on the bed. Here the T2 defaults "make sense."
To me, it means TADS 2 (and TADS 3) is consistent. It means Inform is not.
Again, just opinion.
> I've found that for a beginner (me) preventing the library from doing
> unwanted stuff is a whole lot more difficult than adding complexity where
> I want it because it means digging down through layers of coding that have
> been written for maximum performance - which usually means sacrificing
> comprehensibility.
I think you summed up our different experiences here very well, which is
clearly where our opinions diverge. So I definitely appreciate and
understand your viewpoint here.
> A dumb world model is much easier to write in, because you don't get the
> library butting in so much, but it's not fun to play in because the player
> then has to spend much of the game explaining the obvious to the parser,
> so you get exchanges like:
See -- here's where I'm not so sure. I don't think a "dumb world model" is
necessarily easier to write in, but, with a key caveat. The caveat: if you
know the kinds of things that are and are not possible in IF systems, that
may change how easy you find a "dumb world model" as opposed to a "smart
world model." I'm just throwing that out there. I'm not even sure of that
myself yet. I think a "dumb world model" does seem easier and probably
presents slightly less of a barrier to new people (particularly without
programming) but eventually I think that the "dumbness" makes itself felt.
Further, and as you indicate, the "dumbness" makes itself felt not only to
the author, but eventually to the player. (In another thread I had said that
Inform games often struck me as "cookie-cutter"-like when I played them and
this is largely what I think I meant by that.)
> So any library/system is going to be a compromise between the preferences
> of the authors vs the players.
Or: can you have both? I think TADS 3 goes a long way towards preferences of
the author and the players. I think Inform 7 could also do that (maybe?).
It's the "maybe" part (based on past experience with I6) that really makes
me hesitant to embrace Inform 7, even though I can recognize many of its
nice elements.
- Jeff
Lem Signwriter
>> Imagine you have a dining room. One dining table, one dining chair. If you
>> sit in the dining chair, it makes sense that you can reach what's on the
>> table, yes?
>
> Not necessarily, no. If I sit at one end of *my* dining table I can't reach
> something on the other end without getting up. (Unless I have an incredibly
> small table.) So....
>
>> With Inform, that's what happens. With T2 you have to include the table in
>> the "reach list" of the chair, or the player is told it's "out of reach."
>> (I may not have that exactly right, it's been awhile.) So, Inform got that
>> right.
>
> I disagree that Inform got that right, necessarily. Clearly this is just
> opinion. But, to me, Inform (by what you said) makes an assumption that is
> not necessarily warranted. The Inform documentation says that it makes the
> least possible assumptions based on consistency with the world model. The
> least possible assumption would be not assuming the size of the table or the
> placement of the chair.
You assume that the size and placement-within-room of an object are
relevant to anything. Inform doesn't.
>> But now imagine a large bedroom, with curtains on the window at the other
>> end of the room. The defaults for I6 meant that the player now had
>> ridiculously long stretchy rubber arms since he's able to draw the
>> curtains while lying on the bed. Here the T2 defaults "make sense."
>
> To me, it means TADS 2 (and TADS 3) is consistent. It means Inform is not.
> Again, just opinion.
Perfectly consistent. The difference is that TADS somehow models the
relative placement of objects within a room, whereas Inform's concept of
physical things consists almost entirely of whether a thing is or isn't
the child of another. ("Child of" meaning, depending on the types of
thing involved, inside/on top of/part of.)
Adam Thornton
Jeff Nyman <jeff...@gmail.com> wrote:
>"Blank" <bl...@nowhere.com> wrote in message
>news:4631d87f$1...@news.kcl.ac.uk...
>> sit in the dining chair, it makes sense that you can reach what's on the
>> table, yes?
>
>Not necessarily, no. If I sit at one end of *my* dining table I can't reach
>something on the other end without getting up. (Unless I have an incredibly
>small table.) So....
>
>> With Inform, that's what happens. With T2 you have to include the table in
>> the "reach list" of the chair, or the player is told it's "out of reach."
>> (I may not have that exactly right, it's been awhile.) So, Inform got that
>> right.
>
>I disagree that Inform got that right, necessarily. Clearly this is just
>opinion. But, to me, Inform (by what you said) makes an assumption that is
>not necessarily warranted. The Inform documentation says that it makes the
>least possible assumptions based on consistency with the world model. The
>least possible assumption would be not assuming the size of the table or the
>placement of the chair.
And here's a third viewpoint (this is the stage-set-vs.-model-world
argument again):
It is very, very rare that I care to simulate a dining table to that
degree of precision. Specifically, if I'm sitting at the table, and I
want to take something at the other end, as a player, I will take a more
enjoyable experience if I can just:
===begin fake transcript===
> TAKE SALT SHAKER
Taken.
===end fake transcript===
As opposed to:
===begin fake transcript===
> TAKE SALT SHAKER
You can't reach that from here.
> LEAN FORWARD AND TAKE SALT SHAKER.
You are now leaning forward.
You still can't quite reach the shaker.
> LEAN FORWARD, STRETCH, AND TAKE SALT SHAKER.
You are now leaning forward.
You put all your effort into a mighty stretch. Your fingertips can
barely graze the salt shaker.
You try to grasp the salt shaker, but it's still just a bit too far
away. Thump! You knock over the shaker, spilling some salt.
There is a small pile of salt on the table.
> GET UP
You rise from your seat.
Dining Room
This is the dining room at L'Maison Annoyance. Its chief feature is a
dining table, at which is one chair (unoccupied) and on which (at the
other end) is a salt shaker (on its side) and a small pile of salt.
> TAKE SHAKER
You're at the wrong end of the table.
> WALK TO OTHER END OF THE TABLE
You walk to the other end of the table.
Dining Room
This is the dining room at L'Maison Annoyance. Its chief feature is a
dining table, at which is one chair (unoccupied, and at the other end)
and on which is a salt shaker and a small pile of salt.
> TAKE SHAKER
Taken.
> SIT DOWN
The chair is at the other end of the table.
> WALK TO OTHER END OF TABLE
This is the dining room at L'Maison Annoyance. Its chief feature is a
dining table, at which is one chair (unoccupied) and on which (at the
other end) is a small pile of salt.
> SIT DOWN
You are now seated.
===end fake transcript===
For those rare occasions when I want *that* much simulation, I'd rather
code it myself and not have to worry about that kind of detail in my
world model when it doesn't matter, which will be the vastly more
frequent case.
Adam
Jeff Nyman
> You assume that the size and placement-within-room of an object are
> relevant to anything. Inform doesn't.
Good point -- but there's always assumptions, right? What I'm looking for is
how consistently they are applied with objects and their relationships,
including the disambiguation that is often necessary. Inform acting as
though size and placement-within-room are *not* an issue (and I agree, they
probably aren't in most cases) is an assumption in and of itself.
However, as it turns out, it's all somewhat based on a false premise here.
The original contention was:
** Dining Table, Chair **
TADS: You have to include the table in the "reach list" of the chair.
Inform: You can reach everything on the table.
** Bedroom, Curtains on Window **
TADS: You have to include the curtains in the "reach list" of the bed.
Inform: You can reach the curtains from the bed.
You don't have to make these items "reachable" in TADS (version 3, at
least). They are reachable in both cases just as they are in Inform. So here
both systems are, to me, consistent in what they allow and I was off-base on
this one, no doubt. More to the point, it would seem that by default both
systems do not make assumptions about placement and size, at least in the
case I tried here. (I used a TADS 3 Chair and Platform object for the dining
chair and the table, respectively. In Inform I used an enterable supporter
for both.)
- Jeff
Jeff Nyman
"Adam Thornton" <ad...@fsf.net> wrote in message
news:ufq9g4-...@quicksilver.fsf.net...
> For those rare occasions when I want *that* much simulation, I'd rather
> code it myself and not have to worry about that kind of detail in my
> world model when it doesn't matter, which will be the vastly more
> frequent case.
Very true and that all makes sense. I was originally more speaking to what
kind of assumptions the system made in different cases, particularly in the
case of Inform 7 when it claims it makes the fewest assumptions possible.
Which I agree: it does. I just wasn't sure if (a) that was a good thing and
(b) it was applied consistently.
But, really, in some ways as I think further on this, I am probably a bit
off in my thinking. I say that because my original thought was that I didn't
like how I had to code up all that rule stuff just for a simple UNLOCK
{OBJECT} action. That, to me, should be handled by a world model (which can
be overridden if and when necessary). In Inform 7's case, that functionality
*is* handled by the Locksmith extension.
For TADS 3, it's handled as part of the ADV3 library.
In reality, of course, it makes little difference whether the functionality
you want is via an extension or part of the library, I suppose. I guess what
"worried me" (for lack of a better phrase, since it's not keeping me up at
night) is if a "simple" thing like UNLOCK {OBJECT} is not handled by
default, what are some more complex things that are not handled by default?
Will I have to hope an extension exists or spend a lot of time writing my
own? If an extension does exist, can I use it to hook into various aspects
of the library? If I rely on a ton of extensions, what happens when changes
to the main system change how those extensions have to work (sometimes in
different ways)? Etc. Etc.
It's sort of like when I buy a word processor. I don't want to have to write
my own undo/redo functionality or hope someone else wrote an extension. If I
have an operating system, I don't want to have to write my own networking
layer or API or GUI support layer, etc. Relying on too many "extensions" to
systems has, in my experience, caused me more pain than having a system that
inherently supported the various aspects. I realize this analogy probably
sucks but that's sort of where my thinking was at. I'm now questioning
whether my thinking was valid.
- Jeff
Lem Signwriter
> "Lem Signwriter" <signw...@lem.signwriter.name> wrote in message
> news:f0td5f$ij2$1...@aioe.org...
>
>> You assume that the size and placement-within-room of an object are
>> relevant to anything. Inform doesn't.
>
> Good point -- but there's always assumptions, right?
Oh, there certainly are!