[MUD-Dev] Re: Using HTML for a Mud character generator

Travis S. Casey efindel at io.com
Thu May 14 08:32:30 New Zealand Standard Time 1998


On Wed, 13 May 1998, John Bertoglio wrote:

[stuff about using a JavaScript web page to generate and validate
characters snipped]

I suggested a similar idea on rec.games.mud.admin once.  Thanks to
dejanews, here's what I posted:

IMHO, most skill based muds do it this way because it's simpler
than putting the player through a long character creation process in
which he/she could get to set beginning skills (which is what most skill
based paper rpgs do).  I can see a few good ways around this:

 - A form-based character creation system on the web.  This could be
   point based (a player starts with X points and can spend them to
   buy skills, attributes, etc. for the character), life path based
   (the player creates the character by creating the character's 
   history) or use any other system.

[more ideas cut, since they don't involve web-based character creation]

If I were doing this, I'd use a mixture of CGI and JavaScript -- CGI for
any initial calculations that need to be done (e.g., die rolls),
JavaScript to handle the interface and assigning points to things, and
another CGI after the form is submitted to check for cheating.

With die rolls, a useful thing to do might be to give each form a
randomly-assigned ID number which will expire in, say, an hour (some time
that's long enough that the player will almost certainly finish making the
character).  On the server side, keep the ID number and the rolls that
went with it.  This info can then be used when the filled-in form is
submitted to check whether any cheating was done.

This still doesn't avoid the problem of someone requesting hundreds of
characters until he/she gets "the right one", but it would make it more of
a bother to do.

Also, for random character creation, using a system like many D&D groups
use might help reduce the number of people asking for rerolls -- allow the
player to assign the rolls to attributes.  Then someone who wants to play,
say, a fighter type, won't need to wait to get a set of attributes with a
decent Strength -- he/she can simply take the best score and assign it to
Strength.

Another method I've seen used is to simply roll a bunch of dice, and let
players assign as many dice to each attribute as they want, without going
over a maximum.

If you really wanted to prevent people from doing lots of rerolls, here's 
a couple of ideas:

- Allow your form to be cached.  Now they'll have to either clear their
  cache or stop and restart the browser between tries.

- Keep their IP, and either don't allow a new request from that IP for 
  a limited time (maybe 30 seconds), or return the same rolls as before
  to it for a limited time.  This could be bad for those behind proxies, 
  of course.

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'  Keeper of the rec.games.design FAQ:
     '---''(_/--'  `-'\_)      http://www.io.com/~efindel/design.html



--
MUD-Dev: Advancing an unrealised future.



More information about the MUD-Dev mailing list