Simulation & world consistency

21 views
Skip to first unread message

David Fisher

unread,
Sep 28, 2005, 8:44:19 PM9/28/05
to
I have been enjoying the "Producing Adventures" thread on the limits of
simulation, and I thought I'd throw in a few thoughts ...

A common complaint with IF games is that the player ought to be able to do
something that is obvious to them, but the game author didn't think of.
"This is a crowbar - I ought to be able to open doors with it, not just the
wooden crate !"

In a non-simulationist environment, where the author is only provided with
the basic tools to create a world (rather than a set of pre-existing objects
which they can use and then customise), there is not much the author can do
about this except to be very careful - and try to imagine what the player
might try. If the philosophy is "provide the tools and let the author add
what they need", then there is no way to automatically check for things the
author might not have thought of.

An alternative philosophy (mentioned in the "Producing Adventures" thread)
is, "provide as much as possible (prefabricated objects) and let the author
customise it". There are many potential problems with this idea, but it adds
the possibility of a tool to check for things the game author did not
anticipate:

Imagine a tool that lets an IF author explore the interactions between all
of the objects in a game. It might act something like this:

1. The game author selects an object X.

2. The tool (possibly a GUI tool with a "tree view") lists all of the other
objects X could interact with.

3. The author filters out "uninteresting" objects and interactions.

4. The author checks for desirable & undesirable interactions between
objects, and marks them as such. The tool remembers these interactions, so
that they can be automatically checked again next time (so the author can
re-run the tool after making some changes to the game, to confirm that the
"desirable" interactions still happen and none of the "undesirable" ones are
suddenly happening). Interactions could also be marked as "harmless", so the
author would only need to view unmarked interactions next time the tool is
used (so they could filter these out & not need to recheck them next time
they run this tool).

The reason why a simulationist-with-customisable-objects type system is
needed is so the tool has a list of standard interactions to check against.
In a non-simulationist system, there are no standard behaviours to act as a
base line and check against.

This also helps with the issue Mike Roberts (brilliantly) brought up about
the diminishing returns of a simulationist system (MJR, Sep 26th 1:28 pm):

> The instinct that Aidy is following is that when players try
> something that's reasonable, they want a reasonable response. They
> don't want to be told "I don't know that verb" and they don't want
> "You can't do that (just because I say so)." Aidy's instinct, I think,
> is that adding more simulation will yield fewer of these, which is true
> as far as it goes. The naive misconception is that this is always a
> net win. In the experience of lots of people who've been at this a
> while (as seen in this thread), there's a point of diminishing returns.
> The cost of added simulation is that it creates more opportunities for
> bizarre, bug-like responses that reveal the limits of the simulation

I think a tool like this becomes absolutely necessary in a simulationist
environment, because even if the system design gets the basic set of objects
to interact "perfectly" with each other, there is so much potential for the
above mentioned bizarre bug-like responses to occur when a game author
starts customizing all the bits. (All of this is assuming that the
simulationist system would still be fully programmable, not just
"configurable", as Aidy keeps agreeing with when people mention the
difference).

An example in case all of this is too abstract:

* Game world already includes a kitchen knife
* Author introduces a vacuum cleaner with a power cord and runs the
"interaction checker" tool
* Author notices that one of the interactions is that the power cord can be
cut with the knife and then used as a rope; this is undesirable as it would
spoil one of the puzzles
* Author goes and modifies the vacuum cleaner to prevent the cord from being
cut (and adds a message about destroying other people's property to explain
why the PC can't do it)

In summary, a simulationist system along with a tool to help the game author
check the interactions between game objects could be a great help in
producing games with self-consistent, more believable worlds ...

David Fisher


Kevin Forchione

unread,
Sep 28, 2005, 10:10:47 PM9/28/05
to
"David Fisher" <da...@hsa.com.au> wrote in message
news:TRG_e.1300$96.1...@nasal.pacific.net.au...
<snip>

> In summary, a simulationist system along with a tool to help the game
> author check the interactions between game objects could be a great help
> in producing games with self-consistent, more believable worlds ...

I would assert that given such a system, a good game writer would actually
be compelled to customize the model so as to drastically *reduce* the
simultationist opportunities available to the player. Why? Because in
fiction a believable world is one that obeys the laws of narrative
causality, and not newton's three.

--Kevin

--Kevin


Nikos Chantziaras

unread,
Sep 29, 2005, 3:28:41 AM9/29/05
to
David Fisher wrote:
> An example in case all of this is too abstract:
>
> * Game world already includes a kitchen knife
> * Author introduces a vacuum cleaner with a power cord and runs the
> "interaction checker" tool
> * Author notices that one of the interactions is that the power cord can be
> cut with the knife and then used as a rope; this is undesirable as it would
> spoil one of the puzzles
> * Author goes and modifies the vacuum cleaner to prevent the cord from being
> cut (and adds a message about destroying other people's property to explain
> why the PC can't do it)
>
> In summary, a simulationist system along with a tool to help the game author
> check the interactions between game objects could be a great help in
> producing games with self-consistent, more believable worlds ...

It won't work. :)

An author is bound to miss a few such interactions. Even a GUI checker
won't help:

UNLOCK DOOR WITH KNIFE
DAMAGE LOCK WITH KNIFE
CUT MY THROAT WITH KNIFE
THROW KNIFE AT WALL
PEEL RED HERRING WITH KNIFE
STICK KNIFE TO TREE, STAND ON KNIFE, GET APPLE
PUT KNIFE ON CHAIR. BILL, TAKE A SEAT
PUT KNIFE ON DOOR. BILL, OPEN THE DOOR (long shot, but hey)
TIE KNIFE TO PLANK. CUT APPLE
[etc.]

Now, this isn't a limitation of a "simulationist" system. It's true for
all systems. Usually, the author just rethinks the idea of including a
knife in the game and, if the task of handling all possible responses
seems too overwhelming (with a GUI tool, the possible interactions seem
almost infinite), replaces it with a toothpick... :)

David Fisher

unread,
Sep 29, 2005, 4:10:54 AM9/29/05
to
"Nikos Chantziaras" <rea...@arcor.de> wrote in message
news:433b97f4$0$37580$892e...@authen.white.readfreenews.net...

> David Fisher wrote:
>>
>> In summary, a simulationist system along with a tool to help the
>> game author check the interactions between game objects could
>> be a great help in producing games with self-consistent, more
>> believable worlds ...
>
> It won't work. :)
>
> An author is bound to miss a few such interactions.

It would be equivalent to having a written list of interaction to check
manually, but using a program to help you keep track of what must be checked
and what you have already verified. Without such a tool (or written list),
you are left to your imagination ... I would rather do a check like this
systematically using a list of known interactions, than have to try and
think them up again each time.

This would not be a fool proof system (since it still relies on a human
looking over the list), but it would surely be much better than having no
list at all ... and faster than using a physical, written list (since the
program would manage everything for you, including filtering out unnecessary
checks) ?

> Even a GUI checker won't help:

I am genuinely not following your reasoning in the examples you give below
... all of them can be handled OK. All it depends on is the (fixed) level of
simulation of the system (which will always be much less than a "full
simulation of reality" down to the level atoms, etc - similar to the way
there is a fairly fixed level of natural language parsing in current IF
systems).

> UNLOCK DOOR WITH KNIFE
> DAMAGE LOCK WITH KNIFE
> CUT MY THROAT WITH KNIFE
> THROW KNIFE AT WALL
> PEEL RED HERRING WITH KNIFE
> STICK KNIFE TO TREE, STAND ON KNIFE, GET APPLE
> PUT KNIFE ON CHAIR. BILL, TAKE A SEAT
> PUT KNIFE ON DOOR. BILL, OPEN THE DOOR (long shot, but hey)
> TIE KNIFE TO PLANK. CUT APPLE

Depending on the level of simulation of the system (which is determined by
the system author, not the game author), it may be possible to twist an
arbitrary piece of metal into a lock pick, or not. If it is, this is one of
the things the tool I proposed would check; if not, it wouldn't check it.
Where is the problem ?

To put it another way, as an author, I would like to know about (1) any
unforseen interactions between objects in the game, and (2) attempted uses
of objects by players I may not have thought of. Using a computer to help
with this task seems like the best idea (if it is possible), for lots of
reasons - one of which is that it can keep track of the decisions I have
made so far, and (a) re-verify them each time and (b) not ask me again about
them each time. Much more work without a computer to help with this task
(and I am definitely saying "help", not automate the process completely,
since the whole point is to make subjective decisions about how you want
things to operate in your game).

> Now, this isn't a limitation of a "simulationist" system. It's true for
> all systems. Usually, the author just rethinks the idea of including a
> knife in the game and, if the task of handling all possible responses
> seems too overwhelming (with a GUI tool, the possible interactions seem
> almost infinite), replaces it with a toothpick... :)

Still don't follow your line of reasoning (but I would like to). Are you
saying that *all* objects have simulationist uses that will potentially
wreck a game (or maybe that there is an overwhelming number of possible
interactions between objects, so no one could ever check them all ?) Or
something else ?

Thanks for the post,

David Fisher


David Fisher

unread,
Sep 29, 2005, 4:55:13 AM9/29/05
to
"Kevin Forchione" <ke...@lysseus.com> wrote in message
news:H2I_e.3377$KQ5....@newssvr12.news.prodigy.com...

Do you believe that it would destroy the plot if the player is allowed to do
simulationist things ? Surely there is a way to allow reasonable but
non-plot-related actions in a game without it destroying the narrative ?

Personally I am most frustrated by games where I am not permitted to do
something that should definitely be possible in the game world, and I have
the most fun when I can do all kinds of things ... this doesn't wreck the
plot for me at all, but enhances it by making everything seem more real and
consistent. I also like the reward of working out a solution to a puzzle
that ought to work, and it does - as opposed to the frustration of being
told it fails.

I can't find it right now, but a read an article about creating worlds that
"work by themselves" and the enjoyment of the creators when a player tried
out something they hadn't thought of - and it worked, because the physics of
the world was consistent enough. I love that idea too; I would enjoy finding
out that a player solved a puzzle in an entirely unexpected way in one of my
games.

Another question for you - how do you prevent this kind of situation from
happening in your games (frustration at not being able to do something
obvious) ? And how do you advance the plot without the player feeling there
is not much freedom in their choices ? (I would get annoyed by a plot device
that only left me with one possible option when there should realistically
have been other options).

David Fisher


Nikos Chantziaras

unread,
Sep 29, 2005, 9:10:46 AM9/29/05
to
David Fisher wrote:
> "Nikos Chantziaras" <rea...@arcor.de> wrote in message
> news:433b97f4$0$37580$892e...@authen.white.readfreenews.net...
>> David Fisher wrote:
>>>
>>> In summary, a simulationist system along with a tool to help the
>>> game author check the interactions between game objects could
>>> be a great help in producing games with self-consistent, more
>>> believable worlds ...
>>
>> An author is bound to miss a few such interactions.
>
> It would be equivalent to having a written list of interaction to check
> manually, but using a program to help you keep track of what must be checked
> and what you have already verified. Without such a tool (or written list),
> you are left to your imagination ... I would rather do a check like this
> systematically using a list of known interactions, than have to try and
> think them up again each time.

Sure, but that wasn't the point. The actual problem is actually
realizing what needs customizing. (I think the canonical example here
is KISS MERLIN?)

Let's say the PC needs to climb on a tree. The player might try:

STICK KNIFE TO TREE
STAND ON KNIFE

A GUI won't help make the author realize that the above is actually a
good way to solve the puzzle (OK, a kitchen knife is not suitable for
this; it's just an example). The tool you propose would list STAND ON
KNIFE as a possible command, true. But does that help much? It would
also have to list *all* of the possible states the knife can be in,
without any means to filter out the ones that don't make sense.
Therefore, the list would be incredibly long.


> This would not be a fool proof system (since it still relies on a human
> looking over the list), but it would surely be much better than having no
> list at all ... and faster than using a physical, written list (since the
> program would manage everything for you, including filtering out unnecessary
> checks) ?

Like STAND ON KNIFE :) I don't think there's any such thing as an
"unnecessary check" in IF.


>> Even a GUI checker won't help:
>
> I am genuinely not following your reasoning in the examples you give below

> .... all of them can be handled OK.

The problem is realizing that they actually need to be handled.


> All it depends on is the (fixed) level of
> simulation of the system (which will always be much less than a "full
> simulation of reality" down to the level atoms, etc - similar to the way
> there is a fairly fixed level of natural language parsing in current IF
> systems).

What is done in IF parsers has quite little to do with NLP. If you look
closely, you'll see it's "just" an oversized (but smart) hack. But
let's not drift away.

The simulation turns out to be the problem rather than the solution
sometimes. STICK KNIFE TO TREE is no problem; the knife is sharp and
pointy, the tree's made of wood, so the system knows what to do.
Problem is, the player might or might not be able to climb the tree this
way. The author has to customize here, but it's hard to realize it
since an action like STAND ON KNIFE looks quite innocent at first sight;
it's not possible to think of all the possible ancestors of this command
(like STICK KNIFE TO TREE). Sure, the simulation allows STAND ON KNIFE.
But it doesn't help.


>> UNLOCK DOOR WITH KNIFE


>
> Depending on the level of simulation of the system (which is determined by
> the system author, not the game author), it may be possible to twist an
> arbitrary piece of metal into a lock pick, or not.

I rather doubt it. No matter how hard I think about it, I can't come up
with any idea of a system that would allow something like this.


> If it is, this is one of
> the things the tool I proposed would check; if not, it wouldn't check it.
> Where is the problem ?

It's with the tool's inability to aid the author into reading the
player's mind.

And such a tool can't really "filter-out" anything. What might look as
a stupid thing to try, might later turn out to be actually a valid way
of solving a particular puzzle.


> To put it another way, as an author, I would like to know about (1) any
> unforseen interactions between objects in the game,

Countless. And I mean it.


> and (2) attempted uses
> of objects by players I may not have thought of.

Fewer than "countless", but hidden and mixed with the countless. :)


> Using a computer to help
> with this task seems like the best idea (if it is possible),

OK, I can't really know if it's possible or not. I'm just speculating
here. IMO, it isn't.


> for lots of
> reasons - one of which is that it can keep track of the decisions I have
> made so far, and (a) re-verify them each time and (b) not ask me again about
> them each time.

There's a big trap hidden here. As soon as you insert anything new into
the story, you'll have to re-verify everything, especially if you want
your game to be solvable at all times. Look up BURN PICTURE below.


> Much more work without a computer to help with this task
> (and I am definitely saying "help", not automate the process completely,
> since the whole point is to make subjective decisions about how you want
> things to operate in your game).

Yes, such a tool would be indeed very useful. But I don't see any way
of actually pulling it off.


> Still don't follow your line of reasoning (but I would like to). Are you
> saying that *all* objects have simulationist uses that will potentially
> wreck a game (or maybe that there is an overwhelming number of possible
> interactions between objects, so no one could ever check them all ?) Or
> something else ?

Yes and yes (mostly; there's no absolute in these things). I think
that's the reason we don't see swords, matchboxes and liquids very often
in games. Put a sword it the game, and you'll have to prevent the
player from killing people (innocent or not) and breaking doors. Put a
bottle of water in it, and now you'll have to make sure that the puzzle
involving BURN PICTURE stays solvable. (OT: put a dragon in it and
watch those Cheerios...)

As an extreme example: remember how to get the babel fish in HHGTTG?
Suppose that in your game, the puzzle is solved differently, but the
player somehow manages to figure out that doing all these insane things
should actually solve it too. There's no freakin' way for any author to
figure out that all these actions, when combined together, actually make
sense. And it would be even worse if the system would have such an
advanced simulation model that allows the player to solve the puzzle
this way. Usually, if a puzzle can successfully be "solved" by other
means than what the author intended, the game breaks (becomes
unsolvable, crashes later on, who knows what, because the algorithm+data
have entered a state that was never meant to be).

ant

unread,
Sep 29, 2005, 9:34:20 AM9/29/05
to
> I can't find it right now, but a read an article about creating worlds that
> "work by themselves" and the enjoyment of the creators when a player tried
> out something they hadn't thought of - and it worked, because the physics of
> the world was consistent enough. I love that idea too; I would enjoy finding
> out that a player solved a puzzle in an entirely unexpected way in one of my
> games.

I had a similar thought a few months ago when I was playing the
excellent All Things Devours. It occurred to me that despite enormous
differences in tone and topic, it was remarkably similar to
Metamorphoses, in that both games defined a small area of world-logic
sufficiently robust that it would work with more or less anything the
player threw at it. (All Things Devours is particularly elegant in
having a very high ratio of possible player actions to pre-coded rules,
but this is probably something that occurs on reflection after
finishing the game rather than contributing to enjoyment while playing
it. After all, as a player, I will rejoice when the game accepts my
wacky idea (e.g., wearing a shrunken workbox as a thimble) for any
reason whatsoever, without considering whether or not the author has
anticipated that particular action.) I was really impressed with the
atmosphere of freedom this gave both games, and reckon that this, if
not the Way Of The Future(TM), is certainly a technique worth
exploring.

But I think the key here is relevance to the game -- both of these
games were so successful because the "world that works by itself", to a
very large extent, *was* the game. If I can scale the red herring, chop
it up, and use it to cook bouillabaise, I want something to make that
action worthwhile -- either that it advances the plot in some way, or
that it simply elicits responses that make the action worthwhile in its
own right. If I get bored, minimal responses that seem to have been
included purely for the sake of simulationism, that's not going to make
the game seem more *interesting*, which is presumably the point of
making it seem more *real* (well, if it's not, then we're in the realms
of AI rather than IF).


A.

Kevin Forchione

unread,
Sep 29, 2005, 10:58:04 AM9/29/05
to
"Nikos Chantziaras" <rea...@arcor.de> wrote in message
news:433b97f4$0$37580$892e...@authen.white.readfreenews.net...
> Now, this isn't a limitation of a "simulationist" system. It's true for
> all systems. Usually, the author just rethinks the idea of including a
> knife in the game and, if the task of handling all possible responses
> seems too overwhelming (with a GUI tool, the possible interactions seem
> almost infinite), replaces it with a toothpick... :)

Or the reduce the scope of useful interactivity and devise an appropriate
default response for all other cases. What an author ought to be striving
for is a set of responses that are consistent within the requirements of the
narrative, not necessarily consistent within the requirements of physics, or
even of the physics model of the game world. If the response is one that
would be consistent with narrative requirements then the player will
continue to suspend disbelief. However, if the action *is* allowed, and is
out of character then the player will say, "Bob wouldn't *do* a thing like
that!" or "That *wouldn't* happen in this story." Granted that most PCs are
not well-defined characters, generally acting as masks for the player, we're
still dealing with the laws of narrative causality, which must be
consistently in play if we are to tell a convincing story.

--Kevin


Peter Mattsson

unread,
Sep 29, 2005, 12:12:32 PM9/29/05
to
David Fisher wrote:

>> UNLOCK DOOR WITH KNIFE
>> DAMAGE LOCK WITH KNIFE
>> CUT MY THROAT WITH KNIFE
>> THROW KNIFE AT WALL
>> PEEL RED HERRING WITH KNIFE
>> STICK KNIFE TO TREE, STAND ON KNIFE, GET APPLE
>> PUT KNIFE ON CHAIR. BILL, TAKE A SEAT
>> PUT KNIFE ON DOOR. BILL, OPEN THE DOOR (long shot, but hey)
>> TIE KNIFE TO PLANK. CUT APPLE
>
>
> Depending on the level of simulation of the system (which is determined by
> the system author, not the game author), it may be possible to twist an
> arbitrary piece of metal into a lock pick, or not. If it is, this is one of
> the things the tool I proposed would check; if not, it wouldn't check it.
> Where is the problem ?

I think what the poster is trying to get at here is that a complete
check of all possible interactions would be a very open-ended process.
For example, the player could use a knife to cut a vacuum-cleaner cord,
which could then be tied to a couple of rocks and used as a bola. The
bola could then be thrown at the branch of a tree, severing it. The
branch could then be lit by a match and used as a torch, completely
eliminating the find-the-battery-for-the-flashlight puzzle that the
author had worked so hard on. Could any conceivable checking system spot
these kinds of problems in a reasonable time? Checking interactions
between existing objects is one thing, but expanding the checks to all
objects that the player could conceivably create would be a
computational nightmare.

I'm not saying that a checking tool wouldn't be useful, but it would
always have limitations. Having players come up with unexpected
solutions as a result could often be quite an entertaining side-effect,
but you'd have to be sure that they didn't ruin your carefully planned
story by taking an unexpected shortcut!

Cheers,

Peter

James Mitchelhill

unread,
Sep 29, 2005, 1:53:20 PM9/29/05
to
On Thu, 29 Sep 2005 17:12:32 +0100, Peter Mattsson wrote:

<snip>


> I'm not saying that a checking tool wouldn't be useful, but it would
> always have limitations. Having players come up with unexpected solutions
> as a result could often be quite an entertaining side-effect, but you'd
> have to be sure that they didn't ruin your carefully planned story by
> taking an unexpected shortcut!

I'm wondering if we're thinking of this in the right way. The general
consensus (and my own opinion from previous posts) seems to be that
simulationism leads to deep problems in implementing the stories we want
to tell using IF.

But, of course, there'd be no point in trying to tell traditional IF
stories using similationism. Traditional IF is fairly good at telling its
stories without overarching game physics.

I'm beginning to think now that the more interesting question is what type
of stories could be told in a simulationist framework. The way that
puzzles are used would have to change (but how exactly?). How deeply
simulated would NPCs have to be? Would the resulting game play more like a
text-based RPG or IF or something else entirely?

I think it's an avenue worth exploring.

--
James Mitchelhill
ja...@disorderfeed.net
http://disorderfeed.net

Peter Mattsson

unread,
Sep 29, 2005, 2:59:33 PM9/29/05
to
James Mitchelhill wrote:
> I'm beginning to think now that the more interesting question is what
> type of stories could be told in a simulationist framework. The way
> that puzzles are used would have to change (but how exactly?). How
> deeply simulated would NPCs have to be? Would the resulting game play
> more like a text-based RPG or IF or something else entirely?
>
> I think it's an avenue worth exploring.

I quite agree. My first thought is that the most interesting uses of a
simulationist approach are in situations that are essentially
exploratory, rather than goal-directed (since players can so easily
subvert any attempt to drive them towards a given end). Rather than a
plot, you would simply set up a world which you think has the potential
to evolve in interesting ways, put the player in it and let them do what
they want to.

The classic literary novel often seems to work like this: the author
sets up a situation with enough conflict potential, say, to make things
interesting, devises some characters to put in it, and then writes down
their best guess as to what would happen if those characters were really
to come together in that situation. The best such novels are often the
ones that stay true to this ideal, and avoid making the characters act
in unnatural ways to push the plot in the direction the author wants.

This may seem to make things simpler in some ways -- you only have to
come up with an initial setup and a map -- but that's likely to be more
than compensated for by the difficulty of ensuring that as many players
get something interesting out of it as possible. The good thing about
the current approach is that it doesn't allow the player to go too far
off track; I'm not sure how you would do that within a simulationist model.

For example, at the moment, if you want the player to overhear a
conversation in the next room, you can simply trigger the conversation
to happen when the player goes by. In a simulationist game, you wouldn't
have this sort of "game logic" to lean on, so the chances are pretty
good that the player would miss the conversation. How you make sure that
the player nonetheless stumbles on enough interesting stuff to make the
game worthwhile without this level of control is, to me, the most
difficult question to answer.

Cheers,

Peter


David Fisher

unread,
Sep 29, 2005, 6:50:40 PM9/29/05
to
"Kevin Forchione" <ke...@lysseus.com> wrote in message
news:0iT_e.682$sL3...@newssvr13.news.prodigy.com...

> What an author ought to be striving for is a set of responses that are
> consistent within the requirements of the narrative, not necessarily
> consistent within the requirements of physics, or even of the physics
> model of the game world. If the response is one that would be consistent
> with narrative requirements then the player will continue to suspend
> disbelief. However, if the action *is* allowed, and is out of character
> then the player will say, "Bob wouldn't *do* a thing like that!" or "That
> *wouldn't* happen in this story." Granted that most PCs are not
> well-defined characters, generally acting as masks for the player, we're
> still dealing with the laws of narrative causality, which must be
> consistently in play if we are to tell a convincing story.

An alternative view (again I wish I could find the original reference - this
came up in a previous post to RAIF):

If the player says "attack the man" (or even "jump off cliff") and the game
replies, "Bob wouldn't do a thing like that", the player might justifiable
reply, "Yes, he would ! I just did !"

If the player wants the PC to act in a way that makes the story
unconvincing, then I believe the player's enjoyment takes precedence over
the story (to whatever extent is easily manageable without utterly
destroying the story). I would rather be able to do something interesting or
silly (as long as it is relatively inconsequential to the plot) than be told
I can't do it ...

David Fisher


David Fisher

unread,
Sep 29, 2005, 7:06:33 PM9/29/05
to

"Peter Mattsson" <pe...@XYZZYmattssons.e7even.com> wrote in message
news:dhh3kh$iq5$1...@news.e7even.com...

Hmmm. What might be needed then is something that lets you ask the question,
"Is there any way for the player to get from A to B without going via C ?"
(where C is a game state like "having the knife", "talking to Fred", etc).

So the tool I originally speculated about might need the ability to check
for reachability and paths between game states ... tricky not impossible.
This gets into the area of program verification and data flow analysis,
which should be simpler for IF than for most other programming domains,
since there are fewer things like recursive functions, complex loops, etc.

Nikos - good example in your post about sticking the knife into the tree ...

David Fisher


David Fisher

unread,
Sep 29, 2005, 7:13:55 PM9/29/05
to
"James Mitchelhill" <ja...@disorderfeed.net> wrote in message
news:pan.2005.09.29....@disorderfeed.net...

>
> I'm wondering if we're thinking of this in the right way. The general
> consensus (and my own opinion from previous posts) seems to be that
> simulationism leads to deep problems in implementing the stories we want
> to tell using IF.

Could I ask you to sum up these problems ? I can see that some puzzles could
be "short circuited", and that the player could get distracted by all of the
things they could do ("tie up bartender") - which I see as something fun for
the player to experiment with, rather than a real problem. What else ?

> I'm beginning to think now that the more interesting question is what type
> of stories could be told in a simulationist framework. The way that
> puzzles are used would have to change (but how exactly?). How deeply
> simulated would NPCs have to be? Would the resulting game play more like a
> text-based RPG or IF or something else entirely?

Great point ...

David Fisher


David Fisher

unread,
Sep 29, 2005, 7:31:57 PM9/29/05
to
"Peter Mattsson" <pe...@XYZZYmattssons.e7even.com> wrote in message
news:dhhddm$vt7$1...@news.e7even.com...

>
> For example, at the moment, if you want the player to overhear a
> conversation in the next room, you can simply trigger the conversation to
> happen when the player goes by. In a simulationist game, you wouldn't have
> this sort of "game logic" to lean on, so the chances are pretty good that
> the player would miss the conversation.

You can "twiddle the internals" of the game so that the player still happens
to encounter such things at the right time ... what the player doesn't know
won't hurt them :-)

I don't think it's a good idea to make NPCs completely autonomous and
AI-controlled ... they might want to go and get something to eat when the PC
vitally needs them to be there. If an NPC model complete with emotions,
motivations, fears and desires is used, I think it should also contain
"overrides" to make sure certain things happen (maybe implemented as an
overwhelming desire to tell the PC about the lighthouse on the hill or
whatever).

> How you make sure that the player nonetheless stumbles on enough
> interesting stuff to make the game worthwhile without this level of
> control is,
> to me, the most difficult question to answer.

I have started a collection of interesting "plot points" that can happen in
a game (eg. from Star Wars: Luke inheriting his father's light sabre;
generalisation => a powerful object is inherited by the PC). Perhaps a
system could be developed which generates "plot events" at different points
in the game, with an overarching theme like "destroy the powerful enemy" or
"find the lost city" and the details filled in as the game progresses.

Having the details dynamically generated like this could solve the problem
of player freedom to wreck the plot ... if the PC ignores a potential plot
point (eg. ignores a hint from an NPC to find Beedle the Red), then an
alternative plot point could be generated instead - enough to keep the game
interesting.

David Fisher


Peter Mattsson

unread,
Sep 29, 2005, 7:39:20 PM9/29/05
to
David Fisher wrote:
> Hmmm. What might be needed then is something that lets you ask the question,
> "Is there any way for the player to get from A to B without going via C ?"
> (where C is a game state like "having the knife", "talking to Fred", etc).
>
> So the tool I originally speculated about might need the ability to check
> for reachability and paths between game states ... tricky not impossible.
> This gets into the area of program verification and data flow analysis,
> which should be simpler for IF than for most other programming domains,
> since there are fewer things like recursive functions, complex loops, etc.

This still seems tough to me -- at least, to do the job on a
realistically-sized game in a feasible amount of time -- but I'll leave
arguing the point to those who know what they're talking about... (By
the by, you'd want to give the author clear information about the
solutions such a search finds, as it would naturally take you through
all possible cases, including -- if you weren't careful -- a lot of
fairly nonsensical ones. On the other hand, it might reveal useful
information about the limits of the simulation. "What, the player can
lasso the horse with the dental floss?")

Depending on how you wanted to play it, another thing you'd need to
check for would be states that render the game unwinnable (if you wanted
to be nice to the player, at least). Checking that the intended path to
the solution is still open would obviously be easy enough, but that
still leaves cases where the intended path is closed but some
alternative, unconsidered, path is still available. At a guess, this
would be substantially harder, though, so it could well not be worth it.

Cheers,

Peter

Peter Mattsson

unread,
Sep 29, 2005, 8:05:37 PM9/29/05
to
David Fisher wrote:
> "Peter Mattsson" <pe...@XYZZYmattssons.e7even.com> wrote in message
> news:dhhddm$vt7$1...@news.e7even.com...
>
>>For example, at the moment, if you want the player to overhear a
>>conversation in the next room, you can simply trigger the conversation to
>>happen when the player goes by. In a simulationist game, you wouldn't have
>>this sort of "game logic" to lean on, so the chances are pretty good that
>>the player would miss the conversation.
>
>
> You can "twiddle the internals" of the game so that the player still happens
> to encounter such things at the right time ... what the player doesn't know
> won't hurt them :-)
>
> I don't think it's a good idea to make NPCs completely autonomous and
> AI-controlled ... they might want to go and get something to eat when the PC
> vitally needs them to be there. If an NPC model complete with emotions,
> motivations, fears and desires is used, I think it should also contain
> "overrides" to make sure certain things happen (maybe implemented as an
> overwhelming desire to tell the PC about the lighthouse on the hill or
> whatever).

I'd been thinking of autonomous NPCs (and hence that the game author
would have no control over the timing of the conversation above). As
soon as you go away from this, though, and force things to happen, you
run the risk of breaking down the simulation to a point that the player
will notice. For example, say the player decides to ambush one of the
characters that is supposed to take part in the conversation before he
gets there, then ties him up and leaves him in a cupboard. The
conversation can't then happen at all, and much of the rest of the plot
might get mucked up. To avoid this, you'd need to find ways to disallow
such actions (making the character strong enough or fast enough to fight
the player off, say), but you'd struggle to keep that believable in the
face of a really determined and devious player. ("What? Old Tom, the
one-legged, blind octogenarian fought me off and ran away?") My feeling
is that "narrative causality" will just have to fall by the wayside if
you want to take simulationism seriously.

>
>
>>How you make sure that the player nonetheless stumbles on enough
>>interesting stuff to make the game worthwhile without this level of
>>control is,
>>to me, the most difficult question to answer.
>
>
> I have started a collection of interesting "plot points" that can happen in
> a game (eg. from Star Wars: Luke inheriting his father's light sabre;
> generalisation => a powerful object is inherited by the PC). Perhaps a
> system could be developed which generates "plot events" at different points
> in the game, with an overarching theme like "destroy the powerful enemy" or
> "find the lost city" and the details filled in as the game progresses.
>
> Having the details dynamically generated like this could solve the problem
> of player freedom to wreck the plot ... if the PC ignores a potential plot
> point (eg. ignores a hint from an NPC to find Beedle the Red), then an
> alternative plot point could be generated instead - enough to keep the game
> interesting.

This sounds like a much better idea, if you could get it to work. Again,
though, I worry what players determined on wrecking your scenario
could do to it, and the effort you'd need to put in to stop them. (Then
again, you could just give such players their just desserts, and let
them have a dull life if that's what they really want!) Finding
alternative plot points for every occasion (that are also believable)
could be tricky, but I agree that it doesn't seem an insuperable problem.

One thing this highlights, though, is that you'd have to set aside the
current notion of telling a detailed story and content yourself with
broad strokes. That, however, could well be a good thing!

Cheers,

Peter
>
> David Fisher
>
>

James Mitchelhill

unread,
Sep 29, 2005, 9:10:06 PM9/29/05
to
On Fri, 30 Sep 2005 09:13:55 +1000, David Fisher wrote:

> "James Mitchelhill" <ja...@disorderfeed.net> wrote in message
> news:pan.2005.09.29....@disorderfeed.net...
>>
>> I'm wondering if we're thinking of this in the right way. The general
>> consensus (and my own opinion from previous posts) seems to be that
>> simulationism leads to deep problems in implementing the stories we want
>> to tell using IF.
>
> Could I ask you to sum up these problems ? I can see that some puzzles
> could be "short circuited", and that the player could get distracted by
> all of the things they could do ("tie up bartender") - which I see as
> something fun for the player to experiment with, rather than a real
> problem. What else ?

Maybe I was overstating the case of there being a consensus a little... ;)

As I see it, there's a number of different problems, some of which are
more tractable than others.

1) Generating Human-like Text

Increasing simulation leads to decreasing levels of abstraction in the
underlying game world. Writing code to generate human-like descriptive
text becomes harder as abstraction increases.

The difference is between "In the drawer you see three coins and a piece
of paper" and "Towards the front of the drawer you see three coins stacked
into a small tower, which rests on top of a piece of of paper."

This also has an effect on the way authors would have to write
descriptions. The problem of authored descriptions not matching the
underlying model becomes much more general. The canonical example in
traditional IF is a game where an object is mentioned in a room
description which remains there, even when the player has moved it.

In a simulationist game, the author cannot be certain of the
results of anything that is controlled by the game physics. So a
description that mentions how "The harsh, fluorescent light casts a
flickering glow over the room, robbing the world of shadows and depth"
becomes innacurate if the player throws a rock that shatters the light and
chooses to illuminate the room using the branch he set fire to using the
stove in the kitchen.


2) Authorial Burden

Combinatorial explosion is hard enough for authors to deal with in
traditional IF. While simulation seems to help with the problem, it
actually makes it much more difficult for the author. A computer generated
response, whether the result of a simulation or a default response is not
interesting for players.

In traditional IF the author only has to deal with a subset of
interactions, where most responses will be failure messages. One sign of
well designed IF is that trying things that don't work can be just as
interesting as success. In simulationist IF, the author would have to deal
with every possible interaction, without knowing which of these is
reachable within the game or the context in which players will be seeing
them.

Then secondary problems I've seen mentioned (mostly in the recent
"producing adventures" thread:

3. Specifying Objects - The amount of properties that an author has to
provide to define an object well enough for a simulationist model is too
high.

4. Customising the "physics" of the world would presumably be a much
larger undertaking than customising traditional libraries.

5. Greater possibility of very strange bugs.

6. Simulation seems incompatible with plot.

7. Difficulty leading the player to do the interesting things the author
intended rather than the multitude of other possibilities present.

8. Complications involved with coding much more abstractly than authors
are used to, leading to a higher learning curve for the system.

9. How will NPCs fit into a simulationist world model?

There's probably others. I don't see any problems that are truly
insurmountable, but I don't see any easy way around the first two. This
may be because I'm not imaginative enough.

It's an interesting direction to explore, though.

David Fisher

unread,
Sep 29, 2005, 9:17:30 PM9/29/05
to
"Peter Mattsson" <pe...@XYZZYmattssons.e7even.com> wrote in message
news:dhhvg9$1t2$1...@news.e7even.com...

> David Fisher wrote:
>>
>> I have started a collection of interesting "plot points" that can happen
>> in a game (eg. from Star Wars: Luke inheriting his father's light sabre;
>> generalisation => a powerful object is inherited by the PC). Perhaps a
>> system could be developed which generates "plot events" at different
>> points in the game, with an overarching theme like "destroy the powerful
>> enemy" or "find the lost city" and the details filled in as the game
>> progresses.
>>
>> Having the details dynamically generated like this could solve the
>> problem of player freedom to wreck the plot ... if the PC ignores a
>> potential plot point (eg. ignores a hint from an NPC to find Beedle the
>> Red), then an alternative plot point could be generated instead - enough
>> to keep the game interesting.
>
> This sounds like a much better idea, if you could get it to work. Again,
> though, I worry what players determined on wrecking your scenario could do
> to it, and the effort you'd need to put in to stop them. (Then again, you
> could just give such players their just desserts, and let them have a dull
> life if that's what they really want!) Finding alternative plot points for
> every occasion (that are also believable) could be tricky, but I agree
> that it doesn't seem an insuperable problem.

I am imagining quite a large database of plot points, each with pre & post
conditions and other information to help them fit together ...

> One thing this highlights, though, is that you'd have to set aside the
> current notion of telling a detailed story and content yourself with broad
> strokes. That, however, could well be a good thing!

Hmmm. The game author could become a "plot point inventor" instead of an
"overall plot determiner" ... writing snippets of connectable pieces with a
common theme that can be joined together, rather than writing a single
story. (I would happily play games I had written myself if I didn't know
what was going to happen !) There is also a greater possibility of
collaboration, as each author contributes a part to the whole set of
possible plots ...

Another issue is that of automatically generated text (to explain the
generated plot points) ... as mentioned in the "tracks in the snow" part of
the Producing Adventures thread, this is also very tricky.

David Fisher


Christos Dimitrakakis

unread,
Sep 29, 2005, 10:18:39 PM9/29/05
to
On Fri, 30 Sep 2005 11:17:30 +1000, David Fisher wrote:

> "Peter Mattsson" <pe...@XYZZYmattssons.e7even.com> wrote in message
> news:dhhvg9$1t2$1...@news.e7even.com...
>> David Fisher wrote:
>>>
>>> I have started a collection of interesting "plot points" that can happen
>>> in a game (eg. from Star Wars: Luke inheriting his father's light sabre;
>>> generalisation => a powerful object is inherited by the PC). Perhaps a
>>> system could be developed which generates "plot events" at different
>>> points in the game, with an overarching theme like "destroy the powerful
>>> enemy" or "find the lost city" and the details filled in as the game
>>> progresses.
>>>

Whenever you start with such a set of predetermined plot points, or nodes,
or whatever they may be called, you will have the problem of connecting
the plot points in a consistent way. You will need a model for transitions
from one plot point to the other. Not only that, but you will also need an
underlying model for the physical/emotional objects which are essential
parts of the plot points.

It is possible to factorise the model, as in, you might have a model where
the transition of (boy loves girl)->(evil man steals girl)->(evil man too
strong for the boy to defeat)->(boy searches object of power)->(boy
defeats evil man with object of power) is one particular plot sequence
derived from our plot model, and the actual evil man/girl/object/boy
objects are instances of a separate model.

>>> Having the details dynamically generated like this could solve the
>>> problem of player freedom to wreck the plot ... if the PC ignores a
>>> potential plot point (eg. ignores a hint from an NPC to find Beedle the
>>> Red), then an alternative plot point could be generated instead - enough
>>> to keep the game interesting.
>>
>> This sounds like a much better idea, if you could get it to work. Again,
>> though, I worry what players determined on wrecking your scenario could do
>> to it, and the effort you'd need to put in to stop them. (Then again, you
>> could just give such players their just desserts, and let them have a dull
>> life if that's what they really want!) Finding alternative plot points for
>> every occasion (that are also believable) could be tricky, but I agree
>> that it doesn't seem an insuperable problem.
>
> I am imagining quite a large database of plot points, each with pre & post
> conditions and other information to help them fit together ...
>

Again, possible, especially with factorisation, where different factors
are combined to create possible transitions from one plot point to the
other. But interesting? Self-consistent? I'd like to try doing something
like that, but my chances of success I feel are very low. Furthermore, by
simply saying that you will 'just do whatever is possible to do something
more interesting'... you mean this:

You have a model of what is an interesting plot - and you have a model of
your player - and whatever the player does, you generate events according
to your interesting-plot model. Right? The only problem with this scenario
is that if you want to have a very large number of possible events, you
will never be able to write everything by hand (otherwise you'd take care
of all eventualities by hand) - so that will result in a lot of generic
descriptions of events. Which is fine, but it's not what traditional IF is.


>> One thing this highlights, though, is that you'd have to set aside the
>> current notion of telling a detailed story and content yourself with broad
>> strokes. That, however, could well be a good thing!
>
> Hmmm. The game author could become a "plot point inventor" instead of an
> "overall plot determiner" ... writing snippets of connectable pieces with a
> common theme that can be joined together, rather than writing a single
> story. (I would happily play games I had written myself if I didn't know
> what was going to happen !) There is also a greater possibility of
> collaboration, as each author contributes a part to the whole set of
> possible plots ...
>

Seamlessly connectible pieces will seriously diminish the number of plot
possibilities available. Again, this is something that could be hardcoded
and for which no general model can easily be generated.

> Another issue is that of automatically generated text (to explain the
> generated plot points) ... as mentioned in the "tracks in the snow" part of
> the Producing Adventures thread, this is also very tricky.
>

Hah, automatically generated text.


steve....@gmail.com

unread,
Sep 29, 2005, 10:19:23 PM9/29/05
to
Kevin's point is basically for the story's aesthetic coherence, but
that's just an aesthetic that the writer might like to ignore (as you
argue). But I would like to mention that we're talking about an
(essentially insurmountable) AI problem also....

> If the player says "attack the man" (or even "jump off cliff") and the game
> replies, "Bob wouldn't do a thing like that", the player might justifiable
> reply, "Yes, he would ! I just did !"

It sounds like you're arguing against the use of "default messages"
that limit the player's range of action. (I know that's not your point,
but it's a consequence of what you're saying.) The player may be
frustrated by the narrowness of the game's availible range of action,
but what's the author supposed to do about it? Create a customized
response to permit everything imaginable? Obviously, this is
practically impossible even in a small game (though "Pick up the Phone
Booth and Aisle" comes to mind as a possible counterexample). The
alternative is to create a simulation that's smart enough to figure out
a reasonable response to any action, without requiring the writer to
fill in all the blanks -- but even cutting-edge AI isn't even close to
this capability. The narrowness of availible action is an inevitable
consequence of the genre's command-line driven input framework. Where,
in other genres, there appears such a boundless game, this is owing to
a frame clever enough (and a simulation simplistic enough) that it
produes the *sensation* of unlimited possibility. Perhaps this is just
another way to describe suspension of disbelief, but that's something
we already have in well-wrought IF.

Kevin Venzke

unread,
Sep 29, 2005, 10:31:51 PM9/29/05
to
Hi,

"David Fisher" <da...@hsa.com.au> wrote in message

news:hh__e.1365$96.1...@nasal.pacific.net.au...


> If the player says "attack the man" (or even "jump off cliff") and the game
> replies, "Bob wouldn't do a thing like that", the player might justifiable
> reply, "Yes, he would ! I just did !"
>
> If the player wants the PC to act in a way that makes the story unconvincing,
> then I believe the player's enjoyment takes precedence over the story (to
> whatever extent is easily manageable without utterly destroying the story). I
> would rather be able to do something interesting or silly (as long as it is
> relatively inconsequential to the plot) than be told I can't do it ...

A problem with this is that the player doesn't necessarily know he's
making a decision between what he wants to do, and what the author
requires from him in order to keep the story sensible. As far as the
player knows, "attack the man," if permitted, might be exactly what
the author intended. So how does the author communicate to the
player what's a reasonable action and what's implemented just for the
fun, at the story's expense?

Kevin Venzke


Kevin Venzke

unread,
Sep 29, 2005, 10:42:08 PM9/29/05
to

"James Mitchelhill" <ja...@disorderfeed.net> wrote in message
> 7. Difficulty leading the player to do the interesting things the author
> intended rather than the multitude of other possibilities present.

I think this one is huge. When the player gets a response more promising
than "I don't know what you're talking about," he tends to believe he's on
the right track. Having default library messages string the player along,
making him falsely believe he's on to something, is just going to exhaust
the player's patience.

Worse, the interactions the author actually wants the player to try have
to compete for attention with the interactions made possible (but not
useful, at least not intentionally useful) by the library.

I suppose you could say that the author should make his puzzles
solvable through mechanisms built into the simulationist library. Then
the "use X to get Y" technique might disappear from the code. In
place of this, the programmer has to think long and hard about the
implications of the properties of any object he adds to the game.
He's after all designing a *game* and not a simulation.

Kevin Venzke


James Mitchelhill

unread,
Sep 30, 2005, 12:16:27 AM9/30/05
to
On Thu, 29 Sep 2005 19:19:23 -0700, steve.breslin wrote:

> Kevin's point is basically for the story's aesthetic coherence, but that's
> just an aesthetic that the writer might like to ignore (as you argue). But
> I would like to mention that we're talking about an (essentially
> insurmountable) AI problem also....

<snip>

> The alternative is to create a simulation that's
> smart enough to figure out a reasonable response to any action, without
> requiring the writer to fill in all the blanks -- but even cutting-edge AI
> isn't even close to this capability.

<snip>

I've been thinking about whether these problems are AI-complete or not and
I haven't been able to convince myself one way or the other yet, although
I'm leaning towards not. The important thing to remember is that the goal
isn't to replace, but to augment the author.

Parsing natural language is an AI-Complete problem. The more sophisticated
IF parsers don't do this, but they simulate a solution to a limited
subset of the problem. (They're actually more limited than they need to
be, because IF lends itself to concise formations of language - it's easy
to extend them to cover a fairly broad range of their problem set.)

My point being? The way IF has handled intractable problems is to reduce
their scope to a smaller subset of the problem, while still remaining
useful. The system doesn't need to be smart enough to solve any problem,
because it can leverage the non-artificial intelligence of authors. (This
seems back to front - Authors can leverage the computational power of the
system.)

It's still a difficult problem, but it doesn't seem impossible to me. That
said, I don't actually have any concrete ideas about how a possible system
would function.

David Fisher

unread,
Sep 30, 2005, 12:19:48 AM9/30/05
to
<steve....@gmail.com> wrote in message
news:1128046763....@o13g2000cwo.googlegroups.com...

>> David Fisher wrote:
>>
>> If the player says "attack the man" (or even "jump off cliff") and the
>> game
>> replies, "Bob wouldn't do a thing like that", the player might
>> justifiable
>> reply, "Yes, he would ! I just did !"
>
> It sounds like you're arguing against the use of "default messages"
> that limit the player's range of action. (I know that's not your point,
> but it's a consequence of what you're saying.)

As I said in my previous post:

>> I believe the player's enjoyment takes precedence over
>> the story (to whatever extent is easily manageable without utterly
>> destroying the story). I would rather be able to do something
>> interesting or silly (as long as it is relatively inconsequential to
>> the plot) than be told I can't do it ...

I think failure messages are fine in lots of contexts, like reaching the
edge of the map - but it greatly adds to my own sense of immersion in the
game if I am permitted to do things that seem "obvious", as long as they
don't destroy the ongoing plot of the game.

> The player may be frustrated by the narrowness of the game's

> available range of action, but what's the author supposed to


> do about it? Create a customized response to permit everything
> imaginable?

That's what the (huge) simulation library would be for ... the generated
text would hopefully seem quite similar to a custom response. I would be
less interested in a simulationist approach that forced you to customise
everything yourself.

While I'm on the subject of imaginary future IF systems, just a quick
thought: Imagine a system that let an author define their writing style
(*somehow* - maybe from examples and snippets of text. Don't confuse me with
implementation issues :-) You could play the same game in the style of
Graham Nelson and of Emily Short, with text generated in the style of your
preferred author.

> The alternative is to create a simulation that's smart enough
> to figure out a reasonable response to any action, without
> requiring the writer to fill in all the blanks -- but even
> cutting-edge AI isn't even close to this capability.

I believe there could be a level of simulation which works well enough to
make people like me happy, but still has clearly defined limits ... just as
current parsers have definite limits which are still acceptable to people
(with the possible exception of conversation with NPCs). The kind of AI you
are talking about may not be necessary if the level of simulation is low
enough ... it would be lower than "figuring out a reasonable response to any
action", anyway. Defining the intended limits of the system is be a big
enough task by itself, though !

Practical example: liquids ... the libraries that already exist for Inform
and TADS2/3 seem just about there already. Things like chemical reactions,
acidity, exact evaporation times, etc. would not really be required in the
basic library.

Example 2: string and ropes. I enjoyed Mike Roberts' post about tying a
piece of string to a book (27th Sep 2005, 12:59 PM in the Producing
Adventures thread). If I was playing a game and I wanted to tie a piece of
string to something (eg. to lower an object to someone), I would be
frustrated if I couldn't do it. But I wouldn't mind if I wasn't allowed to
specify the type of knot to use, or even if I couldn't tie a knot 2/3 of the
way along it ...

Example 3: breakable objects. If there is a wooden chair and a fireplace,
and I have to find some firewood, then I would be unhappy if breaking up the
chair was not an option.

Non-example 4: digging tunnels. I am content with a game that doesn't let
you do major changes to the geography of the game, like creating a passage
where there wasn't one before.

Anyway, that's about the level of simulation that would work for me ...

> The narrowness of availible action is an inevitable
> consequence of the genre's command-line driven input framework. Where,
> in other genres, there appears such a boundless game, this is owing to
> a frame clever enough (and a simulation simplistic enough) that it
> produes the *sensation* of unlimited possibility.

Could you give an example from another genre ?

Thanks for the thoughts and responses,

David Fisher


James Mitchelhill

unread,
Sep 30, 2005, 12:29:10 AM9/30/05
to
On Fri, 30 Sep 2005 02:42:08 +0000, Kevin Venzke wrote:

>
> "James Mitchelhill" <ja...@disorderfeed.net> wrote in message
>> 7. Difficulty leading the player to do the interesting things the author
>> intended rather than the multitude of other possibilities present.
>
> I think this one is huge. When the player gets a response more promising
> than "I don't know what you're talking about," he tends to believe he's on
> the right track. Having default library messages string the player along,
> making him falsely believe he's on to something, is just going to exhaust
> the player's patience.

<snip>

Odd. I think this one is really minor. We're not taking about a
traditional IF system, so the expectations of traditional IF don't really
apply. There's not much point in adding vast simulation to what would
otherwise be a traditional IF game.

The conventions of IF have been shaped by the tools available, which are
excellent for the task of creating certain types of story and game.
Different tools would enable the creation of different types of stories
and games.

steve....@gmail.com

unread,
Sep 30, 2005, 11:06:16 AM9/30/05
to
James writes:

> I've been thinking about whether these problems are AI-complete or not and
> I haven't been able to convince myself one way or the other yet, although
> I'm leaning towards not.

AI-complete means basically that the machine is able to solve the
problem as well as a competent human would. So this problem is
AI-complete, if that's the kind of solution you want the machine


capable of. But as you write:

> The way IF has handled intractable problems is to reduce

> their scope to a smaller subset of the problem[.]

That's the strategy for taking an AI-complete problem and make it
workable: lowering our expectation of what the machine is supposed to
be able to do. We lower the expectation far enough, and the problem
becomes tractable.

My point is, the limitations of the "simulation" part of IF are
necessary for exactly the reason you expose. Developments normally
happen when we notch up our expectation a bit, and do a lot of work to
support this incrememted expectation.

steve....@gmail.com

unread,
Sep 30, 2005, 11:22:32 AM9/30/05
to
David writes:

> > The narrowness of availible action is an inevitable
> > consequence of the genre's command-line driven input framework. Where,
> > in other genres, there appears such a boundless game, this is owing to
> > a frame clever enough (and a simulation simplistic enough) that it
> > produes the *sensation* of unlimited possibility.
>
> Could you give an example from another genre ?

It's become a fad over the past few years; multi-threaded has been,
well not surpassed, but anyway challenged, by the open-ended game.
Think how many games promise "total control of your world": which is
one flavor of what I'm talking about. For examples: the latest GTA
game; Black & White and other civilization-building games; probably
some "Sims" games are like this; and so on. Even first-person shooters
(if you look at it a certain way) present a full range of action within
their limited confines.

So, sure you can sort-of do whatever you want, and everything is
open-ended, etc. But this is only possible within a really limited
frame, and an even more limited input-mechanism. Our command-line
input-regime is the main reason we don't have this kind of aeathetic in
IF. The full realization of this aesthetic in IF -- this is
AI-complete.

Adam Thornton

unread,
Sep 30, 2005, 2:20:19 PM9/30/05
to
In article <dhhvg9$1t2$1...@news.e7even.com>,

Peter Mattsson <pe...@XYZZYmattssons.e7even.com> wrote:
>My feeling
>is that "narrative causality" will just have to fall by the wayside if
>you want to take simulationism seriously.

Chris Crawford has an answer to this. It's the wrong answer, and it's
what I short-handedly referred to as "Greek tragedy," which set Emily
Short's teeth on edge, so let me be a little more explicit:

Crawford believes, in a viewpoint consonant with if not actually taken
from, Aristotle's _Poetics_ that plot ought to emerge dialectically from
character. That is, the events of the story ought to be those fated, in
some sense, by the nature of the people in the story. It is the
collisions of their goals and beliefs that cause narrative tension and
plot advances.

I think that this is both an intractable-to-solve-convincingly-with-current-
or-near-term-forseeable-technology problem, and a means of proceeding
that, even *if* you could do it perfectly, which I do *not* grant,
*might*--and I emphasize *might*--allow you to construct stories of the
approximate shape of Greek tragedies, where the events of the narrative
are those that are a natural effect of the working out of the
characters' natures via their actions.

I don't think that's *all* stories, nor even *all entertaining* stories,
nor even *most entertaining* stories. Which is where I disagree,
vehemently, with Crawford.

>One thing this highlights, though, is that you'd have to set aside the
>current notion of telling a detailed story and content yourself with
>broad strokes. That, however, could well be a good thing!

The Erasmatron tries exactly this.

As far as I've ever been able to determine, it doesn't work, and it not
only doesn't work because the implementation is not very good (it is not
very good even given the current state of the art, and the current state
of the art is nowhere near enough to actually allow it to work well),
but also because the underlying concept is broken. See above.

The Holodeck sequence of _Stiffy Makane: The Undiscovered Country_ is a
somewhat more entertaining attempt to address these questions.

Adam

Adam Thornton

unread,
Sep 30, 2005, 2:28:00 PM9/30/05
to
In article <4D__e.1368$96.1...@nasal.pacific.net.au>,

David Fisher <da...@hsa.com.au> wrote:
>"James Mitchelhill" <ja...@disorderfeed.net> wrote in message
>> I'm beginning to think now that the more interesting question is what type
>> of stories could be told in a simulationist framework. The way that
>> puzzles are used would have to change (but how exactly?). How deeply
>> simulated would NPCs have to be? Would the resulting game play more like a
>> text-based RPG or IF or something else entirely?
>Great point ...

Folks, do the literature search.

This is precisely the point of Chris Crawford's Erasmatron. I don't
think it works, but, hey, go check it out for yourselves:

http://www.erasmatazz.com/

Also read his book on interactive storytelling:

Crawford, Chris. _Chris Crawford on Interactive Storytelling.
Berkeley: New Riders, 2005. ISBN 0-321-27890-9

Adam

Adam Thornton

unread,
Sep 30, 2005, 2:30:43 PM9/30/05
to
In article <P63%e.1684$96.1...@nasal.pacific.net.au>,

David Fisher <da...@hsa.com.au> wrote:
>(*somehow* - maybe from examples and snippets of text. Don't confuse me with
>implementation issues :-) You could play the same game in the style of
>Graham Nelson and of Emily Short, with text generated in the style of your
>preferred author.

Oh, you can just use RAIF-POOL with the --pastiche option on the
output. I particularly enjoyed Plundered Hearts As Told By
H.P. Lovecraft.

Adam

James Mitchelhill

unread,
Sep 30, 2005, 3:35:44 PM9/30/05
to
On Fri, 30 Sep 2005 18:28:00 +0000, Adam Thornton wrote:

> In article <4D__e.1368$96.1...@nasal.pacific.net.au>, David Fisher
> <da...@hsa.com.au> wrote:
>>"James Mitchelhill" <ja...@disorderfeed.net> wrote in message
>>> I'm beginning to think now that the more interesting question is what
>>> type of stories could be told in a simulationist framework. The way
>>> that puzzles are used would have to change (but how exactly?). How
>>> deeply simulated would NPCs have to be? Would the resulting game play
>>> more like a text-based RPG or IF or something else entirely?
>>Great point ...
>
> Folks, do the literature search.

Have done.


> This is precisely the point of Chris Crawford's Erasmatron. I don't think
> it works, but, hey, go check it out for yourselves:
>
> http://www.erasmatazz.com/

Already did.

> Also read his book on interactive storytelling:
>
> Crawford, Chris. _Chris Crawford on Interactive Storytelling. Berkeley:
> New Riders, 2005. ISBN 0-321-27890-9

Don't see the point.

I've not been impressed by what I've read from Chris Crawford. And I was
even less impressed by the Erasmatron when I checked it out. What
surprises me is that Chris Crawford is still working on it, although the
last public release seems to have been five years ago.

In any case, there doesn't appear to be a huge cross-over between the
Erasmatron and what we're discussing here.

So, what relevance does this have?

Adam Thornton

unread,
Sep 30, 2005, 3:51:32 PM9/30/05
to
In article <pan.2005.09.30....@disorderfeed.net>,

James Mitchelhill <ja...@disorderfeed.net> wrote:
>In any case, there doesn't appear to be a huge cross-over between the
>Erasmatron and what we're discussing here.
>
>So, what relevance does this have?

Because there *is* a huge cross-over: you guys are talking about
simulation-driven worlds and their relation to plot, and that's ENTIRELY
the purpose of the Erasmatron, except that Crawford is much more
interested in emotional than physical simulation. Nevertheless, the
same objections will apply, to wit, that allowing the "physics" (whether
that's emotional or mechanical physics) to drive the story is going to
result in, *at best*, Greek tragedies about character archetypes
colliding with one another and the world, and, *in practice*, really
boring pointless stories that don't go much of anywhere.

Adam

ems...@mindspring.com

unread,
Sep 30, 2005, 4:01:34 PM9/30/05
to

Adam Thornton wrote:
> In article <dhhvg9$1t2$1...@news.e7even.com>,
> Peter Mattsson <pe...@XYZZYmattssons.e7even.com> wrote:
> >My feeling
> >is that "narrative causality" will just have to fall by the wayside if
> >you want to take simulationism seriously.
>
> Chris Crawford has an answer to this. It's the wrong answer, and it's
> what I short-handedly referred to as "Greek tragedy," which set Emily
> Short's teeth on edge, so let me be a little more explicit:

Aw, I was teasing you, Adam. Sorry if it sounded like anything else.

I had a pretty good idea of what you meant, namely that you were using
"Greek tragedy" as a shorthand for "a reductionist view of the Poetics,
which are themselves a reductionist view of Athenian drama".

Anyway, contra Crawford, I don't think we currently have the ability to
make interesting stories arise spontaneously out of a simulated
environment, whether that simulation is designed to mimic a physical
reality or the behavior of humans. (The second point being, of course,
much harder.) Though some people obviously disagree with me, I've never
had anything I would consider a *story* emerge from playing with the
Sims or games of that ilk. They can be fun, and there can be a sequence
of events where bad and good things happen, and have some causal effect
on what bad and good things can happen next; but there wasn't what you
would call a real narrative structure. There was no focus, no rising
tension, no crisis and resolution. At best, at very best, you get
something which could, with editing, become a story. The events of
Greek tragedy might be described, in some cases, as the natural
working-out of character traits -- but the fact that you perceive it
that way is, I think, the result of the playwright's skill. And it
would be ludicrous to propose that if we had a sufficiently good
character-machine, and plugged it in, and gave it some parameters for
Orestes and Electra, Clytemnestra and Aegisthus, what we would get out
the other end would be Aeschylean, with all its richness of language
and doubleness of intent...

Okay, really, I'm stopping now. The rest is mostly my take on this and
not really a reaction to the complaints against Crawford, with which I
largely agree.

I think simulation becomes interesting, and useful to us with the
current state of technology, when it allows the player freedom in how
he does what he is supposed to do in a given work of IF.

That is: the work does not work out by simulation what the plot points
are. There is nothing in the machinery that calculates, "hey, now
Orestes might feel like killing off his Mom!" and generates this event
from scratch on general principles. There are, instead, a finite set of
possible narrative outcomes; they are known in advance to the author,
and prewritten by him; they may be triggered by the world being in a
certain state. The systematic, simulationist portion of the IF allows
the player to change the world state from one to another, and trigger
events -- and maybe, though not necessarily, to choose between one
event and another -- with some degree of freedom, by
perhaps-unanticipated paths.

Setting such a thing up requires

1) that we have a specific idea of what the player's job is in this
particular game (persuade someone who holds her captive to let her go;
find out information about his enemies and use this against them; use
high-tech gadgets to break into a compound) and of how he is allowed to
interact in order to do it (by asking about topics, by choosing a tone
of voice to speak in, by exploring a space thoroughly, by destroying
doors and barricades that get in his way);

2) that we write the simulation in such a way that it allows the player
to do *this kind* of interaction consistently (the gadgets plug
together in a systematic way and the components can be swapped;
exploding something always has a rational effect, rather than working
on two things and nothing else);

3) that we write the plot events in such a way that changes are
triggered by world state and not by the specific player action (i.e.,
making the character mad in one way should have the same effect as
making him mad another way);

4) that we communicate to the player very clearly -- through what we
choose to describe, through the commands the parser will accept, and
through the ways it rejects unacceptable commands* -- what the range of
action is. In my experience most players most of the time, if they are
not frustrated and do see a positive way they can play with the IF
world, will not be annoyed that they cannot take the story off on a
complete tangent. On the contrary, they'll be a little relieved to have
the parameters of the interaction made clear to them.

[* Postulate a game with a strong system of cutting, so that the player
has got a saw, a jacknife, and an X-acto blade, and they all have
slightly different uses and effects on the other objects of the game
world. Instead of accepting a generic CUT SILK SHEETS command, the
parser should either a) choose a reasonable default for the instrument
AND SAY THAT IT IS DOING SO "(with the saw)"; or b) demand that the
player clarify which instrument he would like to use. This is not just
good for preventing frustration; it is actually teaching the player
something critical about the game, namely that cutting things is
important in this work, and means-of-cutting is going to turn out to
matter, so he should pay attention to that, stock up on other knifey
things he might find, etc.]

Simulation for its own sake is perhaps interesting but not, I think,
useful to narratively strong IF, or even to strongly puzzly IF, since a
good puzzle tends to require some quirkiness and invention. (Sure, a
Tower of Hanoi, a fifteen puzzle, a maze -- these things could be
auto-generated, but they are also, not coincidentally, the sorts of
puzzle considered unbearably tedious by much of the audience at this
point.)

Moreover, text is a difficult medium in which to present the results of
a computed simulation anyway; so that I do not think that a text
version of, say, Tropico: Pirate Island would have nearly the appeal of
the original.

So I think where a system is useful is-- well, more or less where we're
already using one, in a sense: existing IF systems already provide a
(somewhat limited) model world for this purpose. That it be limited is
right, though: extending the simulation is, in my experience, useful
when it supports the intended interaction, and otherwise a distraction
for the player and a time sink -- an enjoyable, seductive,
reason-your-game-never-leaves-your-hard-drive time sink -- for the
author.

-- Emily

James Mitchelhill

unread,
Sep 30, 2005, 5:17:35 PM9/30/05
to

I don't think this is true, but the best way to demonstrate this would
probably to implement a system of this type and write an interesting game
with it. I don't think it's a good idea to use the Erasmatron as an
example, not only because its implementation was so badly done, but
because the whole assumption behind it was that interesting stories would
result merely from the interaction of archetypes.

However, IF games *are* simulations and this simulation is a good thing
otherwise we'd all be writing CYOA games. Mike Roberts argued in the
"producing adventures" thread that after you reach a certain level of
simulation the additional benefit of deeper simulation is less than the
work needed to implement it.

What I've suggested is that the expectations and techniques employed in
traditional (i.e. contemporary) IF have been shaped by the tools available
to authors and the responses of players to the games authors have
produced. If tools (which dealt with the problems I and other have
elsewhere mentioned) were made to produce deeply simulated IF, the
authorial techniques of traditional IF may not all carry over.

This does not mean there aren't ways to make interesting stories in deeply
simulated IF, only that (because nobody's made any yet) we don't know
exactly which techniques would need to be employed. I don't think this
equates to a reduction of plot to Greek tragedy (and other people have
been talking about how the hypothetical system could best enable
authors to avoid this).

I'm interested in what stories could be made with such a system. You may
be right and it could turn out that there aren't any ways to reconcile
plot with simulation. I think that there are and this is
something worth investigating.

James Mitchelhill

unread,
Sep 30, 2005, 8:40:09 PM9/30/05
to
On Fri, 30 Sep 2005 08:06:16 -0700, steve.breslin wrote:

> James writes:
>
>> I've been thinking about whether these problems are AI-complete or not
>> and I haven't been able to convince myself one way or the other yet,
>> although I'm leaning towards not.
>
> AI-complete means basically that the machine is able to solve the problem
> as well as a competent human would. So this problem is AI-complete, if
> that's the kind of solution you want the machine capable of.

As I understand it, that's not what AI-complete means, exactly. There's
plenty of problems where machines vastly out-perform humans. AI-complete
problems are problems that seem to require strong AI to exist before they
can be solved. They generally involve multiple components, which are
inextricably linked.

Vision is an example. It appears relatively simple at the outset - all you
need to do is link a camera or two to a computer and process the input,
but it turns out that understanding visual input requires a sophisticated
understanding of the world.

Whether a system that can generate a response to a large (but limited)
range of actions is AI-complete isn't so clear.

>> The way IF has handled intractable problems is to reduce their scope to
>> a smaller subset of the problem[.]
>
> That's the strategy for taking an AI-complete problem and make it
> workable: lowering our expectation of what the machine is supposed to be
> able to do. We lower the expectation far enough, and the problem becomes
> tractable.
>
> My point is, the limitations of the "simulation" part of IF are necessary
> for exactly the reason you expose. Developments normally happen when we
> notch up our expectation a bit, and do a lot of work to support this
> incrememted expectation.

Absolutely.

steve....@gmail.com

unread,
Sep 30, 2005, 9:59:20 PM9/30/05
to
James writes:

> > AI-complete means basically that the machine is able to solve the problem

> > as well as a competent human would.[...]


>
> As I understand it, that's not what AI-complete means, exactly. There's
> plenty of problems where machines vastly out-perform humans. AI-complete
> problems are problems that seem to require strong AI to exist before they
> can be solved. They generally involve multiple components, which are
> inextricably linked.

I'm sorry, this is somewhat off-topic. But I guess I should clarify the
terms nevertheless, for those who might be interested.

The terms "NP-hard" and "NP-complete" have technical meanings; they
describe algorithmic complexity. By contrast, "AI-complete" doesn't
describe anything concrete like that. It's a casual and kind of a
cutesie term. It normally means "we'd need a machine that's capable of
solving the relevant problems as well as a competent human could." The
term is most often used when the parameters of the problem are so vague
that we cannot even describe the problem in terms of algorithmic
complexity (that is, when we haven't even figured out an algorithm for
it). It normally implies, "if we figure out an algorithm for 'competent
human', this project is doable, but not otherwise."

James Mitchelhill

unread,
Sep 30, 2005, 10:44:20 PM9/30/05
to
On Fri, 30 Sep 2005 18:59:20 -0700, steve.breslin wrote:

> James writes:
>
>> > AI-complete means basically that the machine is able to solve the
>> > problem as well as a competent human would.[...]
>>
>> As I understand it, that's not what AI-complete means, exactly. There's
>> plenty of problems where machines vastly out-perform humans. AI-complete
>> problems are problems that seem to require strong AI to exist before
>> they can be solved. They generally involve multiple components, which
>> are inextricably linked.
>
> I'm sorry, this is somewhat off-topic. But I guess I should clarify the
> terms nevertheless, for those who might be interested.
>
> The terms "NP-hard" and "NP-complete" have technical meanings; they
> describe algorithmic complexity.

I'm not a mathematician or computer scientist, but don't NP-hard and
NP-complete refer to time complexity rather than algorithmic complexity?

> By contrast, "AI-complete" doesn't
> describe anything concrete like that. It's a casual and kind of a cutesie
> term. It normally means "we'd need a machine that's capable of solving the
> relevant problems as well as a competent human could."

"Requiring a machine capable of solving problem x as well as a human
could" is the same thing as the strong AI problem having been solved.

Adam Thornton

unread,
Oct 1, 2005, 12:53:00 AM10/1/05
to
In article <pan.2005.10.01....@disorderfeed.net>,

James Mitchelhill <ja...@disorderfeed.net> wrote:
>"Requiring a machine capable of solving problem x as well as a human
>could" is the same thing as the strong AI problem having been solved.

Depends on "problem x", doesn't it?

I mean, if "problem x" is attempting to factor a large number and either
returning its factors or telling us it's prime, then computers are
already a lot better at it than people, no?

Adam

James Mitchelhill

unread,
Oct 1, 2005, 1:29:01 AM10/1/05
to

FX: Head bouncing repeatedly off keyboard.

Context.

Steve said:
"AI-complete means basically that the machine is able to solve the
problem as well as a competent human would."

I replied, making the point you just have:


"As I understand it, that's not what AI-complete means, exactly. There's
plenty of problems where machines vastly out-perform humans."

Steve then said:
"It's a casual and kind of a cutesie term. It normally means "we'd need a
machine that's capable of solving the relevant problems as well as a
competent human could.""

I responded, not bothering to restate my earlier point, which is the same
point you've just raised: ""Requiring a machine capable of solving problem


x as well as a human could" is the same thing as the strong AI problem
having been solved."

--

Damian Dollahite

unread,
Oct 1, 2005, 4:25:15 AM10/1/05
to

By definition, a story-advancing action will have lasting, relevant
repercussions on the state of the game world; a non-story-advancing
action won't. That's really all you need to tell them apart.

For example:

--------------------
:> ATTACK MAN
The man gives a scream of fright and runs away.

:> Z
The man creeps back cautiously, eyeing you warily. Upon deciding that
you are no longer a threat, he resumes what he was doing before.
--------------------

At first glance, this might look like I've advanced the story in some
way, but after trying two or three times, maybe with different weapons,
I'll conclude that it's not, because it invariably returns to the status
quo within a couple of turns. Once I decide I'm not going to accomplish
anything by attacking the poor guy over and over, I won't try it again
unless something in the story tells me to.

On the other hand, if the man's presence is preventing me from doing
something, then scaring him away for a turn or two and doing that thing
while he's gone does not result in a return to the status quo, so then I
know I'm on the right track.

It doesn't hurt to have the player waste a few turns on a red herring.
Even the most well-clued and logical of puzzles is still largely solved
by process of elimination, so players will be wasting many turns on
useless actions anyway. Providing some entertainment during the process
might just keep them playing long enough to find the action that *does*
work.

Even clearer is the other example command:

---------------------
:> JUMP OFF CLIFF
You jump off the cliff and plummet down to the rocks below.

*** YOU HAVE DIED ***
---------------------

Now that's pretty clearly *not* the right thing to do. Unless players
are so frustrated with an endless series of "That doesn't work"
responses that they consider the protagonist committing suicide a
satisfactory ending. Then maybe the author should consider if some more
interesting responses to unnecessary actions might have alleviated the
frustration enough to avoid that situation.

--
Ryukage

David Fisher

unread,
Oct 1, 2005, 8:38:58 PM10/1/05
to
"Adam Thornton" <ad...@fsf.net> wrote in message
news:dhk08j$bid$3...@localhost.localdomain...

I'd love to read an extract ... do you remember any ? :-)

David Fisher

~~ See
http://www.ifwiki.org/index.php/Past_raif_topics%3A_Miscellaneous#Humor if
anyone is wondering what RAIF-POOL is ~~


David Fisher

unread,
Oct 1, 2005, 9:18:49 PM10/1/05
to
"Kevin Venzke" <step...@yahooo.frr> wrote in message
news:rs1%e.341218$5N3....@bgtnsc05-news.ops.worldnet.att.net...

Hmmm ... still pondering this. Emily Short made a similar point about
limiting the more fully implemented simulation aspects of the game to
actions which have a bearing on the plot, so that player gets a feel for the
range of useful actions in the game (in this thread, Oct 1st 2005, 6:01 AM).

Is there room for a game where the direction the player should proceed is
not revealed in this way, though ? If the current goal was clear enough,
maybe the ability to perform non plot related actions wouldn't be so
misleading to the player. Consider a Role Playing Game ... the players can
decide to do "anything", but probably won't settle down and start a
shoe-making business when they know their current goal is to defeat the bad
guys.

I guess in most IF games a lot of the time the goal is to work out what the
goal actually is ... adding lots of simulation makes that more difficult,
because there are fewer possibilities to exclude if everything you try seems
to "work". But I would still rather be permitted to do any reasonable
seeming action (and work out whether it's relevant or not) than be stuck
trying to work out the one thing the author thought of ...

Still pondering,

David Fisher


Nikos Chantziaras

unread,
Oct 2, 2005, 6:32:01 AM10/2/05
to
David Fisher wrote:
> [...]
> So the tool I originally speculated about might need the ability to check
> for reachability and paths between game states ... tricky not impossible.
> This gets into the area of program verification and data flow analysis,
> which should be simpler for IF than for most other programming domains,
> since there are fewer things like recursive functions, complex loops, etc.

Not much harder than an algorithm that searches for "mate in 20" in a
chess position. Such an algorithm is easy and straightforward to
implement (I think; didn't try yet). But, it takes ages to complete
even on the most advanced piece of hardware, especially in the initial
board setup (where of course the algorithm isn't able to find a mate in
20, by the way; if you were to try it out though, I think if would take
months or even years for the "no mate in 20 found" message to come up).

Are IF "moves" as complex as chess moves? (OK, the moves themselves
aren't complex, but their possible combinations are.) If yes, it would
be pointless trying to come up with an algorithm that searches for
reachability of paths and/or whether the game remains solvable at all
points.

One might argue that a comparison between chess and IF is bogus. I
didn't think too much about it, but I believe that there are many
similarities. Also, IF "positions" seem much more complex to compute
than chess. In chess, you only need to care about legal moves. In IF,
all moves are legal. Brute-forcing through every possible sequence of
"moves" seems to require an overwhelming amount of CPU time and RAM,
much more than chess.

(The above are just some quick thoughts though; if everyone has done
real analysis on the chess vs. IF issue, feel free to correct me.)

Nikos Chantziaras

unread,
Oct 2, 2005, 7:12:38 AM10/2/05
to
steve....@gmail.com wrote:
> David writes:
>
>>> The narrowness of availible action is an inevitable
>>> consequence of the genre's command-line driven input framework. Where,
>>> in other genres, there appears such a boundless game, this is owing to
>>> a frame clever enough (and a simulation simplistic enough) that it
>>> produes the *sensation* of unlimited possibility.
>>
>> Could you give an example from another genre ?
>
> It's become a fad over the past few years; multi-threaded has been,
> well not surpassed, but anyway challenged, by the open-ended game.
> Think how many games promise "total control of your world": which is
> one flavor of what I'm talking about. For examples: the latest GTA
> game; Black & White and other civilization-building games; probably
> some "Sims" games are like this; and so on. Even first-person shooters
> (if you look at it a certain way) present a full range of action within
> their limited confines.

Most importantly, the "simulation" in these game is fun to *watch* (and
hear). I don't think it would be much fun to play an IF version of The
Sims.

GTA is another story; it *has* a plot. But in order to achieve this,
the simulation is "turned off" when the plot kicks in.

Nikos Chantziaras

unread,
Oct 2, 2005, 7:15:08 AM10/2/05
to
David Fisher wrote:
> "Adam Thornton" <ad...@fsf.net> wrote in message
> news:dhk08j$bid$3...@localhost.localdomain...
>>
>> In article <P63%e.1684$96.1...@nasal.pacific.net.au>, David
>> Fisher <da...@hsa.com.au> wrote:
>>>
>>> (*somehow* - maybe from examples and snippets of text. Don't
>>> confuse me with implementation issues :-) You could play the same
>>> game in the style of Graham Nelson and of Emily Short, with text
>>> generated in the style of your preferred author.
>>
>> Oh, you can just use RAIF-POOL with the --pastiche option on the
>> output. I particularly enjoyed Plundered Hearts As Told By H.P.
>> Lovecraft.
>
> I'd love to read an extract ... do you remember any ? :-)

No problem. Here goes:

[CENSORED BY THE LABAC FI]

Richard Bos

unread,
Oct 2, 2005, 11:50:34 AM10/2/05
to
steve....@gmail.com wrote:

> James writes:
>
> > > AI-complete means basically that the machine is able to solve the problem
> > > as well as a competent human would.[...]
> >
> > As I understand it, that's not what AI-complete means, exactly. There's
> > plenty of problems where machines vastly out-perform humans. AI-complete
> > problems are problems that seem to require strong AI to exist before they
> > can be solved. They generally involve multiple components, which are
> > inextricably linked.
>
> I'm sorry, this is somewhat off-topic. But I guess I should clarify the
> terms nevertheless, for those who might be interested.
>
> The terms "NP-hard" and "NP-complete" have technical meanings; they
> describe algorithmic complexity. By contrast, "AI-complete" doesn't
> describe anything concrete like that. It's a casual and kind of a
> cutesie term. It normally means "we'd need a machine that's capable of
> solving the relevant problems as well as a competent human could."

That's not how I understand the term. AIUI, "this problem is
AI-complete" means, basically, "to get a computer to solve this problem
as competently as a human would, we'd have to make the computer as
intelligent _in general_ as a human is". IOW, an AI-complete problem is
one that is so closely related to the essence of intelligence that it
cannot be solved separately; it must be solved by creating real
intelligence of a certain level.

Needless to say, nobody knows which problems really _are_ AI-complete,
but we can make enlightened guesses that most board games are not, and
parsing human speech correctly without limiting the conversation to a
fixed domain is.

Richard

steve....@gmail.com

unread,
Oct 2, 2005, 1:43:52 PM10/2/05
to
For the purposes of the larger discussion (highly robust Simulation),
the term "AI-complete" is already sufficiently clear. (And I think
everyone is roughly in agreement about what the term means in general,
vague as it is.)

My point, anyway, is that there are two conceptual approaches to the
problem of highly robust Simulation:

(1) the incremental approach, where we gradually notch up our
expectations for "robust simulation" until we reach a level of detail
everyone is really happy with. This means a whole lot of work each
step. This is basically the approach library and module writers are
already following. Whether we'll ever reach the ideal seems highly
doubtful, in lieu of...

(2) the miracle approach, where we construct an AI capable of figuring
out all this robust simulation stuff.

So, when someone suggests "wouldn't it be great if IF simulation were
amazingly robust" I normally say something like "yes, that's amazing,
but you're talking about an AI miracle." In other words, the problem is
AI-complete.

As I mentioned, the term "AI-complete" is really vague. I guess this
makes it fun to try to define, but this is off-topic, so I won't waste
any more space.

James Mitchelhill

unread,
Oct 2, 2005, 3:50:40 PM10/2/05
to
On Sun, 02 Oct 2005 10:43:52 -0700, steve.breslin wrote:

> For the purposes of the larger discussion (highly robust Simulation), the
> term "AI-complete" is already sufficiently clear. (And I think everyone is
> roughly in agreement about what the term means in general, vague as it
> is.)
>
> My point, anyway, is that there are two conceptual approaches to the
> problem of highly robust Simulation:
>
> (1) the incremental approach, where we gradually notch up our expectations
> for "robust simulation" until we reach a level of detail everyone is
> really happy with. This means a whole lot of work each step. This is
> basically the approach library and module writers are already following.
> Whether we'll ever reach the ideal seems highly doubtful, in lieu of...

Unfortunately the incremental approach doesn't work in this case.

Adding additional simulation incrementally does not necessarily lead to
improvements. The amount of additional work simulation requires for
authors is less than the benefit gained. Conventional IF systems have
gravitated to a generally optimal balance. See Mike Roberts' post on this
in the "producing adventures" thread.

Simulationism isn't a general goal for IF systems.



> (2) the miracle approach, where we construct an AI capable of figuring
> out all this robust simulation stuff.

This isn't an approach at all.

> So, when someone suggests "wouldn't it be great if IF simulation were
> amazingly robust" I normally say something like "yes, that's amazing,
> but you're talking about an AI miracle." In other words, the problem is
> AI-complete.

Let me suggest another approach. Rather than thinking of a robust
simulation system as an evolution of IF, think of it as a related (and
currently potential) species. Conventional IF provides clues as to how it
could be constructed, but does not provide a model for it. A simulation
system will share much with conventional systems - I don't see much change
to the parser, for example, but the underlying model of the world would
almost completely change.

(3) the other approach

Where we carefully examine the problems that such a system would face,
recognising when we are asking for something that would be impossible, and
reduce our goals to what is possible. We think carefully about the
requirements of the system and what problems will face the authors who are
likely to use such a system and design our tools carefully to make their
lives easier.

When we finally have a useful, working system, then we can take an
incremental approach.

steve....@gmail.com

unread,
Oct 2, 2005, 6:48:28 PM10/2/05
to
This is all very lovely, but we need some model, some algorithm. Just
hypothesizing about its possibility (or impossibility) doesn't get us
even to the starting gate.

That said, there's a module for Tads-3, soon forthcoming, which well
solves some related problems; not finely-grained simulation, but...
well, we'll have to wait for the formal announcement.

James Mitchelhill

unread,
Oct 3, 2005, 3:29:35 AM10/3/05
to
On Sun, 02 Oct 2005 15:48:28 -0700, steve.breslin wrote:

> This is all very lovely, but we need some model, some algorithm. Just
> hypothesizing about its possibility (or impossibility) doesn't get us even
> to the starting gate.

Have you read my post "Simulationism and IF" where I outline the problems,
the various arguments about them and possible solutions to them, before
suggesting a starting point for thinking about what model may be plausible
for building such a system?

I'm not just hypothesising about its possibility. Really. But I think one
of the ways to get to that starting gate is to think carefully about what
approach should be taken. And we do this by talking about it.

Adam Thornton

unread,
Oct 3, 2005, 2:19:06 PM10/3/05
to
In article <J2G%e.2452$96.1...@nasal.pacific.net.au>,

David Fisher <da...@hsa.com.au> wrote:
>I'd love to read an extract ... do you remember any ? :-)

I try, but then unnameable, unspeakable, unimaginable, indescribable
images of heaving bosoms and rugose tentacles overpower me, and I awake,
hours later, in a puddle of cold sweat. And aren't you glad that last
noun was "sweat" ?

Adam

David Fisher

unread,
Oct 3, 2005, 7:51:37 PM10/3/05
to
"Adam Thornton" <ad...@fsf.net> wrote in message
news:dhrsmq$crh$1...@localhost.localdomain...

Maybe I shouldn't have asked ... :-P

David Fisher


steve....@gmail.com

unread,
Oct 4, 2005, 5:32:59 PM10/4/05
to
James writes:

> > This is all very lovely, but we need some model, some algorithm. Just
> > hypothesizing about its possibility (or impossibility) doesn't get us even
> > to the starting gate.
>
> Have you read my post "Simulationism and IF" where I outline the problems,
> the various arguments about them and possible solutions to them, before
> suggesting a starting point for thinking about what model may be plausible
> for building such a system?

No, I haven't. I'll probably read it closely when time permits. Just
glancing over it (and I really haven't read it closely at all), parts
of it have the appearance of a legitimate proposal.

> I'm not just hypothesising about its possibility. Really. But I think one
> of the ways to get to that starting gate is to think carefully about what
> approach should be taken. And we do this by talking about it.

I enjoy the brainstorming aspect of this thread, even though it is
plain stormy. If my comments (to the gross effect of: "this or that is
impossible") have been of any help to the discussion, then good. But if
you really want to activate my interest, produce a model, an algorithm,
something tangible.

Adam Thornton

unread,
Oct 4, 2005, 11:34:52 PM10/4/05
to
In article <1128110494....@g14g2000cwa.googlegroups.com>,

<ems...@mindspring.com> wrote:
>Anyway, contra Crawford, I don't think we currently have the ability to
>make interesting stories arise spontaneously out of a simulated
>environment, whether that simulation is designed to mimic a physical
>reality or the behavior of humans. (The second point being, of course,
>much harder.)

You and I are in violent agreement. My thesis is that even if we had
perfect technology, we still couldn't do this, because it's just not the
way to generate interesting stories.

This, in turn, revolves around the thesis that most lives are boring, at
least to those not living them. Sorry, folks, but that's what I
believe.

>At best, at very best, you get
>something which could, with editing, become a story.

Yeah, we're in violent agreement.

>I think simulation becomes interesting, and useful to us with the
>current state of technology, when it allows the player freedom in how
>he does what he is supposed to do in a given work of IF.

Violent agreement again.

Adam

Adam Thornton

unread,
Oct 4, 2005, 11:38:36 PM10/4/05
to
In article <pan.2005.09.30....@disorderfeed.net>,
James Mitchelhill <ja...@disorderfeed.net> wrote:
>I don't think this is true, but the best way to demonstrate this would
>probably to implement a system of this type and write an interesting game
>with it. I don't think it's a good idea to use the Erasmatron as an
>example, not only because its implementation was so badly done, but
>because