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
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.
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
mushy mixing Y sticks to X Y sticks to X
rigid X splatters break if X nothing
flexible X splatters nothing nothing
How do you get to Carnegie Hall?
Practice, practice, practice. Or turn left at Columbus Circle.
>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
that can be allocated to objects at compile time, and
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?
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 | |
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.
I know I'm paranoid.
The question is, am I paranoid enough?
>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.
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).
> 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
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