[WF-General] Player Database

jbest at magnacom.net jbest at magnacom.net
Thu Oct 5 01:50:47 PDT 2000


A comment or two...

Tess Snider wrote:
> 
> On Thu, 5 Oct 2000, Richard Wilkins wrote:
> 
> > Okay there's the intro...I noticed you had only a bool for the IS_ADMIN element. Given that there will be occupations on an RPG such as world building, which may or may not be coupled with general administration, wouldn't it be wise to have a range of levels of 'superiority', such that someone with a lower level could not delete a character/ban an account, but stick just to their job. I'm not sure what the range of abilities for the admins on WF are (because I'm a naughty boy...no because I only joined the mailing list yesterday), so what I'm saying could be irrelevant. I probably shouldn't bring up Ultima Online, I might get shot, but I will.
> 
> What you're looking for is a roles-management system.  I was pondering
> this very issue, the other day; thanks for reminding me.  The problem with
> assigning a "level" is that it doesn't provide enough flexibility.  You
> might want to be able to give someone the power to do A and C, but not B,
> and it might not equate to any kind of level, per se.  Instead, you want
> to assign "roles" to players.  A given player can have any combination of
> roles that the administration chooses to give him/her.
> 
> There are three quick-and-dirty ways to implement roles:
> 
> 1.) Bitvector.  TinyMUSH, for example, uses flags for roles.  These are
>         stored as a simple bitvector, to my knowledge.
> 
This is how I have done it in previous servers.  It was great to be able
to grant abilities to users on a command by command basis, and all of
the checks were done with simple macros.  Ability groups were also
defined.


> 2.) Table columns.  Each role could be a boolean table column.  This is
>         not a good choice, in my opinion, since it's not terribly extensible,
>         and takes up a lot of space.
> 
This makes for bulky and hard to manage implementation in both
relational databases and code structures.  Many databases also limit the
number of columns on a table (some as low as 250), and this could be a
limiting factor for complex games.

> 3.) Mapping table.  This is a table which contains two columns:  One for
>         playerID, and one for roletype.  To get a player's roles, select
>         from the table where playerID is the ID for the player you're
>         interested in.
This makes for a nice, quick lookup, but you would want an index on the
playerID field.  This could easily triple the size of the table space,
and having a hundred or more rows for each player object might be a
major waste of lookup time and database space.

> 
> My preference is towards 1 or 3.  Option 1 takes up the least space, and
> is the most efficient, by far, but makes it very difficult to edit roles
> from external programs (such as a web-based admin tool).
> 
> Tess
> 
> _______________________________________________
> General mailing list
> General at mail.worldforge.org
> http://mail.worldforge.org/lists/listinfo/general

I believe that option 1 is the best case for bool permissions.  Note
that another table, something like option 3, would be good for other
permissions that require an integer "level" or key to another table.

James Best




More information about the General mailing list