[MUD-Dev] Vast areas in muds

[Nathan Yospe]

On Mon, 19 Jan 1998, John G. wrote:

:Ling wondered:
:: [with regard to representing rather big areas in muds]

:: I've always wondered...  For a real 3d movement sort of
:: mud, imagine the player got shrunk into a 1 inch high 
:: stag beetle and gets transported to a desert.  Does this
:: mean the player will sit there watching a blank screen
:: as the character attempts to traverse a few thousand 
:: miles of desert or does the occassional message appear:

:One solution would be to change the game perspective.
:If your mud recognizes an area as 'vast' then the units of
:  distance per time and resources consumed per time
:  can be increased.
:Similar to the arcade fighting games that zoom out and
:  speed up the characters to encompass a wide screen,
:  but zoom in when the combatants near each other.
:Your message would then be: "and you pass many silly
:  and stupid things while traveling for what seems like an
:  eternity"... just make sure to take off more water, food,
:  movement resources, whatever you have.

And of course, as the guy that does _way_ too much of this,
I do have a bit to contribute. I may have given a bit of an
overview before on the ALMS component of Physmud++ (you can
tell someone's been working in the ... erm ... industry too
long when they come up with acronyms for everything.) ALMS,
the descendant of my earlier locations system, scales based
on active thread requirement. A deeper layer of locality is
now generated as the local layer becomes insufficient. This
allows threaded localities to be dynamicly allocated. There
was a bit of concern with concepts such as space-bourne and
massively scaled life forms. The Advanced Location Modeling 
system assumes threads are only needed in locations holding
player-controlled (or equivalent) characters. All "empties"
are batch-rendered by a handful of updater threads. This is
quite useful, as it results in a thread container number <=
2*(total players) + n, where n is the number of updater and
utility threads. The other advantage is this: a player with
the perspective of a flea gets the same amount of input, on
their scale, as a player in a whale. The detail may be more
generic, as details beyond the autogenerated ones will most
likely be added only on the "human" scale, but sand will be
large rocks to a sand-flea. Provided the builder really did
use sand to make the sand, of course. I like the thought of
a group of people walking on what they think is sand, but a
visually acute member of the party recognizing the material
as perfectly uniform cubes of some smooth material, of size
similar to grains of sand. (Of course, that would require a
template for the said material, which is a bit of work, and
sand is one of my predefined materials...)

The real challenge here is the recognition of the detail as
a generatable feature, and the control over how much detail
the computer has to process. I prefer to consider the world
as a featureless plain first, and then render the orders of
the "detail series" only as far as required. (Yes, there is
a bit of interpretation in the series model, but it is not,
considering, inaccurate. The actual physical calculation is
a genuine expansion, with switches for faster/better models
of the situation. Collision detection, thermodynamic paths,
and fluid flow/gas diffusion all use the same type of large
to small modeling.
--

"You? We can't take you," said the Dean, glaring at the Librarian.
"You don't know a thing about guerilla warfare." - Reaper Man,
Nathan F. Yospe  Registered Looney                   by Terry Pratchett
yospe at hawaii.edu   http://www2.hawaii.edu/~yospe           Meow