R: [MUD-Dev] Moving toward Massive Multiplay (was CongratulationsHorizons...)

Ghilardi Filippo ghilardi at dsdata.it
Wed Jan 21 17:23:02 CET 2004

On Jan 17, Mike Shaver wrote:
> On Jan 15, Paul Schwanz wrote:

>> A major gripe I have against current MMORPGs is that, although
>> they are billed as massively multi-player, they don't really
>> offer much in the way of massive multiplay.


>>     MMP: Your town adds Odin's Hammer to its display case in the
>>     town hall and all the blacksmiths in town learn how to craft
>>     weapons with increased magical properties.  Perhaps you
>>     quested for the item. Perhaps it was the spoils of war with a
>>     rival town.  Perhaps you bought it from a distant
>>     civilization.

>>     MMP: Your village gathers the resources and skills needed to
>>     construct a perimeter wall and gate.

> SB's city-building metagame permitted a fair bit of this, as did
> DAoC's relic warfare, I believe.

Beside confirming (at least DAoC part) I would add that we can
generally see two distinct types of global/server quest/goal
implemented in MMP games.

Goals and rewards can be the same but how this can be accomplished
by players can get to significantly different playing experiences.

  Type A: When players are asked to accomplish a task that
          is done soloing or with just a small group.
          (just to make it easier)

  Type B: Is needed and asked full partecipation of big groups
          all present at the same time, coordination among them
          and organization among players.

In both cases is supposed to get a reward that will affect all
players or big groups (like factions) and not only who partecipated.

  (type A example)

    Instead I've seen other games where there's a story and a server
    wide quest accomplished when enought people solve a specific
    quest (doable in solo). In this case you never feel the
    community around you. You just do a quest (that could be like
    many others) and at some point read that your side had win
    (doing more than other side or whatever was needed). Yes, you
    know that you contributed but you feel that it wasn't really
    necessary. It could be even a SP game with a central DB for a
    global computation of each results for what you see sometimes.

  (type B example)

    Just to take an example using DAoC, I've seen assaults to get
    relics. Seeing hundreds players that togheter (and at same time)
    try to get/defend a relic is exciting.  As forces start to
    gather from each side, more and more people are called to get
    involved called with a simple mouth to mouth aproach. All gets
    in a nice excalation pretty fast.

Now, I understand that those epic large scale involvments aren't
easy to implement. Just only being able to handle large crowds can
be a challenge for client/server if they aren't properly designed.

In those examples I've depicted two extreme opposite scenery (from
solo to massive). We can have also solutions that stay in the
middle. Special spawns could be activated to simulate a siege of
every town with nasty mobs (like undead invasion in UO). Users would
spread a bit preventing server collapse from all users in same

In any case, I agree on that MMP need to use the MM feature part. I
think that in the end a player don't care if a server can handle 1
thousand or 10 thousand players. What is cared is the sense of
community that can derive from this.

Having personal pocket-dungeon is good to offload some resources
from main server and to let players to not interfere each other with
specific/particular quests. But this doesn't have to be
abused. Heavvy usage of personal dungeons/areas would be like
playing with another Diablo2 (with a graphical lobby area instead of
simple chat window).

Community is enanched if there's common and big goals to
achieve. All this staying togheter, sharing experiences, being able
to stick with old friends and at same time being able to meet new

This don't mean that users have to group. Grouping shouldn't be
enforced. If someone want to solo for any reason, he should be able

ciao ciao
MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the mud-dev-archive mailing list