Simulations vs. pre-planned plots (longer)
Derek S Felton
post that precedes this one. This one is longer, but more organized.
I like the idea of a "simulation," but only a well-constrained
one. What follows is a "what it is, what it's not" according to
me. As always, feel free to add or contradict whatever you like.
To me, simulated environments...
* ...Contain characters that are more than state machines--
that is, characters should be guided by motivations that
evolve in ways the author might not have foreseen. These
characters do *not* have to exhibit all facets of human
personality. That, we all know, will be impossible
for a *long* time (but I won't say forever).
* ...Contain objects that are more than just puzzle pieces.
In other words, the oft-cited shovel could function in more
than just the place it was *meant* to be used. Further-
more, that same shovel could be used as a weapon, a lever,
or anything else the parser will support. Again, such ob-
jects would *not* require a full implementation of every
physical law known to humanity. The level of abstraction is
purely up to the designer.
* ...Allow themselves to be altered in realistic ways. For
instance, in a fantasy setting, a fireball spell would most
likely blast a door off its hinges, or even break a hole
in a wooden/plaster wall. I think the world model should
be dynamic enough to tolerate new linkages (and closures)
between its locations. Ditto on the "laws of physics" dis-
claimer: we can't and don't have to model all possible
object/environment interactions--just enough to enhance
the believability of both.
Naysayers: such environments are not necessarily devoid of plot!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The notion of embedding plot and puzzles within objects and
characters is crucial.
Arguments against simulations state that "you could spend for-
ever just waiting for something to happen!" Yes and no.
Yes, you could find a remote place, stay there, and twiddle your
thumbs for as long as you please. But think about it... you can do
that in many segments of "plotted" IF, too.
No, because an interesting simulated environment would place the
reader in a place/situation where he or she *must* do something.
Simulation isn't turning readers loose in a glorified playground,
where you can pick up and play with things but not be hurt or affect-
ed by them. Hell, no! Objects and people in simulation-style IF
can definitely bite back if that is part of their behavior.
Some believe that a simulation "hides" the plot so that the user
has to find it. Plots in simulations--or, "suggested activities"--
can be made just as obvious as in traditional IF.
For example, say you're a peasant working in the stables. This
would be a bad simulation if you had to *break character* to entwine
yourself in the important events of the world. But think of great
fantasy novels that employ this plotline: something always happens
to believably sweep the main character into the grand design. A
dragon suddenly incinerates the village... a mysterious mentor ap-
pears, telling the main character about his/her destiny... strange
goings-on arouse the protagonist's curiosity. You get the idea.
At the other end of the story, there's no reason why the action
has to degenerate into a meaningless tangle of random, half-developed
plot threads. Timed events--"demons"--can keep things moving, and
a high-level plot manager can tweak NPC motivations if things get
too stagnant. Structure people, objects, and events in such a way
that things are likely to shake out the way you want them to.
The idea of managing the combinatorial explosion is ludicrous.
The solution is not to try.
OK... some people like to control every aspect of their story.
That's great, because some fantastic stories *can't* be told properly
without the author's total control. But someone (I'm sorry I can't
attach a name to the quote) said, "I never play games I've written,
because I know everything that's there." I want to write a story
engine that will give simulated worlds the power to surprise even their
creators.
Do I know what this thing will look like? Not a *%$#ing clue.
But I *don't* think it's impossible. Thanks for your patience and
interest.
--- Derek S. Felton
de...@esu.edu
David Baggett
> * ...Contain characters that are more than state machines--
> that is, characters should be guided by motivations that
> evolve in ways the author might not have foreseen.
It's easy to talk about great things if you're willing to ignore
implementation issues. Unless you explain how a system like the one you've
described could be implemented, you might as well be talking about making
games that, for example, converse with you in perfect English.
>These characters do *not* have to exhibit all facets of human personality.
>That, we all know, will be impossible for a *long* time (but I won't say
>forever).
Even what you've described has been difficult enough to elude everyone
who's tried so far. This leads one to believe that we need to get a better
understanding of basic facts about intelligence and emotions before we can
proceed.
>Naysayers: such environments are not necessarily devoid of plot!
Not in an absolute sense, no. Events will occur. Some may even be
interesting. But the real claim is that the plots that arise in
simulationist IF will not be very *good* plots.
Computers can be programmed to generated something that you might call
prose. But the difference between computer-generated prose and
human-generated prose is *quality*. I do not forsee computers being able
to develop high-quality plots in the near future, just as I don't see
computers being able to generate high-quality prose in the near future.
Both these problems require solutions to difficult knowledge representation
problems that have plagued AI people since the birth of the field.
Good plots rarely arise magically out of real life. Why should expect them
to arise out of simulations?
>The notion of embedding plot and puzzles within objects and characters is
>crucial.
If this is the crux of it, then design a two-location game with suitably
crafted objects such that good plots arise automatically. If it is really
possible to write such a thing, doing it on a trivial scale should be quite
easy. If it is not easy, then doing it on a grand scale is certainly out
of our reach right now.
I'll admit it's a bit cheap to say "prove it with an example", but I'm
struck by the total lack of grounding in statements like "the plots will
arise out of the characters" and "embed plot in the characters". Neither
you nor Felix gave any indication about how this might be done. I'm not
saying that's it's absolutely absurd, but I won't believe it until I see
it, because I think it's very unlikely to work.
>Do I know what this thing will look like? Not a *%$#ing clue.
If you can't imagine how it would work, then why do you think it's
possible? I'm serious -- this strikes me as similar to saying, "I can't
quite imagine how you'd get to the moon just by improving tree-climbing
technique, but I'm *sure* it's possible."
Historically speaking, this has been a problem with AI research in general.
Dave Baggett
__
d...@ai.mit.edu MIT AI Lab He who has the highest Kibo # when he dies wins.
ADVENTIONS: We make Kuul text adventures! Email for a catalog of releases.
Paul Francis Gilbert
[...stuff deleted...]
>>It's easy to talk about great things if you're willing to ignore
>>implementation issues. Unless you explain how a system like the one you've
>>described could be implemented, you might as well be talking about making
>>games that, for example, converse with you in perfect English.
>I'd have to agree with Dave on this, even though I've been guilty of the
>same sort of wishful-thinking-out-loud in the past. It's really easy to
>spout great ideas on r.a.i-f, and really hard to sit down for months on end
>and come up with a working game/program/artwork/whatever.
Yes, but we must remember that such a task IS possible. Mike Roberts has
obviously put a lot of time into TADS, as Graham has put into Inform, and
indeed Dave has into WorldClass
>An aside: I can't speak for anybody else, but I tend to give Dave Baggett's
> opinion a good hearing, simply because I know he has wrestled with
> IF development problems long enough to have *actually produced
> something*: the Unnkulia games, worldclass.t, Horror of Rylvania,
> etc. I find it particularly telling that after writing lots of
> puzzle-based IF, Dave is now moving away from it (but that's
> another story).
I have to agree with you here. The Unnkulia series is totally froody. And indeed
having studied WorldClass.t, I still can't understand lots of the low-level
coing [but I'm working on it (: ]
>This is definitely not intended as a flame of Derek or Felix: I've found
>both of your posts interesting and articulate. I would like to suggest,
>however, that it might be profitable for the r.a.i-f readership to get more
>into the nitty-gritty of game development; to discuss implementation
>strategies, algorithms for actor control, etc. Of course, we're still
>talking vapourware, but at least it would be vapourware with some sort of
>tangible outline.
Here's the main part of my post: I would tend to disagree on this point. Sure
this is a great group for discussing problems in the latest Inform version, or
tricks to try in TADS/Inform, but we must remember that this newsgroup is for
interactive fiction, and half the battle is defining the exact nature of our
IF, how to implement it, and considerations on realism. Let's not just clamp
down to coding and implementation details, when we can profit just as much from
a theoretical basis.
>>If you can't imagine how it would work, then why do you think it's
>>possible? I'm serious -- this strikes me as similar to saying, "I can't
>>quite imagine how you'd get to the moon just by improving tree-climbing
>>technique, but I'm *sure* it's possible."
I can only find myself agreeing with this up to a point. Sure, it is a bit
naive to not have some idea of how your ideas could be implemented, but again
the first step is HAVING those ideas. Without them, you'll find your IF coding
to become a mess of spaghetti coding, clashing plot details, or just generally
not a top notch piece. As some philosopher once said:
"What you can do, and what you can achieve, is only limited by what you can
dream about."
>Again, I think Dave has a point here. A wish list is one thing, a strategy
>for developing a working game is something else.
Just to tie up my point here. I think that friendly discussions of this nature
are appropriate, as a whole, to the genre of IF. I'm not going to go into all
the debate that's already gone on in this thread about simulation/plot, etc,
but just to merely point out that while such things as a total simulation may
not be possible for a long time, aspects of it can provide invaluable help to
writing a more life-like IF piece.
...I now return you to your regularly scheduled debate...
--
Paul Gilbert | s940...@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 1, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.
Gerry Kevin Wilson
[Troll stuff deleted.]
Hunh. Just so happens I have 2 NPCs like this in Avalon. Mind you, not
everyone reacts to being kicked and poked and spit at and laughed at
and....you get the idea. This is where simulation would come in handy.
Problem: I've STILL got to code individual responses for them, even if I
use simulation. Why? Well hell, they're not going to act alike. They
have very distinct personalities. There's a retarded mole, and an evil
knight. Obviously, "The X gets angry at you." doesn't cut it. It's got
to be "The mole flinches away from you and stares in fear." and "The
knight, with a swift motion, knocks your feet out from under you as you
try to kick him." The generic simulation message don't cut the mustard.
Now, I suppose I could have the reaction messages be in a certain
property pointer. BUT, even this fails me. I STILL have to code things
individually, because the mole grows more fearful of you, and the knight
grows angrier at you. Entirely different reactions to reflect their
personalities. This was my big complaint. I have yet to get any use out
of simulation simply because a generic message is not suitable. If I've
got to code a vaguely realistic NPC, I'd rather do it by hand and get the
higher quality reactions.
--
<~~~VERTIGO~~~~~~~~~~~~~~~~SPAG~~~~THIRD~ISSUE~DUE~OCT~26~~~~~~~~~~~~|~~~~~~~>
< The Society for the Preservation of Adventure games. Filled with | ~~\ >
< reviews, ratings, and advertisements...all about text adventures. | /~\ | >
<___SOFTWARE______E-MAIL...@uclink.berkeley.edu__|_\__/__>
Derek S Felton
> Hunh. Just so happens I have 2 NPCs like this in Avalon. Mind you, not
> everyone reacts to being kicked and poked and spit at and laughed at
> and....you get the idea. This is where simulation would come in handy.
> Problem: I've STILL got to code individual responses for them, even if I
> use simulation. Why? Well hell, they're not going to act alike. They
> have very distinct personalities. [...]
Very good point. I don't think any kind of generic response system
could work (i.e., threatening an evil knight and a tiny rodent shouldn't
trigger the "attack" response in both).
I still like the idea of "simulation-style" IF, but I don't think
we should *ever* sacrifice believable responses and stories just for
the sake of making actions universal. In other words, I think we should
be able to offer food (or whatever) to every character, but I don't
think they should always want it, take it, or suddenly become your best
friend because of it.
I'll digress into a reference: in one of the Infocom mysteries--I
believe it was THE WITNESS--you could shoot anyone you wanted. The only
catch was that killing innocent characters promptly got you arrested.
Isn't that better and *more believable* than a stock response stating,
"Shooting ______________ wouldn't do you any good."?
My suggestion would be to let each character store an "opinion" of
important characters (and possibly things) with whom he/she comes in
contact. This can get as specific as memory and speed will allow.
(For instance, it might be nice to have characters store opinions of
every item he or she has seen, but such a feature would consume too
much memory for most platforms and would be useless 99% of the time.)
Somewhere in the "response resolution" segment of the program, this
opinion would be consulted when an interaction occurs. Therefore,
trying to kick the rodent might generate an opinion of "FEAR," which
would consequently lead to the response of "FLEE FROM." Kicking the
knight, on the other hand, might produce an opinion of "CONTEMPT" or
"HATE." Based on these opinions, the knight would respond with "ATTACK."
(By the way, I *do* realize that emotions interact and affect each other;
these are just quick suggestions, not final solutions.)
I don't want to give specs on what an "opinion" data structure might
look like, because I think they'd vary from story to story. More
importantly, everyone has their own definition of what constitutes an
opinion of someone/thing. Authors have to build "opinion" structures
according to their own individual definitions.
Comments?
--- Derek Felton
de...@esu.edu
Jason Noble
(Paul Francis Gilbert) writes:
>Here's the main part of my post: I would tend to disagree on this point. Sure
>this is a great group for discussing problems in the latest Inform version, or
>tricks to try in TADS/Inform, but we must remember that this newsgroup is for
>interactive fiction, and half the battle is defining the exact nature of our
>IF, how to implement it, and considerations on realism. Let's not just clamp
>down to coding and implementation details, when we can profit just as much from
>a theoretical basis.
Paul, I should have been more specific. I don't mean to suggest that
philosophical debate and discussion is not useful. I'm not suggesting we do
any *less* of this, I'm just suggesting that we not be afraid to add in a
concrete suggestion or algorithm every now and then.
Regards,
---------------------------------------------------------------------------
Jason Noble | jno...@bunyip.bhs.mq.edu.au
National Centre for HIV Social Research | jno...@laurel.ocs.mq.edu.au
Macquarie University, Sydney, Australia | ph. (61 2) 850 8667
---------------------------------------------------------------------------
Paul Francis Gilbert
>I propose a system where we simulate / operationalise the troll's goodwill
>towards the player as an ordinal variable. We keep the two hand-coded
>events, because they're useful and add to the game experience. The troll's
>goodwill score starts at 0. If it is less than 10, the troll will prevent
>the player from passing. If greater than or equal to 10, the player will be
>allowed through. The troll's goodwill goes down over time, shall we say,
>and is gained through the donation of food, or to a limited extent, through
>flattery (let's say a maximum of 3 "flatter troll" commands will work).
>Now we have a simulation system where more things are possible, with only a
>moderate amount of additional implementation. In this new game, the player
>might just give the troll the cream bun (foodvalue 15) and get past. Or,
>not having found the cream bun, he/she might flatter the troll repeatedly
>(gaining 3 points of goodwill each time) and then give the troll the
>relatively crappy crust of bread (foodvalue 2) and get past.
This is actually a very good idea. Simple characters tend to become like
cardboard cutouts (such as the guard in Ditch Day Drifter, although it was
brilliant to have Floyd try and sell insurance to him ). It wouldn't be too
hard to implement this particular example, indeed I seem to recall that CCR
had something along that lines for dealing with getting the hamster to power
the wind tunnel: different foods having "energy" factors or something.
The thing is though, that is how can we formalise the concept of these scripts.
Obviously in TADS we could, for this particular example, check the class of
any object given to the troll to see if it was an foodItem / Edible [I'll leave
the shameless plugs of WorldClass to Dave ;-) ]. But that doesn't go far to
formalising a script language. Perhaps we could just give actors a few standard
characteristics, such as friendliness ( wasn't what-iz-name the Avion writer
talking about the same thing for his NPCs? ), attitude, etc. and build a
standard set of interaction rules from that which would be built into the class
ie: for talking:
If communication is possible, and the actor's disposition to towards
actor xx is hostile, then initiate attack on actor xx. Otherwise, reply
to question.
Something along the lines, with some methods to check [if the actor is
controllable] if the player is causing him to do something dangerous, which
would lower this good-will towards the player, until such time as the actor
attacks him on sight. In comp.sys.ibm.pc.games.rpg, I think it was, it was
mentioned how in DarkLands, your players get "recognised" from City to City if
they've been really good, or really bad. In the case of good, they get welcomed
as heros, and for really bad, they get attacked on sight.
That's just thinking on "karma" rating. There should obviously be some more for
good representation. Perhaps some way of specifying relationships between
variables:
ie: lists of statements which would be parsed like:
if actor._property_ is LOW, then INCREASE actor._property2_ by ONE
[per 10 turns].
So we could call _property_ the actor's hunger, and _property2_ the actor's
hostility towards the Player. And so, on.
Just adding my $0.02
Jason Noble
The story so far...
Derek Felton and Felix Lee have been discussing the possibilities
inherent in their vision of more open, "simulationist" IF.
Dave Baggett has chided them for neglecting the serious issue of how
one might actually implement this sort of thing.
======================
In article <37sef6...@life.ai.mit.edu> d...@ai.mit.edu writes:
>It's easy to talk about great things if you're willing to ignore
>implementation issues. Unless you explain how a system like the one you've
>described could be implemented, you might as well be talking about making
>games that, for example, converse with you in perfect English.
I'd have to agree with Dave on this, even though I've been guilty of the
same sort of wishful-thinking-out-loud in the past. It's really easy to
spout great ideas on r.a.i-f, and really hard to sit down for months on end
and come up with a working game/program/artwork/whatever.
An aside: I can't speak for anybody else, but I tend to give Dave Baggett's
opinion a good hearing, simply because I know he has wrestled with
IF development problems long enough to have *actually produced
something*: the Unnkulia games, worldclass.t, Horror of Rylvania,
etc. I find it particularly telling that after writing lots of
puzzle-based IF, Dave is now moving away from it (but that's
another story).
This is definitely not intended as a flame of Derek or Felix: I've found
both of your posts interesting and articulate. I would like to suggest,
however, that it might be profitable for the r.a.i-f readership to get more
into the nitty-gritty of game development; to discuss implementation
strategies, algorithms for actor control, etc. Of course, we're still
talking vapourware, but at least it would be vapourware with some sort of
tangible outline.
>If you can't imagine how it would work, then why do you think it's
>possible? I'm serious -- this strikes me as similar to saying, "I can't
>quite imagine how you'd get to the moon just by improving tree-climbing
>technique, but I'm *sure* it's possible."
Again, I think Dave has a point here. A wish list is one thing, a strategy
for developing a working game is something else.
So in an effort to practise what I preach, here are some thoughts on
implementing a more simulationist IF architecture. If you think I'm being
too vague, or wrong, or just plain boring, feel free to comment.
As Andrew C. Plotkin recently noted, we can see all IF as having varying
proportions of two elements: a simulationist aspect, where an attempt is
made at modelling some real or imaginary world and the player is able to do
what he/she likes within that world; and a plotted, "exception-based"
aspect, whereby the author exerts fairly rigid control over possible events.
The canonical simulationist example (c/o Andrew) would be the take / drop
inventory system: the author has not explicitly foreseen that you might want
to drop the crowbar in the Grey Room, but the system of rules for taking and
dropping things in locations allows you to do this.
The exception-based approach is typified by having to use a particular chair
to break one and only one particular window in the game. Or having a hungry
troll respond only to the cream bun, and not the loaf of bread or the
spaghetti marinara or other food items in the game.
Simulationist aspects allow for a lot of player freedom, but aren't
necessarily very rich or interesting, ie. you can put the crowbar anywhere
you want, but all you ever get is "You see a crowbar here."
Exception based approaches limit player freedom, but are usually much richer
because the author has "hand-coded" the results, ie. you can only give the
cream bun to the troll, but when you do, you get a funny or interesting
description of him scarfing it down.
I think the most important point to be gleaned from this is that IF, as it
stands, *already* includes both approaches. Personally, I'm interested in
expanding the simulationist aspect without sacrificing the quality
of the hard-coded, exception- or plot- based aspect.
One way to do this is by improving the quality of exisiting simulation
traditions. For instance, there might be a better (more convincing) way of
describing the moveable objects in a room. I remember once playing a game
(New England Gothic, I think it was) where I hoarded every object I found in
the hallway of a house. Then when I walked into that hallway, I would get a
ridiculously long list at the end of the room description, enumerating all
the objects present. Perhaps we could have a system where only the largest
/ most striking objects are listed, and the rest is unspecified. For
example:
You see a bulging sack, two wooden chairs, an old-fashioned radio, a
tea-chest, and a whole lot of other stuff here.
> examine other stuff
There's a deck of cards, several coffee mugs, a compass and a map.
This could be achieved in TADS by re-writing the function that lists objects
in a room, and having the floating item "other stuff".
Another strategy is to try to handle in a simulationist way, specific game
elements that have previously been treated in an exception-based manner. (To
quote Han Solo, "Well, that's the real trick, isn't it?").
I think this is the way we'll get IF to advance: by small increments. It's
currently unfathomably difficult to implement a completely simulation-based
game, but it shouldn't be impossible to take things one small step at a
time.
Let's apply this idea to actor control. In a traditional game you might
have a puzzle situation where you had to give the troll the cream bun so
that he would be well-disposed towards you and let you pass through his
domain. Thus, the author has hand-coded two situations: "troll stops player
from passing", and "troll lets player past after having received cream bun".
I propose a system where we simulate / operationalise the troll's goodwill
towards the player as an ordinal variable. We keep the two hand-coded
events, because they're useful and add to the game experience. The troll's
goodwill score starts at 0. If it is less than 10, the troll will prevent
the player from passing. If greater than or equal to 10, the player will be
allowed through. The troll's goodwill goes down over time, shall we say,
and is gained through the donation of food, or to a limited extent, through
flattery (let's say a maximum of 3 "flatter troll" commands will work).
Now we have a simulation system where more things are possible, with only a
moderate amount of additional implementation. In this new game, the player
might just give the troll the cream bun (foodvalue 15) and get past. Or,
not having found the cream bun, he/she might flatter the troll repeatedly
(gaining 3 points of goodwill each time) and then give the troll the
relatively crappy crust of bread (foodvalue 2) and get past.
I see this a way to get more of the game-play variation associated with
simulation strategies. The troll still operates according to two very basic
scripts (and I think the script concept in ALAN is useful here), but the
player now has many methods of triggering the desirable script.
If you'll permit me a moment's vapourware-rambling: once the concept is
extended to include recursion, ie. scripts within scripts, it really takes
off. This way we can have interesting actors without having to solve the
AI-problem. That is, no foreseeable game code is going to *spontaneously
generate* a plan by Sheikh B.G. ibn-al-Nasty to try to fool the player into
thinking that the beautiful belly dancer from the casbah was actually his
secret double agent. However, if the author writes such a script for the
sheikh, and sets it to be activated when the sheikh is already executing the
"confuse player" script plus his "paranoia level" has reached a certain
point, we just might have something.
And please: let's talk coding, algorithms and serious implementation
strategies. People might steal your ideas, but what the hell, none of us
are going to make any money out of this anyway.
Andrew C. Plotkin
suggestions; l.. Gerry Kevin Wilson@uclin (1610)
> Problem: I've STILL got to code individual responses for them, even if I
> use simulation. Why? Well hell, they're not going to act alike. They
> have very distinct personalities. There's a retarded mole, and an evil
> knight. Obviously, "The X gets angry at you." doesn't cut it. It's got
> to be "The mole flinches away from you and stares in fear." and "The
> knight, with a swift motion, knocks your feet out from under you as you
> try to kick him." The generic simulation message don't cut the mustard.
But consider this way of doing things:
Give each NPC two variables to represent their attitude: respect for
you, and agitation. Each is a number from 0 to 99 (or whatever.) 0
respect means the NPC regards you as an insect; 99 respect means he
thinks you can move mountains. 0 agitation is calm; 99 agitation is
massive adrenaline rush.
Then write a table of responses based on the two variables (respect,
agitation):
0, 0: NPC ignores you or orders you around.
99, 0: NPC does anything you ask and licks your boots.
0, 99: NPC tries to kill you.
99, 99: NPC runs away in terror.
And some intermediate values -- 25 responses is plenty (0, 25, 50, 75,
99 in each axis.) These 25 responses apply to *all* NPCs.
Where the NPCs differ is how their variables change in reaction to your
actions. If you throw a rock at the mole, both agitation and respect
increase, because you're really threatening him. So you get the message
"The mole squeaks in pain, and " followed by the updated emotional
response from the table.
If you throw a rock at the knight, it bounces off his armor, and his
agitation increases, but his respect decreases.
And so forth.
NPCs also differ in how their scores change over time. A temperamental
character's agitation would decrease 1 point per minute, etc; a calm one
would go down 10 per minute. A forgetful character's respect for you
would tend towards 50 over time.
Thus, simulationist NPCs. This can be worked into a simulation-style
plot, where you just get to run around and interact with them. It would
also work with a more traditional (exception, author-decreed) plot,
where you have to get the knight to a [high, low] state so that you can
order him to go kill the dragon.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."