[MUD-Dev] Virtual machine design
Chris Gray
cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Apr 18 16:55:39 CEST 1999
[Ola Fosheim:]
>Well, I think the problem is that the more power you get, the more flexible
>or bloated or badly designed code will be written. When programmers wrote
>in assembly code in very limited space, skipping the design faze was not an
>option...
That certainly happens. Up until now (I'm guessing), I think the problems
have mostly been in servers. We're only just getting to the point where
the behaviors coded using in-MUD languages have any algorithms to speak
of. Go examine the world of supercomputing and parallel processing (my
day job is more in that area) - as new power becomes available, new types
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.
>I don't agree here either. I don't think the problem is in accurately
>simulating economies or ecologies (unless you talk about meta-evolution).
>The trouble is that it isn't fun nor fair from a gamer's point of view.
The goals of a simulation are not the same as the methods of the simulation.
For some goals, the more accurate the simulation is the better the result.
If you design your economy/ecology using some simple rules, then you don't
need a complex simulation for it. However, if you decide that you don't
know a set of rules for it, but that you do know the behaviour of the
individual elements that you want to model, then a full-fledged simulation
may be the only way to go. The issue of whether or not that makes for a
good game is a separate issue. No less important, but still separate.
>200 MIPS/2000 = 10000 instructions per second per mobile. That's a lot! Are
>you slowing down the refreshrate for mobiles which players does not interact
>with? Have you considered updating mobiles of the same class in batches for
>optimal speed? Have you considered using bit-wise calculations? etc..
Your suggestions are noted, but I don't think they are relevant. The
machines I test with interact with each other, with player characters, and
with other simpler machines on an ongoing basis. They fight, they pick
things up and drop them, they move around. They each trigger at about
1-3 second intervals. A machine entering a location can in turn trigger
actions by other machines in that location, and cascades can result. The
total code for them is likely a couple thousand lines of MUD language code.
I'm not at all embarassed by their speed of execution. Oh yes, all of this
is on top of a disk-based database.
>Basically, there is a lot you can do to optimize your system, if you just
>know where to look and have insight into several scientific/programming
>fields from which you can collect ideas. Knowledge transfer is perhaps the
>most effective form of invention?
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.
--
Don't design inefficiency in - it'll happen in the implementation.
Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
http://www.GraySage.Edmonton.AB.CA/cg/
_______________________________________________
MUD-Dev maillist - MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list