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

[Caliban Tiresias Darklock]

From: "Marc Fielding" <fielding at computer.org>

> The topic had subtly changed from "Growing the Market" to "Them
> Damn Complainers!"

Not really. I was questioning whether complainers *actually*
represent a shrinking market share, which is certainly relevant to
growing the market.  If complaints *don't* represent shrinking
market share, then we don't *need* to grow the market. This makes it
much more productive to examine other avenues for growing the
market, rather than whatever is generating the complaints.

> I was just supporting my line of argument against the rising tide
> of "Who cares about the people screaming 'We won't buy it!'"
> comments.

I don't see that you really *have* a line of argument. As I see it,
you would like to play multiple characters, and you have a personal
agenda to convince people that single character systems are not even
an option.  Unfortunately, your argument is subjective, which
relegates it to the status of "complaint" and raises the above
question of whether it is even relevant to the market.

I could be wrong. So far, all I've seen from you is some very
intelligent defense of *your* reasons for wanting to play multiple
characters. I do not, however, see any reasonable argument ot the
effect that this is a good thing for the game's business; your
proposal to pay a small fee for multiple characters on the same
server, for example, is ill-conceived and simply would not work.

My line of argument, on the other hand, is that SCS systems are
inherently more efficient in terms of both cost and customer
satisfaction -- and I can actually demonstrate this mathematically,
at the risk of making people's eyes glaze over. If you're not
interested in the math behind it, just scroll down a bit; the
"almost-finished" area is where I start to blend the mathematical
statements into sensible conclusions that may be of interest.

[BEGIN LONG MATH STUFF]

If you have a server that can handle X number of characters, and
each player can have Y characters on that server, then the average
player will have Z characters such that Z >= 1 and Z <= Y. The
server will then handle X/Z players before you need another
server. The higher you make Y, the higher Z tends to go, and X/Z
shrinks dramatically.

So how many servers do you need? Well, first, we assume that all
servers have equivalent X, Y, and Z values. This isn't because they
*have* to, but because I'm not good at the maths which would work in
any and all situation regardless of complexity. I'd tell you to
trust me, but I'd really rather you *don't* trust me and choose
instead to grab the nearest math guru you *can* trust.

If P is the number of players, you need at least P/X, at most
P/(X/Y), and optimally P/(X/Z) for suitable definitions of "optimal"
-- in this case, "optimal" is used to mean "resources allocated =
resources used"; since we cannot use more resources than we
allocate, this is also the PRACTICAL minimum number of servers. It's
instructive to do a little algebra with this, and to produce the
equivalent equations P/(X/Y) = (P/X)*Y and P/(X/Z) = (P/X)*Z. It
should be pretty obvious that as P goes up, so do all of these, so
more players necessarily means more servers.

But while there is no hard and fast rule that says Z *must* go up
whenever Y goes up, there is no reason to increase Y unless it is
perceived as too low.  This means that at least one player wants to
have at least Y + 1 characters on a server, and therefore that we
can reliably expect Z to increase by at least 1/P and at most
(X*Y)-(X*Z) -- which isn't circular, because Z doesn't go up
*immediately* when Y goes up, no matter what happens. It takes a
nonzero amount of time for a player to create a character, so there
is necessarily a nonzero amount of time between an increase in Y and
an increase in Z, during which we can calculate the maximum
increase.

Let's sum up and introduce some shorthand.

  Players total -- P

  Servers total -- S

  Characters total allowed per server -- X

  Characters per player allowed per server -- Y

  Characters per player actually used per server -- Z

  Maximum players possible on server -- X


  Minimum players possible on server -- X/Y

  Actual players used on server -- X/Z

  Fewest possible servers needed to handle playerbase -- F; 

    F = P/X

  Most possible servers needed to handle playerbase -- M; 

    M = P/(X/Y) = (P/X)*Y

  Optimal servers needed to handle playerbase -- O; 

    O = P/(X/Z) = (P/X)*Z

So our equation is now F <= O <= M; in plain English, the fewest
servers needed are less than or equal to the optimal servers needed,
which are less than or equal to the maximum servers needed. We can
further observe that if O > S, then some existing characters will
not fit on the servers and the game will never work. It is good
business sense to keep S close to O, but *how* close is a complex
issue that depends on a lot of factors which aren't relevant to the
current question. Suffice to say that S will *tend* to be pushed
upward at roughly the same rate as O, over time, but that it will
generally do so in bursts rather than continuously tracking the
current value of O.

It should be obvious that as P goes up, all the server variables
except S necessarily go up with it. (An increase in O *may* mandate
an increase in S, but this is not always necessary.) More players
means you need more servers, and that's all there is to it. It
should also be perfectly obvious that an increase in Y anticipates
an increase in Z; while Z does not necessarily go up whenever Y goes
up, Y only goes up when Z is reasonably expected to go up. When Y
goes up, M goes up. When Z goes up, O goes up.

The implications of this are actually pretty simple when you
consider that P, S, X, and Y are necessarily natural numbers. You
can't have part of a player, you can't have part of a server, and
you can't have part of a character. You can *need* part of one, no
matter what it is, but you would have to *use* a whole one.

We can easily define an SCS game as one where Y = 1, and hence Z =
1. This necessarily makes F, M, and O = P/X. The only variable in
the equation that must be predicted is now P, which greatly
simplifies the question of how many servers you need.

We can also easily define an MCS game as one where Y > 1. The only
possible reason you could need Y > 1 is because you anticipate Z >
1. If Z = 1, and no change is expected, then there is simply no need
for Y > 1. So when Y = 2 (the minimal requirement for MCS), F
remains where it is, but M doubles. O necessarily lies somewhere in
between, but *where* is a difficult question to answer. We have to
make some sort of educated guess, but it's always just a guess --
and if we're wrong, players get annoyed at us.

[ALMOST-FINISHED LONG MATH STUFF]

This is complicated by the problem of keeping the actual number of
servers S close to the resource-optimal number O; when you allow Y
characters per server, you are actually making a contract with the
player that he can have Y characters whenever he wants them. So when
a player chooses to play on that server, even if you only allocate
the number of characters he is *expected* to use, you are expected
by that player to allocate the number he's *allowed* to use -- and
if you allocate fewer than he is allowed, he might ask for a new
character and you might have to tell him "no". That violates your
contract with the user and creates player unrest. (This is, of
course, classified as a "bug".) So no matter what Z is, as far as
the server's resource allocation is concerned, EVERYONE potentially
has Y characters... and if you don't have the resources available,
you risk having to forbid things for which the player has contracted
and is paying.

In short, the farther S gets from M (when S <= M), the larger your
customer support risk. You have to balance the *monetary* cost of
having more servers than you really need against the *satisfaction*
cost of not having resources that you have told players are
available.

With an SCS system, however, you allocate one and only one character
slot on the server to a player. It is all he will ever need. You do
not ever have to guarantee that the player can have a character on a
particular server. When the server has precisely X players, the next
player simply cannot have a character there. The server is full, and
when he asks to create a character, you simply don't make that
server available on the list. This will cause virtually no outcry;
internet users are used to it. Internet sites can be too busy, and
they understand this. They don't like it, but they understand.
Support costs of explaining this matter will be minimal, compared to
the cost of explaining why the "create character" button failed when
the manual says the player can have more characters.

More to the point, since an SCS system is one where F = M = O, any
anticipation of increases in P necessarily means that S > M. There
is simply no need to balance M versus O, because M and O are equal
and therefore balance automatically. This also means that the
contract with players is inherently honored by the business goals of
the system; your right to create a new character on another server
is *guaranteed* by the company's desire to provide somewhere new
players can arrive, which means your goals and the company's goals
are in alignment and support one another.

Not many gameplay decisions can offer this elegant and compelling
benefit; usually, a user's "fun" has to be compromised to satisfy
some business requirement. In fact, this is the major complaint
against SCS: the argument that a business goal has stomped all over
something fun. I don't agree with that estimation at all; I think
the business goal will only increase the possibility of fun, and
that the only thing it's stomping all over wasn't really any fun to
begin with -- just something to which people were accustomed. In
fact, it's more often abused for benefit than used for fun.

[END LONG MATH STUFF]

Since a server is ordinarily a fixed cost, this means that -- all
other things being equal -- an MCS game *necessarily* costs more
than an SCS game, and presents questions of customer satisfaction
which simply do not arise in an SCS system. Even if we assume that
an MCS game will achieve a larger market share, which is by no means
demonstrated, how likely is it that the revenue generated from that
larger market share offsets the costs involved?

Not very.

SCS has some big wins over MCS that are not immediately obvious, and
all MCS has to offer is some nebulous idea of making people
happier. I just don't see any *evidence* that MCS systems make
people happier, while I see a *lot* of hard evidence that SCS is a
Good Idea.

>> If someone is quick to argue with others even when he doesn't
>> have a good reason, isn't he generally going to end up being a
>> big pain in the ass?

> Perhaps, if it's an issue of wanton childishness on behalf of the
> protester.

That's a non-answer. It's the answer you can give to anything: "it
depends".  Of course it depends. Everything depends. Ask a
physicist. But you can't live your life from day to day without
having some reasonable hypothesis about how to do that, and if you
deal with a player community, that necessarily includes some
hypothesis about whether the guy acting like a jerk out of the game
is going to act like a jerk in the game.

> I just take comfort in the fact that most users don't participate
> in community forums and most participants don't engage in such
> silly behavior.

> So, your problem children are a minority of a minority! ;)

You can't have this both ways.

Most users don't participate in community forums, but we have a
certain amount of faith that the users who *do* participate are
fairly representative of the entire user community. If this is true,
then whatever proportion of those users do something, we can
reasonably conclude that roughly the SAME proportion of ALL users do
the same thing.

It is simply irrational to turn around and claim uncertainty when
you don't want to believe the implications of this system. Either
the system is reliable, or it is not. If it is reliable, then we
should continue to rely upon its implications. If it is not, then we
should discard it and replace it with something more reliable.

In my experience, if the system is only reliable when you like its
results, then it is probably unreliable.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev