[MUD-Dev] Virtual machine design

[Nathan F Yospe]

On Mon, 19 Apr 1999, Ola Fosheim [iso-8859-1] Gr=F8stad wrote:

:Chris Gray wrote:
:> of. Go examine the world of supercomputing and parallel processing (my
:> day job is more in that area) - as new power becomes available, new type=
s
:> of more accurate simulations become possible, and they are more valuable
:> than the less accurate ones. The chemists, physicists, biologists, etc.
:> who use the massive computer power always need more for the next step
:> in their work. It is this kind of demand increase that I'm talking about=
=2E

:Well, ok, maybe, not sure if one should believe people using Fortran, but
:hey I could be wrong :-) (I'm not going to rule out laziness or prestige,
:but that's OT)

Fortran remains unparalleled in performance on MPP complexes for physical
simulation. Many of us use C++ instead anyway. Watch out for stereotypes.

:Anyway, that does not apply to MUDs. In research on the "laws of nature" y=
ou
:want as much accuracy as you can get. It can even be fatal if you are off =
by
:some small factor and you have something fixed to compare your results to!=
=20

True, and this is a major point... except that the detail of these extreme
precision simulations is far less than that of a good mud. That's because,
in the simulation, you've elliminated everything but the elements you need
to simulate.

:A MUD is in nature much more like Computer Graphics. You don't care about
:whether it is real or not, you only care about how it is perceived. Some g=
o
:for "photorealism" (which computationally can be quite unreal), others for
:"believable", yet others go for "interesting".  Basically, you cheat as mu=
ch
:as you can get away with, you sacrifice efficiency for flexibility only in
:areas where you need to be flexible.=20

No... I strongly disagree. You go the other way as much as possible. There
is a *much* higher need for flexibility in a mud than there is in physical
simulation, and a *much*, *much* lower need for efficiency. Mainly for the
reasons you stated above. We need to *look* right, not be spot on...

:If it looks right, then it is right!

Only if it still looks right when the player tries to look behind the bush
over there. If it has a 2x4 proping it up from behind, everything comes to
pieces.

:This is art, not science 8-)

Heh.

:> Noted. Note also, however that discrete event simulation is one of the
:> most compute intensive areas around, and it is used a lot, in order to
:> simulate complex systems where no general rules for overall behaviour
:> are known. Often, the system is such that it is believed that no overall
:> rules *can* exist, because of the chaotic nature of the system.

:Hmm.. In a MUD I would vote for laziness and development costs, because WE
:invent the rules!  The main advantage of a fullblown simulation over an
:optimized model is that it is easy to change and possibly easier to
:maintain.  The optimized model takes more brain work, or if you like: a lo=
t
:of discrete simulations to arrive at... The real problem is in identifying
:strategies which are both efficient, flexible and easy to implement. *sigh=
*
:I'm not saying it is trivial.

Exactly.

:Main points:=20

:o I think we can do a lot better, but the solution might not be obvious.
:o Existing explicit simulation approaches may make us blind.
:o We DO in fact have a LOT of freedom, because we model a hypothesis
:  (about user behaviour) and a fantasy.
:o "Nothing" is impossible in a fantasy, but we have to look for the right
:  incarnation.

Heck, even __I__ do something far more fakery than discreet simulation.
A lot can be done with statistics... (and that's all the hint I'm going
to give at the moment.)
--=20

Nathan F. Yospe - Born in the year of the tiger, riding it forever after
University of Hawaii at Manoa, Dept of Physics, second year senior (joy)
(On Call) Associate Algorithm Developer, Textron Systems Corp, Maui Ops.
yospe#hawaii.edu http://www2.hawaii.edu/~yospe Non commercial email only



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev