[General] The World Model
Jim Aikin
instance, consider a pair of tweezers. 'pick up stamp with tweezers' is easy
enough to implement, but if the stamp is being held by the tweezers rather
than by the player, 'drop stamp' takes a bit more finagling. The inventory
listing of the tweezers has to be managed by hand. Et cetera.
This set me thinking about the classic world model of IF. Certain things are
well understood and widely implemented in default libraries -- doors, for
example, and darkness, and containers that can be closed and opened. But
with some other types of interactivity that are readily seen in the real
world, the programmer is pretty much on his/her own.
In addition to indirect holders, I'd put windows in this group. Once we move
out of the cave world into worlds where there are buildings, windows (which
ought to allow one to look from one location to another) are often mentioned
in room descriptions -- but seldom implemented as actual functional objects.
Modeling a window is not a stroll in the park, for a variety of reasons, but
I'm hoping that in the future windows might become a standard fixture in IF
libraries, available to be deployed as needed.
The question I'd like to propose for discussion is, what other types of
objects and/or relations ought to be made standard? (By which I don't mean
"standardized," God forbid, just "available in the standard library" of
whatever system you're working with.)
Let's see ... there's more flexible conversation with NPCs. It ought to be
easier than it is to create objects that one can put things on, in, under,
or behind. Fluids -- a messy business.
What objects have you considered adding to a game, but didn't because the
code would get way too messy?
--Jim Aikin
****************************
"Those instances of it which lack
the quality referred to as 'swing'
are meaningless." --Duke Ellington
****************************
fel...@yahoo.com
> The question I'd like to propose for discussion is, what other types of
> objects and/or relations ought to be made standard?
Why, for starters, those already implemented in TADS3:
* windows,
* more flexible conversation with NPCs,
* easy to create objects that one can put things on, in, under,
or behind.
That's 80-90% of what you mentioned. Sounds like a good starting point.
Felix
Jim Aikin
>> objects and/or relations ought to be made standard?
>
> Why, for starters, those already implemented in TADS3:
>
> * windows,
> * more flexible conversation with NPCs,
> * easy to create objects that one can put things on, in, under,
> or behind.
I looked at TADS 3 last winter. Actually started working on a game in it,
which I have now ported over to Inform 6. Not to get into a Language Wars
type of discussion, though, because that isn't really the point. The
question I would have is more general.
For instance: How should a window object behave? Can this behavior be
defined or clarified in a non-language-specific way that would allow
everyone, no matter what language they're using, to take advantage of the
model of a window?
As a starting point:
1) A window has two sides, which are in different locations. It never has
more than two sides.
2) A window can be closed or open. (And it may be closable/openable, or
not.) If it's open, its behaviors might include allowing objects to be
passed through from one side to the other -- or not. If it's open, you would
probably be able to hear conversations (or other sounds) in the other
location.
3) A window can typically be opened and closed only from one side.
4) A window may have curtains. If the curtains are closed, you can't see
through.
5) The curtains are typically in the same location as the open/close
mechanism, and can also be opened or closed only from that side.
6) If the curtains are open, you can view what's in the other location.
However, you probably won't be able to view objects that are (a) smaller
than a certain size, (b) contained in open containers, or (c) hidden by
being against the same wall as the window. As a result, 'look through the
window' can't simply be processed as a 'look' action in the other room.
7) If the curtains are closed, you can see the curtains themselves from the
other side.
8) A window will pass light from one location to the other.
9) In one location, 'look in window' will work, but 'look out of window'
won't. In the other location, the operation of the prepositions is reversed.
10) Depending on its size, a window might be something you can crawl
through. In other words, it might be a door with the special property that
only a 'crawl' action will work.
11) A door (such as a sliding glass door) might also be a window.
Item 6 is especially tricky, because it means (a) that everything that can
possibly be in a room adjacent to a window (whether portable or scenery)
needs a size property, and (b) that scenery objects in a room adjacent to a
window need a "hidden from the window" flag that can be tested.
None of this is impossible to implement, as far as I can see. It's just
trickier for the game designer than declaring that something is a container
and letting the default library handle putting things in it and taking
things out. Even if your language implements windows, you still have to
handle the coding of objects for through-window visibility manually.
And there may be other criteria that I'm overlooking. That's why I'm asking
the question....
--Jim Aikin
Michael Martin
> The question I'd like to propose for discussion is, what other types of
> objects and/or relations ought to be made standard? (By which I don't mean
> "standardized," God forbid, just "available in the standard library" of
> whatever system you're working with.)
How are these not synonymous? Fourteen conflicting implementations of
fluids wouldn't make for a very convenient standard library.
If you mean "Somebody should write extensions that do this", "feel
free" is the traditional answer.
>Modeling a window is not a stroll in the park, for a variety of reasons, but
>I'm hoping that in the future windows might become a standard fixture in IF
>libraries, available to be deployed as needed.
TADS 3 apparently covers them in some form. The Inform 7 manual has
three different models of windows implemented, albeit as individual
objects. Generalizing the rules for those objects to instead involve
objects of a certain type (window) should be straightforward, and that
would allow you to mix in another extension.
The scope handling necessary for doing it in Inform 6 is, again,
notoriously obnoxious.
> Let's see ... there's more flexible conversation with NPCs.
TADS 3 has a fairly complex model, apparently, though I haven't really
seen it used for much besides variants on menu-based systems. Inform 6
has the ORB library extensions. Inform 7 has three or four conflicting
models demonstrated within its manual, and then the Extensions page
includes a few others, including one that's Currently Highly
Nonstandard.
> It ought to be easier than it is to create objects that one can put things on, in, under, or behind.
Inform 6 is notoriously bad at this. Inform 7 has at least one example
that implements this with relations -- it should be reasonably feasible
to make standalone extensions that implement underlying, obscuring, or
both. TADS 3 apparently implements this directly. I would guess TADS
2 doesn't touch it much, since I haven't seen it in any TADS 2 games.
> Fluids -- a messy business.
Nobody even agrees what an acceptable model for fluids should *be*, so
having a "standard solution" would be wasted code in almost all cases.
In the "I should write an extension that does this, but I don't need it
*now* and am lazy" department, coordinate-based navigation (as if one
were wandering on a large chessboard) would have come in handy for me
for a few scenes I've been batting around.
--Michael
Jim Aikin
>> objects and/or relations ought to be made standard? (By which I don't
>> mean
>> "standardized," God forbid, just "available in the standard library" of
>> whatever system you're working with.)
>
> How are these not synonymous? Fourteen conflicting implementations of
> fluids wouldn't make for a very convenient standard library.
Indeed. I didn't express myself well. What I meant was that a model for such
things should be included in a standard distribution of an IF language, not
tacked on as an extension -- but at the same time, the models should be
customizable.
> If you mean "Somebody should write extensions that do this", "feel
> free" is the traditional answer.
I'm working on a couple of things, but they may involve hacking I6 at a
fairly deep level, and I'm not THAT good a programmer.... My interest in
writing I7 extensions (or, indeed, in learning I7) is sharply limited, but
that may change after I get my current WIP done.
>> It ought to be easier than it is to create objects that one can put
>> things on, in, under, or behind.
>
> Inform 6 is notoriously bad at this.
I've done it in the past, but (if memory serves) by creating an invisible
"under the Christmas tree" supporter, which was where objects ended up.
>> Fluids -- a messy business.
>
> Nobody even agrees what an acceptable model for fluids should *be*, so
> having a "standard solution" would be wasted code in almost all cases.
Well, perhaps figuring out what the model should be (and what variations
would be most useful) would be a place to start. I'll think about it.
--JA
Andrew Plotkin
>
> None of this is impossible to implement, as far as I can see. It's just
> trickier for the game designer than declaring that something is a container
> and letting the default library handle putting things in it and taking
> things out.
I wonder if that's true. It's certainly trickier for the *library*
designer to create a universal window than for the game designer to
implement a window which just satisfies criteria 1, 2, and 8 (or
whatever).
Obviously it's tempting to say "the library designer does a lot of
work, and then the problem is solved for everybody" but I worry that
the result will wind up being more cranky and idiosyncratic than truly
reusable.
This is why I'm concentrating on the idea of making it easier for game
designers to mix and match pieces of code. I'd like to see a set of
window *examples* -- this one has a curtain, this one transmits light,
this one can be crawled through -- in a system where it's not
frightening to put bits together.
--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.
Jan Thorsby
that turns all the standard responses to past tense. One that can be turned
on or off at different parts of the game. (Maybe also future tense?) Also
one that switches to first person, and to the various forms of third person.
Jan Thorsby
"Jan Thorsby" <no_spam@spam> skrev i melding
news:4506...@news.broadpark.no...
Oh and maybe the possibility of defining the word used for third person.
Like if you say the word is "Laura" and the player types "jump" they get
"Laura jumps on the spot".
Emily Short
I'm pretty sure that TADS 3 comes with this ability, and there is an
extension to do it in Inform 7.
Neil Cerutti
>> If you mean "Somebody should write extensions that do this",
>> "feel free" is the traditional answer.
>
> I'm working on a couple of things, but they may involve hacking
> I6 at a fairly deep level, and I'm not THAT good a
> programmer....
In my experience, that's the biggest hurdle to Inform 6 extension
development. It's relatively easy to package up stuff that's
outside Inform's world model (most of L.Ross Raszewski's great
contributions), but putting new stuff into the world model almost
always requires the use of Entry Points (this makes trouble for
authors) and sometimes requires replacing library routines (this
makes even more, and also inconveniences the extension
implementor with versioning problems).
I don't think implementing window-like objects is particularly
hard to do in Inform 6, but packaging that implementation in a
library extension that's easy to use and maintain is difficult.
Inform provides most of the means necessary to extend the world
model, but those means aren't well designed for the use of
extension authors.
> My interest in writing I7 extensions (or, indeed, in learning
> I7) is sharply limited, but that may change after I get my
> current WIP done.
>> Nobody even agrees what an acceptable model for fluids should
>> *be*, so having a "standard solution" would be wasted code in
>> almost all cases.
>
> Well, perhaps figuring out what the model should be (and what
> variations would be most useful) would be a place to start.
> I'll think about it.
Emily Short expended a lot of effort in that direction. Perhaps
she will chime in here, but if not, a recent thread on Inform 7
contains her experiences.
--
Neil Cerutti
This scene has a lot of activity. It is busy like a bee dive.
--Michael Curtis
Emily Short
Neil Cerutti wrote:
> >> Nobody even agrees what an acceptable model for fluids should
> >> *be*, so having a "standard solution" would be wasted code in
> >> almost all cases.
> >
> > Well, perhaps figuring out what the model should be (and what
> > variations would be most useful) would be a place to start.
> > I'll think about it.
>
> Emily Short expended a lot of effort in that direction. Perhaps
> she will chime in here, but if not, a recent thread on Inform 7
> contains her experiences.
Hm. Well, okay. Here are some ways I have implemented liquids:
-- a source of liquid is localized in one place and cannot be used to
fill containers. Things thrown into the source are removed from play.
Other interaction is discouraged. (Metamorphoses.)
-- a source of liquid is localized in one place and cannot be used to
fill containers, but things dipped into the source become wet, then dry
again gradually. (Unreleased sample code.)
-- a container of liquid is understood to be the same thing as the
liquid it contains, and "drinking" removes this object from the game.
(See Inform 7 manual.)
-- a container of liquid can be full or empty, and responds to FILL and
POUR, but the liquid is not treated with greater complexity than that.
(Bronze.)
-- a container of liquid has varying fullnesses, but the liquid
contained is not implemented separately; it cannot be poured, divided,
or mixed; there are no puddles, wetting of other objects, etc. (See
Inform 7 manual.)
-- a container of liquid contains a specific quantity of liquid.
Liquids may be divided by pouring into other vessels, but liquids do
not exist outside containers and mixture is prevented. (See Inform 7
manual.)
-- a container of liquid contains a specific quantity of liquid;
liquids may be divided by pouring into other vessels, but liquids do
not exist outside containers; it is possible to define a liquid
"source" from which an infinite amount of that liquid type can be
taken. (See Inform 7 manual.)
-- liquids can be poured; liquids can be heated; liquids extinguish
fire. (Fire library for Inform 6, unreleased because it got out of
hand.)
-- liquids have quantities and are theoretically infinitely divisible;
liquids can be mixed; liquids can exist as puddles outside any
container. Powders are implemented as "dry" liquids. Other objects in
the game can be made wet through sharing a container with a liquid;
objects in a container with liquid can sink or float; objects can
absorb liquid and be squeezed to release said liquid again; containers
may be defined as leaky so that liquid flows through them at a
predetermined rate. (See Waterelement.h for Inform 6.)
-- The same as above, but with some additions. Piping and gradual
evaporation in sunlight are implemented. Colors of mixed liquids are
combined and the color of the result described, and colors may be used
to dye other objects. (See Savoir-Faire.)
-- liquids have no quantities or pourability and cannot be mixed;
however, contact between objects is tracked and things become wet when
in a container with liquid or touched with other wet objects. (See
Inform 7 manual.)
-- liquids have quantities and are theoretically infinitely divisible;
liquids can be mixed; mixtures of liquids are analyzed to discover the
best description for the mixture depending on a predefined "recipe", so
that names for mixed beverages like "strong screwdriver" may be
automatically generated. Wetting other objects, flotation, absorption
are ignored. Liquids may not exist outside a container. (See Inform 7
manual.)
Of these, the most thorough-going is WaterElement, which various people
have mentioned trying; but to the best of my knowledge no one else has
ever used it in a completed game. My impression is that this is not a
fluke, but is rather exactly what one should expect for an extremely
complex library that attempts to furnish everything including the
kitchen sink. (Literally, in this case.) Not only are such libraries
challenging to understand, but they often impose other requirements on
the designed world, such as that the author build in lots of data about
each object (capacity, ability to float, wetness/dryness, etc). They
may also prove hard to extend or merge with other behavior.
For that matter, though WaterElement was excessively complicated, it
still didn't have enough functionality to do many of things I did with
various other liquid models (though some of those were considerably
lighter-weight as code).
For reference, some other liquid implementations for Inform 6:
-- ORLiquid (http://www.onyxring.com/downloads/orlib/orliquid.h). I
haven't studied this, but it appears to distinguish between wet and dry
liquids, allow liquids to be poured between containers, calculate room
remaining, and so on. I do not see at a glance that it handles liquid
mixtures, but I could be wrong.
-- Roger Firth's brief implementation
(http://www.firthworks.com/roger/informfaq/ww.html#8). Handles filling
and emptying containers, but not quantification, mixture, etc.
As I recall, Risorgimento Represso also does some cool things with
liquid containers and quantities; there are probably some other games I
am not thinking of at the moment.
To step back for a moment: as the foregoing may suggest, I'm not
convinced that complex simulation libraries are as useful as they might
look. However, if you are interested in coming up with a specification
for the ideal library, it might be worth doing a feature comparison of
existing libraries and extensions for known languages and noting (if
possible) which of those features turned up in actual finished games.
Al
(SNIP)
Of these, the most thorough-going is WaterElement, which various people
have mentioned trying; but to the best of my knowledge no one else has
ever used it in a completed game. My impression is that this is not a
fluke, but is rather exactly what one should expect for an extremely
complex library that attempts to furnish everything including the
kitchen sink. (Literally, in this case.) Not only are such libraries
challenging to understand, but they often impose other requirements on
the designed world, such as that the author build in lots of data about
each object (capacity, ability to float, wetness/dryness, etc). They
may also prove hard to extend or merge with other behavior.
(SNIP)
To step back for a moment: as the foregoing may suggest, I'm not
convinced that complex simulation libraries are as useful as they might
look. However, if you are interested in coming up with a specification
for the ideal library, it might be worth doing a feature comparison of
existing libraries and extensions for known languages and noting (if
possible) which of those features turned up in actual finished games.
It appears that there is definitely no standard way of handling
liquids. Each author may wish to treat such liquids and types of
liquids differently. Emily for one may have a mixture of olive oil and
water. Andrew on the other hand may try to mix ketchup and chocolate
syrup. The results of which are most likely totally different. Then
Emily could do the ketchup-syrup mix and her concotion would probably
kill every Al-Qaeda terrorist out there. Pouring of certain kinds of
liquids. evaporation, etc are left up the author's imagination and as
they say they whole world at large will probably never be on the same
page.
Eric Eve
news:1158057967.9...@i3g2000cwc.googlegroups.com...
It does; that is it has a switch to change all the standard
responses to past tense, and a property of the player character
object to switch between first, second and third person narration.
The future tense is not supported (though I can't imagine there
being much demand for it in practice).
-- Eric
Eric Eve
>
> Of these, the most thorough-going is WaterElement, which various
> people
> have mentioned trying; but to the best of my knowledge no one else
> has
> ever used it in a completed game. My impression is that this is
> not a
> fluke, but is rather exactly what one should expect for an
> extremely
> complex library that attempts to furnish everything including the
> kitchen sink. (Literally, in this case.) Not only are such
> libraries
> challenging to understand, but they often impose other
> requirements on
> the designed world, such as that the author build in lots of data
> about
> each object (capacity, ability to float, wetness/dryness, etc).
> They
> may also prove hard to extend or merge with other behavior.
> To step back for a moment: as the foregoing may suggest, I'm not
> convinced that complex simulation libraries are as useful as they
> might
> look.
While I don't at all disagree with the main point your making, I
think one can in principle make a distinction between a complex
simulation library that *forces* authors to worry about a whole lot
of extra properties, and one that allows them just to implement the
ones they need (e.g. by choosing suitable defaults for the rest).
For example someone devising a library to limit the carrying
capacity of actors and objects might come up with a model that
involves bulk, weight, and maximum dimension, say, in an extension
that allows authors to set limits on each for actors, surfaces and
containers, but sets the defaults such that these limits have no
effect (e.g. by default every object has a weight, bulk and maximum
dimension of zero and a maximum capacity for all three of the
largest integer available on the system, or even a magic number
like -1 meaning 'no limit). Then if an author is only interesting
in limiting the amount of bulk that can be put into containers, he
only has to set bulk limits on containers and the bulk of portable
items, ignoring the rest of the model. If a second author is also
interested in limiting the amount of weight the PC can carry, she
can specify the weight of all portable items and the weight-carrying
capacity of the PC. Neither author then has to use the parts of the
model that aren't relevant to their needs.
I suppose a second theoretical distinction is between a complex
simulation model that hides most of its complexity under the hood
(you basically just add it to the game and allow it to get on with
it) and one that requires a great deal of author intervention to
make it function well. To some extent, we've covered this ground in
previous discussions, and we're agreed that in often in practice the
extra authorial intervention is necessary to prevent dissonant
default responses. The more complex library/extension functions that
work best without much authorial intervention may tend to be those
that improve the player interface (e.g. by providing a suitable set
of implicit actions to relieve the player of the busy-work of
unlocking and opening a door, or picking up an object before putting
it in a container) rather than those that complicate the world
model.
But I have other reasons for doubting that ever-more-complex
simulation libraries/extensions is really the way to go. They're
clearly of value if they solve one or more problems common to a
reasonably large subset of IF works, but simulation in IF is
generally a means to some other end (such as story-telling or
puzzle-creation) and it's not immediately obvious to me that
ever-increasingly-sophisticated general-purpose simulation really
serves any of the end of IF. One is, after all, trying to support
the creation of works of Interactive Fiction rather than experiments
in ever more realistic simulated worlds. That's not to say that an
individual work of IF may not usefully implement a complex model
suited to its particular story or puzzles, but that's a different
issues.
> However, if you are interested in coming up with a specification
> for the ideal library, it might be worth doing a feature
> comparison of
> existing libraries and extensions for known languages and noting
> (if
> possible) which of those features turned up in actual finished
> games.
I think we're converging to similar conclusions here. The ideal
library for IF (assuming there is such a thing as *the* ideal
library for IF, which may be questionable - but I don't think you'd
disagree with that) is not one that incorporates every cool feature
that anyone can dream up to make all works of IF model features of
the real world (down to muddy footprints in the hall when the PC
comes in from the rain, scalded PC mouths for drinking her coffee
too soon after boiling the kettle, auto-generated piles of junk mail
pushed through every letterbox in the game, and a 'need to go to the
loo' daemon that works three times as fast once the PC has drunk her
lukewarm coffee), but just that set of features that is used, say,
in more than 50% of finished games. The figure of 50% is unimportant
here - the point is that the optimum library complexity is something
vastly different from the maximum library complexity (but is also
not necessarily equal to the minimum library complexity).
But I think I need to qualify the foregoing paragraph (and, by
implication, the statement of yours I was responding to) in one
respect. The absence of a library feature from the great majority of
finished works is not automatically an argument against its
inclusion in a library, since (a) it may simply not exist yet (but
would be welcomed by many game authors if it did) or (b) it serves a
need but is under-used because it is too difficult to use (so that a
more author-friendly implementation might well receive a greater
take up); or (c) it is relatively new and, though potentially
useful, it hasn't yet had sufficient time to appear in a substantial
proportion of completed games. IOW, usage statistics from existing
completing works *could* be misleading under some circumstances,
particularly in areas where the need for innovation and
experimentation is quite widely felt (e.g. conversation systems).
-- Eric
Jim Aikin
"Jan Thorsby" <no_spam@spam> wrote in message
news:4506...@news.broadpark.no...
> Don't know if any system does this, but it would be nice to have a
> "switch" that turns all the standard responses to past tense. One that can
> be turned on or off at different parts of the game. (Maybe also future
> tense?)
Future tense could produce a creepy and effective tone:
> open cupboard
You will open the cupboard.
>search cupboard
In searching the cupboard, you will find a bottle.
>drink bottle
You will drink the contents of the bottle. It will taste very strange.
I think I like this, but it might get old pretty fast....
--JA
steve....@gmail.com
> I've been implementing (in Inform 6) a concept I call indirect holding. For
> instance, consider a pair of tweezers. 'pick up stamp with tweezers' is easy
> enough to implement, but if the stamp is being held by the tweezers rather
> than by the player, 'drop stamp' takes a bit more finagling. The inventory
> listing of the tweezers has to be managed by hand. Et cetera.
>
> This set me thinking about the classic world model of IF. Certain things are
> well understood and widely implemented in default libraries -- doors, for
> example, and darkness, and containers that can be closed and opened. But
> with some other types of interactivity that are readily seen in the real
> world, the programmer is pretty much on his/her own.
I agree, and "indirect holding" seems both typical enough and abstract
enough that a well-worked library would enable that scenario with
minimal effort on the part of the game-writer.
> In addition to indirect holders, I'd put windows in this group.
Certainly. Or, if "windows" is not abstract enough, something like
sense-transmission between connected locations, so that would cover
"sound-windows" for example, like paper walls or ventilation ducts.
> The question I'd like to propose for discussion is, what other types of
> objects and/or relations ought to be made standard? (By which I don't mean
> "standardized," God forbid, just "available in the standard library" of
> whatever system you're working with.)
Eric answered this point perfectly well, but I would say simply
"whatever is generalizable and typical useful." Normally you can so
arrange the classes that general behaviors parent specific behaviors,
and so arrange things nicely, and set things up so powers which are not
relevant to specific games are simply not called upon. Sometimes this
is a question of delicately balancing defaults, and carefully limiting
the library-level implementation.
The development of TADS 3 teaches us (or me, at least) a lot about how
that whole balance works, power and extensibility, levels of
generalization into class-hierarchy, and so on. -- Well worth further
elaboration. A very important question.
OKB (not okblacke)
> 6) If the curtains are open, you can view what's in the other
> location. However, you probably won't be able to view objects that
> are (a) smaller than a certain size, (b) contained in open
> containers, or (c) hidden by being against the same wall as the
> window. As a result, 'look through the window' can't simply be
> processed as a 'look' action in the other room.
<snip>
> Item 6 is especially tricky, because it means (a) that everything
> that can possibly be in a room adjacent to a window (whether
> portable or scenery) needs a size property, and (b) that scenery
> objects in a room adjacent to a window need a "hidden from the
> window" flag that can be tested.
I'm just going to comment on this one because it's something I
spent a good deal of time messing with in TADS 3. Basically, I think
it's even trickier than you think it is.
For starters, what if you have a room with two windows? You can't
just give every object a "hidden from the window" flag; you need to
specify which window.
But what's REALLY complicated is that it's not just "things on the
wall next to the window" that are invisible, it's "things which don't
have a direct line-of-sight to the window" -- in other words, things
might be obscured by other things.
The standard IF spatial model does not have a generalized notion of
the positions of objects within their containers. You can have a room,
and stuff can be in it, and stuff can be on top of other stuff, but
there's no idea of whether a certain object is "next to" or "across the
room from" or "looming over" another object. This is fine for the
standard IF interaction model, because that model generally assumes that
the player-character is in the room too, so you can assume that the PC
implicitly walks around the room to see whatever is behind whatever
else.
When you're looking through a window, though, your POV is tightly
restricted, so what you can see depends on the distribution of objects
in the room. If you have a room with a bookshelf in the middle, and a
window on the wall across from the bookshelf, you won't be able to see
anything on the other side of the bookshelf when you look through the
window.
Because of this, it seems like you have two choices: you either
make a big simplification, or you change the entire IF spatial model and
allow yourself to specify the positions of objects.
And, in the end, the most common simplification is probably "make
the window an object with a statis 'look through' description". This
completely avoids any real world-model concerns. Your idea of hiding
objects on the wall adjacent to the window is also a simplification, and
hiding objects on the wall AND in containers is also a simplification.
None of these simplifications is necessarily wrong, but the point is
that -- for this case as well as for many other world-model problems --
there's a continuum of possibilities ranging from "make it static text"
to "write a physics engine", and it's not always obvious that there is a
"right" place to draw the line and write a library implementation.
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown
steve....@gmail.com
> I'd like to see a set of window *examples* [...]
Oh, like in I7? Yeah, great, wow.
> in a system where it's not frightening to put bits together.
Oh, like in TADS 3? Eww, boo, hiss.
Why thinly disguise in the abstract and subjunctive?
Sure examples are great. So are extensions. So is a robust library to
begin with. I'd vote for all three.
Oh, and of course TADS 3 is very well self-coordinated: I haven't heard
any serious argument that TADS 3 makes "putting bits together" at all
"frightening" -- which seems to be your implication. Indeed, that's a
major benefit of developing all-together the kind of stuff Jim is
talking about (the world model), as he points out: all the features
cooperate very well. (Not so with I7 extensions or examples, though I
wouldn't complain that I7 is therefore "frightening." I'd say instead
it's a negative you take along with the positive; such is life.)
Kevin Forchione
news:1158089108.5...@i42g2000cwa.googlegroups.com...
> Jim Aikin wrote:
>> I've been implementing (in Inform 6) a concept I call indirect holding.
>> For
>> instance, consider a pair of tweezers. 'pick up stamp with tweezers' is
>> easy
>> enough to implement, but if the stamp is being held by the tweezers
>> rather
>> than by the player, 'drop stamp' takes a bit more finagling. The
>> inventory
>> listing of the tweezers has to be managed by hand. Et cetera.
>>
>> This set me thinking about the classic world model of IF. Certain things
>> are
>> well understood and widely implemented in default libraries -- doors, for
>> example, and darkness, and containers that can be closed and opened. But
>> with some other types of interactivity that are readily seen in the real
>> world, the programmer is pretty much on his/her own.
>
> I agree, and "indirect holding" seems both typical enough and abstract
> enough that a well-worked library would enable that scenario with
> minimal effort on the part of the game-writer.
These situations seem to be a case of where an object acts as a
sense-extension for an actor. For instance, a pair of tweezers.
Amplification or dimunition of the sense would be an important aspect of the
object, was well as handling specific commands, such as in the case of a
touch-extension, the "drop" command. In these cases the command should
probably be routed through the actor and percolated down these extensions.
--Kevin
--Kevin
steve....@gmail.com
> > I agree, and "indirect holding" seems both typical enough and abstract
> > enough that a well-worked library would enable that scenario with
> > minimal effort on the part of the game-writer.
>
> These situations seem to be a case of where an object acts as a
> sense-extension for an actor. For instance, a pair of tweezers.
> Amplification or dimunition of the sense would be an important aspect of the
> object, was well as handling specific commands, such as in the case of a
> touch-extension, the "drop" command. In these cases the command should
> probably be routed through the actor and percolated down these extensions.
So... the root class for Tweezers would be, what... Prosthetic? Lovely:
you outdo yourself.
I agree it's a very interesting project.
Jim Aikin
<steve....@gmail.com> wrote in message
news:1158095632.1...@e63g2000cwd.googlegroups.com...
>
>> These situations seem to be a case of where an object acts as a
>> sense-extension for an actor. For instance, a pair of tweezers.
>> Amplification or dimunition of the sense would be an important aspect of
>> the
>> object, was well as handling specific commands, such as in the case of a
>> touch-extension, the "drop" command. In these cases the command should
>> probably be routed through the actor and percolated down these
>> extensions.
I'm not sure how a pair of tweezers acts as a sense-extension, but I don't
know TADS 3 ... this may be obvious to those who do. To me, an indirect
holder isn't about sensing, it's about holding. Here's my preliminary list
of the things an indirect holder should be able to do:
-- You have to be holding an indirect holder before you can pick something
up with it.
-- If you set down an indirect holder, whatever is in it will fall out
(unless the holder is, for instance, a pair of pliers with a latch that
clamps its jaws together).
-- While using (though not simply holding) an indirect holder, you can be
holding, at most, one other thing, because manipulating an indirect holder
takes at least one hand and perhaps two, depending on its size.
-- A holder can hold only one object at a time.
-- Each holder has a maximum size of the object that it can contain. ('pick
up cement block with tweezers' has to be disallowed.)
-- Travelling from place to place while holding an indirect holder that
contains something may or may not be awkward, depending on the holder.
-- What is held by an indirect holder is visible.
-- The 'drop' action functions almost exactly the same with an indirectly
held object as with a directly held object, but needs special code, because
the default library will think you're not holding whatever the holder is
holding.
-- An indirect holder is not like a container, in that you can't 'put x in
holder'. You can only 'pick up x with holder'.
-- A thing may want to be consulted before it allows itself to be indirectly
held.
-- Putting things in containers and on supporters when they're indirectly
held, and getting them out again, will also require special code, at least
in Inform 6, because the Insert, PutOn, Receive, and LetGo actions tend to
assume that the actor is holding the noun.
I'm tinkering with an example game that implements all this ... but I'd
kinda rather get back to the project I'm actually working on!
--JA
steve....@gmail.com
> I'm not sure how a pair of tweezers acts as a sense-extension, but I don't
> know TADS 3 ... this may be obvious to those who do.
No, I wouldn't envision it that way. Stethoscope would probably be a
different sort of object. (But I acknowledge that one figures out the
correct implementation by *doing*, not by guessing how to do.)
> To me, an indirect
> holder isn't about sensing, it's about holding.
That would be my approach.
> Here's my preliminary list of the things an indirect holder should be able to do:
I agree with your specification (and thanks -- I might actually pick up
the project), with two quibbles:
> -- While using (though not simply holding) an indirect holder, you can be
> holding, at most, one other thing, because manipulating an indirect holder
> takes at least one hand and perhaps two, depending on its size.
I think that runs against the typical IF, which tends to ignore
"hands", and typically allows more than two (or four, or six) objects
to be held at the same time.
> -- Travelling from place to place while holding an indirect holder that
> contains something may or may not be awkward, depending on the holder.
TADS 3 does have a mechanism for this. I'd have to do some work to
figure out how Attachable and Holder would work together, especially in
relation to travel.
Andrew Plotkin
> Andrew Plotkin wrote:
> > I'd like to see a set of window *examples* [...]
>
> Oh, like in I7? Yeah, great, wow.
>
> > in a system where it's not frightening to put bits together.
>
> Oh, like in TADS 3? Eww, boo, hiss.
>
> Why thinly disguise in the abstract and subjunctive?
Right, well-spotted.
How about we pretend that I'm irrationally terrified of T3, and you
can psychoanalyze from there.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't thrown you in military prison without trial,
it's for one reason: they don't feel like it. Not because you're patriotic.
Kevin Forchione
news:4oBNg.1041$7I1...@newssvr27.news.prodigy.net...
>
> "Jan Thorsby" <no_spam@spam> wrote in message
> news:4506...@news.broadpark.no...
>> Don't know if any system does this, but it would be nice to have a
>> "switch" that turns all the standard responses to past tense. One that
>> can be turned on or off at different parts of the game. (Maybe also
>> future tense?)
>
> Future tense could produce a creepy and effective tone:
>
>> open cupboard
> You will open the cupboard.
>
>>search cupboard
> In searching the cupboard, you will find a bottle.
>
>>drink bottle
> You will drink the contents of the bottle. It will taste very strange.
And creepier yet...
>eat toadstool
You will eat the toadstool. It will be poisonous.
You will die...
--Kevin
Emily Short
Eric Eve wrote:
> While I don't at all disagree with the main point your making, I
> think one can in principle make a distinction between a complex
> simulation library that *forces* authors to worry about a whole lot
> of extra properties, and one that allows them just to implement the
> ones they need (e.g. by choosing suitable defaults for the rest).
This is true.
> I suppose a second theoretical distinction is between a complex
> simulation model that hides most of its complexity under the hood
> (you basically just add it to the game and allow it to get on with
> it) and one that requires a great deal of author intervention to
> make it function well. To some extent, we've covered this ground in
> previous discussions, and we're agreed that in often in practice the
> extra authorial intervention is necessary to prevent dissonant
> default responses.
Yup, this is partly a recap of things we have already discussed, and I
certainly agree with you here:
> it's not immediately obvious to me that
> ever-increasingly-sophisticated general-purpose simulation really
> serves any of the end of IF.
> But I think I need to qualify the foregoing paragraph (and, by
> implication, the statement of yours I was responding to) in one
> respect. The absence of a library feature from the great majority of
> finished works is not automatically an argument against its
> inclusion in a library, since (a) it may simply not exist yet (but
> would be welcomed by many game authors if it did) or (b) it serves a
> need but is under-used because it is too difficult to use (so that a
> more author-friendly implementation might well receive a greater
> take up); or (c) it is relatively new and, though potentially
> useful, it hasn't yet had sufficient time to appear in a substantial
> proportion of completed games. IOW, usage statistics from existing
> completing works *could* be misleading under some circumstances,
> particularly in areas where the need for innovation and
> experimentation is quite widely felt (e.g. conversation systems).
No, I had in mind a slightly more nuanced interpretation of the
evidence than just "no one has used this yet, so it's not useful at
all." There are new systems out there that haven't gotten a full shake
yet; and to make matters more complicated, the most tricky libraries
are most likely to be used in large or deeply implemented games -- the
ones that take longest to write, and that may just not have emerged on
the scene yet.
I do think that a cross-comparison of libraries and models might reveal
some categories of simulation that are more appealing to library
authors than to game authors -- things that are quite fun (if you enjoy
that sort of thing to start with) to simulate and get working, but
which don't really fit neatly into a game.
steve....@gmail.com
> I had in mind a slightly more nuanced interpretation of the
> evidence than just "no one has used this yet, so it's not useful at
> all."
Eric did not claim that that was your point. Eric's point very well
examined and explained, and certainly not a simplistic argument against
such foolishness as you above enclose in quotation marks.
Simplicity in library design is just great, and something I'm naturally
inclined to agree with, but your argument is ultracrepidarious from the
beginning, and grows ever more amphigorous.
(Hunh. Pretentious diction has a time and place after all.)
Emily Short
steve....@gmail.com wrote:
> Emily Short wrote:
> > I had in mind a slightly more nuanced interpretation of the
> > evidence than just "no one has used this yet, so it's not useful at
> > all."
>
> Eric did not claim that that was your point. Eric's point very well
> examined and explained, and certainly not a simplistic argument against
> such foolishness as you above enclose in quotation marks.
No, which is why my response was basically "I agree with your caveats."
> Simplicity in library design is just great, and something I'm naturally
> inclined to agree with, but your argument is ultracrepidarious from the
> beginning, and grows ever more amphigorous.
>
> (Hunh. Pretentious diction has a time and place after all.)
Yes, I know you think I don't know what I'm talking about, and also
that you find me irritating. It is sad, but I recommend you try a
method I am finding very refreshing: not bothering to engage in
arguments with people for whom you have no respect.
steve....@gmail.com
> But I have other reasons for doubting that ever-more-complex
> simulation libraries/extensions is really the way to go. They're
> clearly of value if they solve one or more problems common to a
> reasonably large subset of IF works, but simulation in IF is
> generally a means to some other end (such as story-telling or
> puzzle-creation) and it's not immediately obvious to me that
> ever-increasingly-sophisticated general-purpose simulation really
> serves any of the end of IF. One is, after all, trying to support
> the creation of works of Interactive Fiction rather than experiments
> in ever more realistic simulated worlds.
That last statement is the most compelling, but it simplifies a rather
more faceted distinction. You want power in a library, to do simulation
stuff if you want, or conversation stuff, or planning stuff -- even
stuff that we'd guess is going to be rare interest -- if the library
can provide a sufficiently abstract infrastructure for it. Indeed I
would say that the art of library design is to provide power without
getting bedeviled by the details, e.g., to make a TADS3esque world
model while gracefully dancing through the many traps of simulationism.
> The absence of a library feature from the great majority of
> finished works is not automatically an argument against its
> inclusion in a library, since (a) it may simply not exist yet (but
> would be welcomed by many game authors if it did) or (b) it serves a
> need but is under-used because it is too difficult to use (so that a
> more author-friendly implementation might well receive a greater
> take up); or (c) it is relatively new and, though potentially
> useful, it hasn't yet had sufficient time to appear in a substantial
> proportion of completed games. IOW, usage statistics from existing
> completing works *could* be misleading under some circumstances,
> particularly in areas where the need for innovation and
> experimentation is quite widely felt (e.g. conversation systems).
I think I disagree. Even stuff that is going to be relatively rare
interest should be provided under some circumstances. Those
circumstances closely depend on the implementation details in the very
particular situation (e.g., the provision of extra senses), which makes
it a little silly to make abstract (amphigorous) theories on this stuff.
steve....@gmail.com
> > > I had in mind a slightly more nuanced interpretation of the
> > > evidence than just "no one has used this yet, so it's not useful at
> > > all."
> >
> > Eric did not claim that that was your point. Eric's point very well
> > examined and explained, and certainly not a simplistic argument against
> > such foolishness as you above enclose in quotation marks.
>
> No, which is why my response was basically "I agree with your caveats."
Eric's point cannot intelligently be reduced to a negation of "no one
has used this yet, so it's not useful at all." Bad job for trying.
> I know you think I don't know what I'm talking about[...]
Oh, god no. I mean, you don't know as much as your amphigory would
suggest, but you definitely know a lot, and you're doing an absolutely
amazing job. (Do you sleep?)
> and also
> that you find me irritating.
Bah, no more irritating than you find me, surely. :)
> It is sad, but I recommend you try a
> method I am finding very refreshing: not bothering to engage in
> arguments with people for whom you have no respect.
Well you certainly have my respect, despite the silliness.
JDC
steve....@gmail.com wrote:
> Oh, god no. I mean, you don't know as much as your amphigory would
> suggest, but you definitely know a lot, and you're doing an absolutely
> amazing job. (Do you sleep?)
I'm going to have to get a new amphigory. All mine suggests is that Amy
fell down the stairs, Basil was assaulted by bears, Clara... oops,
wait, that's my _amphigorey_.
Never mind.
Jacek Pudlo
"objects can absorb liquid and be squeezed to release said liquid again"
I keep saying to myself, this woman has a life even if I can't imagine it.
This woman goes home somewhere. There is someone or something out there who
loves this woman, even if it's only her pet. But where does she go? How does
she live when she's not out here explaining the inner workings of bath
sponges?
Eric Eve
> I do think that a cross-comparison of libraries and models might
> reveal
> some categories of simulation that are more appealing to library
> authors than to game authors -- things that are quite fun (if you
> enjoy
> that sort of thing to start with) to simulate and get working, but
> which don't really fit neatly into a game.
It's quite possible that it may, and the exercise would probably be
interesting. In principle, though, the non-use of these categories
could be due to a variety of reasons:
(1) It's a solution looking for a problem; i.e. it doesn't meet
any perceived needs of the great majority of IF authors'
story-telling or puzzle-planning (this seems to be the central case
you describe above).
(2) It provides for a reasonably common need (e.g. ropes or
liquids) but the either the way it's been implemented is too
cumbersome to use, or even if the implementation is about as
well-designed as it can be it still gives authors' more work then
seems worth their while.
(3) It provides a general solution for a problem that game authors
who tackle it generally prefer to devise their own specialized
system for (an author may, say, have a particular set of puzzles
that involves mixing liquids, but the author finds it more
straightforward to devise his/her own liquid-mixing system from the
ground up, tailored to the particular puzzles s/he has in mind).
(4) It provides a really neat and useful solution to a common
problem that lots of authors would find useful, but for some reason
it never caught on, most likely because hardly anyone knows about it
(it's buried deep in some poorly-documented corner of the standard
library, or it was quietly uploaded to the IF-Archive along with a
description that doesn't do justice to it). Of course, this may turn
out to be an empty set, but it's at least a theoretically possible
category.
I suppose another thing such a cross-system comparison might reveal
is categories of simulation commonly used in system A but absent
from systems B, C and D, which would then raise the question of
whether they could be usefully added to B, C and D, or whether some
fundamental difference between the systems makes them only useful or
practicable in A (e.g. would a Scenes extension actually get much
use in TADS 3, or a ComplexContainer extension much use in Inform 7,
widely-used as those two are in their native systems?).
But this is a refinement of your point rather than a disagreement
with it.
-- Eruc
Emily Short
Eric Eve wrote:
> I suppose another thing such a cross-system comparison might reveal
> is categories of simulation commonly used in system A but absent
> from systems B, C and D, which would then raise the question of
> whether they could be usefully added to B, C and D, or whether some
> fundamental difference between the systems makes them only useful or
> practicable in A (e.g. would a Scenes extension actually get much
> use in TADS 3, or a ComplexContainer extension much use in Inform 7,
> widely-used as those two are in their native systems?).
Hrm, yes.
This project is sounding more and more challenging all the time...