Adventure interface, Physics
Phil Goetz
It is more like a virtual reality system than a text adventure.
You are looking at a 3D line-drawn world on your computer screen.
The world is made of basic geometrical objects ("geons"): "cubes" (though
not necessarily all 3D the same), boxes, spheres, cylinders, pyramids, cones,
sheets. Rooms are made by joining sheets together to form walls, floors,
and ceilings, or by being boxes. Complex objects are made by gluing geons
together.
There are two major design decisions:
1. Do you allow holes in objects? How do you put doorways in? Can we put
holes of specific sizes in objects and still do good physics (see below)?
I think not. I propose constructing from smaller sheets rather than
puncturing big ones.
2. Do you allow objects to rotate? Everything becomes much worse when
just one object rotates. Most notably, calculating when objects collide
is more difficult, and you must consider rotational inertia and torque.
In the first VR IF system, rotation might be disallowed.
There should be other objects in the system. Liquids. Gas. Fire.
I don't know how to deal with them. I suggest not having them in this
initial model.
INTERFACE
Gone are command parsers. Your interaction with this world is done
entirely with an arm. This arm has no joints. It sticks out straight
in front of you. You can pull it in or push it out, and control the
speed at which this is done. You can make it sticky or un-sticky.
Possibly you can also rotate it (roll, for you aerospacers).
Whichever way you face, the arm sticks out in front of you. If you want
to pick up an object from the floor, you bend over until the object is in
the center of the screen at the end of the arm.
(Actually, the end of the arm is not quite at the center of the screen;
you need to see it slightly from the side so as to see how far it is
extended.) Then you extend the arm, change it to sticky, and retract it.
Possibly you can drop items from the arm into an inventory limbo,
and pop them back onto the arm (exchanging them with any object currently
stuck to the arm) from a list.
INTERACTIONS OCCUR AS A RESULT OF PHYSICAL PROPERTIES, NOT CODING
Say you want to throw a ball. You pick it up as described, then
rapidly extend the arm. At the end of the arm's movement, the ball flies
off the arm. (Stickiness is not absolute.)
No code is written for the arm, beyond the ability to extend/contract/
stickify/destickify it. All interactions follow the laws of physics.
Say you want to open a door with a key. Find the key visually. It must
have a flat end that the arm can stick to while the functional part sticks
out ahead. Point the arm at that surface, and pick it up. The piece
picked up will automatically orient itself so that the surface pointed to
will be flat with the end of the arm. Walk to the door. Aim the key at
the keyhole (this may require being able to raise your body up/down as
well as bend up/down). Extend the arm until the key is in the keyhole.
Rotate.
Now, this key is not a tumbler lock, it is a warded lock. There is a
2-part bar inside the door. Turning the key hits one of these parts,
pushing the bar aside, unlocking the door, like so:
B = Bar
D = Door
K = Key (end view) DDDDDDDDDDDDDDDDDDDD
D D
D K D
D K BBBBBB D
BBBBBBBBBBBBBBB D
D D
D D
D D
DDDDDDDDDDDDDDDDDDDD
This does not involve ANY special code. The programmer doesn't have to
specify that K is a key, or which locks the key matches. He just has to
build objects that fit together. The biggest problem is getting the
bar inside the door and the keyhole in the door. The door may have to be
composed of plates (with the bar sandwiched between them). The front
plate may have to be composed of 6 smaller plates, leaving an empty space
that is a keyhole:
PPPPPPPPPPP
P..P...P..P
P..PPPPP..P
P..P P..P
P..P P..P
PPPPP PPPPP
P...P P...P
P...PPP...P
P...P.P...P
PPPPPPPPPPP
The requirement that objects not have holes in them is one of the biggest
problems with this scheme. Note that you have to display the lines that
are boundaries between objects, and so your door is bound to look funny.
THE BIG PROBLEM: PHYSICS
Every object in this world is subject to the laws of physics.
The effects of these laws are computed for every object, at certain time
intervals. These are the factors taken into account:
Gravity
If an object is not supported, it is accelerated straight downward.
The notion of "supported" needs to be strictly defined. See below.
Inertia
An object in motion (3D vector) will continue in that motion until acted upon.
F=ma, conservation of momentum
When object A touches object B, the point of contact must be found,
and the redistribution of momentum between the two objects calculated.
The additional momentum is modified by some elasticity rules (see below),
then added to the current momentum of each object.
Each object then attempts to move in the direction indicated.
This creates 2 problems:
1. What if you bounce a ball against a poster on
the wall? The poster has little mass, so most of the momentum goes to the
poster. The poster won't move, because the wall prevents it; the ball will
drop directly to the ground instead of bouncing.
2. When the ball hits the ground, it will bounce, because the ground has a
large mass. When you drop an anvil on the ground, it will bounce almost as
much. When you drop a feather, it will bounce more. Some model of
elasticity is required. Presumably each geon instantiation will have
object properties assigned to it, incl. elasticity. But I can think of
no way of specifying that a metal block does not bounce if dropped onto a
metal floor, yet will move away if you hit it with a metal bat.
All this physical modelling will take lots of calculation.
Here are two methods for limiting computation:
A. Every object is ignored until some other object comes in contact with it
(e.g. hits it) or stops contacting it (e.g. a support is taken away).
Once an object stops moving, it is ignored again.
B. Every object within a certain distance of you - any distance metric that
is easy to compute - is operated on with a small timeslice. As distance
from you recedes, timeslices increase [probably in quanta, i.e. a 1/1 zone
(where the player is), a 1/2 zone (one timeslice every 2 player timeslices),
a 1/4 zone, etc.], and so simulation is more imperfect. But hopefully
nothing much is happening in these other locations anyway.
Object A "supports" object B if object A is in contact with B along the
surface of B which is selected as the "bottom" at that timeslice.
The bottom is selected for planes by finding that plane whose normal vector
has the largest dot product with the floor's normal vector. For spheres,
this presents a problem; if the whole sphere is one surface, then something
on top of the sphere is considered to be supporting it. So we need to
say "A is in contact with sphere B along B's lower hemisphere".
So, if block B is 4 meters long, and 1 cm of it is over table T, T supports B.
This is bad.
Also, if cube C falls onto the side of pyramid P, it will "stick" there
instead of falling down. Ideally, we would rather have it rotate down,
contact the side of the pyramid, then consider the coefficients of friction
of P and C and the mass of C to decide whether to slide.
I think this could be a cool topic for my PhD dissertation,
provided I emphasize VR and not IF. What do you think?
Phil Goetz
go...@cs.buffalo.edu
"Where's MY subculture?"
Neil K. Guy
>It is more like a virtual reality system than a text adventure.
>You are looking at a 3D line-drawn world on your computer screen.
>The world is made of basic geometrical objects ("geons"): "cubes" (though
>not necessarily all 3D the same), boxes, spheres, cylinders, pyramids, cones,
>sheets. Rooms are made by joining sheets together to form walls, floors,
>and ceilings, or by being boxes. Complex objects are made by gluing geons
>together.
Have you seen the graphic adventure game "The Colony" for the
Macintosh? It does basically that. You have 3-D realtime graphics -
wireframe or filled polygons, and you roam around endless white
hallways, using the mouse to navigate.
I think it's quite an impressive feat of programming. Response is
almost acceptable on a Mac Plus, and quite fluid on faster machines.
Interaction with objects is limited, however. You can just bump into
things, which makes you stop, makes the object vanish or trigger a
bitmapped 2-D representation of the thing (desk, etc.) that you've
touched.
It also tried to have a halfway intelligent plot and story along with
the usual boring "shoot the aliens" theme. I mean, it wasn't an
impossibly original plot - it wasn't meant to be, and there lots of
cute inside jokes with various sf books & movies - but it was fun.
Anyway, I don't know if it's still available. It was published by
Mindscape a while back. If you're interested in this sort of thing I'd
recommend having a look at it.
- Neil K.
Jorn Barger
>This is my vision of the next generation of adventure games:
>It is more like a virtual reality system than a text adventure.
>There should be other objects in the system. Liquids. Gas. Fire.
>I don't know how to deal with them. I suggest not having them in this
>initial model.
>Gone are command parsers.
> [...]
>THE BIG PROBLEM: PHYSICS
> [...]
>All this physical modelling will take lots of calculation.
>I think this could be a cool topic for my PhD dissertation,
>provided I emphasize VR and not IF. What do you think?
Phil, forgive me if I go off a little here... I feel like the Tom Hanks
character in "Big" looking at the building-that-changes-into-a-robot and
saying, "What's fun about this???"
WHERE'S THE GAME IF YOU'RE ALL ALONE???
I've developed a bit of a chip on my shoulder about VR-this and VR-that,
because PHYSICS IS NOT THE BIG PROBLEM. And lots of calculation is not
the solution.
(I know, you could have a certain amount of fun playing physics. But even
3-d physics will quickly start to feel 2d if there's no psychology!)
I think IF needs a new name that rolls off the tongue easier, and we need to
start a campaign to wake the public up to the special problems of "VR deep
structure" as they call it in Oz...
(nothin personal, really! ;^)
((I mean, it's true there are interesting problems to solve in VR, and
your ideas are fine, but ... where's the game? where's the *fiction*?))
Jorn
Tom O Breton
I like your model. It's quite specific.
I nitpick anything which I like, so please take the following as a
compliment:
> INTERACTIONS OCCUR AS A RESULT OF PHYSICAL PROPERTIES, NOT CODING
> Say you want to open a door with a key. [...]
I think you're discarding rather a lot of power there.
It seems to me that some important things are better modelled by
"magical" interactions that happen when surfaces come in contact than by
detailed physical modelling.(*)
In other words, when they come in contact they can invoke other
functions besides the usual each-bounces-off-the-other.
This opens up lots of possibilities, such as surfaces that have a high
effective momentum when pushed by some things and a lower one for
others. (The extreme is surfaces that can only be pushed by certain
things.) Or surfaces that some things can pass right through and others
can't.
For instance, a flame burning things. "Magical" surfaces do it almost
trivially - what it touches gets burned. I don't want to imagine what
complexity it would take to do it with physical modelling.
For another instance, to model different keys (Presumably you don't want
one key to open everything) physically you end up with unholy detailed
models from locksmithing books. Magically, you give both key and plate
an identity, command that the plate can only be moved by the correct
key, and you're done. (You can do it even simpler with magical surfaces
but you start to lose too much realism.)
> 1. What if you bounce a ball against a poster on
> the wall? The poster has little mass, so most of the momentum goes to the
> poster. The poster won't move, because the wall prevents it; the ball will
> drop directly to the ground instead of bouncing.
Poster and ball bounce. Poster and wall bounce. Poster and ball bounce.
Poster and wall and toaster and Paul bounce. Tweedle beetles battles in
a puddle in a bottle. (Oops. I Dr.Suessed out for a sec.)
So it looks like we'll need some rules to handle force transmission
without executing a large number of binary collisions.
The way I like best is to make objects act as part of other objects.
Give them a 3-D "envelope" of forces that might act on them. When
there's a collision, check if the force vector is inside that envelope.
If so, simply calculate it on the group as a whole. Otherwise, detach
them.(**)
We could give surfaces different "stickinesses" so that the poster would
becomes part of the wall despite gravity while other things just fell.
We could even build everything from little bricks with large envelopes,
so that things could break realistically without incurring a lot of
overhead.
> But I can think of no way of specifying that a metal block does not
> bounce if dropped onto a metal floor, yet will move away if you hit it
> with a metal bat.
Er, I don't see the problem. Elasticness just determines how much of the
collision force is lost (becomes heat, if you care to model that)
When more than 50% is lost, it won't bounce up.
Getting into the calculations, you add the resultant force of the
collision to the falling anvil's momentum; you find it is insufficient
to reverse the anvil's direction.
> B. Every object within a certain distance of you - any distance metric that
> is easy to compute -
I suggest that being out of sight is a criterion to emphasize.
> Object A "supports" object B if object A is in contact with B along the
> surface of B which is selected as the "bottom" at that timeslice.
> [...]
> So, if block B is 4 meters long, and 1 cm of it is over table T, T supports B.
> This is bad.
Hard to do without allowing rotation. If it can't rotate, how can it
fall off? Only by going through the table!
It doesn't seem that hard to add rotation to collisions/support. Here:
Looks like you're not modelling a centre of gravity. For binary support
or a binary collision (EG an object against the ground):
If both CoG's fall inside the region of contact (along a line parallel
to the direction of collision), you have a simple straight-on collision.
(Note that with my earlier multiple-objects-treated-as-a-whole
suggestion, simple binary collisions/support becomes more common and you
can get larger regions of contact.)
Otherwise you calculate the angular force (torque) around the CoG's.
Quick and dirty calculation:
Pretend they're connected, as if they were both on the rim of a wheel.
And that they're each exerting force of the collision on this wheel.
Remove the component of them that is pointing toward the hub of your
imaginary wheel - use that part as an ordinary straight-on collision.
The rest becomes angular momentum. (Draw it -- the remaining part of
the vectors are parallel to the "rim" in opposite directions)
You also have to know both objects' distribution of weight to know how
fast it rotates for a given angular momentum. For example, dumbells
won't rotate much for a given angular momentum, whereas a small wheel of
the same mass will go a lot faster. To simplify, you might give
everything the same angular mass.
> I think this could be a cool topic for my PhD dissertation,
> provided I emphasize VR and not IF. What do you think?
Go for it! }:) Care to send me a copy when you're done?
Tom
(*) You're welcome to use this idea in your dissertation if you like.
Please credit me if you do, since it is original (As far as I know).
(**) Ditto for this idea.
--
The Tom spreads its huge, scaly wings and soars into the wild sky...
(t...@world.std.com)
Mike Ayers
This is my vision of the next generation of adventure games:
To each its own.
It is more like a virtual reality system than a text adventure.
You are looking at a 3D line-drawn world on your computer screen.
The world is made of basic geometrical objects ("geons"): "cubes" (though
not necessarily all 3D the same), boxes, spheres, cylinders, pyramids, cones,
sheets. Rooms are made by joining sheets together to form walls, floors,
and ceilings, or by being boxes. Complex objects are made by gluing geons
together.
This is vector graphics - okay for action games (most notably the standups
made by Atari in the mid '80s) but nothing short of annoying from an aesthetic
standpoint.
There should be other objects in the system. Liquids. Gas. Fire.
I don't know how to deal with them. I suggest not having them in this
initial model.
Your limitations are beginning to exceed your abilities. So long as you
restrict your storyline and universe in such a way that these things would
not logically have a place, however, you could get along all right.
INTERACTIONS OCCUR AS A RESULT OF PHYSICAL PROPERTIES, NOT CODING
(stuff deleted)
THE BIG PROBLEM: PHYSICS
This is all a problem in object oriented design, really. Give each physical
element the properties it would have in reality. Code the interactions of
these properties, and watch 'em go.
I think this could be a cool topic for my PhD dissertation,
provided I emphasize VR and not IF. What do you think?
Why not? It's trendy enough (publish, publish!). I think you should think
it out a bit more thoroughly, though. It seems kind of silly to model solid
objects as surface collections when you want them to exhibit the properties
of solid objects. For instance - in case of fire break glass. You get two
choices as a coder - set up the pane of glass such that it models glass and
shatters under the appropriate stress level, thus creating many mini objects,
or jerry-rig it. A game coder would jerry-rig, of course, but that wouldn't
make for much of a dissertation. 8-}
It should be pointed out that such a system as an IF construction kit would
have a lot of value - the storywriter simply sets up the necessary objects
and lets the kit take care of interaction. It would add that degree of
freedom sorely lacking from the majority of IF.
My opins, anyway . . .
--
C: Unintelligible code means job security.
Phil Goetz
>In article <C3334...@acsu.buffalo.edu> go...@cs.buffalo.edu (Phil Goetz) writes:
>>This is my vision of the next generation of adventure games:
>
>character in "Big" looking at the building-that-changes-into-a-robot and
>saying, "What's fun about this???"
>
>WHERE'S THE GAME IF YOU'RE ALL ALONE???
>
>I've developed a bit of a chip on my shoulder about VR-this and VR-that,
>because PHYSICS IS NOT THE BIG PROBLEM. And lots of calculation is not
>the solution.
>
>your ideas are fine, but ... where's the game? where's the *fiction*?))
>
>Jorn
You evidently don't appreciate that, without an in-depth physics,
you will NEVER have interactive fiction, because you will be tied to
following a pre-set storyline. Deviations from a scripted plot are
caused not just by talking to people, but by _doing_ things that the
author has not anticipated. If you can't figure out the proper results
of those actions, you have no IF.
Phil
Kludge
Ok, here's what I'd suggest about handling physics: fake it. Today's
computers are simply not powerful enough to simulate the elaborate interactions
between objects that you're talking about, like a key in a lock. I'm not
saying skip the interactions, just look at them at a higher level - like a
whole key as opposed to the individual ridges/notches. You've got to
get to a good equilibrium between realism and speed/simplicity, or else the
player will get turned off. I'd say to err on the side of speed, but...
--Kludge
Peter Herweijer
>
>you will NEVER have interactive fiction, because you will be tied to
>following a pre-set storyline. Deviations from a scripted plot are
>caused not just by talking to people, but by _doing_ things that the
>author has not anticipated. If you can't figure out the proper results
>of those actions, you have no IF.
You're both right :-). First of all, it's of course impossible to have
anywhere near an accurate simulation of reality on today's CPUs. Nor is
this a problem: it is sufficient to have a workable _model_ of reality.
After all, this is also the way that 99% of the physicists work -- and
achieve amazing results with. The question is 'merely' what model to
take, the detail required, and what aspects to keep out of the model for
reasons of complexity. Furthermore, you will want a plot: a starting
point so that certain things come to happen through the model, some
kludges that make sure that certain things happen despite (the limitations
of) the model, and aspects of the simulation that exhibit more or less
predetermined behaviour (persons and animals being the most obvious
examples).
In a way, current RPG's are primitive examples of 'real' simulations.
They're for the most part utterly plotless. The programmer never has to
worry what happens when the SuperDuperTurboLaserSorcererWand is used on
the UtterlyDestructiveAndFearsomeApparitionFromTheSeventhPit; the program
is able to determine the result from the predetermined 'physics' and some
quantum fluctuations ;->.
Peter
Peter Weyhrauch
Hi, all.
I was watching "Homicide" on TV yesterday. Basically, the entire
story centered around an overnight interrogation of a murder suspect.
One room, one suspect, two policemen, some maps and photographs, and
lots of talk. If you were to build an interactive fiction on this
theme, you probably wouldn't need a physics more sophisticated than
Rooms, and Things. You are a thing that can be in the room, you can
hold things and look at them, but that's it. The story revolves not
around what you do physically, but around how you react to the
interrogation -- what you say, what you think, what they say, and how
you feel.
Unfortunately, it is probably beyond the current state of AI to do
this story well, since the policemen would have to be rather
sophisticated individuals.
My point is that this provides an example of where a detailed physical
model is not required for interactive fiction.
Now, if you ask me whether a detailed physics is desireable, then I
say "You bet" for two reasons. One, most stories do not seem to fall
into the above schema, but rather do rely on a physics. And two, in
interactive worlds people might feel the interactivity has been stolen
from them if they can't get up and move around and do most reasonable
things.
Peter Weyhrauch
Oz Project