Re: remarks on implementation of various skill proposals

["Brian Thomas" <thomas@astro.psu.edu>]

	Hey all, ...some return thoughts.....,
 
ON EXP AWARDING 
 
> Awarding experience is a big pain.  How do you award experience without
>allowing abuse?  For example, once I proposed that clerics be given exp.
>for healing friendly players.  Someone pointed out how readily you could
>
	Well. How about exp for healing monsters? Missonary work :)

>   About the only viable means of awarding exp in the game is via kills of
> monsters.  (A trap is just another kind of 'monster', really.)  Alternately,

	I strongly disagree. With proper forthought using each of the skills 
could be a source for experience. For example.. lockpicking, *any* of the 
idenification skills, etc. would be hard to abuse. Let's face it though, 
some one can *already* abuse the current system by bracing their character
in front of a portal and just kill monsters created by a generator on the 
other side. With enough time (bracing does decrease the exp gain) there is 
*no* limit on how much exp you can gain. What matters is not whether it is
*possible* to cheat, but rather if it is *easy* (or worthwhile) to cheat that 
way. A little forthought with the skills would be what is needed. BTW, I
see no reason not to allow spellcasters some reasonable amount of exp for 
successfull casting. 
 
ON SKILLS

> where there is now one.  Furthermore, skills as someone (i forget who)
> is currently implementing them don't seem to involve experience at all.


	I am currently implementing the skills. Some skills (2-4) do increase
in effect with level, but you are basically correct. I had decided to leave 
the issue of experience effecting (and being gain though the use of) skills
for the future. I guess the future is here now :)


> I'd rather see:
>	1)  there CAN be so many skills that it becomes a mental burden for the
>		player

	Are you being serious here? I note that there are currently about
130 spells in CF; do you think that this is a "mental burden"? If it were,
would you advocate removing some of these spells?!? I rather think lots of
spells adds color to the game. There can never be too many. Ditto for 
skills. Only poorly designed skills (or spells for that matter) should ever
be 'removed' from the game.  


>Undetermined number of skills
>---------------------------------------
>
>I really am not sure how those advocating this were thinking
>of implementing it.  Here's one possible approach to implementation:
>
>Re-implement skills as objects.  When you do a relevant action,
>you find the skill object in that person and add experience to it.
>(I'd appreciate if someone would fill this out.)

	Ok sure :). Skills (as currently implemented) are objects in the 
inventory of the player. Adding an exp field (to only be used by skills
objects) would allow keeping track of a character's exp in each skill.


> Cons:

>  Losing your inventory could destroy your skills

	How often does a player's character loose their inventory??? I 
have never had this happen. 
 
>  inventory search needed for knowing what skills exist

	Yes, that is how it is done now. In monsters this is'nt a problem,
and really isnt much problem for most players either. What could be 
done is that the object structure could have a pointer to 'next_skill' and
the player structure could point to the 'first_skill' ie 

	first skill in list		op->contr->first_skill
	second skill			op->contr->first_skill->next_skill
	etc.

>  coding complexity of assigning experience based on skill when
>  you have a multitude of them


	This is true. Play testing would be required to 'tune' this. Not trivial
	to do.

>   GUI complexity of displaying what skills are around.

	I don't follow you here. Skills as impletmented are either visible 'tools'
(like lockpicks) which allow the use of skills or are invisible. The 'tools' 
very naturally should be in the inventory window, whereas the inherent 'player'
skills are not visible. A command 'skills' currently lists all available skills.
Were we to have each skill having exp, the 'tools' implementation would have to 
be rethought.  


								b.t.