[MUD-Dev] [BUS] Account-management systems

[ceo]

I've recently been working on a project where each game-server is
limited to 512 players (for reasons that have everything to do with
game-design, and nothing to do with performance...the limit is
hard-coded and should never change).

>From the same fundamental gameplay reasons, lots of aspects of the
game are explicitly per-server, and are exposed to the players in
that way. Each server is explicitly a self-contained "island" in
game-terms.

I've been having fun looking at how this kind of situation impacts
account-management and player-identity. I don't want to re-plough
the MCS/SCS ground again, although I find myself re-visiting much of
it now with a slightly different perspective. It seems to me to be
similar to thinking about MUD's which share a player-export/import
function, but in this scenario it's a bit closer to home, because
the islands in this game (as opposed to the different MUD's) are
mostly part of the same game, so that player's expectations of how
much integration there is are different.

On the one extreme, you can just declare each server as 100%
independent of the others. This is quite easy, and sidesteps the
issues of accounts and identities which span multiple servers. On
the other, accounts and identities can be explicitly "global" in
nature, so that if you see someone on server 123 called Bubba, you
know it's the same person you've been competing against viciously on
server 34 called Bubba (and this time around, he might be an ally).

In the middle ground, you have the "human player --- game avatar"
2-level identity system, and variants thereof (e.g. 3-level system,
with human player --- global avatar --- local avatar). In this case,
some aspects of identity are local, some are global. On the whole,
in-game you interact with other avatars using almost entirely local
identity, but you are always (as a player) able to view the
global-identity associated with a local-identity. This is generally
used for making friendships, etc. And players have the option of
building these relationships either locally, or globally, at their
discretion.

W.r.t account-management, a similar 3-horse race seems to exist: all
local, all global, or somewhere in-between. If all accounts are
global, then account-management is greatly simplified for the
players. However, the game-designers lose various gameplay options,
e.g. to do with allowing / denying single human players (accounts)
to have multiple characters in a single server (this is where I
start to venture into SCS/MCS issues. I'd prefer not to go there
again :) unless it's brief, to the point, and doesn't fork into
another massive debate on SCS/MCS).

Personally, I'm inclinded towards the in-between approach for both
topics. However, I'm running into an awful lot of unknowns (mainly
due to my lack of experience with global/local account
dichotomies). I.e. when going in-between, which parts should you
make global, which local, and why? What are the gotchas. etc?

In the current scenario, the situation is further complicated by the
fact that you do NOT create new characters/avatars when you join the
game - you only ever take over an existing uncontrolled avatar
(...hence characters-per-server is constant (512). Assuming player
numbers increase over time, this adds a little more complexity to
the identity debate - because it can make it much harder to play
with pre-existing friends (and/or places further requirements on the
process by which players join a server - they need lots of info
available to make their decision about which one they join) ).

It all brings to mind Skotos's account system, and I suspect that
Christoper Allen and co (and others on this list who have also
developed similar systems?) have all this licked by now...from what
I've seen e.g. the Skotos system handles a wide variety of games,
under a wide variety of conditions - e.g. Skotos own-branded
servers; Skotos-managed, but externally branded servers etc (IIRC -
correct me if I'm wrong!) etc. In fact, the issue of "servers we
manage, but which are re-branded by someone else" is also one that
occurs almost immediately in the game I'm currently working on. This
adds some more questions to the mix, like "How do identities mix
across different-branded servers?".

I'm currently most tempted by a 3-level identity system, where the
middle-level is made up of non-intersecting sets of
global-identities. I.e. A human player has a single account. That
account can create a global identity in any one of the
(separately-branded) planets (to stick with the islands metaphor
from the beginning of this post). Each planet-wide identity can be
used to control any local-identity on any of the islands of that
planet...

...but worrying that it's either over-engineered (and wastes
implementation and maintenance time), or else too constrictive (and
will have to be replaced in the near future :( ).

What are other people doing about this? I've categorized the
possible approaches, but have I missed some out entirely?

Adam M
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev