Simulation & world consistency
David Fisher
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
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
> 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
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
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
> "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 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
> "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
news:433b97f4$0$37580$892e...@authen.white.readfreenews.net...
> 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
>> 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
<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
> 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
> 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
"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
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
>
> 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
> 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
> "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
> "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
> 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
> "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
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
"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
> 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
> 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
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
>
> "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
> 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
> > 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
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
David Fisher <da...@hsa.com.au> wrote:
>"James Mitchelhill" <ja...@disorderfeed.net> wrote in message
>> 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:
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
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
> 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
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
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
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
> 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
> > 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
> 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
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
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
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
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
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
> [...]
> 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
> 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
> "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
> 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
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
> 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
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
> 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
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
Maybe I shouldn't have asked ... :-P
David Fisher
steve....@gmail.com
> > 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
<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
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 the whole assumption behind it was that interesting stories would
>result merely from the interaction of archetypes.
I'm not convinced that the Erasmatron's implementation is all that
awful, although from his book I definitely feel that Crawford rushed to
implement with a half-baked model. His version of English grammar is
downright embarrassing compared to Inform's capabilities, for instance.
>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.
I'm pretty sure that Mike has already pointed out that this is a bathtub
curve: *to a point*, sure, you're right, but after some point, you're
dead wrong. It all comes down to what mimesis a player expects (hint:
Variegated, it's much prettier) and how hard you have to work to meet
that expectation.
>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.
I'm with everyone else here: show me a cool story made this way, and
I'll happily--ecstatically, even--change my mind.
Adam
Mike Roberts
> 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 !"
Well, the fact that *you* just did doesn't prove anything about whether
*Bob* would. The player isn't the PC; the player only plays the PC.
> 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 ...
That seems reasonable at first glance, but in practice I don't think it's
much of an improvement to accept commands superficially - that is, to accept
them without any real effect on the game state. What's bad about rejecting
a reasonable-in-the-real-world command isn't the rejection per se; it's that
a command that should do something specific, doesn't. A superficial
affirmative response that doesn't do that specific expected thing is only
superficially different from a rejection, and no more satisfying to the
player.
When a player types a command, it's usually because she expects the command
to have a particular effect on the game state, and usually because she
expects that effect to further her perceived goals. The player has an idea
of the game world based on the game's text output, and an idea of how a
similar situation would work in the real world, and thinks of a way to solve
the problem at hand using that real-world knowledge. It's obviously
frustratring if the game just says "You can't do that." It's less obvious,
but in my opinion true, that it's equally frustratring if the game replies
with some bland affirmative ("You attack Bob; he's a bit angrier now").
With either reply, the game reveals that its internal model is more limited
than the player has been led to believe by the game's own previous text
output. This frustrates the player and harms the sense of immersion.
In the JUMP OFF CLIFF example, a superficial affirmative response - "You
have died" - could be just as frustrating as "You can't do that." Suppose,
for example, that the player thinks she's figured out a way to jump off the
cliff and survive, thereby solving the problem of how to get to the bottom.
Maybe the player is holding the end of a rope that's tied to a tree, or has
glued giant springs to the soles of the PC's boots, or is trying to use the
tablecloth as a parachute. If the player is convinced that the solution
lies in finding a way to survive the fall, being told over and over that
"You have died" is going to be frustrating because it doesn't acknowledge
any of the precautions the player has painstakingly taken. So if the author
didn't anticipate those precautions, the game may as well say "You can't do
that"; it might even be better for playability, since the player might get
the idea more quickly that jumping simply isn't an option.
--Mike
mjr underscore at hotmail dot com
Kevin Forchione
news:pan.2005.09.30....@disorderfeed.net...
<snip>
> 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.)
Actually, this approach appears to be common to the implementation of all
computer applications. Your suggestion hasn't been overlooked by the IF
community. But there are tolerances that have become conventional in IF
play, which create an upper boundary on the ability to leverage
computational power. Unlike real-time graphics games, which are performing
continuous state changes, IF is turned based, with nearly all state changes
occurring between the parsing of the player command and the execution of
daemons.The acceptable time frame for this is much less than say, the 3
second standard for CICS transactions. Any detectable delay between the
player hitting the enter key, and the generation of screen display is less
than desirable.
In simplest terms, every additional level of abstraction gobbles up
processing time, and even today's fastest processors begin to show
noticeable response lags (the analogy to pc operating systems is apt) when
faced with even minimal simulationist computations. Like our brains, the
computer's computational power is woefully underused in IF, but that is
largely a result of the small window of acceptable operating time we
currently permit between player input and gameworld response.
One solution, of course, is to lower the expectations of players. To accept
a longer processing time between input and response. Three seconds is the
industry standard for the limit of CICS. Another way to handle this might be
to break up the game world into "areas" in which some kind of eye candy is
displayed while these areas are "loading" (i.e. performing computations as a
result of previous play). And finally, one could take advantage of the vast
computation time available during a player's digestion of gameworld response
and their input of player command. This approach, while at first appealing,
does pose some problems though. If states are changing, we might say "in the
background", then they would have to be states that lie outside the
sensibility of the player character (since any state changes made within the
ability of the PC to sense should be reported to the player). Also the
synchronicity problem would have to be addressed: currently state changes
are the results of actions, daemons, or other bits of code imbedded in the
turn-based execution cycle. Certain computations would have to be registered
and de-registered from the background queue as actor scope changes. And on
and on...
Meanwhile we have a small window of perhaps less than a second in which to
leverage the computational power of the computer, and I suspect that in that
situation additional layers of abstraction demand more optimization of code
from an author, not less, so that the odds of creating a situation in which
combinatorial explosions occur may only increase.
> 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.
There's the rub. We are, to borrow your phrase, leveraging our own
imagination in speculating on the solutions to IF problems, rather than
relying on any solid implementation example, perhaps in a non-IF domain. But
these are some of my musings, as we all struggle with our art.
--Kevin
Kevin Forchione
news:1128093752.0...@g49g2000cwa.googlegroups.com...
<snip>
> 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.
Hmmm. This has always been an interesting deception to me. Take a game like
Black & White. Clearly there is a large range of actions that can be
performed: uprooting trees, picking up people, tapping your fingers in the
water, etc. But there are clearly whole sets of actions that cannot be
performed: travel boundaries, picking up your "conscience" or the trainer,
digging in the dirt, etc. My point is that the actions are really very
limited (tried to open the door of a house?) and these actions are equally
reasonable, and yet the fact that they can't be performed doesn't appear to
hinder the game in any way.
In most graphical games we've come to accept that when the tool we are using
to manipulate the game world is "active" then we can interact, and when it
is not "active" we simply pass over that section of game world as eye candy.
The expectation becomes conditioned and we don't even notice that we no
longer question why we don't try to pick up a nearby object even when it
might be entertaining or even useful to do so.
Now imagine in IF, and this is only an illustration, if descriptions
referring to objects or actions contained words that when moused-over became
highlighted, and when clicked produced drop down menus of actions or objects
for which the player could interact. If one played these kinds of games
regularly then very soon one would simply be drawn to scan for the
highlights, knowing that the objects not highlighted couldn't be interact
with. They would, for the most part, become "invisible", eye candy that
served only as backdrop as you scanned across the "playing area", much as
you would with your "hand" in Black & White. Mousing over these words of
text doesn't produce any highlighting, and clicking on them doesn't produce
any response. More highlighting and larger drop-down menus, the world feels
soooo expansive.
To extend this analogy to the IF world, you'd have to change a few things.
First, mousing over a word wouldn't produce a highlight. Clicking on any
word would generate some kind of response, even if that response is a
standardized failure, the backdrop of the game changes. The psychology, of
course, is very different from the other approach. A player doesn't know
which text is interactive and which is merely eye-candy, though practice and
experience will probably lead players to mouse over only nouns and verbs,
and perhaps only those that seem relevant toward moving the story along. And
the conditioning is not present: you never know whether a word is
interactive until you've committed a "click" which is more demanding than a
mere mouse-over. And so a player is more likely to feel frustration over
failures than one who's choices are highlighted. Why can't I do something
with the word "feel" from the previous sentence? The world seems soooo
limited.
Hmmmm?
--Kevin
Kevin Forchione
<ems...@mindspring.com> wrote in message
news:1128110494....@g14g2000cwa.googlegroups.com...
>
> 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.
Sums it up, right there. Anything else is just a toy.
--Kevin
samwyse
> 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.
Yeah, it shouldn't be any harder than the halting problem. ;-)
> 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).
IFM (not IFMapper!) tries to do some of this. You can give it a list of
tasks and pre-conditions, and it will try to find a path to a goal, or
tell you that no path could be found.
Here's what the manual has to say:
First, extra internal tasks are generated. These are tasks to:
. get items which are required for explicitly-mentioned tasks to be done,
. get items which are required to get other items,
. get items which are needed to go in certain directions,
. get items which are scored,
. go to rooms which are scored.
Next, all the rooms are connected using their links and joins. This
means that for each room, a list is made of all other rooms reachable in
one move. Note that it is possible for some rooms to be unreachable—for
example, all rooms in a section where there is no “join” to rooms on
other sections.
Then the task dependencies are calculated. A dependency is where one
task must be done before another. The task dependencies are examined to
see if there are any cycles—that is, chains of tasks where each one must
be done before the next, and the last must be done before the first. If
there are any, then the game is unsolvable, since none of the tasks in a
cycle can be done.
If there are no cyclic dependencies, the task list is “traversed” to
find a sequence which solves the game while satisfying the task
dependencies.
James Mitchelhill
> "James Mitchelhill" <ja...@disorderfeed.net> wrote in message
> news:pan.2005.09.30....@disorderfeed.net... <snip>
>> 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.)
>
> Actually, this approach appears to be common to the implementation of all
> computer applications. Your suggestion hasn't been overlooked by the IF
> community. But there are tolerances that have become conventional in IF
> play, which create an upper boundary on the ability to leverage
> computational power. Unlike real-time graphics games, which are performing
> continuous state changes, IF is turned based, with nearly all state
> changes occurring between the parsing of the player command and the
> execution of daemons.The acceptable time frame for this is much less than
> say, the 3 second standard for CICS transactions. Any detectable delay
> between the player hitting the enter key, and the generation of screen
> display is less than desirable.
I agree. Three seconds would be much too long. I think I'd accept a delay
of half a second at most.
> In simplest terms, every additional level of abstraction gobbles up
> processing time, and even today's fastest processors begin to show
> noticeable response lags (the analogy to pc operating systems is apt)
> when faced with even minimal simulationist computations.
You're right about this. A simulationist system would be more demanding on
the processor than conventional systems. I'd be satisfied with a system
that worked reasonably quickly on most modern PCs. This should be
achievable if we plan the levels of our simulation carefully.
>Like our brains, the
> computer's computational power is woefully underused in IF, but that is
> largely a result of the small window of acceptable operating time we
> currently permit between player input and gameworld response.
>
> One solution, of course, is to lower the expectations of players. To
> accept a longer processing time between input and response. Three seconds
> is the industry standard for the limit of CICS. Another way to handle this
> might be to break up the game world into "areas" in which some kind of eye
> candy is displayed while these areas are "loading" (i.e. performing
> computations as a result of previous play). And finally, one could take
> advantage of the vast computation time available during a player's
> digestion of gameworld response and their input of player command. This
> approach, while at first appealing, does pose some problems though. If
> states are changing, we might say "in the background", then they would
> have to be states that lie outside the sensibility of the player character
> (since any state changes made within the ability of the PC to sense should
> be reported to the player).
Another option would be to precompute the game's next state
during the idle time between commands. The system would record the local
state for each object in the simulation. When the command is processed, it
only has to recompute objects whose initial state has changed as a result
of the command.
> Also the synchronicity problem would have to
> be addressed: currently state changes are the results of actions, daemons,
> or other bits of code imbedded in the turn-based execution cycle. Certain
> computations would have to be registered and de-registered from the
> background queue as actor scope changes. And on and on...
Indeed. Although the simulation only has to be good enough to convince the
playey. I suspect that even with a deeply simulationist system there would
be diminishing returns after a certain point. Time would be important in
a simulationist system, but I think it would make sense to divide the
action into "ticks" of a certain length of time, below which events are
treated as simultaneous.
State changes would still be the results of daemons, but many, many more.
> Meanwhile we have a small window of perhaps less than a second in which to
> leverage the computational power of the computer, and I suspect that in
> that situation additional layers of abstraction demand more optimization
> of code from an author, not less, so that the odds of creating a situation
> in which combinatorial explosions occur may only increase.
>
>> 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.
>
> There's the rub. We are, to borrow your phrase, leveraging our own
> imagination in speculating on the solutions to IF problems, rather than
> relying on any solid implementation example, perhaps in a non-IF domain.
> But these are some of my musings, as we all struggle with our art.
I'm building up slowly to concrete ideas. As you can probably tell,
they're still fairly fuzzy at this point. Whether I'll ever get them clear
enough to do anything worthwhile with them is another matter.
But the discussion is useful in itself. It's probably handy to have a
thread to point people at when they suggest things like this in the
future.
steve....@gmail.com
prompt and the execution of a given player command:
I've had some success with performing some computationally expensive
processes in this "dead time" (in my case, by hooking in via realtime
effects -- which seems the best way to do this with Tads3).
If you break the process into small enough pieces, so that the
command-line input mechanism doesn't turn to choppy, you can actually
perform a whole lot of computation in this interval. And any
computation you don't get to can be gotten to within the command
processing interval.
We're not necessarily talking about game-state changes which occur
before the turn comes up; we're not even necessarily talking about
computation-results which *must* result in game-state changes when the
turn comes up.
Think of it like the chess-program, which considers its next move even
in the interval when it's the other player's turn.
(Speaking of which, the above suggests at least one minor optimization
for the first invocation of the per-turn sense-table calculation in
Tads3.)
David Fisher
"samwyse" <deja...@email.com> wrote in message
news:0h_0f.9156$oO2....@newssvr27.news.prodigy.net...
> Nikos Chantziaras wrote:
>> 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.
>
> Yeah, it shouldn't be any harder than the halting problem. ;-)
I think Marvin Minsky was once assigned the "computer vision problem" to
solve over the summer break ...
:-)
> IFM (not IFMapper!) tries to do some of this. You can give it a list of
> tasks and pre-conditions, and it will try to find a path to a goal, or
> tell you that no path could be found.
[description of operation snipped]
Could you give some pointers to IFM (eg. a web page) ? Is it in a state for
other people to use ?
Thanks,
David Fisher
samwyse
>>tasks and pre-conditions, and it will try to find a path to a goal, or
>>tell you that no path could be found.
>
>
> [description of operation snipped]
>
> Could you give some pointers to IFM (eg. a web page) ? Is it in a state for
> other people to use ?
http://www.ifarchive.org/if-archive/mapping-tools/
ifm-5.1.tar.gz Interactive Fiction Mapper, version 5.1,
written by Glenn Hutchings. Archive contains C
source code.
ifm51.zip Interactive Fiction Mapper, version 5.1,
written by Glenn Hutchings. Archive contains
Windows executables (console mode, i.e. run from a
command prompt).
Dave Chapeskie keeps a write-up about it here, which includes a bunch of
IFM files written by other people: http://www.sentex.net/~dchapes/ifm/
Also, gga (ggarra at advancedsl.com.ar) has been working on a Ruby
program called IFMapper, which I mention because it supports .ifm data
files and includes in its zip file all of the maps listed on Dave's web
page.
Kevin Forchione
>
> Could you give some pointers to IFM (eg. a web page) ? Is it in a state
> for other people to use ?
Heh, the guy'd better patent it first..
--Kevin
ems...@mindspring.com
James Mitchelhill wrote:
> On Wed, 05 Oct 2005 19:54:26 +0000, Kevin Forchione wrote:
> > Any detectable delay
> > between the player hitting the enter key, and the generation of screen
> > display is less than desirable.
>
> I agree. Three seconds would be much too long. I think I'd accept a delay
> of half a second at most.
I find that even for simulation that might not be thought especially
deep -- NPCs who do some basic conversational goal-seeking, or plan
fairly simple ways to interact with the world model -- the processing
requirements are enough to make a noticeable delay when the player
presses enter, especially on older machines.
I thought this might feel less disastrous if the player at least saw
*some* feedback to his command immediately, so I have occasionally
tried something where a response prints immediately and then there is a
delay while the game calculates independent simulationist effects/NPC
actions and prints those. Then the player gets another prompt. (I had
some theory that one might think of this as the player having a move,
then waiting while the NPCs had a move...)
Mixed feedback on that -- most people would, of course, still like
everything to happen instantly, and also, naturally, to do so smoothly
on the reduced-z-machine implementation they are running on a digital
watch. But in my own subjective opinion it is more fun than having to
sit there looking at a blank space for a couple of seconds, wondering
whether the interpreter hung...
ems...@mindspring.com
Adam Thornton wrote:
> 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.
Ah. See, I think they're interesting, but not stories. Raw experiential
data needs some processing to become a story.
Most of the simulationy games I have tried recently -- and I admit this
is still a small set, because I don't play a lot of commercial games --
do try to provide some narrative interpretation, so that if you do
something really spectacular you get a little cut-scene movie or
whatever. Which seems like a sort of half-measure, but then these games
don't really turn on story as the main point of playing.
One could do this with IF also: provide a reasonably complex simulation
model and then a (very) large number of specific prewritten scenes
triggered when the world model gets into the right state; I tried
something sort of like this with the Mystery House project. I would not
say it was a great success as story-telling, though whether that was my
failing or the failing of the concept is another question: there were
assorted other constraints on the project.
One of these days I may experiment further with the general idea,
though it does eat processing power, unfortunately, and require the
writing of many more pieces than the player will ever see in a single
playing.
Kevin Forchione
news:1128627748.5...@g49g2000cwa.googlegroups.com...
> I find that even for simulation that might not be thought especially
> deep -- NPCs who do some basic conversational goal-seeking, or plan
> fairly simple ways to interact with the world model -- the processing
> requirements are enough to make a noticeable delay when the player
> presses enter, especially on older machines.
>
> I thought this might feel less disastrous if the player at least saw
> *some* feedback to his command immediately, so I have occasionally
> tried something where a response prints immediately and then there is a
> delay while the game calculates independent simulationist effects/NPC
> actions and prints those. Then the player gets another prompt. (I had
> some theory that one might think of this as the player having a move,
> then waiting while the NPCs had a move...)
>
> Mixed feedback on that -- most people would, of course, still like
> everything to happen instantly, and also, naturally, to do so smoothly
> on the reduced-z-machine implementation they are running on a digital
> watch. But in my own subjective opinion it is more fun than having to
> sit there looking at a blank space for a couple of seconds, wondering
> whether the interpreter hung...
In my own Proteus library extension, which isn't intended for game use, but
as a means of examining the metadata, I have done something similar by
issuing a "please wait" message immediately upon executing the action,
followed by computations that may, for instance, display the game object
tree hierarchy. Users will probably be far more tolerant of this kind of
solution than players would.
The use of realtime computation during prompt display can be useful, as
indicated for pre-turn computations, such as scope issues and other
initializations that are not dependent on state changes and responses to the
player command. Depending on the typing ability and length of command, this
could buy some significant processing time.
But in terms of responsiveness to player command, or player command
dependent state change, I think we have a sticky situation. We either
encourage the community to upgrade to the very fastest machines, or we
devise an alternate, perhaps cascading, scheme of responsiveness to player
command. Though I am at a loss as to how this might be accomplished.
As an analogy, in a graphics game I could produce the required time by
simply displaying an action in progress and disabling the player's ability
to interact with the game during that time period. An RPG game might do this
in an elevator, with only lighted buttons indicating that something is
happening. But in a text-based game the only indication of change is the
display of text, and representing action in progress through regulating the
display of text would annoy the player, rather than inform them. It's one of
the prices we pay for the medium we use.
It might be possible to organize responses so that large computations and
out of scope state changes might occur asynchronously to the command prompt.
But there's no time-slicing mechanism built into the VMs we use, and we'd
have to worry about sequencing issues. If we set these things up as a series
of tasks to be performed, we could possibly handle them during the realtime
prompting that others are using for initial turn setup, but again you're
talking about needing some way to coordinate character scope with a task so
that when the character is in scope for a particular event that the task
related to it has top priority.
Of course, if that kind of thing were even feasible, don't even talk about
how much easier simulationism would be for novice author game writing....
--Kevin
Kevin Forchione
news:1128628904.0...@g49g2000cwa.googlegroups.com...
>
> Adam Thornton wrote:
>> 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.
>
> Ah. See, I think they're interesting, but not stories. Raw experiential
> data needs some processing to become a story.
That's my take as well.
> Most of the simulationy games I have tried recently -- and I admit this
> is still a small set, because I don't play a lot of commercial games --
> do try to provide some narrative interpretation, so that if you do
> something really spectacular you get a little cut-scene movie or
> whatever. Which seems like a sort of half-measure, but then these games
> don't really turn on story as the main point of playing.
>
> One could do this with IF also: provide a reasonably complex simulation
> model and then a (very) large number of specific prewritten scenes
> triggered when the world model gets into the right state; I tried
> something sort of like this with the Mystery House project. I would not
> say it was a great success as story-telling, though whether that was my
> failing or the failing of the concept is another question: there were
> assorted other constraints on the project.
Other games have implemented "cut" scenes as well, though probably not
specifically designed to optimize simulation processing time. I would say
that audience reaction to these sequences would be uniform regardless of
their intended purpose. I would suspect that they are probably received with
a similar lukewarm feeling that their graphics counterparts receive. Though
I suspect this may be the most practical approach to take.
Anything that delays player interaction is probably going to be seen as
negative unless it otherwise engages the player's attention. Unfortunately,
the use of "cut" scenes has a similar effect as summary does in narrative.
It may consist of exciting scenes, but because it doesn't have any
interactivity, it changes the way the player interacts with the story,
forcing them into the role of reader instead of player. This might be
something that can be minimized though, by limiting it to a screen of text.
> One of these days I may experiment further with the general idea,
> though it does eat processing power, unfortunately, and require the
> writing of many more pieces than the player will ever see in a single
> playing.
The only other solution that seems to be currently available is that of the
realtime processing available during the issue and receipt of the player
command line. This could be used for both pre and post turn processing, but
it would take a clever bit of scheduling. You'd want to have situations that
trigger the loading of a queue that would then be executed during prompt.
Anything still pending in the queue would probably need to be processed
prior to the actual command executing, unless it was something that was
"outside of player scope" and could be deferred to either after the command
execution or remain in the prompt queue until next go around.
The model itself wouldn't be too tough to design (at least in TADS 3), but
the practical application of the mechanism would mean number crunching and
juggling for an author. You might be able to set up a set of PromptTask
classes, so that they could be adjudicated and ranked, but that would have
to be minimized or you'll eat up all your processing time trying to figure
out which task to perform.
Still, these are lovely little things for toymakers to play with, and you
never know who might want to use them.
--Kevin
ems...@mindspring.com
> But in terms of responsiveness to player command, or player command
> dependent state change, I think we have a sticky situation.
Unfortunately, this is where the type of simulation I find interesting
is mostly happening.
> We either
> encourage the community to upgrade to the very fastest machines,
I don't think our encouraging them is likely to make it happen, anyway,
considering how much of the appeal of IF is its compactness and
portability.
> It might be possible to organize responses so that large computations and
> out of scope state changes might occur asynchronously to the command prompt.
Yeah, statements like this make me a little scared. We'd have to be
figure out not what the player's current scope was, but what his scope
*could be* a turn down the road: after all, if NPCs are moving around
in the next room, we don't want to calculate and report their actions
until we know whether the player has walked into that space during the
intervening command.
Bleeagh.
Or else: calculate everything, then recalculate the bits that have to
do with the player's scope changing. But... bleeagh, again.
The only thing of this general nature I've ever tried is caching
best-path calculations during the prologue. And even that took too
long, and I wound up precalculating the whole table and putting it into
the code, in the end. I find this fundamentally inelegant, but it got
rid of a very annoying pause at the outset.
-- Emily
ems...@mindspring.com
Kevin Forchione wrote:
> <ems...@mindspring.com> wrote in message
> news:1128628904.0...@g49g2000cwa.googlegroups.com...
> > model and then a (very) large number of specific prewritten scenes
> > triggered when the world model gets into the right state; I tried
> > something sort of like this with the Mystery House project. I would not
> > say it was a great success as story-telling, though whether that was my
> > failing or the failing of the concept is another question: there were
> > assorted other constraints on the project.
>
> Other games have implemented "cut" scenes as well, though probably not
> specifically designed to optimize simulation processing time. I would say
> that audience reaction to these sequences would be uniform regardless of
> their intended purpose. I would suspect that they are probably received with
> a similar lukewarm feeling that their graphics counterparts receive.
Ah. Okay -- though I can see where you got this idea from the way I
phrased it, I didn't actually mean that the IF scenes should be mere
blobs of uninteractive text.
What I mean by "scene" in IF -- and I realize that this is more or less
a private designation, since it has evolved from my own coding
practices -- is a section of the game where special rules apply to the
player's actions in addition to the ordinary rules of the model; where
there is often some player-independent stuff going on; and where I have
defined particular beginning and end conditions.
This arose from the design of City of Secrets, originally, which has
many scenes where the player is interacting with a specific person (or
something else is going on); the scene puts some constraints on the
usual world-model, so that, for instance, even though there is a door
leading west, which is open and unlocked, the player can't go through
it during the scene where he's talking to the guard NPC; he has to get
to the point where the dialogue is over.
So the scene is basically (as I'm describing it, anyway) a way of
modeling the constraints that the plot and story put on the player's
behavior, rather than those arising from his physical surroundings as
manifest in the room-code and door-code and chair-code and so on. A
moderator within the game knows which scene it is (if any) and applies
the special scene-specific rules and constraints before falling back on
the world model to determine the response to a given command.
In my Mystery House project the way this worked was that at all times
the basic simulation was running: NPCs wandered around, wrecking stuff
and looking for items; and whichever NPC had been designated the
murderer (randomly, at the outset of the game) wandered around trying
to find himself alone with a victim and a weapon, at which point he
would kill the victim off. (There was also a timer to make sure that
the murders didn't happen in too rapid a succession.)
When the player actually encountered a new body for the first time, a
scene would occur: specific dialogue that would never happen again in
that playthrough of the game, selected on the basis of how many murders
had happened so far, and further modified depending on who had died
this time, what evidence was left, what other NPCs were in the room,
what the current emotional relationships of the NPCs were, etc.
There were also some smaller one-time exchanges that would happen if
the player happened to be in the same room with other NPCs when certain
game conditions applied. For instance, if the player is in a room with
an NPC who trusts him but hates a third character, that NPC might make
some remarks throwing suspicion on the third party.
Now, there are lots of things about the actual implementation that I am
not crazy about: it is too slow; it is not as tidy as it ought to be
because I was overambitious for the amount of coding time I actually
had; there are some frustrating bugs; the story that emerges is not
very complex because I was trying not to stray too horribly from the
spirit of the Sierra original; some of the game-play concerns about
leaving enough clues for the player interfered with story-telling
concerns and my attempts to generate a certain atmosphere; the list
goes on. It was an experiment. To make a tighter story I think I should
have halved the number of non-player characters, cut the size of the
map, and vastly increased the amount of individual attention I gave to
each of them. But then it would have been a different project entirely.
Nonetheless, I think that the underlying concept is not necessarily
proven bad by my rather ham-handed management of it. A story is made up
of distinct crises, qualitative changes in the state of things --
discontinuities, in short. These moments might arise from the player's
actions, from random factors, from NPC behavior, or from a combination
of all three (as in the case of Mystery House Possessed), but I think
it's necessary to treat them as a structure imposed over the
simulationist part of the code, not as behavior we could expect to
arise from the simulation itself.
This may seem obvious, but there's a fundamental difference of thought
here from the simulated-story approach of the Erasmatron. Chris
Crawford's model -- I hope I don't misrepresent him, but this is what I
got from a reasonably careful reading of his book on Interactive
Storytelling -- in any case, *as I understand* his model, it involves
programming, say, Lancelot and Arthur and Guinevere with a sufficient
set of human behavior that Arthur will know to get angry at Lancelot
when he finds out what is going on, etc. And presumably if you somehow
(as the player) managed to arrange things so that Arthur and Lancelot
wound up together, Guinevere could discover this and *she* could get
angry. This postulates writing a system that anticipates and generates
all the *kinds* of plot event that could happen. It also suggests that
because all these plot events are generated by the model and not by the
author, they are likely after a while to have a certain sameness. Oh,
sure, modulated, perhaps, by some different character traits for
Guinevere than for Arthur, but basically they would be of a type. Nor
is there (as far as I was able to tell) any clear mechanism for
ordering plot events or providing a narrative structure of escalation
and crisis.
What I'm suggesting is that, instead, the author might have in mind a
fairly specific set of events that belong to his story-world; not all,
perhaps, to the same single narrative thread. Some might be mutually
exclusive. But all the scenes fit his overall vision and could be
components of a story he would like to tell. They're distinct, not
necessarily alike in type (or categorizable in any particular way), so
that we don't have "Guinevere's angry scene" and "Arthur's angry scene"
and "Lancelot's angry scene", but "the scene where Arthur discovers the
truth and decides to have Guinevere executed", which is very different
in tone, purpose, and world-effect from "the scene where Guinevere is
disturbed by the Arthur/Lancelot situation and joins a convent". Or
they might belong to categories, but categories according to their
narrative function: set-up scenes, betrayal scenes, resolution scenes.
In any case, these scenes are coded in such a way that they sit around
waiting to happen until the world model falls into exactly the right
configuration. Then they trigger, changing the world model according to
their own instructions, allowing the player some special kinds of
interaction in that particular context (because now, while this scene
is in progress, ASK GUINEVERE ABOUT LANCELOT should get some special
and different results), playing out over a few moves or a few dozen
moves to some sort of shapely narrative conclusion.
Such a system allows for the author to do some ordering, as well: we
might rule that no more than one betrayal scene can appear per
play-through, even if multiple betrayals are possible. We might also
rule that the world model has changed after a betrayal in such a way
that the NPCs no longer form any further romantic alliances. (They've
all become, I suppose, jaded.) And since the author does know what the
overall shape of his narrative will be, it is possible to introduce
some of the other conventional devices of literature: foreshadowing,
thematic development, etc.
In Mystery House Possessed scenes are brief and the player is not
always -- indeed not usually -- in the midst of one. In City of Secrets
there is very often some scene or other going on, though in the
exploratory middle section of the game "scene" is fairly loosely
defined. Though I don't think either of those particular works succeeds
entirely at what I wanted to do, I think either model would in theory
be a workable basis for future experiments in interactive storytelling.
(Mine, anyway, if no one else's. This is more quixotic solo venture
than crusade.) The density of scenes might well reflect other aspects
of the story being told: something with a lot of characters might well
be very context-dependent, and thus constantly in one scene or another;
something with a lot of exploration might allow the player to spend
most of his time playing with the model and only now and again
triggering an event.
Basically what I am describing is an extension of the way IF is already
conventionally written: many IF games are already world models in which
extraordinary behavior kicks in occasionally in response to the player
getting things into just the right state. I'm just proposing a way to
imagine the design and organize the code so that it is easier to do
flexible plotting, and sequences of extraordinary behavior that go on
for more than one move without breaking. Which is where I think this
all actually becomes interesting, and not a toy.
steve....@gmail.com
ems...@mindspring.com wrote:
> Kevin Forchione wrote:
[...]
> > It might be possible to organize responses so that large computations and
> > out of scope state changes might occur asynchronously to the command
> > prompt.
>
> Yeah, statements like this make me a little scared. We'd have to be
> figure out not what the player's current scope was, but what his scope
> *could be* a turn down the road: after all, if NPCs are moving around
> in the next room, we don't want to calculate and report their actions
> until we know whether the player has walked into that space during the
> intervening command.
>
> Bleeagh.
>
> Or else: calculate everything, then recalculate the bits that have to
> do with the player's scope changing. But... bleeagh, again.
I agree with this, bleeagh and bleeagh. Keeping fluctuating information
in sync with forward-looking processes is a fragile thing. But you do
have some stable information you can crunch in this "dead time"
interval. For example the first time you need to calculate scope is
sometime before the given command begins its execution. (You need to
know the scope information at whatever point you need to know what game
objects the player's command can resolve to). Unless the game itself
features realtime effects, this information isn't going to change in
the interval between the prompt and the command.
> The only thing of this general nature I've ever tried is caching
> best-path calculations during the prologue. And even that took too
> long, and I wound up precalculating the whole table and putting it into
> the code, in the end. I find this fundamentally inelegant, but it got
> rid of a very annoying pause at the outset.
If your compiler allows preinitialization, you can put this code in a
preinitialization routine. So when you compile the game, you have this
pause, but the information is recorded in the compiled game file, so
this pause doesn't occur when the game is played.
(Any "all points shortest path" (APSP) algorithm will take some time
for a large map. (After around 50 rooms, I start to notice some
lagtime). But most IF maps are small enough (under 25 rooms or so), so
Floyd-Warshall APSP for example should be able to calculate this in
very little time. But maybe Inform's memory constraints make a problem
of this, I don't know. I do know that Inform's memory constraints have
been a problem for other searches, such as the RAP planbase search,
which had to be implemented (in Inform) as a depth search for this
reason.)
Rikard Peterson
Only slightly related (and probably not particulary relevant to IF),
but I was reminded of a talk by Will Wright on his upcoming game Spore
that can be found here:
http://www.pqhp.com/cmp/gdctv/
I thought it was interesting. (Some of the other videos there are also
good.)
Rikard
Kevin Forchione
news:1128637730.7...@g44g2000cwa.googlegroups.com...
> The only thing of this general nature I've ever tried is caching
> best-path calculations during the prologue. And even that took too
> long, and I wound up precalculating the whole table and putting it into
> the code, in the end. I find this fundamentally inelegant, but it got
> rid of a very annoying pause at the outset.
Oh, I agree. One advantage that TADS provides is that computations of a
static nature can be done during pre-compile, which means that at least the
computer is doing *some* of the work before the game is actually assembled
into a load module. But the fundamental problem remains: dealing with the
activities of objects inside and outside of an actor's scope - a range that
may shift from message to message during a single game turn. And having said
that, I'm a loss as to how to abstract a solution that wouldn't be as
computational hungry as the simulation it's supposed to keep track of....
--Kevin
Kevin Forchione
news:1128641639.5...@g14g2000cwa.googlegroups.com...
> Basically what I am describing is an extension of the way IF is already
> conventionally written: many IF games are already world models in which
> extraordinary behavior kicks in occasionally in response to the player
> getting things into just the right state. I'm just proposing a way to
> imagine the design and organize the code so that it is easier to do
> flexible plotting, and sequences of extraordinary behavior that go on
> for more than one move without breaking. Which is where I think this
> all actually becomes interesting, and not a toy.
Very thought provoking, and I think that your analysis regarding the issues
is on track. It's quite different from the discussion on simulation so far,
in that what you are suggesting is a mechanism for generating or regulating
plot points in the course of storytelling, and quite independent of the
degree of physics or emotion simulation implemented. I see that I'm going to
have to absorb this concept and reread what you've written here.
My first impressions (and musings) are of a collection of objects that
represent these individual plot events and that run in an infrastructure
that first checks to see if any of a subset of candidate plot points have
game-state condition requirements met; the plot point that does (assuming
for the moment that there are distinct and mutually exclusive conditions for
each plot point, or at any rate, only one is selected at any given time) the
one that does is then "in control of the story", becoming the mechanism that
both moderates and spins the story in its new direction (a combination of an
environment that restricts the possible of the story within the duration of
the plot point, and at the end of which sets new game state); finally, the
plot point would need to eliminate itself from the pool of possible plot
points (no circular stories) and generate the new pool of candidates. This
mechanism would run before the start of each turn, in a manner similar to
that which daemons/fuses are run, with any given plot point still moderating
the story until it has been satisfied. At the end of each game turn, after
daemons and fuses have run, the mechanism would perform a check to see if
the plot point condition had been satisfied. At that point it would
establish new candidate plot points triggered from the one executed, and
release control to the default library mechanism until the conditions are
right for a new candidate to be activated. If conditions have not been
satisfied for that turn then the plot point remains in effect until it
either is, or it is expired. In this way you could push the story along,
while giving the player a range of freedom.
The role of the moderating stage of a plot point would be to limit and
control the kinds of responses that player commands generate, hopefully to
achieve increasing conflict and resolution, a change of value in the player
from when they first entered the scene, and marked by the achievement of
some game state goal before triggering off a new plateau of events and
establishing a new set of candidates plot points.
--Kevin
Neil Cerutti
I'm not sure. Even simple toy simulations are capable of
obviating (thanks, Infocom verbositator!) an author's puzzles, so
an extremely complex and computationally expensive simulation,
which does the same thing, isn't really an improvement, at least,
not for the reason given above.
--
Neil Cerutti
steve....@gmail.com
have termed Drama Management. One really interesting potential of the
Drama Manager, as Mateas and others have written, is its capability to
allow dynamic re-ordering of plot points based on a
narrative-heuristic. The idea being, if the game designer can write a
function which maximizes the interest of a story based on what plot
points have already been visited (and their order), and based on some
projection of the remaining plot points (or a subset thereof) (and
their order) -- then we can have a sort-of minimax algorithm that can
select what plot point(s) should be newly availible at the end of any
transition.
Think of it like a chess program, where the computer's objective is not
to reach a favorable position, but a favorable narrative. So it
responds to the player's "moves" by adjusting the plot-points
accordingly.
ems...@mindspring.com
steve....@gmail.com wrote:
> As perhaps you know, you're describing aspects of what other writers
> have termed Drama Management. One really interesting potential of the
> Drama Manager, as Mateas and others have written, is its capability to
> allow dynamic re-ordering of plot points based on a
> narrative-heuristic. The idea being, if the game designer can write a
> function which maximizes the interest of a story based on what plot
> points have already been visited (and their order), and based on some
> projection of the remaining plot points (or a subset thereof) (and
> their order) -- then we can have a sort-of minimax algorithm that can
> select what plot point(s) should be newly availible at the end of any
> transition.
Yes, I know. And other similar ideas have turned up in various rec.arts
threads over the years, including the ones listed here:
http://www.ifwiki.org/index.php/Past_raif_topics:_IF_Theory:_part_2#Computer_generated_story_lines
I'm not entirely sure how convinced I am by the idea of assembling
pieces of story entirely by algorithm, though: I find it a really
alluring idea, and at the same time I am not sure I believe in the
possibility of it working to produce a strong story.
I'm not able to comment on Stern and Mateas' work on Facade since I do
not have a computer on which it would run, but my impression from
reading reviews is that the end product is a bit more fluid and
unstructured than what I have in mind. This is partly because the
component pieces of the drama are (as far as I can tell) pretty short,
but also partly, I am guessing, because of the algorithmic approach. I
tend to imagine something with fewer, longer components combined in a
way that is at least partly anticipated by the author.
Kevin Forchione
news:1128704311.5...@g44g2000cwa.googlegroups.com...
> I'm not entirely sure how convinced I am by the idea of assembling
> pieces of story entirely by algorithm, though: I find it a really
> alluring idea, and at the same time I am not sure I believe in the
> possibility of it working to produce a strong story.
I doubt very much that it would produce a strong story. The dramatic
elements of well-crafted stories aren't something you can simply transpose
to achieve differing affects. I realize that I'm arguing for linearity here,
but that's my taste. It's certainly possible to transpose plot points and
perhaps achieve an affect that wouldn't jar a player, but again, if the
sequence of the element doesn't make a difference to the story, it probably
doesn't belong there. That's not to say that the sequence of subplots within
the overall story couldn't be shifted perhaps, but I rather doubt that the
ordering of plot points can be transposed to any beneficial effect.
Of course we can argue that the point is all hypothetical, and yet somehow I
feel that if I chopped up To Kill A Mockingbird into plot points and tried
to transpose a few it would be detrimental to the story structure. We could
argue of course that Mockingbird has been pared down to the minimum set of
plot points required to tell the story and that stories using algorithmic
selection would have a larger pool to draw on that wouldn't affect story
impact. But I don't believe that would turn out to be the case. What you'd
have under the best circumstances would be something akin to a rambling and
episodic tale.
Still, once you've got the basic framework (which ought to in itself be
interesting to design and build) you can always add an algorithmic selection
mechanism.
--Kevin
Andrew Plotkin
> <ems...@mindspring.com> wrote in message
> news:1128704311.5...@g44g2000cwa.googlegroups.com...
> > I'm not entirely sure how convinced I am by the idea of assembling
> > pieces of story entirely by algorithm, though: I find it a really
> > alluring idea, and at the same time I am not sure I believe in the
> > possibility of it working to produce a strong story.
>
> I doubt very much that it would produce a strong story. The dramatic
> elements of well-crafted stories aren't something you can simply transpose
> to achieve differing affects.
Okay, what if you're not trying to use it to produce a strong story?
The simulation parts of the standard IF world model -- containment,
take/drop, room exits -- are there to provide a set of
mostly-predictable actions for the player. They support the game when
the player can take his in-game desire ("I want to reach that trap
door in the ceiling") and turn it into a series of game commands
("STAND ON TABLE. OPEN TRAP DOOR") without feeling like he's flailing
at the parser. At the same time, the model wants to allow a few
surprises (maybe "PUSH WARDROBE UNDER TRAP DOOR" will work? If I hold
one end of this curtain, can I jump off the balcony and swing across
the room instead of plummeting?)
A character-simulation engine would be valuable in the same role. This
more or less requires that it *not* generate great storytelling. It
has to generate *mostly predictable* character actions, so that the
player has a comfortable toolset for advancing in the game.
This is the idea behind the model of game (starting with Zork 2) where
you can order an NPC around. The simulation is blindingly simple (and
what complexity it has is sponged off the parser and the world model
that the *player* uses). But it is a set of rules: the NPC does what
he's told, or else he refuses for some in-game reason. As long as the
player can comprehend the reasons, the scene works.
There's no reason why a more complex (but still limited) character
model can't serve the same purpose. The thing, though, is that this is
guaranteed to fail if you go in a Crawfordesque "Fear my seventeen-
dimensional emotion space!" direction.
I don't know how this applies to *plot* computation. Unless you cast
the player in the role of the Drama Director, and let him use some
kind of toolset to work towards the "winning" plot (of which there is
ultimately just one.) The toolset would look pretty strange, though.
"If I send the self-doubting artist into the love triangle, his
perspective on the war will generate enough contrast with the angry
soldier to create an antinomy and end Act Three!" The player would
have to be *really* fond of meta. :)
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.
Kevin Forchione
news:di6mc4$j6v$1...@reader1.panix.com...
> Okay, what if you're not trying to use it to produce a strong story?
That would change matters.
> The simulation parts of the standard IF world model -- containment,
> take/drop, room exits -- are there to provide a set of
> mostly-predictable actions for the player. They support the game when
> the player can take his in-game desire ("I want to reach that trap
> door in the ceiling") and turn it into a series of game commands
> ("STAND ON TABLE. OPEN TRAP DOOR") without feeling like he's flailing
> at the parser. At the same time, the model wants to allow a few
> surprises (maybe "PUSH WARDROBE UNDER TRAP DOOR" will work? If I hold
> one end of this curtain, can I jump off the balcony and swing across
> the room instead of plummeting?)
>
> A character-simulation engine would be valuable in the same role. This
> more or less requires that it *not* generate great storytelling. It
> has to generate *mostly predictable* character actions, so that the
> player has a comfortable toolset for advancing in the game.
>
> This is the idea behind the model of game (starting with Zork 2) where
> you can order an NPC around. The simulation is blindingly simple (and
> what complexity it has is sponged off the parser and the world model
> that the *player* uses). But it is a set of rules: the NPC does what
> he's told, or else he refuses for some in-game reason. As long as the
> player can comprehend the reasons, the scene works.
>
> There's no reason why a more complex (but still limited) character
> model can't serve the same purpose. The thing, though, is that this is
> guaranteed to fail if you go in a Crawfordesque "Fear my seventeen-
> dimensional emotion space!" direction.
The TADS 3 character model probably supplies you with much of this.
> I don't know how this applies to *plot* computation. Unless you cast
> the player in the role of the Drama Director, and let him use some
> kind of toolset to work towards the "winning" plot (of which there is
> ultimately just one.) The toolset would look pretty strange, though.
> "If I send the self-doubting artist into the love triangle, his
> perspective on the war will generate enough contrast with the angry
> soldier to create an antinomy and end Act Three!" The player would
> have to be *really* fond of meta. :)
What I am thinking about is not a computation, but a means of organizing and
moderating events. At this point in my imagining, the stages involved would
be something like:
a. Select a "plot point" object from a candidates pool based on the plot
point object's evaluation of game state.
b. The plot point object would then set a global value to indicate that
we were at that particular stage (Possibly useful for modifying object
behaviors)
c. Adjust Actor States (i.e. in TADS 3 this governs actor behaviors) to
those appropriate for the plot point
d. Execute any code pertinent to the plot point (i.e. perhaps initiate
daemons/fuses, set other object states, play out "cut" scenes, etc.)
e. Determine if the particular plot point is completed. If so, then
1. Adjust Actor States to their default values
2. Create a new pool of candidates out of an overall story pool.
f. Goto a.
The scheme might not work. But the idea is that only when the conditions are
right will a plot point become "activated", and remain activated as long as
conditions are right. The point is to produce a temporary framework under
which the behaviors of actors, objects, and events are directed to push the
story forward. After the push then the plot point is "deactivated" and the
player goes on his merry way until either his actions or the game world
itself produce a game state that triggers the activation of the next plot
point.
My expectations are that the player wouldn't even notice these transitions.
It would simply serve as a means for an author to organize and control the
flow of the story, and yet leave the player free to explore the game world.
Of course we still have the same issues of having the player put the game
state in a position where none of the candidates would ever be selected.
That's something for another thought session.
--Kevin
Nikos Chantziaras
> [...]
Steve, if possible, please provide some context (quotes) in your
replies. Thanx.
(IIRC, you always quoted; when did you stop?)
ems...@mindspring.com
Andrew Plotkin wrote:
> Here, Kevin Forchione <ke...@lysseus.com> wrote:
> > <ems...@mindspring.com> wrote in message
> > news:1128704311.5...@g44g2000cwa.googlegroups.com...
> > > I'm not entirely sure how convinced I am by the idea of assembling
> > > pieces of story entirely by algorithm, though: I find it a really
> > > alluring idea, and at the same time I am not sure I believe in the
> > > possibility of it working to produce a strong story.
> >
> > I doubt very much that it would produce a strong story. The dramatic
> > elements of well-crafted stories aren't something you can simply transpose
> > to achieve differing affects.
>
> Okay, what if you're not trying to use it to produce a strong story?
>
> The simulation parts of the standard IF world model -- containment,
> take/drop, room exits -- are there to provide a set of
>
> A character-simulation engine would be valuable in the same role. This
> more or less requires that it *not* generate great storytelling.
Yes. But this is what I'm thinking of as substrate, with the scene
stuff over the top of it.
So you have a character simulation engine with characters who have,
say, five levels of attitude towards the player, ranging from hostile
to friendly; they start out with one attitude or another, but the
player can affect these attitudes by being polite or insulting,
revealing allegiance to the character's political party of choice (or
to their opponents), etc. This is about the level of the character
simulation in CoS.
Then on top of the engine you have the scenes, which are triggered when
that simulation engine hits states that are "interesting". You've
provoked a powerful person too far; you've given yourself away to
someone inclined to betray you; etc. The scenes are plotful, and handle
special case situations which are too complicated to be woven into the
whole model. (I decide what's interesting because I am the author, so I
know what sets of plot twists should be allowed.) But the underlying
engine is, as you say, what gives the player a chance of interacting
consistently, and pursuing goals of some sort.
A problem, in my opinion, with a plot generator system that works
entirely by its own internal calculus ("okay, the storymaster AI has
decided that X and Y have happened, so next Z will happen") is that it
does make the interaction pretty mysterious from the player's
perspective. Whereas I think what we want -- at least, what I have
wanted, the two times I've made a serious shot at implementing
something like this -- is a plotting system triggered by the states
achieved in a fairly consistent underlying world model.
Unlike Kevin, I do see the "scene" as something the player would
notice; at least, as I apply it, these are often sequences where
something unusual is going on: an NPC is doing something every turn,
say, or the player is confronted with a special crisis. The range of
actions that the player can reasonably take is narrowed, and the
pressure to act rises. Sometimes I am doing this because we have
reached a make-or-break moment: a timed scenario which could end in
failure (if it's a puzzle sort of game), or a choice scenario where the
player's actions could drive the rest of the plot in any of several
directions (if it's more a story sort of game).
Sometimes the point of the scene is a little more mundane (hold the
player in one spot while an NPC tells him some important information),
but even then I try to arrange things so that there is some sense of
tension for the duration.
Once whatever-the-scene-is-about gets resolved, we can go back to
slower-paced, exploratory action with a greater range of freedom.
Though the world model may also have changed significantly: if your
choices during the scene have made the King of the Universe hate you,
your opportunities from now on may be a little different.
Kevin Forchione
news:1128726112....@g14g2000cwa.googlegroups.com...
That would parallel the Actor States and conversation model that TADS 3 has
implemented. The idea is rather similar: when an actor is assigned a certain
state object that object governs not only the actions and interactions of
the actor, but the conversations as well.
> Then on top of the engine you have the scenes, which are triggered when
> that simulation engine hits states that are "interesting". You've
> provoked a powerful person too far; you've given yourself away to
> someone inclined to betray you; etc. The scenes are plotful, and handle
> special case situations which are too complicated to be woven into the
> whole model. (I decide what's interesting because I am the author, so I
> know what sets of plot twists should be allowed.) But the underlying
> engine is, as you say, what gives the player a chance of interacting
> consistently, and pursuing goals of some sort.
>
> A problem, in my opinion, with a plot generator system that works
> entirely by its own internal calculus ("okay, the storymaster AI has
> decided that X and Y have happened, so next Z will happen") is that it
> does make the interaction pretty mysterious from the player's
> perspective. Whereas I think what we want -- at least, what I have
> wanted, the two times I've made a serious shot at implementing
> something like this -- is a plotting system triggered by the states
> achieved in a fairly consistent underlying world model.
>
> Unlike Kevin, I do see the "scene" as something the player would
> notice; at least, as I apply it, these are often sequences where
> something unusual is going on: an NPC is doing something every turn,
> say, or the player is confronted with a special crisis.
Ah... What I meant was that the player would not have to be conscious of the
"meta" aspect of the mechanism. The player should see the story, and not
have to be conscious of the dramatic mechanism itself that has been
activated. But they most certainly should notice the dramatic moment.
>The range of
> actions that the player can reasonably take is narrowed, and the
> pressure to act rises.
Absolutely necessary. And this is one reason why I feel that a strong story
will never ever naturally arise from pure simulation. Conflict builds from
the narrowing of options as each opposing side seeks to achieve its dramatic
need. This, I believe, will always require some kind of bottlenecking device
superimposed over the basic world model - like a lens moving over a piece of
paper, focussing the light until we have a fire.
>Sometimes I am doing this because we have
> reached a make-or-break moment: a timed scenario which could end in
> failure (if it's a puzzle sort of game), or a choice scenario where the
> player's actions could drive the rest of the plot in any of several
> directions (if it's more a story sort of game).
Yes, the "time" or "option" limitation that software such as Dramatica
employ.
> Sometimes the point of the scene is a little more mundane (hold the
> player in one spot while an NPC tells him some important information),
> but even then I try to arrange things so that there is some sense of
> tension for the duration.
>
> Once whatever-the-scene-is-about gets resolved, we can go back to
> slower-paced, exploratory action with a greater range of freedom.
> Though the world model may also have changed significantly: if your
> choices during the scene have made the King of the Universe hate you,
> your opportunities from now on may be a little different.
Exactly so. A new state of equilibrium has been achieved, and we let the
player function with the wider focus of the world model until the game state
has again activated another plot point and once again our focus is narrowed,
and the story is spun in the direction designed by the author.
That's the theory... but I don't do the armchair quarterback thing well.
Build it and see, that's the way forward.
--Kevin
Andrew Plotkin
> moderating events. At this point in my imagining, the stages involved would
> be something like:
>
> a. Select a "plot point" object from a candidates pool based on the plot
> point object's evaluation of game state.
> b. The plot point object would then set a global value to indicate that
> we were at that particular stage (Possibly useful for modifying object
> behaviors)
> c. Adjust Actor States (i.e. in TADS 3 this governs actor behaviors) to
> those appropriate for the plot point
> d. Execute any code pertinent to the plot point (i.e. perhaps initiate
> daemons/fuses, set other object states, play out "cut" scenes, etc.)
> e. Determine if the particular plot point is completed. If so, then
> 1. Adjust Actor States to their default values
> 2. Create a new pool of candidates out of an overall story pool.
> f. Goto a.
Heh. That's more or less the mechanism I put into _Shade_ to manage
goal progression. Except that each "plot point" was resolved by a
single player action, so the "scenes" were very short.
steve....@gmail.com
> Steve Breslin wrote:
> > As perhaps you know, you're describing aspects of what other writers
> > have termed Drama Management.
> Yes, I know.
Er, sorry. Yes, I know you know. :)
As Nikos pointed out, I failed to indicate who I was responding to....
It was to Kevin, who has been (as Emily knows) sort of reinventing an
approach to narrative handling which was long-ago invented by the
Carnegie-Mellon Oz project. (No offence to Kevin -- this stuff is
(unfortunately) outside of the normal IF-developer's required reading
list. -- If only we had an IF-Theory book....)
But, on to the point:
> I'm not entirely sure how convinced I am by the idea of assembling
> pieces of story entirely by algorithm[.]
Really nobody is suggesting we dice up the plot, and shove it into an
algorithm to crunch. Drama Management does not imply that the plot is
"assembled entirely by algorithm," or anything nasty-sounding like
that.
Quite the contrary: the plot-tree is entirely determined by the author,
and to whatever extent the author wishes to allow "play" in the plot,
the parameters of this play are also determined by the author. The
drama manager simply facilitates this.
As far as the plot tree being entirely determined: each plot point will
declare a list of plot points which are prerequisite; and each plot
point will declare a list of plot points which are availible after this
current plot point closes. (This is one of the basics of how Fascade
works.)
The availibility of the points varies on other considerations of
game-state, such as NPC "mood" for example. This stuff prunes or
influences the currently availible plot tree, but does not alter its
basic structure, except where the author wants it to do so.
Mateas has suggested that a "narrative heuristic" might offer
additional pruning or influence to the plot tree. So, if the author
declares that A->B->C is preferable to A->C->B, then plot-point A would
either (1) disallow plot point C; or (2) adjust the game-state such
that plot point B is (somehow) more likely to fire than plot point C.
>From only this simplistic example, this in itself does not sound like a
great accomplishment. -- But where we have several levels of branches
in the plot-tree, and further effecting factors (like NPC mood for
example), the drama-manager handles automatically those sticky
computations towards the optimal plot tree described by the author.
Again, that tree is fully determined by the author. -- It's *really
not* envisioned that the plot should be assembled entirely from
algorithm.
steve....@gmail.com
> A problem, in my opinion, with a plot generator system that works
> entirely by its own internal calculus ("okay, the storymaster AI has
> decided that X and Y have happened, so next Z will happen") is that it
> does make the interaction pretty mysterious from the player's
> perspective.
Sorry, but I don't understand the logic here. In the typical game, "X
and Y have happened, so next Z will happen" -- this is quite normal.
The point is the same whether the author declares it or the
"storymaster AI" resolves it. I'm not seeing where the mystery comes
from.
> Whereas I think what we want -- at least, what I have
> wanted, the two times I've made a serious shot at implementing
> something like this -- is a plotting system triggered by the states
> achieved in a fairly consistent underlying world model.
That's what a Drama Management system does, except the plotting system
can be parametrised at the author's discretion. Sure, there's more to
it than that, but basically it's the idea of a text interwoven more
tightly, not more loosely and arbitrarily/mysteriously.
ems...@mindspring.com
steve....@gmail.com wrote:
> Emily writes:
>
> > A problem, in my opinion, with a plot generator system that works
> > entirely by its own internal calculus ("okay, the storymaster AI has
> > decided that X and Y have happened, so next Z will happen") is that it
> > does make the interaction pretty mysterious from the player's
> > perspective.
>
> Sorry, but I don't understand the logic here. In the typical game, "X
> and Y have happened, so next Z will happen" -- this is quite normal.
Indeed. But what I meant by "entirely by its own internal calculus" was
"relying mostly on a set of information/reasoning that is invisible to
the player".
This is all getting pretty vague and hand-wavy, partly because I am
trying to critique the Facade model without ever having played Facade;
I have only read transcripts and reviews and descriptions of play, and
some of the behind-the-scenes articles on
http://www.interactivestory.net/. (URL included for benefit of readers
wondering what I'm talking about, not you personally, Steve.)
However. One complaint I have seen players offer repeatedly is that
they often find it difficult to understand what effect their actions
are having, and why. Partly this is because the world model/simulation
aspect is pretty effectively hidden: you never see "Trip is getting
angrier!" (thank goodness, too); just complicated, context-dependent
reactions, with the drama manager making choices about what kind of
situation can arise next, based on things the player never gets to know
about.
And you also don't get to know what part of your *input* is deemed
important by the program, because it takes natural language input and
selects trigger information from it and throws away the rest of what
you said. This *sometimes* gives the eerie feeling that the NPCs
understand you perfectly, and often the sense that they are utterly
crazy/unable to communicate; and, in any case, it gives the player very
little sense of how to steer.
At least, such is my impression based on what has been said.
I realize that at least half that set of complaints can be (and has
been) leveled at some of my own work, though with IF ASK/TELL or menu
systems the player does at least have some idea what he's doing that's
changing the model state.
> > Whereas I think what we want -- at least, what I have
> > wanted, the two times I've made a serious shot at implementing
> > something like this -- is a plotting system triggered by the states
> > achieved in a fairly consistent underlying world model.
>
> That's what a Drama Management system does, except the plotting system
> can be parametrised at the author's discretion.
Well. Okay. Possibly I am also misunderstanding the way Facade works,
or the way Drama Management might work in systems that are not Facade.
> Sure, there's more to
> it than that, but basically it's the idea of a text interwoven more
> tightly, not more loosely and arbitrarily/mysteriously.
I'm not a hundred percent happy with "more tightly". It seems like the
extreme granularity of the beats is actually one of the things working
against dramatic effectiveness in Facade (again, look at me
extrapolating hugely on the basis of third-hand reports); I think what
we want are not "beats" lasting a few seconds/a single move of
playtime, but structured scenarios lasting multiple moves. (It's also
hard to say exactly what difference it makes that Facade is in realtime
whereas any IF application would probably be turn-based.)
Anyway. To analyze this with any thoroughness we need more examples.
Though I'm intrigued to learn that the Shade code does something like
this. This makes sense; I just hadn't realized it.
steve....@gmail.com
> [W]hat I meant by "entirely by its own internal calculus" was
> "relying mostly on a set of information/reasoning that is invisible to
> the player".
> One complaint I have seen players offer repeatedly is that
> they often find it difficult to understand what effect their actions
> are having, and why.
You're pointing out the primary problem of AI-in-IF. To appreciate an
AI, its effects (and limitations) must be somehow disclosed. Just
shifting things around behind the scenes does not give a sense of AI,
but instead a sense of confusion. The AI-process needs to tip its hand
somehow, or the aesthetic suffers. This does not mean that the process
need be disclosed; but some representation of the process is necessary.
This is, by the way, my closing thought in the AI-in-IF article.
But this is not a complaint against an AI system, but a complaint about
the aesthetical mis-handling or mis-application of the system.