[MUD-Dev] Distributed PSW design

John Buehler johnbue at msn.com
Sun Jan 21 13:21:14 CET 2001


> Eli Stevens

> While I agree that fractal generation is the way to go to create the
> world, a caveat to making the client use the same technique is that
> computationally intensive post-processing cannot be done on the
> resulting terrain.  Things like erosion, continental drift, etc. are
> all ruled out (from what I have heard, simulating erosion is very
> slow).  It also means that as time passes and more and more players
> leave footsteps, craters and foxholes, the terrain delta map will
> become increasingly complex, eventually negating any benefit when it
> becomes as complex as the original landscape (unless the terrain
> "heals" itself over time, but that is not persistent enough for my
> taste :).

Of the top of my head, I'd rely on the fact that not all information
needs to be presented to the player, so not all information needs to
be transmitted to the client.  As an extreme example, consider the
blind character.  Not fun for a player, but the client display should
permit the player to manage the world by virtue of auditory and
sensory cues.  So no color information or detail needs to be sent to
the client.  Unless the blind character actually steps onto something,
touches it or hears some cue of its existence, nothing will be
displayed to the client - to the player.

A less extreme case is that of the ranger versus the warrior.  My use
of the terms is not intended to suggest classes, only general ways of
playing the game.  The ranger walks along and sees tracks in the
ground.  The warrior walks along and does not.  That's because his
senses are not geared to perceiving such things.  This limited
perception model is a natural means of culling information to be sent
to the client.  Obviously, things like craters are going to be sensed
by essentially all characters, so they would always have to be
transmitted as an 'exception' to the normal terrain.

Someone who understands wilderness vegetation may see patches of one
color or another in the vegetation, while someone who is ignorant of
(unskilled in) wilderness lore will see the wilderness in simpler
terms.

Contrarily, when the warrior sees a combat situation, he can make
appraisals and perceive things that those unskilled in combat will not
see.  This is a significant means of ensuring that character skill is
dominant over player skills.  The player skills are limited to
decision-making by using the information obtained by the character's
perceptions.

Such a scheme requires significant server-side processing in order to
cull down all the data that has accumulated.  I believe that this can
be done through distributed processing and storage.  The organization
of that distribution would be skill-based.  Each skill would be an
almost completely self-contained cross section of processing and data.
Generic processing tasks such as relative position detection and
things like that would be handled by separate machines which use high
bandwidth connections in order to let other the various skill machines
get the data that they need.

> If bandwidth becomes a problem, maybe something like sending an
> interlaced .gif for the heightmap and then refining it over time
> would work.  Not that I am suggesting .gif in particular, just
> something along the same very general lines.

Why would that be more efficient than sending most of that heightmap
as a fractal and sending exceptions using the bitmap mechanism?

>>> The factral program can be found at:

> When I tried to run these, they bombed out within the first few
> seconds.  "The instruction at '0x0040e5f4' referenced memory at
> '0x00000000'.  The memory could not be 'read'."  Somewhere in there,
> it looks like a NULL is slipping through the cracks.  Both programs
> give me the same error when I run them back to back...  I am running
> a well-service-pack'ed Win2k box with about 70 MB or so of physical
> RAM free ATM.  Anyone else have any problems?

The code is hardly what I would consider production quality.  It's
just a quick hack, but I'm surprised that it would crash for you on a
Windows 2000 box, as I'm running the same OS.  You need DirectX 7.0a
or better.  At least, that's the versions I've been running.

Something may be trying to run in software for rendering on your
machine.  I'm using an NVIDIA GEForce2 Pro.

> Does the entire world depend on one seed, or can you seed patches of
> the planet individually?  The program that I am working ATM leaves
> everything as flat seabed, unless I specifically fill a patch with
> height values.  If I like, I can have continents span multiple
> patches, or just one, and they all (should) blend together
> seamlessly.  I say should because the current incarnation of the
> program is not functional ATM, but I should have something
> presentable in a few days (unless, of course, I decide to rewrite
> the durn thing for the umpteenth time).  :) then, of course, I have
> to re-tool the viewer, but I have enough directX examples and
> previous work that it should be fairly painless.

You quoted both me and JC, but I'll answer for my software.  The
entire world is currently predicated on a single seed, but there are
scads of individual controls permitted.  I used random application of
those controls simply because it produces interesting results without
having to come up with a means of applying them manually (i.e a user
interface).

JB


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list