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 email. 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? Regards, /Torgny -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | | Newbie List: http://groups.yahoo.com/group/circle-newbies/ | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT