[MUD-Dev] Star Wars Galaxies: 1 character per server

tomi.sarvela at iki.fi tomi.sarvela at iki.fi
Mon Jan 27 03:00:52 CET 2003


--<cut>--
Note: This message was written via the list web archives.  There is
no guarantee that the claimed author is actually the author.
--<cut>--
Original message: http://www.kanga.nu/archives/MUD-Dev-L/2003Q1/msg00010.php

On Thu, 02 Jan 2003 17:27:38 -0800
"Marc Fielding" <fielding at computer.org> wrote:
> [Rayzam]
 
>> Large Percentage -
  
>>   Actually, I disagree with the common assertion being made that
>>   SCS ruins the casual player. I have seen the casual player
>>   leave games because the average player requires muling or
>>   joining a guild, to survive.  As you state, the casual player,
>>   the large mythical golden market, won't want to handle
>>   mules. If that's 95% of the player base, then just make the
>>   place SCS.
 
> But removing MCS removes the ability of a casual player to explore
> different aspects of the game with different characters. All in
> the name of preventing "abuse" by a few.
  
>>   Mules are like a virus :) Some players start up with them. As
>>   other players advance, and run into not finding X character
>>   type when they need one, then they'll start muling. It
>>   snowballs. I agree with your statement that the large
>>   percentage won't, to START. But that the population as a whole
>>   will shift over time.
 
> The percentage shifts over time because most games LOSE casual
> gamers as the game ages, whether it's from new MMOGs coming out or
> gameplay being targeted at the hardcore level.
 
>> I'm sure this is a testable hypothesis, if someone has access to
>> the data. Take a MMORPG and track the average # of
>> characters/account over time.  Also track the time to reach the
>> median # of characters/account as the game matures.  It would be
>> an interesting study, not from a marketing standpoint, and not
>> mainly from a social standpoint, but from a developer standpoint.
>> Quantify one aspect of a game's evolution, anyone?

> Good suggestion.
 
> To make the test valid, the analysis should seek to find the
> number of characters per account within a certain level range of
> the account's highest-leveled character. Those below that range
> are most likely "toy" characters, not mules.

Hi,

I'm just a lurker here, reading archives on my spare time. To
introduce me quickly, I've been interested in making games, and more
specifically, making game interesting, long-lasting addictive
experience =) My experiences are from looking over one mud as minor
diety and sysadmin, and own playing experiences.

Reading the posts a stupid idea hit me, wrt. MCS vs SCS:

  To discourage muling (and thus, resource hogging), but still
  giving players possibility to explore other races/classes, and
  acknowledge one account / many characters:

    Make players accounts vault/safe shared between characters.

As vault I mean the big storage: if inventory is biggest there is,
then it is it. Otherwise, D2's stash, EnB's vault, Daoc's vault.

Thinking it a while, it would legitimate twinking, but prevent
muling (unless new account, but that is also a possibility with
SCS). It would give player the possibility to explore the other
facets of the game (which, as it seems from the posts and my own
experiences, is the main reason for MCS). Twinking is possible if
you have several characters, but at the moment, people are doing it
anyway, using friends help, and twinking one's own character is not
necessarily bad thing, in my opinion.

Starting from the basic assumption that characters world view is
limited (player can't see all content and experience everything
within his choices, and gamemasters can't generate new content as
fast as explorers consume it), there is reason for MCS to exist. Is
it good enough reason, I don't know, but lets stick to it for now:
can you see any immediate abuse issues with this kind of shared
storage approach?

Tomi



_______________________________________________
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