Mixture

[Nathan Yospe]

On Tue, 25 Mar 1997, Travis S Casey wrote:

: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.

Even better is to force them to choose their age first, then mash their
Character into a database of local histories and potential experiences in
each locality, broken by age. I'm working on this for Physmud++ (I use it
for my paper and pencil game, running a four hour solo session with each
new player to create this "history") For example, a human choosing to be
35 years old will be given a choice of birthplaces (lets see, 35 makes
them born in the year 2287... about the time of the explosion... human
colonization to this point has been tentative, so the player gets a choice
of about a dozen locations on earth or one of three colony ships... this
being 5 years before the breakthrough that makes long range instantanious
travel cheap), be told a little about their parents, then worked through
their earliest memories. At about age 5 (for the ones with rougher
lifestyle rolls) up through the age of 13 (for the rich kids) they start
getting decisions to make at critical junctions in life. In between, they
get a steady scroll of story. When they reach the year 2322 (eventually, I
may change this, but not soon.. for now, the year zero is uniform) they
are cut loose into the world. They know their past, they've been
traumatized by the near past (five years in a prison camp for the luckiest
humans in the galaxy) and the present is bleak. The future is up to them.

: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.  :-)

Well, aside from the year zero flaw, mine is about that detailed.
Incidentally, the years I gave are human terms... the year, galactic, is
only 63. (The invasion was in the year 52 GS) Not that that means
anything, aside from the fact that I've got a 200 year detailed future
history. (and, not wanting to waste it, I've made a book of it. Soon as my
first book becomes a national bestseller <yeah, right> I'll publish it.) I
enjoy writing the ultimate codebase (tm) as muchg as the rest of you, but
I also enjoy writing the perfect world. One reason I hate free user
programming.

:> 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.

Hmmm. I guess. I like making it a one way street. Then again, its not just
a questionair, and some questions are only asked (most, in fact) if
another question has been answered a certain way.

: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.

Or just encode the sucker. As in, make the interpretation meaningless
except to the server.

: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.

That's a good idea. I still have the (pre birth) stat rearangement. Its
sort of a "you have these points to divy up among these attributes. Please
remember that these are not the final attribute values, and that these are
just bonuses, so an attribute left at zero is not zero." The point is,
sometimes this swings life choices. Essentially, the guide, once I've fine
tuned it, should account for greater strength or cunning by providing the
character with a background involving more physical labor, etc.

:> 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.

not if its a representation of something very complex and dynamic, and the
names are situationally cued. "Your arm is screaming in agony, sending
spasms of pain through your shoulder every time you jostle it!" might be
the result of a broken arm, or possibly a burned arm, though you would
know from memory, which of the two it was, or could deduce from the
blisters that it was a bad burn... how bad? Well, you are no doctor, but
it hurts like hell. (A medical skill would get you a lot more info, of
course.)

: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.

I tend to think that RP flows more easilly if they learn of injuries from
the perspective of their characters.

: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.

Of course there should. Like I said above, the guy isn't a doctor, so he
has no clue what the severity of the burn is (or that he's gonna get
gangrene if he doesn't get it treated. Preferably by amputation and
cybernetic replacement.)

:> 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.  :-)

No clue here, either. I use a structural integrity formula for physical
damage, with mental health being a special kind of structural integrity.
In other words, a lot of things can happen to a Character aside from the
immediate damage... shock, simple death from pain, insanity from pain,
torture, etc... 

:> 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.

I like this idea myself. I had avoidede randomness altogether for the sake
of repeatability, but this sounds awfully nice.

   __    _   __  _   _   ,  ,  , ,  
  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
 /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu