Mixture

[Travis S Casey]

On Sun, 23 Mar 1997, Adam Wiggins wrote:

[lifepaths for character creation]

> Yeah, this is a pretty common method for character creation.  Sometimes
> it's in the form of a story, ala Aturian Dynasty:

[story example cut]

> Normally it's something more mundane (no storyline), like:
> 
> Your parrents were:
> a) Greatly respected in the community.
> b) A blacksmith and a seamstress.
> c) Killed in a great battle while you were very young.
> d) Serfs who toiled endlessly for the local baron.
> 
> And so on - it leads you through your 'lifetime', branching and so forth.
> This is perfectly fine by me, my only complaint is lack of complexity/options.
> Usually there just aren't _enough_ questions or choices, so that by your
> third character you're already bored with the process.  Secondly, players
> quickly figure out what each response 'means'.
> 
> This sort of detracts from the experience, as far as I am concerned.
> After all, if you want to just distribute points among your stats, it's
> far easier to just do it manually than by this convulted method.
> This works vastly better when there are a myriad of questions, arranged
> in a tree so that you only see 8 or 10 out of 50 possible questions.
> Possibly the same questions would pop up but with different choices for
> your answers.  In addition, they shouldn't have simple, gaugable effects
> like +3 con, they should bonus and minus to many stats and skills, and with
> slightly randomized effects.

The main advantage to using lifepaths rather than using a straight
point system is that the character comes out with a history instead
of just a set of numbers.  Making that history more detailed can 
give people role-playing hooks.

For example, if a player chooses a stint in the army as part of the
character's lifepath, the system could randomly choose a unit that
the character served in.  Once character generation is over and the
character's age is known, it could then calculate backwards to figure
out the time period that the character was in the army and supply
names of battles, wars, or whatever that the character would have
participated in.

This can allow things like this:

John:  So, you were in the army?  What unit?

Jim:   I was in the 104th Dragons.

John:  Hey, that's my old unit!  When were you in?

Now, I've never seen a lifepath system that detailed... but it's certainly
possible.  :-)

> One last note: I think it's ridiculous that people need to 'stat hunt' on
> some muds.  Hey - if I want a strong character, why not just let me make
> one?  I'm gonna get it sooner or later, whether I have to do it via random
> rolling or via just selecting the option, "You are particularly large and
> strong for your race."
> 
> A simple example, but rarely do I see this sort of thing.  At best you
> get to choose the order of your stats, so that your best die-roll goes to
> the first choice, the next best to the next choice, and so on.

I agree.  This sort of thing is why I prefer point systems and lifepath
systems.

IMHO, a better way of having people create characters than the traditional
one would be to let them create characters via one or more web-based
forms.  This would make it easier for players to start over, change
their minds, etc., than doing it through a series of questions and
answers on the mud.  It would be possible to allow players to back up
and change their answers through a mud text-based interface, but it would
require a good deal of additional programming.

Using JavaScript or VBscript for the forms could move some of the 
calculations off the server.  Of course, you'd then need to have the
server check the data which comes back to make sure that people aren't
downloading your form, seeing how it works, and then trying to cheat.

An idea I had along those lines a while back... instead of allowing
players to actually choose how many points to put into attributes
and skills, use the numbers they put in as priority levels.  Thus, if
someone puts in a 20 for strength and a 10 for dexterity, it just means
that strength is twice as important to him/her as dexterity.  When the
server receives the form back, it can use those priorities to decide how
to split up points.  Thus, someone who puts down that he wants a high
score in everything will find that he gets an average score in everything.

> Hmm, this also brings up the issue of number-hiding.  Good or bad, and if
> so, how to implement it?  I realize most of the folks on this list come
> from an LP background; my experience with LPs has been that they show you
> all the numbers right up front, at least those that have stats and skills
> as a major part of gameplay.

I don't have any problem with displaying numbers, so long as things are
kept reasonable... if you use a name-based scale, players pretty quickly
learn what's better than what, and by approximately how much.

Personally, I prefer to give players info about stats and other things
that the characters would know fairly well in terms of a 1 to 10 scale,
where 5 is human average and 10 is human maximum.  This doesn't have to
be the scale that's actually used internally, though.

Where I *don't* like specific numbers is in things like hit points...
a character should have an idea of how tough he/she is and how wounded
he/she is, but there should be some doubt as to exactly how far down
you are, to help keep players on their toes.

> This would actually all work pretty well, except for a nasty little thing
> called breakpoints.  This is a problem which plagues all RPGs, but I find
> it most annoying in muds.  That is, only certain points of stats cause
> 'rollover'.  Thus having a 90 con is the same as a 99 con, but a 100 con
> is vastly better than a 99 (or 90, for that matter).  Why?  Mostly
> it's because muds still rely on tables, ie:
> 
>   hitpoints = hp_table[ch->class][ch->con / 10];
> 
> Of course the simple solution to this is to make it a formula:
> 
>   hitpoints = ch->con * ch->level;
> 
> Assuming you had levels and hitpoints (we don't), of course.

Hmm... none of the muds I've worked on has used tables or had 
breakpoints like this... but I'll take your word for it.  :-)

> Ours is very similar to this.  We solved both of these problems, as well.
> For the first - we use static random generation.  That is, we seed the
> generator with they player's (unique) id number, so that the same sentence
> said by the same person with a given skill in a language will always
> result in the same words being outputed.  This is the same method we
> use for many psuedorandoms - for instance, hiding in a room, the player
> will _always_ get the same random generation (just make a dword from the
> room's x/y/z coords and the low eight bits of their id num).  Thus the only
> way to change whether they can hide in a room or not is to modify other things,
> such as their skill with hiding (or, their skill in awareness if they are
> the viewer), or the concealment value for the room (if possible).
> The second case (saying complex words perfectly but screwing up 'the'),
> we simply make a skill roll for each word, and the difficulty is assumed to
> be exponentially more difficult as the word gets longer.  The result is that
> if you don't know the language well, you're best off speaking in short words,
> or breaking up your long words.

I like the idea of using predictable seeds for the random number
generator... it reminds me of a rule that the paper RPG Arduin has:
namely, that when it comes to things like picking locks, saving 
against spells, etc., you only get one try.  If you fail, you'll
always fail unless either the situation changes (i.e., modifiers 
give you a better chance) or your level goes up.  Conversely, if
you *make* a saving throw against a mage's spell, you'll always 
make it until either the situation changes against you or the mage
goes up a level.
--
       |\      _,,,---,,_        Travis S. Casey  <casey at cs.fsu.edu>
 ZZzz  /,`.-'`'    -.  ;-;;,_   System Administrator, FSU CS department
      |,4-  ) )-,_..;\ (  `'-'     (904) 644-7339; Room 011 Love
     '---''(_/--'  `-'\_)       No one agrees with me.  Not even me.
  rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html