[MUD-Dev] DEV: Peer-to-Peer MUD

Justin Rogers justin at mlstoday.com
Thu Oct 4 10:07:50 New Zealand Daylight Time 2001


[Phillip]

> I may have brought this up before, but has there ever been any
> development of a peer-to-peer graphical MUD.  I theorized and
> began some development of this some time ago, but ran out of
> energy/time/whatever. The premis is that rather than having one
> server holding a large map created by a single person, you have
> many small maps being held in many small clients. As you walk
> around the seemingly large, contigous, map, you are actually
> crossing between servers(clients really).  I believe Ultima does
> this with some success on a multi-server system.

Well, maybe you're looking in the wrong places.  The concept of a
MUD is fairly loose and doesn't just pertain to Medieval/Star Trek.
For one Sun Microsystems release a screen saver some time back where
each peer is a fish tank or part of a fish tank rather.  As fish hit
the edge of the screen they are teleported and appear on someone
else's machine.  This is similar to the concept you're talking
about, and it is graphical in nature.

I am currently working on the Terrarium for Microsoft.  The
Terrarium is composed of peers that each host a given number of live
organisms (plants, herbivores, and carnivores).  The amounts and
size of one's map are chosen at run-time by some CPU clocks.  Rather
than have the animals run off the edge of the screen we have a
teleporter, visible to the client, but invisible to the animals
which runs around the map and transports organisms from one machine
to another.

These types of peer to peer games aren't altogether what you're
looking for, but they apply the same concepts that you'd be looking
for in your game.  Some MUDs are obviously going to work much better
with this theme, like our Terrarium that doesn't require user
interaction (user's program their animals).

> One of the most interesting things to me about this is that you
> could create a HUGE map only boundried by the number of clients
> joined on the network. Maintenance of the network would be handled
> gnutella style.

Hum, I almost think that a very large ROAM style map on each client
would be suitable, along with random placements of teleporters
between the various clients.  Actually creating a contiguous 3D
world across client boundaries with client connections and latency
(no matter how fast DSL gets it still has a min 30 ms latency).


> My favorite part is how to map out the world if clients are
> joining, leaving, going down, all the time. You could use, and I
> have with some success, a random number algorithim, distributed in
> a spiral, to dictate what the map should look like. Each number
> representing a tile. I have made some very pretty maps using this
> method.
 
>        9 2 3
>        8 1 4
>        7 6 5     and so on...
 
> Granted quests would difficult, though not impossible, but as far
> as the other mechanics of the game, as long as every client has
> the same set of rules, there should be no problem.

I'm not prepared to comment on this one yet since it really looks
like your allowing each client to maintain a piece of the 3D
universe.  This is extremely difficult, unless of course terrain is
developed using an algorithm wherein each client holds the seed
values for its land.  That way if a client goes down while you are
on it, you would have already downloaded the seeds, and the block
would still exist (on your computer) until you left it.

Justin Rogers

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



More information about the MUD-Dev mailing list