Physics
Jamieson Norrish
want nothing whatsoever to do with MUDs.]
One of the areas of MU*s which I feel is sadly insubstantial is in the
area of physics - the interaction of object with object. Such things
as dealing with fluids, object relationships (on, in, behind, under,
etc), temperature, and the like come under this title.
My question is this: what physical systems have people developed (not
just specifically for MU*s)? What level of detail/abstraction is
do people think is appropriate in different types of MU*s?
I would rather that replies to this were posted, rather than emailed -
I think physics is almost unknown in many MU*s, and that a discussion
of this subject is long overdue.
Jamie
Brandon Vanevery
>area of physics - the interaction of object with object. Such things
>as dealing with fluids, object relationships (on, in, behind, under,
>etc), temperature, and the like come under this title.
>
>My question is this: what physical systems have people developed (not
>just specifically for MU*s)? What level of detail/abstraction is
>do people think is appropriate in different types of MU*s?
I am attempting to develop a physics for a 3d spatial database driven MUD.
It has to be "game pseudo-physics" - there is not enough game computing
resource to engage in demanding calculations.
At a minimum, a game physics system needs to support:
(1) impenetrability of object boundaries - if things simply slide
past each other, it's not a mechanical physics.
(2) collision action/reaction - otherwise, the game components
are not physically interrelated.
(3) continuous contact between surfaces - this is more of a
computational demand. If you can't represent it, how are you
going to get a lobster to walk along a floor efficiently?
I'm working on the basic spatial database. So far I have NO IDEA how to
implement any of these, other than they must be "cheap."
Brandon
--
The opinions expressed are not necessarily those of the University of
North Carolina at Chapel Hill, the Campus Office for Information
Technology, or the Experimental Bulletin Board Service.
internet: laUNChpad.unc.edu or 152.2.22.80
Stephen White
(Jamieson Norrish) writes:
> One of the areas of MU*s which I feel is sadly insubstantial is in the
> area of physics - the interaction of object with object. Such things
> as dealing with fluids, object relationships (on, in, behind, under,
> etc), temperature, and the like come under this title.
part of the problem is the way most MUD servers treat objects.
*especially* object-oriented MUD servers (so i'm also to blame here).
when two objects interact, you have to figure out how to negotiate
between them. on most MUD systems, a function on one of the objects
is going to have to get called (or a function on a parent). that
means one or the other object is going to have to take
responsibility for the result.
when i put on a pair of sunglasses, cutting out the amount of light
that reaches my eyes isn't inherent in the sunglasses, or in me.
without them, i don't have that ability. without me, the sunglasses
don't do much either.
when i hit a bat with a ball, the fact that the ball goes sailing
off into the distance isn't due to some property of the bat, or
of the ball. it's the *relationship* between them that triggers
the result.
ideally, it would be nice to specify a way for objects to negotiate
such relationships with each other -- "i know how to wear, do you
know how to be worn?" currently, few MUD's allow this, since either
one or the other object is going to get processed first, and take
control. i attempted a bit of the above negotiation in my servers
with the object movement protocol: when you want an object to move,
you ask it to move. if it decides you're worthy, it asks the
destination room to "accept" it. if it's accepted, it removes
itself from the old room and updates its location pointer. (it's a
bit more general than this, in that this negotiation happens when
entering all objects, not just rooms).
however, even if you manage to get this to work, only those objects
which have been explicitly flagged to handle those cases are going
to act in an interesting manner.
another problem with this approach is that you may end up with
a top-heavy class hierarchy: in order to deal with all the default
properties for objects which don't specialize explicitly, you have
to jam a zillion methods onto the root classes. and mostly what
you'll end up with is "you can't hit that", instead of something
meaningful.
on the other hand, if you establish right off the bat what properties
are allowed (either by strict design or by hardcoding them in the
server), you can force each new object to be evaluated in those
terms and expressed such that it acts "predictably" when you attempt
to do something "beyond the norm" (like putting the round peg in the
square hole).
it seems that we want to express relationships between objects,
instead of attaching the responsibility to one or the other object.
maybe a tuple space MUD isn't totally far out.
-- sfw
LindaMUD LindaMUD LindaMUD..
--
Stephen F. White
sfw...@sciborg.uwaterloo.ca
"I don't even know what reality is." - David Lynch
Jay A. Carlson
ideally, it would be nice to specify a way for objects to negotiate
such relationships with each other -- "i know how to wear, do you
know how to be worn?" currently, few MUD's allow this, since either
one or the other object is going to get processed first, and take
control.
This is an active area research in object oriented systems in general,
since this situation tends to come up a lot when modeling the real
world.
Lisp-like systems have dealt this with something called `generic
functions'. The idea is you have a generic function like `multiply',
with two arguments. Then you add methods for multiplying an integer by
a float, an integer by an integer, a matrix by a number in general,
etc, to the generic function.
This allows you to specialize a method dispatch on the type of more
than just one object.
Anyway, just wanted to point you at some sources; this is also refered
to as `multimethods', and some systems this is used in are Dylan and
CLOS, and I think in one or two Scheme object systems. I just read a
paper on a language called Cecil that integrates this with a
message-passing model---quite interesting.
another problem with this approach is that you may end up with
a top-heavy class hierarchy: in order to deal with all the default
properties for objects which don't specialize explicitly, you have
to jam a zillion methods onto the root classes. and mostly what
you'll end up with is "you can't hit that", instead of something
meaningful.
Mixin-style programming may be useful here too, but I think this is
what yr talking about. We were also talking about formalizing
protocols on JaysHouseMOO, but eventually gave up on this, cos it was
hard.
it seems that we want to express relationships between objects,
instead of attaching the responsibility to one or the other object.
maybe a tuple space MUD isn't totally far out.
Heh.
--
Jay Carlson
n...@theory.cs.mankato.msus.edu
Flat text is just *never* what you want. ---stephen p spackman
Stephen White
n...@theory.cs.mankato.msus.edu writes:
[ i wrote: ]
> ideally, it would be nice to specify a way for objects to negotiate
> such relationships with each other -- "i know how to wear, do you
> know how to be worn?" currently, few MUD's allow this, since either
> one or the other object is going to get processed first, and take
> control.
> This is an active area research in object oriented systems in general,
> since this situation tends to come up a lot when modeling the real
> world.
> [ interesting text about LISP solutions and multimethods deleted ]
> I just read a
> paper on a language called Cecil that integrates this with a
> message-passing model---quite interesting.
felix gallo pointed out to me in email that a Prolog-style
rule-based system has possibilities as well. in a system
with strong physics (even if those physics are non-standard),
the rules should be enforced VR-wide, or "realm"-wide if you
like.
combining this with an object oriented-approach for object
specialization would be interesting. express the fundamental
physics, etc as Prolog-style rules, then allow objects to specialize
as desired within those rules. there was some discussion
recently on comp.object about rule-based OO systems, although
i didn't read it all.
if you want a more free system, with "physics when you want
it" or "physics when it's fun" :) you could simply inherit
the rules from a parent class. of course, you'd need an equivalent
of the "protected" data class in C++, which is missing in the MUD's
i've written. without it, objects could avoid "playing fair" by
twiddling their internal physics data without following the rules,
and still appear to be children of the parent class.
-- sfw
Jay A. Carlson
hell, I'm lazy.)
In article <C5prw...@watserv2.uwaterloo.ca> sfw...@sciborg.uwaterloo.ca (Stephen White) writes:
In article <NOP.93Ap...@theory.Mankato.MSUS.EDU>
n...@theory.cs.mankato.msus.edu writes:
[ i wrote: ]
> ideally, it would be nice to specify a way for objects to negotiate
> such relationships with each other -- "i know how to wear, do you
> know how to be worn?" currently, few MUD's allow this, since either
> one or the other object is going to get processed first, and take
> control.
> This is an active area research in object oriented systems in general,
> since this situation tends to come up a lot when modeling the real
> world.
> [ interesting text about LISP solutions and multimethods deleted ]
felix gallo pointed out to me in email that a Prolog-style
rule-based system has possibilities as well. in a system
with strong physics (even if those physics are non-standard),
the rules should be enforced VR-wide, or "realm"-wide if you
like.
This problem comes up a lot. Here's my favorite example:
On LambdaMOO, :isa used to be defined on the root class, since it
seemed all nice and OO. yduJ built a shield on herself that made
herself immune to being splatted with food. Grump then made some food
that overrode :isa and claimed it wasn't food. :isa was rapidly moved
onto $object_utils. :-)
combining this with an object oriented-approach for object
specialization would be interesting. express the fundamental
physics, etc as Prolog-style rules, then allow objects to specialize
as desired within those rules. there was some discussion
recently on comp.object about rule-based OO systems, although
i didn't read it all.
JoeFeedback and I discussed this kind of thing in the context of
generic functions. If you think about it, generic functions are where
a particular protocol is defined. If you give generic functions
ownership and authority checking, a lot of these kinds of problems
are solved.
For example, in strong movement physics, the `move' generic function
would be wizard-owned, and normal players would not be allowed to add
methods to it. The problems with `isa' and other reflective
operations that must be secure are fixed nicely with this too---just
add methods for the root class, and don't let anyone mess with 'em.
I haven't considered how this would work in a message-passing
multimethod model.
Incidentally, Prolog as a language for MUDs was discussed a while back
on the MultiPlayer Interactive Fiction mailing list. The general
consensus was that Prolog had big problems with objects with varying
states---eg, location. I really don't remember this in detail. Doug,
is there an archive of MPIF anywhere?
if you want a more free system, with "physics when you want
it" or "physics when it's fun" :) you could simply inherit
the rules from a parent class. of course, you'd need an equivalent
of the "protected" data class in C++, which is missing in the MUD's
i've written. without it, objects could avoid "playing fair" by
twiddling their internal physics data without following the rules,
and still appear to be children of the parent class.
Well, this is a worry only in MUDs where you don't trust all your
programmers. I mean, you can just @toad people who break the rules,
but it seems like you're sticking your head in the sand....