IF in the news
Neil Yorke-Smith
</lurking>
In today's Daily Telegraph (a British national newspaper), Connected
supplement, an article by Michael Bywater who wrote for both Infocom and
Magnetic Scrolls. He compares the development languages of the two
companies:
In my opinion: What are you made of?
<lurking>
-- Neil
Daryl McCullough
This article is interesting. Basically, the author is claiming
that Infocom's approach was to try to anticipate everything that
the player might do in advance, and to program a suitable response.
In contrast, Magnetic Scrolls tried to supply each object in the
game with all the information necessary to deduce how it interacts
with other objects.
It seems that the IF languages (all I know is Inform, but I assume
that the same is true for TADS, Hugo, etc.) support either approach.
However, the default library doesn't really know very much about
how objects interact other than how containers and supporters and
doors work.
It might be an interesting group project to try to come up with
a Simulationist Library, which would understand some core collection
of object types and their interactions. This might include:
1. Light and heavy objects.
2. Burnable objects.
3. Liquids and containers.
4. Ropes, strings, and tying things together.
5. Breakable objects.
6. Edible and drinkable substances.
7. Soft and hard objects.
8. Boyancy---floating in water or air.
As pointed out in the article, the interesting thing
about such a simulationist approach is that it allows
for puzzles to have solutions that the IF author never
thought of. That's very rare (if not impossible) in a
non-simulationist approach.
Anybody interested in working on such a project? I prefer
it to be done in Inform (just because I'm most familiar with
that). The result would not be a game, but instead a world
in which games could be played. Probably each type of object
should be separately loaded, so that a game author can only
include those object classes relevant to their game.
--
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
John Hill
<n...@icparc.ic.ac.uk> wrote:
> In my opinion: What are you made of?
>
> http://www.telegraph.co.uk:80/connected?ac=004405729124331 \
> &rtmo=weAnnjMb&atmo=rrrrrrrq&pg=/et/01/2/22/ecrimo22.html
wherein Michael Bywater wrote:
> I still believe, at some deep
> and idiotic level of the mind, that on my death bed someone will
> come along and offer me the options. Do you want to [R]estore
> a saved position, Re[S]tart or [Q]uit?
Now where did I put that Gentleman Thief costume...
I just hope somebody does the same for me when it's my turn to go.
--
John Hill
T Raymond
>It might be an interesting group project to try to come up with
>a Simulationist Library, which would understand some core
>collection of object types and their interactions. This might
>include:
>
> 1. Light and heavy objects.
> 2. Burnable objects.
> 3. Liquids and containers.
> 4. Ropes, strings, and tying things together.
> 5. Breakable objects.
> 6. Edible and drinkable substances.
> 7. Soft and hard objects.
> 8. Boyancy---floating in water or air.
Well not to say it's been done already, but most of these are
available in some form in the examples directory for TADS. Although
I've been told that realistic rope is technically a horror show, but
I'm still working on it ;)
The only one I don't think has really been touched on in your list is
soft and hard objects, partly because I haven't finished my extencion
for breakables which implemets a basic scale of hardness for objects.
I can't say I'm as familiar with what additions are available gor
Inform, but I would think that most of these have been put together
by someone or another for it as well.
>As pointed out in the article, the interesting thing
>about such a simulationist approach is that it allows
>for puzzles to have solutions that the IF author never
>thought of. That's very rare (if not impossible) in a
>non-simulationist approach.
THis part would be really cool, just don't tie it into an e-mail
system that phones home when a player thinks of something the author
didn't. ;)
>Anybody interested in working on such a project? I prefer
>it to be done in Inform (just because I'm most familiar with
>that). The result would not be a game, but instead a world
>in which games could be played. Probably each type of object
>should be separately loaded, so that a game author can only
>include those object classes relevant to their game.
Darn, this could be interesting, but I'm not up for Inform this year.
*L*
Tom
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Tom Raymond adk AT usaDOTnet
"The original professional ameteur."
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Kent Tessman
that the limitations of the world-model system might be due to
implementation in Infocom's library itself. It's notable, for instance,
that in both Hugo and Inform, at least (which are based on a
(relatively) similar object and behavior modeling system) things like
that which the author describes as being particularly helpful in the
Legend system are easily implementated in a general Hugo/Inform modeling
system, given those physical parameters to which they need to comply.
Picture, for instance, being able to assign a given object the attribute
sharp_enough_to_cut, and then testing for it in a given situation.
--Kent
Sean T Barrett
>This is all very interesting, since it would seem based on the article
>that the limitations of the world-model system might be due to
>implementation in Infocom's library itself.
>easily implementated in a general Hugo/Inform modeling system
>Picture, for instance, being able to assign a given object the attribute
>sharp_enough_to_cut, and then testing for it in a given situation.
Indeed, this is all true--except that most people would say
that the "Inform system" really includes the library, and the
reality is that the library isn't coded to this style, the
parser doesn't default to things in this style, etc.--so true,
in fact, that we need not picture it in our imagination, merely
look at games like Metamorphoses (see past posts by the author
on how it was implemented) and some not-really-a-game that
was released more than a year ago I think by somebody to demo
the idea of being deeply simulationist, but I can't remember
what the demo was or who released it. (I am oh so helpful
here, indeed.)
I think one of the things you have to be careful about with
the simulationist urge is to be careful to still make abstractions.
One might be tempted to not simply have "sharp enough to cut"
and "cuttable", but instead varying degrees of cutting-sharpness,
and varying requirements of sharpness for cutting. There are
cases where this deeper simulation might be useful, but generally
it's going to interfere with playability--just as some people
have suggested over the years giving objects mass and volume 0
unless they are notably massive or awkward, rather than giving
each object a realistic mass and volume.
We went through exactly this experience working on Thief: The
Dark Project with the object interaction system which was called
"Act-React"; the designer who proposed the system wanted an
entirely abstracted system, trying to generalize the "use object
x on object y" which had been in our previous games like Ultima
Underworld; the programmer/designer who designed the system and
implemented it went much more deeply simulationist, using real
units and relative values and effects-at-a-distance which decayed
according to one-over-distance-squared; but in practice the system
only got used for things like "water arrows douse torches and
fire arrows light them", which wanted to be effectively binary
so they were fun to play (as long as you got close, it had the
effect you intended).
SeanB
The Iconoplast
> that Infocom's approach was to try to anticipate everything that
> the player might do in advance, and to program a suitable response.
> In contrast, Magnetic Scrolls tried to supply each object in the
> game with all the information necessary to deduce how it interacts
> with other objects.
There are pros and cons to doing it either way. If you go the Infocom way,
you're able to put richer prose into the game. Since you know precisely how
many ways the player can solve the puzzle, you can come up with equally
verbose explanations to the puzzle. If you do it the Magnetic Scrolls way,
you'll have a greater number of possibilities for solving the puzzle, but
actually solving it may not be as rewarding. In the article's example for
disposing of the ogre, you have a simple solution that the game "wants" you
to use (the knife), and a complex one you came up with (the broken shard).
Using an open-ended system, the interpreter would spit out: "With the aid of
the <cutting instrument> you slice the rope. You soon hear a thud as the
ogre hits the abyss below." If you did it Infocom-style, it could give
either (assuming those two methods were the only you could to solve the
puzzle): "<With a quick and deft stroke of the knife,> (or) <Using your
homemade knife,> you slice the rope. You soon hear a thud as the ogre hits
the abyss below." The code could also compromise between the two. A few
verbose descriptions could be around for methods the programmer figured out,
and a generic description for anything the gamer would construct.
This relationship between verbosity and possibility goes back to the old
trade-off between linearity and non-linearity (it is pretty much the same).
If I write a really linear piece of IF, the gamer has little choice, but the
results are potentially richer. A non-linear story gives the gamer more
choice and makes the experience potentially more richer for him. Non-linear
is the way to go. If someone really wants to write a totally linear piece
of IF, they should be a novelist instead.
> 1. Light and heavy objects.
Maybe instead a weight on a scale of 0 to 100. This way you can determine
carryabilty, and be able to make complex puzzles involving balances and
other mechanical devices.
It's probably best to put attributes like weight on a relative scale so they
can be compared in a complex situation. If you were writing a library for
this, you could also easily put in constants like WEIGHT_LIGHT and
WEIGHT_HEAVY.
> As pointed out in the article, the interesting thing
> about such a simulationist approach is that it allows
> for puzzles to have solutions that the IF author never
> thought of. That's very rare (if not impossible) in a
> non-simulationist approach.
This would be amazing to see. I find way too often when playing some IF
that I have a seemingly simple solution to a puzzle that the interpreter
doesn't understand. In a game with enough of those situations, it's an
accomplishment just for the interpreter to allow your input. Many designers
get very convoluted logic into their games which doesn't seem to be in
accord with the way the world works in the mind of the gamer. Rather than
letting the player see a different perspective, you're forcing it on him
from the start.
> Anybody interested in working on such a project? I prefer
> it to be done in Inform (just because I'm most familiar with
> that). The result would not be a game, but instead a world
> in which games could be played. Probably each type of object
> should be separately loaded, so that a game author can only
> include those object classes relevant to their game.
I wouldn't mind joining you on this quest. Send me an e-mail if you want to
talk about it more.
-Adam
Trevor Powell
very dangerous idea. It's likely to wind up putting the player into an
unwinnable situation, without even a chance for the game to realise that
it can no longer be won. That, more than anything else, erodes
player-author trust.
The main point, I think, is that if the player types a reasonable command,
that command should be understood and responded to (or at least given
a plausible reason why the command wasn't obeyed). This doesn't require
a simulationist approach (which has the danger of putting the game into
an unknown and possibly unwinnable state), but does require vigilance by
the implementor and diligence by the testers in ferreting out all those
reasonable commands.
And of course, without superhuman vigilance and diligence, even a
simulationist approach won't cover all possible actions.
Trevor
(And yet, I'm toying with a simulation-based system in Inform in my spare
time. You'd think I'd take my own advice, wouldn't you?)
Branko Collin
white...@wonderland.zikzak.net (Trevor Powell) wrote:
>Letting the player do things that the author didn't expect is probably a
>very dangerous idea. It's likely to wind up putting the player into an
>unwinnable situation, without even a chance for the game to realise that
>it can no longer be won. That, more than anything else, erodes
>player-author trust.
Could you not write a game in such a way that the player can never end
up in an unwinnable situation? After all, it is the game playing
experience that counts, not wether you win or lose. Winning is the
reward for experiencing enough of the game.
--
branko collin
col...@xs4all.nl
Branko Collin
<Adam_Bar...@Msn.com> wrote:
>> This article is interesting. Basically, the author is claiming
>> that Infocom's approach was to try to anticipate everything that
>> the player might do in advance, and to program a suitable response.
>> In contrast, Magnetic Scrolls tried to supply each object in the
>> game with all the information necessary to deduce how it interacts
>> with other objects.
>
>There are pros and cons to doing it either way. If you go the Infocom way,
>you're able to put richer prose into the game. Since you know precisely how
>many ways the player can solve the puzzle, you can come up with equally
>verbose explanations to the puzzle. If you do it the Magnetic Scrolls way,
>you'll have a greater number of possibilities for solving the puzzle, but
>actually solving it may not be as rewarding.
True, but it is still up to you to program the richness of the
experience. If you do not like the standard answer of Inform to the
verb 'sing', you add a line to each roomobject changing the behavior
of your singing depending on the room you are in. But it is still nice
that Inform provides for a standard answer.
>If someone really wants to write a totally linear piece
>of IF, they should be a novelist instead.
I have played some games that flirted with linearity, and they were
actually quite nice. ('Being Andrew Plotkin' comes to mind.)
>> 1. Light and heavy objects.
>
>Maybe instead a weight on a scale of 0 to 100. This way you can determine
>carryabilty, and be able to make complex puzzles involving balances and
>other mechanical devices.
If you use a digital scale (say 0 to 128), you can single out objects
by their weight, as long as they are the only object with that weight.
I do not know of any useful applications of this, though (since you
can easily check for 'marble in player'), but I thought I would
mention it, in case anybody does see a use for this. I gues it makes
things a bit faster, especially when checking for multiple objects.
>It's probably best to put attributes like weight on a relative scale so they
>can be compared in a complex situation. If you were writing a library for
>this, you could also easily put in constants like WEIGHT_LIGHT and
>WEIGHT_HEAVY.
Yes, why not use both?
>I wouldn't mind joining you on this quest. Send me an e-mail if you want to
>talk about it more.
I won't join, but I would like to see the end result. So I say 'go
ahead' and wish you guys good luck.
--
branko collin
col...@xs4all.nl
The Iconoplast
> very dangerous idea. It's likely to wind up putting the player into an
> unwinnable situation, without even a chance for the game to realise that
> it can no longer be won. That, more than anything else, erodes
> player-author trust.
I'd personally prefer the extra freedom. The author could easily put in
some catches on essential objects. For example, if you tried to break the
clay pot in the article, the game could spit out, "You get a strange
sensation you'll need to leave the pot intact." That's not the most elegant
solution to the problem.
A better one might be having actions needed done by the object taken care of
once it's rendered unusable. This has its own fallacies, since you could
get a lot of actions inexplicably happening throughout the game world.
> The main point, I think, is that if the player types a reasonable command,
> that command should be understood and responded to (or at least given
> a plausible reason why the command wasn't obeyed). This doesn't require
> a simulationist approach (which has the danger of putting the game into
> an unknown and possibly unwinnable state), but does require vigilance by
> the implementor and diligence by the testers in ferreting out all those
> reasonable commands.
The benefit to the simulationalist is that every possible solution is
already taken care of. You would end up wasting a lot of testing time
coding information for every possibility (which with Inform might give you
trouble with file size) instead of better tweaking puzzles and refining the
story.
> And of course, without superhuman vigilance and diligence, even a
> simulationist approach won't cover all possible actions.
I imagine problems with verbs would crop up, but that's more of the parser's
fault than the author. The general supply of verbs would probably do a
decent job covering the player's actions.
> (And yet, I'm toying with a simulation-based system in Inform in my spare
> time. You'd think I'd take my own advice, wouldn't you?)
I'd be interested to hear the method you're using. Are you using a list of
attributes? If so, what are you using?
-Adam
The Iconoplast
> the simulationist urge is to be careful to still make abstractions.
> One might be tempted to not simply have "sharp enough to cut"
> and "cuttable", but instead varying degrees of cutting-sharpness,
> and varying requirements of sharpness for cutting. There are
> cases where this deeper simulation might be useful, but generally
> it's going to interfere with playability--just as some people
> have suggested over the years giving objects mass and volume 0
> unless they are notably massive or awkward, rather than giving
> each object a realistic mass and volume.
I suggested in another post that you could have a relative scale from 0 to x
(probably 100). If you wanted, you could assign each object an arbitrary
weight which you could utilise however you wanted. However, if you just
want to use an attribute like "heavy," there would be a constant in the
library called WEIGHT_HEAVY (could be 75) that would be heavier than
WEIGHT_LIGHT (could be 25). I wouldn't matter what value any of those
constants had since you'd just be using them to compare one object to
another.
-Adam
Dennis G. Jerz
> It might be an interesting group project to try to come up with
> a Simulationist Library, which would understand some core collection
> of object types and their interactions. This might include:
>
> 1. Light and heavy objects.
> 2. Burnable objects.
> 3. Liquids and containers.
> 4. Ropes, strings, and tying things together.
> 5. Breakable objects.
> 6. Edible and drinkable substances.
> 7. Soft and hard objects.
> 8. Boyancy---floating in water or air.
>
In the "about" text to "Metamorphoses," Emily Short describes her work on a
materials library, for which the game that turned into "Metamorphoses" was
supposed to be a testing ground.
Phil Goetz wrote a little something on simulation libraries in 1994...
scroll way down a subheading on computer simulation.
http://www.mud.co.uk/richard/ifan194.htm
Chris Craword's unusual "Erasmatron" tries to break down human behavior into
a similar set of libraries.
http://www.robotwisdom.com/ai/crawford.html
Jorn Barger suggests a similar thing, this time using objects and their
relationship to humans:
"The food meta-story: A person tended a garden or farm raising plants or
animals to eat or sell. They harvested the food when the time was right and
sold it or preserved it or prepared it and ate it or fed it to friends or
family. If it was well-prepared, their hunger was satisfied and they were
happy. The food travelled thru their intestines and had to be excreted. If
they didn't get enough good food, they got thin and died. Maybe the person
preparing the food put poison in it to injure the person who ate it. They
might have to disguise the flavor of the poison. Maybe they prepared it
poorly and it tasted bad."
http://www.mcs.net/~jorn/html/ai/ifdesign.html
Will Grzanich
>
> I'd personally prefer the extra freedom. The author could easily put in
> some catches on essential objects. For example, if you tried to break the
> clay pot in the article, the game could spit out, "You get a strange
> sensation you'll need to leave the pot intact." That's not the most elegant
> solution to the problem.
Yeah. The problem there is that you couldn't have any red herrings - a
player can find out which items are needed just by seeing whether or not
the game will let him break them / cut them / set them on fire.
> A better one might be having actions needed done by the object taken care of
> once it's rendered unusable. This has its own fallacies, since you could
> get a lot of actions inexplicably happening throughout the game world.
Or, provide multiple independent solutions to each puzzle; for instance,
if it turns out you needed that pot you broke later on, another similar
pot pops up somewhere else, or another solution to the problem appears.
Of course, even then, you could end up allowing the PC to dig himself
into a hole, but it might help.
-Will
Fraser Wilson
> Non-linear
> is the way to go. If someone really wants to write a totally linear piece
> of IF, they should be a novelist instead.
Well, that's overstating things a bit. Linear and non-linear are
simply two classes of IF. Unless you're talking about "press the
space bar to continue" linearity, I think it's quite different from
the experience of a novel.
I used to be a Simulationist when I was younger. I dreamed of a
sufficiently rich class hierarchy that enabled stories to be written
just by putting objects in other objects, and letting the reader walk
around. NPCs would be generated by choosing desires and attitudes;
the simulation would pick plans and sub-goals, and they would wander
around doing stuff in essentially the same manner as the PC. The
initial goal was a sort of IF requiem for my dog, Monty.
This philosophy received a severe kick in the pants from the pivotal
moment in Spider and Web (if you've played it, you know what I mean.
If you haven't, you should). I put it to you that a simulationist IF
piece _cannot_ generate that kind of oh-my-god moment, in the absence
of real AI.
Fraser.
(I still want to get that dog simulation going though)
The Iconoplast
> up in an unwinnable situation? After all, it is the game playing
> experience that counts, not wether you win or lose. Winning is the
> reward for experiencing enough of the game.
You could easily do that. In fact, it would be easier on the part of the
designer, and possibly more enjoyable for the player. The problem is that
gamers, like most conniseurs of leisure, are deeply rooted in their
conventions and hate to see new things. </cynicism> True, it's a cynical
statement, but it is for the most part true. If you can slowly wean people
away from something, they might end up trying something new. If you want to
have fun though, just slap them across the face with something totally new.
:)
Your suggestion brings up a question as to what the goal of playing a
computer game. Is it to win, to use up time to play, to have the
experience, etc.? Most gamers now would say it's to win. Computer gaming
will get *much* more interesting once it moves away from simple games and
into deeper territory.
-Adam
Aris Katsaris
The Iconoplast <Adam_Bar...@Msn.com> wrote in message
news:uv84pSnnAHA.339@cpmsnbbsa09...
> > Could you not write a game in such a way that the player can never end
> > up in an unwinnable situation? After all, it is the game playing
> > experience that counts, not wether you win or lose. Winning is the
> > reward for experiencing enough of the game.
>
> You could easily do that. In fact, it would be easier on the part of the
> designer, and possibly more enjoyable for the player. The problem is that
> gamers, like most conniseurs of leisure, are deeply rooted in their
> conventions and hate to see new things. </cynicism> True, it's a cynical
> statement, but it is for the most part true.
Are you talking about the interactive fiction community btw, or about the
world
of commercial gaming?
Because this entire post of yours seems vaguely uninformed about the
attitude and current happenings in the IF community... But it's probably
true
for the world of gaming in general, alas....
Aris Katsaris
Aris Katsaris
Fraser Wilson <blanc...@blancolioni.org> wrote in message
news:fy7d7c9...@whitelion.org...
Simulationism is in my opinion a tool, among many others. Emily Short's
"Metamorphoses" has proven it a more than enjoyable experience to
me... It was really glorious when I could do really far-fetched things that
would work in real life... I never expected them to have been
implemented...
It was just my idea of what I would do if such a problem presented itself
to me in real life.
But a good story also requires something of a "narrativium", the sense of
narrative within the story. Plot-points, perhaps even plot-twists. So
simulationism should *not* be the end-all-be-all of Interactive fiction.
Aris Katsaris
Kathleen M. Fischer
=====
>Your suggestion brings up a question as to what the goal of playing a
>computer game. Is it to win, to use up time to play, to have the
>experience, etc.?
To have the experience.
Kathleen
-- Masquerade (Comp2000)
-- ftp://ftp.gmd.de/if-archive/games/zcode/Mask.z5
-- The Cove - Best of Landscape, Interactive Fiction Art Show 2000
-- ftp://ftp.gmd.de/if-archive/games/zcode/Cove.z5
-- Excuse me while I dance a little jig of despair
The Iconoplast
> world
> of commercial gaming?
It exists to some extent. Since there really is no commercial intrusion
into most IF, it's not to much of a problem.
> Because this entire post of yours seems vaguely uninformed about the
> attitude and current happenings in the IF community... But it's probably
> true
> for the world of gaming in general, alas....
That's mostly where my point lies, sorry for the confusion.
-Adam
Branko Collin
<Adam_Bar...@Msn.com> wrote:
>Your suggestion brings up a question as to what the goal of playing a
>computer game. Is it to win, to use up time to play, to have the
>experience, etc.? Most gamers now would say it's to win. Computer gaming
>will get *much* more interesting once it moves away from simple games and
>into deeper territory.
I would get pretty bored pretty quickly if there was not some kind of
goal to be achieved while playing a game. And of course, if you paint
that goal pink and call it 'winning', you effectively have got
'winning' (actually, you could leave out the pink painting). But the
winning has to come at some price: it should not be easy.
--
branko collin
col...@xs4all.nl
Matthew Russotto
As long as you include a universally accessible "restart" command, all
games are like that.
<FLAMEBAIT>
Besides, the "it is the game playing experience that counts, not
wether [sic] you win or lose" is a doctrine for losers.
</FLAMEBAIT>
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."
Joshua E Millard
>
><FLAMEBAIT>
>Besides, the "it is the game playing experience that counts, not
>wether [sic] you win or lose" is a doctrine for losers.
></FLAMEBAIT>
Shah, whatever. "Winning isn't the most important thing -- it's the only
thing" is a doctrine for small minded proto-jocks with all the broadened
horizon of a prison cell.
<CONNERY>
Your besht? Loshersh alwaysh whine about their besht...
</CONNERY>
--
+---+ With great effort, you move the boulder. ################
|..$| # Josh Millard #
|.@'.##########################################################
|<d.| # pu...@wpi.edu # www.wpi.edu/~pulp - music, words, etc #
+---+ ########################################################
Sean T Barrett
><Adam_Bar...@Msn.com> wrote:
>>Your suggestion brings up a question as to what the goal of playing a
>>computer game. Is it to win, to use up time to play, to have the
>>experience, etc.? Most gamers now would say it's to win. Computer gaming
>>will get *much* more interesting once it moves away from simple games and
>>into deeper territory.
>
>I would get pretty bored pretty quickly if there was not some kind of
>goal to be achieved while playing a game.
A goal is widely regarded as a (the?) distinction between a game
and a toy; for example see Greg Costikyan's
http://www.crossover.com/~costik/nowords.html#Goals
Of course, one can challenge whether IF is necessarily a game;
but then again, with regards to books, although we might not say
"the goal is to reach the end of the book", there is some sort
of truth there that I don't know how to phrase correctly.
SeanB
Marnie Parker
>From: buz...@world.std.com (Sean T Barrett)
>Date: 2/24/2001 9:22 PM Pacific Standard Time
>Of course, one can challenge whether IF is necessarily a game;
>but then again, with regards to books, although we might not say
>"the goal is to reach the end of the book", there is some sort
>of truth there that I don't know how to phrase correctly.
>
>SeanB
Closure. When I play IF I aim for closure. Either to "win" or to see the end of
the story (in a piece that may not involve winning but is still interactive).
Doe :-) But first and foremost I play IF for the experience, i.e. the
entertainment value interactive fiction it has for me.
doea...@aol.com
Glulx/Glk for Dunces http://members.aol.com/doepage/glkdunces.htm
IF Art Gallery http://members.aol.com/iffyart/
IF Review Conspiracy http://www.textfire.com/conspiracy/
The Tame Computer http://members.aol.com/tamecomputer/
Branko Collin
Russotto) wrote:
><FLAMEBAIT>
>Besides, the "it is the game playing experience that counts, not
>wether [sic] you win or lose" is a doctrine for losers.
></FLAMEBAIT>
Man, you must be a bitch at the breakfast table. ;-)
--
branko collin
col...@xs4all.nl
ems...@mindspring.com
> in fact, that we need not picture it in our imagination, merely
> look at games like Metamorphoses (see past posts by the author
> on how it was implemented) and some not-really-a-game that
> was released more than a year ago I think by somebody to demo
> the idea of being deeply simulationist, but I can't remember
> what the demo was or who released it. (I am oh so helpful
> here, indeed.)
Er, that would also be mine, assuming you mean peacock.z5, which had
timed burning routines (variable burning length depending on the size
and material in question, flame that spread among adjacent objects,
smoke that accumulated when a large fire occurred, carbon that gathered
on glass containers used to burn things (but it could be wiped off
again), blowing on items to extinguish them if they were not to
vehemently burning, and forcing the player to drop things that were
being consumed in flame.) It also had fragile objects and cutting edges
that could cut different materials; it had paper that could be used to
take rubbings of textures and inscribed lettering (and then
distinguished from other paper based on this fact); it had a camera that
recorded the states of objects at the moment photographed, and a flash
that went off if the light level in the room was too low. It did not
demo, however, my liquid library (infinitely divisible and miscible
liquids, proportion of mixed liquids remembered for the sake of recipes
and poisoning puzzles) due to the fact that the latter has some parsing
troubles.
Peacock is buggy, but it does at least try to do many of the things
described in this thread. I never saw a need for buoyancy, though it
could easily have been dealt with as an extension of the existing
density property.
None of my current projects do much with this kind of thing, since I
have gotten distracted by the NPC problem, but before I semi-shelved it
this was basically meant to become exactly the kind of library you
describe. There were modules that could be turned on or off at will (so
if you didn't want all the burning you didn't have to have it) and it
tried to be integrated and slick. Two problems (aside from the
liquid-parsing problem): 1) it was a pain in the ass to code because
every object had so many properties; 2) memory. Inform never likes any
of my experiments because they're always low-mem intensive. Sigh.
But anyway. I have worked on the problem. If people are interested I
suppose I could share the code, though IIRC it's in a kind of tangly
state.
-- Emily
ems...@mindspring.com
> Letting the player do things that the author didn't expect is probably a
> very dangerous idea. It's likely to wind up putting the player into an
> unwinnable situation, without even a chance for the game to realise that
> it can no longer be won. That, more than anything else, erodes
> player-author trust.
This is not necessarily the case.
Simulationism doesn't mean "giving the player the ability to do anything
at all", since programming for this would be equivalent to recreating
the world. It does mean "giving the player freedom within a limited
scope (which I control the shape of, if not the particulars)".
So, having made the routines, I have a pretty good sense of what the
possible end-states for objects are, in general. If one of them is
'destroyed,' then yes, there is the possibility that the player will
ruin things; but there are routes to preventing this, which range from
forestalling him at the PC level ("you don't want to do that") to
providing infinite replacements. With Metamorphoses there are a lot of
alternate puzzle solutions, so that the destruction of one or two (or
more) objects won't lead to disaster; it's still possible, for instance,
for someone to systematically turn everything in his inventory to glass
and then fling it against the wall, at which point he'll have nothing to
work with.
Which would serve him right.
I haven't heard of anyone finding the game unfinishable for this reason,
however; which suggests to me that if you set up the game in such a way
that the game physics seems logical, the player will only do things that
seem like a good idea (or, if he tries to test the limits, will realize
he's testing them, and save first.) This is in contrast to those games
where the puzzle logic is so mysterious that you run around doing random
things with your inventory just because it's there. (I recently played
Heroine's Mantle; the puzzles there spanned the range from brilliant to
incomprehensible, and the 'do it because you can, not because it makes
sense' logic seemed to apply on several occasions.)
So I guess it basically comes down to shifting the player/author trust
to a new form. If the player trusts that the game world makes organic
sense and can be logically manipulated to produce the win state, then
there may not be much resentment over the fact that it is also possible
to produce losing/unwinnable states.
-- Emily
Sean T Barrett
>Sean T Barrett <buz...@world.std.com> wrote:
>> but I can't remember what the demo was or who released it.
>
>timed burning routines (variable burning length depending on the size
>and material in question, flame that spread among adjacent objects,
>it had a camera that
>recorded the states of objects at the moment photographed, and a flash
>that went off if the light level in the room was too low.
Hmm, this peacock thing sounds like it does about four times
as much stuff as the demo I played. But yes, that's the one,
I guess I didn't play with it enough.
>None of my current projects do much with this kind of thing, since
>I have gotten distracted by the NPC problem
"distracted", heh. No need to be pejorative about working on Galatea.
>2) memory. Inform never likes any
>of my experiments because they're always low-mem intensive. Sigh.
Go glulx, young woman. Or perhaps Tads 3, someday...
SeanB
ems...@mindspring.com
> Hmm, this peacock thing sounds like it does about four times
> as much stuff as the demo I played. But yes, that's the one,
> I guess I didn't play with it enough.
Which leads us to another important point of simulationist IF: You will
spend a lot of time writing things that any individual player will Never
See. And it is right that it should be so, for lo, this is what makes
the world seem flexible.
>>2) memory. Inform never likes any
>>of my experiments because they're always low-mem intensive. Sigh.
> Go glulx, young woman. Or perhaps Tads 3, someday...
Cf. my earlier laments about the unavailability of a glulx compiler for
the Mac. (Turning large, sad eyes in the direction of Robert Pelak.)
But maybe soon.
It would take a lot to make me switch to Tads. This is not because I
think Tads is a bad language; it's just that my investment in Inform (in
the form of writing libraries, etc) is now so large that it would be a
major pain to go back and port.
-- Emily
Adrian McCarthy
The Iconoplast <Adam_Bar...@Msn.com> wrote in message
> There are pros and cons to doing it either way. If you go the Infocom
way,
> you're able to put richer prose into the game.
That's true in a pure simulation environment. But if the simulation
can reasonably handle many things you didn't think of, then, as an
author, you can concentrate on tailoring the prose for the important
situations.
I've always wanted to try a simulationist approach, and I'm currently
dusting off a project to try it. But my interest in the simulation was
always in the programming challenge, and in making a game that can
help suspend disbelief by cutting down on the things it doesn't
understand or can't represent.
This article was an epiphany for me. Never, did it occur to me that
a player might come up with a solution that the author didn't dream
up first. As an author, I would be proud of the game that allows
that. As a player, I would be thrilled to discover such a solution.
Perhaps a scored game could even award bonus points for solving
a puzzle in an unanticipated way. Now I'm even more enthusiastic
about doing a good simulation. The interactive game aspect of the
experience is enhanced by this.
> CUT THE ROPE WITH THE BROKEN SHARDS
I never would have thought of that. [bonus points!]
The rope gives way and ...
I see two aspects to fiction: prose and plot.
Prose is certainly at risk if the author relies solely on the
simulation. But if the system's ability to simulate the mudane can
free up development effort for the intersting stuff, then the
simulation can actually be a plus.
One thing I'd like to try is prose generation from an underlying
representation. I don't just mean lots of MadLib templates, but a
system that can take the internal representation of state and events,
combine them, and produce a decent description. Generated text
interspersed with handcrafted prose for plot development might
have a synergy that surpasses what either approach could
accomplish alone.
I don't see plot in jeopardy from a simulationist approach. Plot is
driven by motivation and conflict. In IF, conflict is often in the
form of puzzles. Solving a puzzle moves the plot along, regardless
of the solution. It's not important what I used to cut the rope, just
that I found a way to defeat the ogre that was climbing up it.
Simulation doesn't prevent an author from dreaming up motivations,
obstacles, twists, and devices to move the story along.
As for those worried about the player getting into unwinnable states,
that's nothing new. I haven't played many IF games, but I have
seen plenty of examples where you can shoot yourself in the foot
by running out of time, destroying a treasure, using that last match,
or being eaten by a grue. That's a part of the life in IF. If that vase
was really important later in the game, I'll have to figure that out
when the time comes. The next time, I'll have to find a different
solution for the ogre, or perhaps the simulation will enable me to
substitute something else for the container.
Aid.
Goober
scripted kind of game.
Is there any IF that uses hit points/strength etc?
Mel
> Anybody interested in working on such a project? I prefer
> it to be done in Inform (just because I'm most familiar with
> that). The result would not be a game, but instead a world
> in which games could be played. Probably each type of object
> should be separately loaded, so that a game author can only
> include those object classes relevant to their game.
I don't program in Inform, but I'm interested if you want a
tester/another person to bounce ideas off of.
Mel
Gunther Schmidl
Beyond Zork. It's incredibly annoying.
-- Gunther