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.