Re: Unified account with many characters

From: Torgny Bjers (
Date: 12/08/02

On 02-12-08 19.40, "Jeremy M." <jkm4802@HOTMAIL.COM> wrote:

> ---= In Regards to: =---
> "I have been sketching on a system for our CircleMUD which will allow
> players to have one login account with multiple characters.  I thought I'd
> run this by the list since I am having some problems with actually planning
> the system code-wise, and perhaps somebody has done something like this
> before, and perhaps they even have code tidbits to share."
> --* Snip! *---
> The first thing I thought of when I began reading your post was, why would
> anyone really want to do that? What are the advantages? Doesn't Circle
> handle players well enough? Why reinvent the wheel again?
> I've also seen these types of systems implemented and even now I can't help
> but wonder to myself, why bother..  I've had my interests tantalized by the
> topic because I get bored and don't mind throwing in code when I'm like
> that. :P  Can anyone answer any of the above stated questions? I've either
> got blinders on to the benefits, or there really aren't any benefits to
> adding that system.

Brian already replied, and brought up some of the points that lead up to my
decision, although I chose to reply to your post without his comments in the

Q: Why would anyone want to have one login with multiple characters?

A: The advantages are numerous.  For instance, you only have to approve the
player once, from then on you'll know who he is, since he uses the same
account to create all his characters.  Characters per account is not an
issue with a non-commercial mud, since it makes no nevermind how many chars
an account creates, since we don't really care about any value return at
all, like a commercial pay-to-play mud would.

The player only needs to create one account, that means one login, one
password.  If you play a roleplaying MUD, you generally have several
characters, you don't multi, you just role play several different roles,
since you are dependant on others, and they might be online, then you need
to RP with someone else in the meantime, for instance.

You can keep track of multiplaying a lot easier, since they have one login
for all their characters.  Of course, they can use a new email to multi
with, but that means that it has to be a real email, since I already use
email validation for all player accounts.

Contact between players and administrators / game guides will be made a lot
smoother, since it will be easier to know what player uses what character,
and what other characters he plays.

Q: Doesn't Circle handle players well enough already?

A: Sure it does, if you consider the fact that each player only has one
character.  Since I know for a fact that ALL my players will have between
one and five characters (some even more), then they suddenly have to
remember 5 different passwords and five different logins.  Well, maybe they
pick the same password for each char, but it still leaves room for a lot of
confusion on their side.  Of course, it works, but why not make it better?

Q: Why re-invent the wheel?

A: How am I reinventing the wheel by extending a system which is already
there?  I am merely altering the login procedure.  The actual storage and
operation in-game is exactly the same for the most part, execpt that each
descriptor will have an account storage as well as a character storage.  The
character won't need a password anymore, all it needs is to have a reference
back to the account, either by name, or by ID.

Q: Are there any downsides to this system?

A: Memory, perhaps, but one struct more on each descriptor makes no
never-mind to me, since I haven't seen an RPI MUD with more than 50 players
on at once anyway, and if I do get that many players I won't have to worry
anyway, since I have my MUD hosted on a beefed up server which will just
laugh at my puny attempts at eating up it's gigantic memory.

As for any other downsides, I can only speak for the systems which I have
used that utilize this kind of login, and I must say that it makes my life a
whole lot easier as a user.  Simple is better.  That it might be difficult
to code, for a little while before I have figured out how to do it, is of no
real concern to me.

If anybody else know of any direct pitfalls and don't-do's in regard to this
type of login procedure, speak now, or forever hold thy breath.

Q: Why bother?

A: Why not?


   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT