Newsgroups: rec.arts.int-fiction
Path: gmd.de!jvnc.net!darwin.sura.net!zaphod.mps.ohio-state.edu!caen!uunet!mcsun!sun4nl!dutrun!dutiws!dutiag!appelo
From: appelo@dutiag.tudelft.nl (C.J. Appelo)
Subject: Re: Naive Physics
Message-ID: <appelo.723476373@dutiag>
Sender: news@dutiws.twi.tudelft.nl (news en nntp)
Organization: Delft University of Technology
References: <3150117@hpsemc.cup.hp.com>
Date: Fri, 4 Dec 1992 13:39:33 GMT
Lines: 108

dag@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.   |
| appelo@dutiag.twi.tudelft.nl   |                                |
===================================================================

