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.
<snip>
>> 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
place.
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
players.
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
to.
ciao ciao
F.G.
_______________________________________________
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