Naive Physics

15 views
Skip to first unread message

David A Graves

unread,
Nov 30, 1992, 5:46:57 PM11/30/92
to
In his posting "Naive Physics," Phil Goetz asked the question "Can these
classes, or ones like them, be used for objects in the adventure world to
simplify interactions between objects?"

I'd say yes, they can. I make extensive use of classes of general physical
characteristics to define the physics of object interaction in my IF software.
For example, here are a few of the classes I use:

container ! stuff can go inside
surface ! stuff can go on top
openable ! can be opened
lockable ! can be locked
flammable ! can burn
fluid ! is a fluid
solid ! is a solid
edible ! is edible
transparent ! can see through
airtight ! won't leak water or air
wearable ! can be worn (garment, jewelry, tools)
binding ! can be bound (rope, chain)
fixed ! can't be moved
above ! overhead
below ! a floor or sunken bathtub
high ! out of reach
distant ! impossibly far: objects on horizon, in sky.

Note that multiple inheritance is necessary, because most objects will need
to inherit physics rules from more than one of the classes listed above.

Thus, whiskey is an "flammable edible liquid", and a bottle is an "airtight
transparent container".

I see the examples in Phi's posting as a natural extension of the
classifications above. That is, one could easily integrate the physics of
rigid/flexible, flat, thin/thick, and powder.

Phil Goetz

unread,
Dec 1, 1992, 1:44:53 PM12/1/92
to
In article <315...@hpsemc.cup.hp.com> d...@hpsemc.cup.hp.com (David A Graves) writes:
>...

> container ! stuff can go inside
> surface ! stuff can go on top
> openable ! can be opened
> lockable ! can be locked
> flammable ! can burn
> fluid ! is a fluid
> solid ! is a solid
> edible ! is edible
> transparent ! can see through
> airtight ! won't leak water or air
> wearable ! can be worn (garment, jewelry, tools)
> binding ! can be bound (rope, chain)
> fixed ! can't be moved
> above ! overhead
> below ! a floor or sunken bathtub
> high ! out of reach
> distant ! impossibly far: objects on horizon, in sky.
>
>Note that multiple inheritance is necessary, because most objects will need
>to inherit physics rules from more than one of the classes listed above.

I think the need for properties like the above are indisputable.
I hadn't thought of rigid/flexible etc. as properties in the same way,
though they really are. I was thinking specifically of properties
that are relevant for gross interactions, e.g. when objects hit each other
or are sent flying through the air. With disjoint classes, I could draw a set
of 2D charts like this:

RESULT OF STRIKING X WITH Y

X: mushy rigid flexible
Y
____
mushy mixing Y sticks to X Y sticks to X

rigid X splatters break if X nothing
is fragile
flexible X splatters nothing nothing

Phil
go...@cs.buffalo.edu
--
How do you get to Carnegie Hall?
Practice, practice, practice. Or turn left at Columbus Circle.

C.J. Appelo

unread,
Dec 4, 1992, 8:39:33 AM12/4/92
to
d...@hpsemc.cup.hp.com (David A Graves) writes:

>In his posting "Naive Physics," Phil Goetz asked the question "Can these
>classes, or ones like them, be used for objects in the adventure world to
>simplify interactions between objects?"

>I'd say yes, they can. I make extensive use of classes of general physical
>characteristics to define the physics of object interaction in my IF software.
>For example, here are a few of the classes I use:

> container ! stuff can go inside
> surface ! stuff can go on top
> openable ! can be opened
> lockable ! can be locked
> flammable ! can burn
> fluid ! is a fluid
> solid ! is a solid
> edible ! is edible
> transparent ! can see through
> airtight ! won't leak water or air
> wearable ! can be worn (garment, jewelry, tools)
> binding ! can be bound (rope, chain)
> fixed ! can't be moved
> above ! overhead
> below ! a floor or sunken bathtub
> high ! out of reach
> distant ! impossibly far: objects on horizon, in sky.

I am thinking a lot about classes and relations between them lately.
These classes will, of course, help you a lot making an adventure game.
But I do think they need revision. (sorry)

Objects cannot, I think, be solid and fluid at the same time. Since
I do miss the class "gas", I would propose a property called
PhysicalState (or whatever) with 3 possible values: solid/fluid/gas.
ALL objects MUST have this property with one of the three values.
Introducing separate classes, like mentioned above, can introduce
objects without such a physical state or even with two or three ones.

"container" and "surface" introduce relationships with other objects
(being IN or ON this object). "lockable" introduces relationships
with only some kinds of objects (keys). "flammable" introduces no
relationships, I believe. This is no correction to the above mentioned
classes, but it implies carefully examining the subtle differences
between these classes.

I don't think I would introduce a class "airtight". Some may recall
my proposal for properties of the relations between objects. Some of
these properties can be the amount of air/water/sound/radiation let
through over the link specified by the relation. So placing a book
on an open bottle creates a relation with properties. One of these
can specify how much air can still go into the bottle.

Also I wouldn't create the classes "above" and "below" I think.
Cealings and floors are connected to rooms via the relation PartOf or
NextTo. With properties like Position you can specify that a ceiling
is above an actor.

I hope David won't mind tearing down his classes (just a bit though).
Needless to say that my proposals introduce a much more complex
system, but it could create very enjoyable situations. Like lowering
ceilings and spreading gasses.

Last night I came up with another idea: It seemed to me that some
properties like Position, PhysicalState and Description are always
necessary for objects. They cannot be added or deleted during the
game, for this would create impossible states. On the other hand,
properties like Flammable, Edible and Fixed are very suitable to
be changed during a game. (Pizza's are edible, unless you
leave them lying around for too long.) For this reason I would
like to introduce

STATIC PROPERTIES

that can be allocated to objects at compile time, and

DYNAMIC PROPERTIES

that can be added and deleted at run-time.

The static properties can be implemented by data-fields (or
pointers to data-fields) in the classes and they can be inherited
by subclasses. The dynamic properties can be implemented using
pointers that can be added to and removed from sets of properties
at run-time. (Much like prototypes in some OO-languages.) For some
reason the dynamic properties seem to be all booleans. But I think
someone can come up with examples of other types.

Any reactions to some of the above?

Jurgen.

p.s. I don't claim that my proposals are perfect either.

p.p.s. OASYS IS _NOT_ OBJECT-ORIENTED!
It supports no inheritance, no polymorphism, no delegation,
no prototypes, no encapsulation, nothing actually.
It only calls it's procedures 'methods' and it calles it's
types 'classes'. That's no reason for being called object-
oriented in my opinion.

===================================================================
| Jurgen Appelo | |
| Delft University of Technology | When Technology Is Master, |
| The Netherlands | You Reach Disaster Faster. |
| app...@dutiag.twi.tudelft.nl | |
===================================================================

Phil Goetz

unread,
Dec 4, 1992, 2:31:31 PM12/4/92
to
>Last night I came up with another idea: It seemed to me that some
>properties like Position, PhysicalState and Description are always
>necessary for objects. They cannot be added or deleted during the
>game, for this would create impossible states. On the other hand,
>properties like Flammable, Edible and Fixed are very suitable to
>be changed during a game. (Pizza's are edible, unless you
>leave them lying around for too long.) For this reason I would
>like to introduce
>
> STATIC PROPERTIES
>
>that can be allocated to objects at compile time, and
>
> DYNAMIC PROPERTIES
>
>that can be added and deleted at run-time.
>
>The static properties can be implemented by data-fields (or
>pointers to data-fields) in the classes and they can be inherited
>by subclasses. The dynamic properties can be implemented using
>pointers that can be added to and removed from sets of properties
>at run-time. (Much like prototypes in some OO-languages.) For some
>reason the dynamic properties seem to be all booleans. But I think
>someone can come up with examples of other types.
>
>Jurgen.

I think your distinction is useful, but don't call them "static"
vs. "dynamic", because the "static" properties can change.
Obviously position changes. Physical state can change, e.g. a block
of ice melts. Size can change (e.g. a hunk of cheese which you
cut pieces off of).

When an object inherits the value of one of these "static" properties,
it should only be a default inheritance, and allowed to be
overruled or to be changed later.

Phil
go...@cs.buffalo.edu
--
I know I'm paranoid.
The question is, am I paranoid enough?

C.J. Appelo

unread,
Dec 7, 1992, 6:13:17 AM12/7/92
to
go...@acsu.buffalo.edu (Phil Goetz) writes:

>I think your distinction is useful, but don't call them "static"
>vs. "dynamic", because the "static" properties can change.
>Obviously position changes. Physical state can change, e.g. a block
>of ice melts. Size can change (e.g. a hunk of cheese which you
>cut pieces off of).

>When an object inherits the value of one of these "static" properties,
>it should only be a default inheritance, and allowed to be
>overruled or to be changed later.

>Phil

I can understand the word "static" is somewhat misleading. Whatever we
call them, it's just important to note that HAVING the property
Position or PhysicalState will NOT change. The values in it will change
of course, but not the fact that they are present. This is different from
the Edible boolean, for example. An object can become edible during the
game, which can introduce the property Taste, with values like sweet, salt
etcetera. So, Position is static (changeable but not removable) and Taste
is dynamic (changeable and removable).

Jurgen.

Whi...@fwva.saic.com

unread,
Dec 7, 1992, 1:00:26 PM12/7/92
to
app...@dutiag.tudelft.nl (C.J. Appelo) writes:
>go...@acsu.buffalo.edu (Phil Goetz) writes:
>
>>I think your distinction is useful, but don't call them "static"
>>vs. "dynamic", because the "static" properties can change.
>>Obviously position changes. Physical state can change, e.g. a block
>>of ice melts. Size can change (e.g. a hunk of cheese which you
>>cut pieces off of).
>
>>When an object inherits the value of one of these "static" properties,
>>it should only be a default inheritance, and allowed to be
>>overruled or to be changed later.
>
>>Phil
>
>I can understand the word "static" is somewhat misleading. Whatever we
>call them, it's just important to note that HAVING the property
>Position or PhysicalState will NOT change. The values in it will change
>of course, but not the fact that they are present. This is different from
>the Edible boolean, for example. An object can become edible during the
>game, which can introduce the property Taste, with values like sweet, salt
>etcetera. So, Position is static (changeable but not removable) and Taste
>is dynamic (changeable and removable).
>
>Jurgen.


How about calling them:
Inherent -- having attribute does not change, value may.
Acquired -- having attribute can change, as well as value.

Is there some other kind of attribute that is 'sticky', ie: you don't have
the attribute originally, but once you do something, you get the attribute
and can't lose it after that point?

The attribute I am thinking of is kind of like 'adultness'. Once you are
older than a certain age, you get it, but you don't start out having it.
(or maybe 'vampire-ness??)

Mind Teaser:
What is the Physical State of a ghost?

Dave (whi...@fwva.saic.com) US:(619)535-7764 [I don't speak as a company rep.]

David A Graves

unread,
Dec 7, 1992, 2:05:57 PM12/7/92
to
First of all, I'd like to point out that my posting mentioned that "here are
a few of the classes I use". The listing was meant to be an example, not an
exaustive list. Anyway, no offense taken.

Jurgen writes:

> I do miss the class "gas", I would propose a property called
> PhysicalState (or whatever) with 3 possible values: solid/fluid/gas.

IMHO, it comes down to a matter of judgement, not physics. You have to decide
how slavishly you will model the world. Note that Phil Goetz's original
posting was on "Naive Physics". This is right on the mark! You want a
*minimal* set of laws which will still meet all the needs of your work of
fiction. Over several IF projects, I have not yet had the need to represent
gasses. Of course, I support your right to do so, if you wish to. :-)

> "container" and "surface" introduce relationships with other objects
> (being IN or ON this object). "lockable" introduces relationships
> with only some kinds of objects (keys). "flammable" introduces no
> relationships, I believe. This is no correction to the above mentioned
> classes, but it implies carefully examining the subtle differences
> between these classes.

Right. Every time you define an attribute/class/property, you have to ensure
that your set of rules is still consistent, or else decide that you are not
willing to go any deeper into your model of physics. As you have pointed out,
several attributes imply others. For example, since containers and surfaces
can support other objects, the concept of volume is suggested. How big is the
container? How big is the stuff going into it? Is the stuff oddly shaped?
(A broom has less volume than a backpack, but it won't fit inside with the
zipper zipped up).

By the way, "flammable" does imply more attributes, in my system: "burning"
(being consumed as time goes by) and "radiant" (providing light).

> I don't think I would introduce a class "airtight". Some may recall
> my proposal for properties of the relations between objects. Some of
> these properties can be the amount of air/water/sound/radiation let
> through over the link specified by the relation. So placing a book
> on an open bottle creates a relation with properties. One of these
> can specify how much air can still go into the bottle.

I see how your design removes the need for an "airtight" attribute. I don't
plan to go that deep into physics modeling, so airtight covers a good many
needs that way for me. Liquids stay in bottles but leak out of baskets, etc.

> Also I wouldn't create the classes "above" and "below" I think.
> Cealings and floors are connected to rooms via the relation PartOf or
> NextTo. With properties like Position you can specify that a ceiling
> is above an actor.

I find "above" and "below" very handy for defining objects attached to walls,
trap doors, etc. I agree that a set of "position" (x,y,z) properties would
cover this need, but I think thats a lot of work for Interactive Fiction.

** You can spend so much time on your model of physics that you never get **
** around to writing any Interactive Fiction! Take care! **

On static and dynamic properties: yes, certainly need to be able to change
the attributes of an object at runtime. As Phil Goetz pointed out, some of
the things we might think of as static should really be treated as dynamic.
(Consider magic: most magic is just altering attributes that most people
consider to be static).

For the sake of being brief in my posting, I had not included examples
of altering attributes, but since you mention it, here are a *few* of my
dynamic attributes:

opened/closed
locked/unlocked
lit/unlit
radiant/unradiant
fastened/unfastened
dead/alive
awake/sleeping
reclining/standing

Note that frequently the presence of an attribute implies another. For
example, a lit object is radiant, until it is extinguished. Removing the
"lit" attribute also requires removing the "radiant" attribute. On the
other hand, a glowing orb would be radiant all the time, without being lit.

Also the use of an attribute almost always has prerequisites. For an object
to be "fastened" it first must be "fastenable". (Ropes and chains, for
example, would have the fastenable attribute). The thing that it is to be
fastened to must have an appropriate attribute as well. The verb routines
(such as "fasten") would check for the presence of all the appropriate
attributes, then do the state change.

We would never be able to come up with a set of classes, properties, and
verbs that everyone agrees upon because there are so many point of view
(and differences in taste) over how Interactive Fiction could or should
be created. However, discussions like this *do* help us clarify our
thinking and enable each of us to improve upon our own systems of rules
and attributes.

Reply all
Reply to author
Forward
0 new messages