[MUD-Dev] Re: MURKLE: Wot it is

[Nathan F Yospe]

On Fri, 15 May 1998, Mike Sellers wrote:

:[Not sure what's up --don't have a lot of time to monitor the list-- but I
:seem to be missing a *lot* of original messages: almost all of them are
:"Re: something incredibly important" ]

:At 01:13 PM 5/14/98 -0700, J C Lawrence wrote:
:>On Fri, 08 May 1998 17:54:27 -0700 
:>J C Lawrence<claw at under.engr.sgi.com> wrote:

:><<Hi me!>>

:>> A preface on MUD game design:

:>>   The largest failure of MUDs is that they have generally never, and
:>> never stably, been able to assemble large simultaneous populations.
:>> What is "large" in this context?  I would start at 500 as still
:>> being on the verges of small.

:>>   Raph, Sellers: Can you provide context from UOL and M59 here?

:One difficulty here is the perennial disagreement of the definition of
:"MUD."  Lots of muds or mud-like games get 500 or more simultaneous users.
:Gemstone and LambdaMOO have both done this or come close to it, and I'm
:sure there are lots of others.

:OTOH, I'd say a "large" simultaneous population may start somewhere below
:500 users, and mostly depends on the size and nature of the game.  In M59,
:100-150 people starts to feel pretty large (but not exactly metropolitan);
:in Everquest (if their world size estimates are accurate), this will be
:nothing.  

:In the final result, I wouldn't get too hung up on having a certain number
:of simultaneous players without setting that in the context of what sort of
:game the MUD is.  

I spent last weekend on this, and its relevant, so now would be a good time
to broach the topic on the list. I've mentiond the GURU project, Physmud++,
and the relationship between them in the past, but for now, I'll summarize. 
The GURU project (Graphical User-Rendered Universe) was started by me and a
group of associates; math, computer science, and physics students with more
talent than time. We spent several hours a week working on detailed design.
I created a working tile generator, editor, and scaling engine, others made
working models of other components. We detailed a potocol, a routed server,
a process manager, and an extremely sophisticated (to the point that I have
not, in the three and a half years since, seen anything nearly as good) way
of managing thread merging... completely invalidating Dragon's Dinner. With
all of this, what we lacked was time, manpower, and financial resources. We
ended up backburning the project. Eventually, the other members went off in
pursuit of other interests. Some of them were part of Singularity, a Rom2.4
mud that ended up spawning Physmud++, in its own odd way. Currently, I have
all rights to the design of GURU. I still intend to produce it, and have in
fact begun production... but like Physmud, it has evolved beyond its origin
as a simple project. In this case, it has become a basis for a VR arcade. I
have extended the design of the manager to handle noncentered distribution,
merging of remotely handled threads (that was a pain in the butt) and rough
approximation (at this point) of global event propogation over a noncentric
network. The game itself is fantasy, with well designed laws and rules and,
most importantly, a world almost as vast as the real world. I have done the
preliminary work on the hardware as well, using eight-point sensor mapping,
frequency tagged reflex point transmission, and pneumatic feedback. There's
a lot left to do. I intend to roll the prototype out in eight years, with a
large allowance for slideback. In the meantime, Physmud++ gets GURU's hand-
me-down designs. Which brings me to the point: populating a large world, in
a more belieable manner than your average NPC, without a large player base.

GURU has three methods to increase world population; Two are staying in the
GURU project only - ghosts (sequenced NN fed AIs) and groupies (companions,
in the old D&D campaign style, that map your own behavior to their template
personas, forming a sort of you-if-you-were-the-thief/mage/whatever instead
of whichever role you picked; you get to build your team of groupies as you
go, two are picked when you generate your character and join you in the pre
game introduction), but the third method, the mirrors, I spent this weekend
porting to the Physmud++ model. Mirrors are just that: they mirror a player
into an NPC. Not an NPC in the same area, however. A mirror will look for a
suitable player, generate the other side of the mirror in the corresponding
location - another NPC will wander up to the player being mirrored - and it
will mirror the first player. Let me illustrate:

    Bubba is a player, a well to do half troll.
    Boffo is a player, a human rogue.
    Buffy is a player, a human journeywoman.
    Zagga is a nonplayer (NPC), a mirror.
    Zumba doesn't exist yet.

    Bubba approaches Zagga. Zagga is tagged to mirror. Zagga begins to look
    for a suitable player to mirror. Zagga finds Buffy, who matches Zagga's
    profile, but Buffy is in the wrong sort of terrain. Zagga checks Boffo,
    and Boffo is a suitable match. Zagga generates Zumba, and locates Zumba
    relative to Boffo so that Zumba corresponds to Bubba, Zagga to Boffo. A
    mirror starts between the pairs.

    <Bubba> A rough looking man with bulging muscles is trudging up the old
    mill path. He has a long blue sword strapped to his back. He looks your
    way and waves excitedly.

    <Boffo> A well dressed half-troll in chain mail is leaning on a wall at
    the top of the hill. He gazes at you.
    <Boffo> Wave troll
    <Boffo> You wave excitedly at the troll.

    <Bubba> Say 'Fine day, friend. I am Bubba. What would your name be?'
    <Bubba> You call out to the rogue. He replies, "Well met, stranger. I'm
    called Zagga."

    <Boffo> The half troll calls, "Fine day, friend. I am Zumba. What would
    your name be?"
    <Boffo> reply 'Well met, stranger. I'm called Boffo.'
    <Boffo> You nod at the troll and reply in turn.

Of course, the technical difficulty in maintaining the appearance of mirror
characters are significant. For every character present on either side, one
must be mirrored on the other side. All recognizable names must be mirrored
as well, and no doubt the explorers will catch on soon enough. But... there
are a number of advantages to be gained here, and it is worth the effort. I
find it especially useful for mirroring hostiles with no common language. A
hostile without common language just becomes a smarter opponent. Terrain is
a bigger problem. Mirroring makes terrains in a locality remap to match, if
the terrain is not marked fixed. Occasionally, a player may spot this. Much
to gain, much to lose...
 -- 

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/




--
MUD-Dev: Advancing an unrealised future.