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

Caliban Tiresias Darklock caliban at darklock.com
Mon Jan 6 10:21:23 CET 2003


From: "Dubious Advocate" <dubiousadvocate at hotmail.com>
> From: "Caliban Tiresias Darklock" <caliban at darklock.com>

>> I also see the SCS idea as at least *incidentally* encouraging
>> people to go look at other servers, which is certainly a
>> community-building activity, and it's pretty hard to argue that
>> it's a bad thing. When you have an SCS system, creating a new
>> character is no longer a trivial activity. It requires some
>> thought and some deliberation and a certain degree of risk and
>> uncertainty. I think

> I disagree that people actually work this way, or are encouraged
> to change what I see as fundamental human behaviors simply because
> a developer finds the goal desirable.

You're completely missing the point.

On an SCS system, the player who wants to create a new character
without deleting his current character MUST go to another server to
create it. This means he MUST commit to learning a new environment
and fitting into the context of a new culture, which in turn means
he MUST invest some thought and deliberation in whether he wants to
do this in the first place, and also MUST expose himself to a
certain degree of risk and uncertainty by moving to an unfamiliar
environment.

These happen because of the nature of the system. Whether the
developers like them or not is immaterial, they MUST happen. You
simply can't have an SCS system where they don't, unless it is also
an SCA (Single Character Account) system.

> When people first approach a product they're open to this sort of
> thing because they *do* want to meet people.  But they want to get
> established, not create a revolving door - for most people it is
> tiring or even stressful to meet new people.

That's the tradeoff: if you want to play X characters, you must
participate in X communities. If it's not worth it, then you either
buy more accounts or don't play those other characters.

> The mechanic you're outlining suggests people are opening to
> creating new social connections repititously and I suspect you'll
> be disappointed with the results.

I'm not suggesting anything. As I said before, creating a new
character is no longer a trivial activity. That's a fact. Characters
now have an associated cost. They're not free anymore. I'm not
saying that all the people who want more characters are going to pay
that cost, I'm saying that if they DON'T pay it, they won't get the
characters.

> Bear in mind we have a history in earlier products to look
> to... invariably games start off with these sorts of restrictive
> assumptions about character and community development, and then
> have to ease off them in response to customer dismay.

Are you thinking my position is that SCS will induce players to
participate in more community activities? Because I think that would
be a pretty stupid thing to propose. Players will participate in
communities to whatever extent they choose to participate, and if
they involve themselves in multiple communities they will simply
divide the community participation among those communities. They
won't participate *more* if they have multiple characters, they'll
just participate with a wider variety of people. Consider.

On an MCS system, Bob logs on to server A and plays his character
Joe for a while. Then he plays his character Fred for a while. Since
they are both on the same server, Bob interacts with the same
community as both Joe and Fred.

On an SCS system, Bob logs on to server A and plays Joe for a
while. Then he goes to server B and plays Fred for a while. Since
they are on different servers, Bob interacts with two different
communities depending on his current character.

Now, Bob will not play longer or work harder during play in either
case. He just plays. But in the SCS system, Bob "pays" for his two
characters by participating in two communities -- in which he cannot
have quite the same impact.

The key issue here is not that Bob plays more, it's that Bob comes
in contact with more people. That gives more people the opportunity
to meet Bob. That forms connections between Bob and these
people. And that builds community, but only to the extent that Bob
*chooses* to build community. The key factor here is that Bob
interacts with more people, not because we've said "go interact with
more people", but because it is a natural consequence of what Bob
wants to do -- and the operative word is NATURAL! There's no
arbitrary rule stating that you have to do a certain amount of
socialising; Bob is more than welcome to hole up in a corner and
socialise with nobody at all if he likes, and he can still have
multiple characters. Attempting to *force* community building never
works. SCS simply divides the community building you were going to
do anyway, so those who play more characters will necessarily
*dilute* their impact on the community.

It should be reasonably obvious that there will be more community
impact from the player who plays only one character, all other
things being equal.  Assume that a player exerts an amount of effort
E on the game as a whole, and that he plays a number of characters A
with an average exerted effort of B per character. On the SCS
system, he will switch characters C times in a given period of time,
and expend an average amount of effort D (over and above that
expended in the MCS system) each time he switches characters.

So on the MCS system, E = ( A * B ). But on the SCS system, E = ( A
* B ) + ( C * D ). If E is equivalent in both instances, the SCS
system only matches the MCS system when A = 1 and C = 0. As soon as
you add another character in the SCS system, there starts to be a
nonzero cost for switching characters, which reduces the player's
overall impact on the system.

Now, it would be Wrong to try and compensate for this by enhancing
the impact in some other way. While we have reduced the player's
impact, we have currently reduced every player's impact *naturally*,
such that everyone's impact is reduced to an equivalent level. The
Correct response is to try and minimise D, instead of encouraging an
increase in E or artificially boosting B.

It would be interesting to take D negative by making it *easier* to
log into a character on another server than it is to log into one on
the same server.  That could actually encourage MCS players to treat
things the same way as SCS players, putting all the characters on
different servers. It probably wouldn't, but it would still be
interesting to look at ways you could design a negative-D interface.

>> You know what really bothers me? I don't know what people are
>> trying to accomplish here. A decision has been made. It's a
>> decision that took a long time, and involved consideration of a
>> lot of factors we simply do not (and currently cannot)
>> appreciate. And when someone actually stands up and says "we have
>> decided this, and while I do not personally like the decision we
>> have made, I am convinced that it is the right decision" -- we
>> give him hell for it.

> I don't know that all people on this list really feel this way.

I, on the other hand, don't care. I don't speak for the list, and
neither does anyone else. The fact is, Raph gave a very detailed and
lucid explanation of how and why the SCS decision was reached, and
in *this* forum the people who discuss it seem primarily concerned
with whether it was a decision worth considering in the first place.

> We're debating the assumptions behind the decision, not the
> decision itself.  In other venues I see extreme whining against
> it.  But not here.

While there may not be "extreme whining", there's certainly a
distinct lack of rational discussion. Every participant in this
"debate" (and I use the term loosely) either wants an MCS system
because that's what he personally likes, or doesn't really have a
preference. The MCS proponents don't really have an overarching
reason why SCS is bad, it's just bad because it's not MCS.

There is some apparent resistance to the idea that an SCS system is
a Good Idea, and it appears that some amount of this is sour
grapes. MCS has problems, and we know it. But since we didn't think
of MCS *as* MCS, the solution of SCS simply didn't occur to us. I
think certain people are shocked by the idea that they missed such
an obvious solution, and are desperate to find some reason why it's
not the right solution anyway.

It seems the fear is not so much that they will not be able to play
SWG, but rather that SCS will "catch on" and the next fifty-odd
games that come out will use it, too. We're about to take away
baby's favorite toy, and he's fussing about it because he sees it
coming.

>> So what exactly ARE people trying to accomplish with this SCS/MCS
>> discussion? Anything?

> Should the decision work out we'll need to rethink our
> assumptions, which after all resulted largely from our own past
> experiences...

Why don't we rethink our assumptions NOW, instead of waiting until
someone *proves* they're stupid?

> But I personally don't care that a specific company somewhere made
> a specific decision.

However, people seem to care very keenly that *a* company has made
*this* decision. It doesn't matter that it's SOE on SWG, it just
matters that someone has kicked us solidly in the ass with something
we didn't expect. We can either learn from this, or shove our heads
in the sand and yell about how it's a bad idea that will never work.

> I like the discussion that has come out of the topic, and suggest
> we can explore the assumptions and ramifications.  I like having
> my underlying assumptions questioned.

I've been going over the thread, and here's what I see.

  1. People discussing why MCS sucks.

  2. People discussing why SCS sucks.

  3. People discussing what players currently do.

  4. People discussing what players are going to do.

  5. People discussing what players ought to do.

What I *don't* see is a whole lot of discussion about the
*differences* of MCS/SCS, or about what players *want* to do. I
don't see people challenging the implicit assumptions that one or
the other of MCS/SCS necessarily has to suck, and that what players
are doing has some direct relation to what they want.

It seems to me that these are much more productive discussions, and
that the five things we're discussing are really supporting
statements on one side or the other of these discussions. But we're
not really exploring much of anything; we're just investing our
personal egos on the sides that we personally like. A little effort
to be objective would probably prove helpful; I don't really like
the idea of SCS either, but when you look at it with a neutral eye,
it starts to make a whole lot of sense. I can think of lots of fun
things that I could do with multiple characters, too, but that
doesn't mean I can't have fun doing something else with just one.

I spent years on an RP MUSH where I had one and only one character,
even though I was *permitted* to have as many as I wanted. When I
played Diku variants, on the other hand, I would commonly skirt "one
character per player" rules to create several alternate personae;
this was never really a *secret*, but it was technically against the
rules all the same. What I never really questioned at the time was
why, when I could have all the characters I wanted, I stuck with one
-- but when told I could only have one, I created several. I
occasionally assumed it was just contrariness, and I wanted to do
whatever I wasn't expected to do.

In retrospect, I think the reason I didn't feel the need to have
another character was simply because the one character I had was
rich enough and flexible enough to meet my requirements. On most
Diku variants, however, I felt like I had to have several
characters; each of them felt like a cardboard cutout, and the only
way to provide depth to the experience was make a big stack of
them. I would make a character that had certain capabilities, and
then find that I needed others. Since I couldn't acquire them, I
would have to make a new character with other capabilities. The
tradeoff, of course, was that creating a character on the Diku took
two minutes, while creating one on the MUSH took two hours and you
had to wait until a staff member got around to examining your
character and giving it the thumbs-up.

I'd like to turn around here and examine what I call the "Fourfold
Development Process". Imagine that we have a graph on which all
problems exist. Along the X axis, you have "difficulty of
fixing". Along the Y axis, you have "difficulty of avoiding". This
gives you four quadrants: easy/hard, easy/easy, hard/hard, and
hard/easy. (Order is always fix/avoid.) And that's the order in
which they get fixed: first we fix the things that are easy to fix,
and then we turn to the ones that are hard. But the priority of a
problem is proportional to how hard it is to avoid, so when we get
to the problems that are hard to fix -- we never reach the bottom of
the list, because more problems constantly arise which are either
easier to fix or harder to avoid. Since there are easy workarounds
to the problems, however, they eventually leave the problem space
altogether because people have become so accustomed to the
workarounds that they are no longer seen as problems.

What this means is that on a game, just as on any large-scale
development, the development team and the QA team collectively let
the problem drop out of the problem space by working through it to
find more pressing issues.  When characters are shallow and
uninteresting, they work around this by making more characters to
keep themselves interested. If that wears thin, they write it off as
the natural state of any software tester after he's been testing
something for a long time. Then they allocate a short-term beta
phase for real world testing, during which virtually nobody
encounters the problem of having cardboard characters because
they're too excited by the opportunity to play the game first and
get an advantage over other players.  So the people who would be
capable of saying "this is a problem" simply aren't given the chance
to *perceive* the problem.

It is possible you can NEVER give them that chance. A concept that
appeals to me is to split the development team at some point; a
company could use the "exterme programming" concept of pair
programming through the point of getting to internal beta, and then
split the pairs into one who tests and one who fixes bugs. After a
while, you swap them off, so the tester goes into bug fixing and the
bug fixer goes into testing. Throughout this process, you also have
a nontechnical test team that does nothing but test.  The idea is to
make sure that *all* your developers get to spend time just playing
the game and seeing how it really works, but that your game is also
tested by some people who *don't* know the code. (I could go on
about this, but it would get really long and pointless and this post
is long and pointless enough as it is.)

Once people start encountering the problem in the real world, they
resolve the problem by distracting the player -- they make new
character classes, new areas, new quests, and that sort of
thing. But the problem of characters being too boring and lifeless
is never addressed, and eventually the player gets jaded. Around
this time, a new MMOG hits the streets, and the dissatisfied player
goes running over there to get in on the new game that will
undoubtedly be better. After all, it's a whole new world.

Over time, the distraction of a new world becomes less of a
distraction, and the players determine much more rapidly that the
characters are unsatisfying even when switching MMOGs. This is
evident on the SWG forums, where some people are convinced that SWG
cannot possibly be all that different from the existing games --
because they are not all that different from one another.  IOW,
because we *don't* have diversity, the community is beginning to
think we *can't* have it. This was also at the root of my
disagreement with the PA that I left; the developers would say "this
is how things work" and then the PA would attempt to plan things out
based on the way things worked in EQ or UO. When I pointed out that
the devs told us things wouldn't work this way, they insisted that
other games *say* it will be different, but it never really is.

An example that was pulled up repeatedly was some argument related
to the economy in Anarchy Online, where they tried a system that
didn't work but then had to yank it entirely and use a system just
like other MMOGs use. (I don't remember the specifics. Someone else
probably does.) This has effectively trained several
otherwise-intelligent people to believe the maxim that "new things
don't work", so whenever the SWG team said things would be
different, these people nod knowingly and say "yeah, right". It's
pretty sad, really; I can't quite imagine being so cynical that you
don't think things CAN get better. I'm pretty cynical about how
things *are*, but I still think the future has potential.

Which leads to my point. Players are becoming aware that MMOGs in
general are unsatisfying. However, they don't really know *why*, so
they can't get the problem fixed. Furthermore, you can't alter your
entire concept of character in a game without essentially starting
over. So the existing game simply *cannot* fix the problem. The only
available option for that game is to give people more characters and
let them wallow around until the hole is deep enough to make them
happy. Which, of course, just digs a deeper hole.

New games, however, have an opportunity to address that problem at
its source: the shallowness and general unsatisfying nature of
characters in the average MUD. I see SWG making a definite attempt
to fix this problem, and I applaud the effort regardless of the
results. I also see a certain danger.

Simply adding more depth to the characters does not mean the player
will observe this depth. Since the player is not accustomed to
having characters with depth, he needs to be *encouraged* to explore
that depth; and as long as he can do what he has always done, which
is to create additional characters for depth, he will continue to do
it. The danger area becomes not only that we must encourage the
player to explore the depth of the character, but that we cannot
FORCE him to explore it. The player must feel that he has *chosen*
to explore that depth. We must therefore *allow* the player to have
multiple characters, but not in such a way that they *substitute*
for character depth.

SCS apparently does this. Two characters no longer make a deeper
experience, they make a broader experience; they demand *more* work
from the player, instead of assisting one another and making the
player's job easier. This encourages the player to stick with one
character for a little while longer, and to explore the depth that
character provides -- but the player who wants another character can
still have one. He just doesn't get to stack them up.  While we have
yet to see how well this works, the reasoning behind it is certainly
sound, and it has distinct benefits that one simply *cannot* get
from an MCS system. Full-stop.

What would be *really* productive here would be to examine how an
MCS system solves problems that you can't solve in an SCS system;
this would give us some idea of the tradeoffs involved. How does an
SCS system *hurt* players?  How does an MCS system help them?

> Stifling design level discussion doesn't seem ideal.

I'm more interested in stifling IRRATIONAL design level discussion.
Irrational discussion is not going to give useful results, so not
having any of it actually *is* ideal.
_______________________________________________
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