From alex_sch at telus.net  Sun Jul  1 00:05:15 2007
From: alex_sch at telus.net (Alex Schultz)
Date: Sat, 30 Jun 2007 23:05:15 -0600
Subject: [crossfire] Organizing efforts, was Re:  Project: New Intro
In-Reply-To: <4686FA14.8020105@sonic.net>
References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net>
Message-ID: <4687360B.6030208@telus.net>

Mark Wedel wrote:
>   The original mail in question had what I really two different topics - one for 
> the idea of redoing what players see when they connect, and a second about group 
> efforts to get things done in a timely fashion.  This mail more focuses on how 
> to do group efforts - ideally to come up with some scheme that can be used as a 
> model, because as Ryo pointed out, there are lots of big projects on the list 
> beyond just a new starting village.
>   
Indeed I did have those two topics combined in there. Indeed there are
lots of other big projects, but I was just trying to pitch what seemed
most reasonable to me to be a starting place :)
Perhaps I may have been somewhat hasty in rushing to trying to suggest
one particular project, however I was rather anxious to see things
happen and I was, and still am, concerned that the decision making
process could be too slow or even stall.

>   Some projects/changes may have dependency issues (rebalancing spells should 
> likely be done after redoing classes/races as an example). Those need to be 
> identified and ordering sorted out.
>   
Perhaps map out all proposed big projects in including their
dependencies, and create a sort of vague roadmap which could be posted
on the site somewhere, which would be revised to include a marker for
what is the current project once it's been agreed on. Perhaps this may
sound a touch overengineered, however I think that such a roadmap could
be made quick and simple with Graphviz and would make it easy to see
what priorities and possible future priorities may be including
dependencies. Anyways, this little paragraph of mine is getting a little
off topic into the technical implementation details which are of
relatively lesser importance.

<snip>

>   In this particular case, I agree that a new intro should be something at the 
> top of the list.  But going forward, I think we need some way to decide what is 
> done.
>
>   In the context above, developer is anyone that is willing to help out to get 
> the project done - doesn't mean coder, could be map maker, artist, person 
> writing documentation.  but someone that just plays the game probably shouldn't 
> be included, as that isn't going to help get the project done - my idea here is 
> that you want the project decided on by those actually going to do the work. 
> One the project is decided on, all are welcome to pitch in ideas, etc.
>   
Yes, this makes sense: That the project would be decided on by those who
feel committed to trying to do what they can for the project that is
decided on.

>   So after the project is decided, there needs to be a project leader.
In some ways, it may make sense to have project leaders decided before
the project, in that each proposed project prior to deciding which one
would have a developer assigned to the project who feels competent with
the project at hand and comfortable with the leadership role, which may
often be whoever had the biggest hand in proposing that particular
project. This might shave a little time off of deciding on a project
leader and avoid disputes, though it may not, but just a thought.

> Depending on the project, what that means may vary.  But I would say that the 
> leader should come up with a plan detailed enough that it can be divided into 
> work by several people.  An example would be maps - having broad outlines of 
> what should be done is a good starting point, but having a 1 or 2 line 
> description of what is needed on the maps then provides folks enough detail to 
> work on it.  For coordination, putting this chart on the wiki, and people 
> signing up for parts of it is probably a good way to go.
>   
Yes, agreed. And just as a little note/tip/plug, dependency charts of
tasks within the project could also be done quick n' dirty with Graphviz
in a clear format if the project leader believes it would be useful :)

>   I tend to think that it is best of the project lead starts by sending out a 
> fairly detailed document - the reason I say this is that a fair number of 
> developers have been around a long time, and can probably come up with a fairly 
> complete starting plan without a lot of input.  They should still send that out 
> and get input, but having a good starting point may trim a week or two off the 
> discussion, and also provide a clearer picture to everyone what the idea is. 
> Some of the basis here is also that some points have already been extensively 
> discussed in the past - new points are welcome, but we don't necessarily need to 
> fully discuss all the issues again.
>   
Yes, this makes sense to me

>   Once the plan is more or less agreed to (hard to get 100% agreement), people 
> start working.  In fact, work may start before this, as there may be some points 
> which everyone is in agreement on, and it may be more adding new points/details 
> to the plan.
>
>   The role of the project lead/coordinator is to take the pieces and make sure 
> they all work.  In the case of the map example, look over the maps, make sure 
> they meet various standards, basic idea behind the map, and link up the exits, 
> etc (possible that some maps completed before the ones they link to).
>   
Indeed, this type of role is important (and is some ways something I
feel we've been lacking to an extent in the project in general)

>   All projects should be worked on until fully done.  If a new NPC speech method 
> is done that requires modifying the NPCs, it isn't sufficient to put that new 
> support in and modify the NPCs in scorn and say 'it is ready' - that project 
> isn't done until all the NPC's on all the maps are updated.  Otherwise, past 
> experience shows that those other NPCs probably won't get updated.
>   
Yes, we often get too much in the way of sparsely used features and this
policy may help avoid that (hopefully).


Alex Schultz


From crossfire at kahnert.de  Sun Jul  1 01:43:46 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Sun, 1 Jul 2007 08:43:46 +0200
Subject: [crossfire] Organizing efforts, was Re:  Project: New Intro
In-Reply-To: <4686FA14.8020105@sonic.net>
Message-ID: <20070701064346.GA869@cthulhu.desy.de>

On Sat, Jun 30, 2007 at 05:49:24PM -0700, Mark Wedel wrote:
> This mail more focuses on how to do group efforts - ideally to come up
> with some scheme that can be used as a model,

Is there a list of deciders?  Who needs to nod, before something could
be implemented?

If there is no such list, create it.  Or better extend the developer
list with the responsibilities.


> there are lots of big projects on the list beyond just a new starting
> village.

On the CF 2 todo list are a few high priority projects.  Most of them
are independent (without dependencies to the other projects).

"Character Creation" and "Game Balance" have a strong dependency by each
other.

Those two needs the highest priority for CF 2, and it has to be clear
what's the goal before a single line of code is written for it.


> Some projects/changes may have dependency issues (rebalancing spells
> should likely be done after redoing classes/races as an example).
> Those need to be identified and ordering sorted out.

Exactly.  Touching this part of the game means, you have to abandon old
characters.  Everybody has to start over with a level 1 character.  You
can't change the game balance and keep the old unbalanced characters.

This has to be clear and stated.


> But for any volunteer project, it is difficult to force people to do
> anything.

It's not necessary to force someone.  It's finished when it's finished.
You don't have to pay a contract penalty if you can't keep your
timeline.


> My thought here is that each month (or maybe more/less frequently,
> based on how long it takes to do the different things), the developers
> should decide what is the most important thing to change/add/fix.

If one project is finished, than there are free capacities and that's
the time you have to decide what's made next.  Should they help others
to finish their project faster or is there another project needs to be
done?  There is no need for peridical polls about the priority.


> In this particular case, I agree that a new intro should be something
> at the top of the list.  But going forward, I think we need some way
> to decide what is done.

See beginning, who are the decision makers?


> but someone that just plays the game probably shouldn't be included,

I don't think so.  They can help testing.

If you like to rebalance and reorganize the world, you need player who
likes to test it.

I think about a set of standard characters on different levels.  How
does it feel to solve the map as a sorcerer on level 5 compared to a
warrior on level 5.  Is it possible with a fireborn, what's the
challenge for a dragon, ...?

Create a standard character for each class on different levels.  Don't
say this is a level 5 map if not all the level 5 standard characters
classes passed through it.  Maybe you'll see that this map is a level 1
dragon warrior map but a level 8 fireborn sorcerer one.

Yes, this needs extensible testing and this will only be able with a lot
of players.  You'll need a "game balance coordinator / leader " which
will collect the player comments and discuss this with the developers.


> I tend to think that it is best of the project lead starts by sending
> out a fairly detailed document - the reason I say this is that a fair
> number of developers have been around a long time, and can probably
> come up with a fairly complete starting plan without a lot of input.

And I think that you should develop the idea with the others.  Out of
the discussion the leader has to make a detailed concept.

Creating a detailed document and nobody likes the idea is a waste of
time.


> Some of the basis here is also that some points have already been
> extensively discussed in the past - new points are welcome, but we
> don't necessarily need to fully discuss all the issues again.

Instead of discuss it all over again, send the link to the archive.


> Once the plan is more or less agreed to (hard to get 100% agreement),

And again, who has to agree before the work should be started?


> but lots of things has been extensively discussed, and all the
> discussions in the world don't really make it so that the project gets
> done any faster.

That's the coders point of view: "need to code", "can be changed later",
... ;)

If something is already extensively discussed, than there has to be a
summary and a concept for the work plan.  If this is missing, the
discussion is not finished, yet.

    J?rgen




From nicolas.weeger at laposte.net  Sun Jul  1 03:45:10 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Sun, 1 Jul 2007 10:45:10 +0200
Subject: [crossfire] classes & guilds, was Re:  class guild map
In-Reply-To: <4686EDDC.9060203@sonic.net>
References: <20070630183324.GA15855@cthulhu.desy.de>
	<4686EDDC.9060203@sonic.net>
Message-ID: <200707011045.14482.nicolas.weeger@laposte.net>

>   One problem with this approach is that skill scrolls now become value for
> all classes and all levels (until such point as you've minimized the
> affinity for all your skills).  Which I'm not positive is a good thing -
> we've had things like this before (in particular, scrolls of identify) -
> the 'fix' for that was to add identify tables so that low level characters,
> or those not first to run to the mage shop after it reset, could identify
> their items.
>
>   I have no problem with the general idea, but I think that any reduction
> in affinity should be done through quests (guildmaster teaches you
> something after completing quest, or some quest item reduces it).  I don't
> think having it changed on the whim of random treasure showing is that
> good.

What about we simply remove skill scrolls? Or seriously reduce their 
frequency?
I think one could acquire a skill either "randomly" (drop in water a few 
times, you start knowing how to basically swim - but you can't progress 
much), or through some masters (want to learn karate? then find a dojo where 
to train, and acquire basic skills, and when you're somehow higher level you 
can train for higher level access).
Of course not all skills would necessarily work like that (how do you train 
woodsman without really using it?)


Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'al?atoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/c0805d9a/attachment.pgp 

From nicolas.weeger at laposte.net  Sun Jul  1 03:57:52 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Sun, 1 Jul 2007 10:57:52 +0200
Subject: [crossfire] Organizing efforts, was Re:  Project: New Intro
In-Reply-To: <4686FA14.8020105@sonic.net>
References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net>
Message-ID: <200707011057.55792.nicolas.weeger@laposte.net>

>   My thought here is that each month (or maybe more/less frequently, based
> on how long it takes to do the different things), the developers should
> decide what is the most important thing to change/add/fix.  My rationale
> here is that if the developers agree that some issue is most important,
> they are much more likely to help out.  If the general developer response
> is 'that isn't very important', then you could pretty much figure they
> probably aren't going to put much effort in.  Note it may be reasonable to
> do less frequent votes, on the basis that after the top priority is done,
> whatever was #2 probably makes sense to be the next top priority, etc.  But
> new projects may pop up, or the completion of one may spawn a new one
> (before such and such feature was added, no one thought of something or it
> wasn't feasible).

No, not developers. Developers *and* players. I'm afraid developers deciding 
will lead back to current situation, focused on the code and not contents.
For us it's sometimes sexier to document the whole code than fix a messy 
complex bug that isn't too important (but still bothers players) :)
One important thing, though, is documentation. We should clearly document 
things, so we have 1) reference when something seems strange 2) detailed 
explanation non coders can understand and comment on (example: bracers will 
add armour, but only if it's the "best" armour bonus - thus if you cast a 
spell giving armour+5 your bracer armour+2 won't have any effect ; or how 
resistances / immunities work).

>   In the context above, developer is anyone that is willing to help out to
> get the project done - doesn't mean coder, could be map maker, artist,
> person writing documentation.  but someone that just plays the game
> probably shouldn't be included, as that isn't going to help get the project
> done - my idea here is that you want the project decided on by those
> actually going to do the work. One the project is decided on, all are
> welcome to pitch in ideas, etc.

Player feedback is important. I would even say that's the critical thing, else 
we end with a developers-only game.

>   I tend to think that it is best of the project lead starts by sending out
> a fairly detailed document - the reason I say this is that a fair number of
> developers have been around a long time, and can probably come up with a
> fairly complete starting plan without a lot of input.  They should still
> send that out and get input, but having a good starting point may trim a
> week or two off the discussion, and also provide a clearer picture to
> everyone what the idea is. Some of the basis here is also that some points
> have already been extensively discussed in the past - new points are
> welcome, but we don't necessarily need to fully discuss all the issues
> again.

Again, developers will focus on code, whereas we need also players.
Once something is decided, yes we can start doing code / preparing for coding 
tasks. Not before.

>   The role of the project lead/coordinator is to take the pieces and make
> sure they all work.  In the case of the map example, look over the maps,
> make sure they meet various standards, basic idea behind the map, and link
> up the exits, etc (possible that some maps completed before the ones they
> link to).

No, the role of the coordinator is to make sure the work is done, he's not 
necessarily the only one working :)

>   I don't mean to have draconian policies in place in the above - in fact,
> just the opposite.  What I really want is something in place so that
> projects can be decided fast, what needs to be done decided fast, and that
> broken down into pieces so that it can be completed rapidly.  That's not to
> mean without thought, but lots of things has been extensively discussed,
> and all the discussions in the world don't really make it so that the
> project gets done any faster.

We do need a draconian policy on some things, though. IMO, we should reject 
things if they don't bring anything to the game, or are messing with other 
things.
As an example, I'd say my logger and newspaper plugins shouldn't have been 
committed in their current state - they are basically useless for now, and 
didn't really correspond to any needed feature.
So we should forbid some commits sometimes, else the code will go astray.


Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'al?atoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/1cd1228b/attachment-0001.pgp 

From crossfire at kahnert.de  Sun Jul  1 07:27:36 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Sun, 1 Jul 2007 14:27:36 +0200
Subject: [crossfire] classes & guilds
In-Reply-To: <4686EDDC.9060203@sonic.net>
Message-ID: <20070701122736.GB869@cthulhu.desy.de>

On Sat, Jun 30, 2007 at 04:57:16PM -0700, Mark Wedel wrote:
> Juergen Kahnert wrote:
> > Doesn't show the level itself the knowledge about a skill? Is having a
> > "master level 1" better than "basic level 50"?
>
> No.  If you are master level 10, and basic level 10, the skill
> operates the same.

I would say, no, the master should be better.  How?  Just use the
"affinity" value to modify the effect of a skill.

A warrior with a high affinity to one handed weapons should be able to
do more and "better" damage than a clumsy one.

You could use it as a divisor for the damage.  The lower the affinity
value the higher the damage and vice versa.  This won't work for every
skill, but most.  If not the damage, than the chance like for alchemy.
Or the duration like hiding.


> The difference is that it may take a character 4 times as much exp to
> get to basic level 10 as it takes a character to get to master level
> 10.

For example, if you compare two karate black belt fighter, both have the
same level (black belt), but they could have a totally different skill,
because of the natural talent / ability (here called "affinity value").

Someone who trained really hard may be able to beat someone with a high
natural ability who spent less time training.


> Reducing the exp gain is a very easy way to add some difference to the
> classes/skills.  Level caps would be another way (I know that this may
> not be liked, but if you instead say 'this class just doesn't get a
> skill', that is basically the same as a level cap of 0).

I don't say to deny a class a specific skill.  Just make it harder to
master and without advice of the guild masters, no chance to discover
the deepest knowledge.  This is because the guild masters have access to
the studies of generations.  If someone has to learn it all by himself,
he has to live very, very long. ;)


> > Every skill level you're able to read one skill scroll to decrease
> > the "affinity" value. And make skill scrolls a rare item.
> >
> > Only the class skills will be allowed to decrease below 1. And
> > skills unlikely to the class not below 2.
> >
> > This could be fine tuned if you like the idea.
>
>   One problem with this approach is that skill scrolls now become
> value for all classes and all levels (until such point as you've
> minimized the affinity for all your skills).  Which I'm not positive
> is a good thing

Ok, no problem.  Use a marker on every skill.  This marker will keep the
xp of the skill a character has by reaching a new overall level.  Now
calculate how much [overall] xp was gained through which skill.  And
those skills above e.g. 15% will decrease the affinity value.

This needs some tuning as well, and is independent from skill scrolls.


>   I have no problem with the general idea, but I think that any
> reduction in affinity should be done through quests (guildmaster
> teaches you something after completing quest, or some quest item
> reduces it).

This could be also done.  Add a flag which will decrease the affinity
value after reaching a new value.  Either by reaching a new overall
level or after reaching a new level of the skill.  This flag could be
set by the guild master, quest reward or whatever.


> I don't think having it changed on the whim of random treasure showing
> is that good.

As always, I just offer options how it could look like.  I'll never say
it has to be like this. ;)

Hopefully we're able to find a good solution for more fun with CF. :)


> So it is a matter of modify the treasurelists as needed to have
> different sets of skills for different classes.  Right now, there is
> something like a 'basic skill' treasurelist, which contains all of the
> basic skill everyone starts with (search, disarm, melee weapons, etc).
> Those need to get altered, so fighters get good versions of the combat
> skills, and mages get the bad versions, instead of everyone getting
> the same.

Or just stack them.  For example, if a fireborn gets 20 advances of the
skill pyromancy and the pyromancer also 20, stack them together and
advance the skill 40 times.  Starting with an affinity value of 5 with
an reduction of 0.04 * affinity value per advance, you end up with a
starting affinity level of ~1 for pyromancy as a fireborn pyromancer.


> I don't see any reason that every character should be able to learn
> every skill.  And in fact, right now there are a few special class
> limited skills (meditation comes to mind as one that can not be
> learned later)

Good example.  I've no idea why meditation shouldn't be learnable.  Even
if you never meditated so far, you'll be able to learn it (in the real
world).  Same for other things.  You're able to join a karate club and
learn karate, ...

Only because other role playing games have hard limits for races and
classes doesn't mean you also have to implement them.  Yes, copying
things is easier than develop new ones and may be more safe, but it's
not the case that it has to be always the same.

Same for weapon / armor restrictions.  Extend the bonus malus system on
weapons and armor.  A mage shouldn't like to use heavy armor because
this makes him fumble the spells more often and heavily reduces the
spell points regeneration.  A fighter wouldn't care nor notice the
malus, but a mage.


> The idea of skill/class reform in terms of archetypes doesn't
> need/have to conflict with the idea of guilds.  With all the changes
> above, there is nothing to prevent there from being fighters guild -
> but instead of it being based on class, it is really based on your
> skill level.

Sure, I thought we already agreed with that.  A guild will be based on
the skill level (way of living) instead of an initial class.  With the
initial class you are a member of the specific guild of that class, but
that doesn't mean you can't change if you follow the rules of another
guild(s).

Do you like to see me writing a summary / draft concept of the new skill
/ class / guild system?  Or do we need more discussions about specific
parts?

    J?rgen




From nicolas.weeger at laposte.net  Sun Jul  1 16:51:28 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Sun, 1 Jul 2007 23:51:28 +0200
Subject: [crossfire] classes & guilds
In-Reply-To: <20070701122736.GB869@cthulhu.desy.de>
References: <20070701122736.GB869@cthulhu.desy.de>
Message-ID: <200707012351.32009.nicolas.weeger@laposte.net>

> Good example.  I've no idea why meditation shouldn't be learnable.  Even
> if you never meditated so far, you'll be able to learn it (in the real
> world).  Same for other things.  You're able to join a karate club and
> learn karate, ...

One game I saw worked by "skill spots". I don't remember the values or the 
details, but the general idea was: characters had like 20 spots, which could 
be filled by skills, with 1 spot for basic skills, 2 for advanced ones, and 3 
for master ones. There was a "graph" dependancy, some skills required other 
skills at a certain level.
Players could "drop" skills, or reduce their spot, to use other ones.
Not totally sure about the way that was done, though (didn't play, just saw 
someone play).


As for the general idea for skills, I think it's nice to be able to learn all 
skills (except intrinsec skills, like levitation or clawing - though with 
nails? <grin>).
But we definitely need to balance that somehow, through maluses/bonuses, 
things like that.
And I wouldn't oppose to skill restriction, either :)


> Do you like to see me writing a summary / draft concept of the new skill
> / class / guild system?  Or do we need more discussions about specific
> parts?

I'd say you can write a first quick summary, preferably on the wiki 
(http://wiki.metalforge.net just create a page somewhere, maybe linked from 
another - which one, not sure) :)

Doesn't mean it's set in stone, but would be nice to have a full summary, I 
think :)

Of course we can still go on discussing on the list.

Thanks for all ideas :)

Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'al?atoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/f4b561b6/attachment.pgp 

From nicolas.weeger at laposte.net  Sun Jul  1 16:53:25 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Sun, 1 Jul 2007 23:53:25 +0200
Subject: [crossfire] reorganizing the entire world
In-Reply-To: <20070629194924.GE11217@cthulhu.desy.de>
References: <20070629194924.GE11217@cthulhu.desy.de>
Message-ID: <200707012353.25879.nicolas.weeger@laposte.net>

> > 3) Like point #1 for scrolls in maps, also extend it to NPCs.   So the
> > various NPCs in scorn could also talk about the goblins around the
> > area, and perhaps other things.
>
> Yes, similar to my idea of giving every NPC knowledge about the world.
> Give them extra knowledge about the region, and this will be perfect.

Related, even if not totally what you meant: we should definitely use the lore 
from the wiki, and/or expand it to cover the world. So places have historic 
facts, some background stories, which have consequences (Brest is isolated 
from the rest of the world, do you know why? check the wiki :p)


Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'al?atoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070701/0ff35485/attachment.pgp 

From mwedel at sonic.net  Sun Jul  1 23:53:13 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Sun, 01 Jul 2007 21:53:13 -0700
Subject: [crossfire] classes & guilds
In-Reply-To: <200707012351.32009.nicolas.weeger@laposte.net>
References: <20070701122736.GB869@cthulhu.desy.de>
	<200707012351.32009.nicolas.weeger@laposte.net>
Message-ID: <468884B9.4000105@sonic.net>


  To quickly follow up on some points:

I am not adverse to all races/classes starting with all skills (save those 
intrinsic ones like Nicolas mentions), but with a fair number being really poor 
versions.

  For example, the fighter would have good versions of things like melee 
weapons, bow, perhaps smithery, and really bad versions of the wizard ones 
(pyromancy, evocation, etc).  This also does cover the place - everyone can in 
theory swim, but those with bad versions may have a very hard time to get exp in 
it, and thus can never swim very well.

  It seems that there is a fair amount of debate exactly how the different 
versions of the skills operate.  The basic division seems to be:

1) skills operate the same, just harder to get levels in ones you are not good 
at.  So a person with crappy version of evocation at level 10 casts the same 
spells just as effectively a person with a good version of the evocation skill 
at level 10.  It is just that crappy version took a lot more work to get to 
level 10.

2) Skills operate different.  A person with the good version of evocation at 
level 10 casts spells much more effectively than a person with crappy evocation 
at level 10.  I'd think that in this model, the exp gain should be the same - 
that is to say that the crappy version needs the same exp total as the good 
version to get to level 10.  The difference here is that it becomes harder with 
the bad version, because the spells don't do as much damage, so you need more of 
them, etc.  I say that level gain should be the same, or close, as otherwise you 
are really punishing those with poor versions of the skills - not only is the 
skill not as effective, but you need more exp.  You can of course do that, but 
then at some point, it is almost what is the point of offering such skills in 
the first place.

  Note also that in many cases, point #2 really looks like point #1.  For 
example, for disarm traps, you basically either disarm the trap or don't, and 
those odds are based on level, difficulty of trap, etc.  Presumably with method 
#2, the character with the bad version gets less benefit from their skill level, 
so effectively this just means that the bad version of level 10 is the same as 
the good version at level 3.  So you don't really gain much in this case, except 
for guilds that look at minimum level (but then the question comes up, should 
they also take the version of the skill into account?  A person with the poor 
version at level 10 should be treated differently than a person with the good 
version at level 10.  At some level, it almost seems that a bunch of complexity 
is being added, and internal at some level, everything is getting adjusted skill 
level, and using method #1 in that case is a lot easier.

  The original point of redoing skills/classes was the general complaint that at 
higher levels, all classes look alike, becuase all classes/races have the same 
skills at high levels.  From some of the discussions here, I'm not sure if 
everyone actually thinks that is an issue, and instead of fixing the 
classes/skills, the idea is to enforce/add differentation by guilds and special 
perks.  In that case, this could be the easiest:

3) There is no classes - every starts with same version of all the skills, and 
what they become is based on what skills they use.  A person using magic would 
be in the mages guild, a person using melee skills in the fighter, etc.  This 
becomes a pure case of you are what you practice.  Characters may look the same 
at higher level, OTOH, if the guilds do offer special benefits, maybe not.  This 
doesn't require any code changes - the real change that would be needed is some 
new way for characters to get starting equipment (as that is one of the big 
differences between classes right now - mages start with spellbooks, fighters 
with arms and armor).



From mwedel at sonic.net  Mon Jul  2 00:22:27 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Sun, 01 Jul 2007 22:22:27 -0700
Subject: [crossfire] Organizing efforts, was Re:  Project: New Intro
In-Reply-To: <4686FA14.8020105@sonic.net>
References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net>
Message-ID: <46888B93.2060705@sonic.net>


  Quickly catching up with followups:

  I'm not sure we really need graphs to track dependencies - I'm not sure they 
are that complex (there are not that many).  What is really needed is to just 
note what the dependencies are, so we can know there is no reason to bring spell 
reform to the table until class/race/skill changes are done.

Having project leaders before the project is worked on/voted on makes sense. 
And as I think about it more, it would generally be good to have the detailed 
project plan before voting, so people actually know what they are voting on. 
OTOH, writing up project plans for all the potential things to do is a daunting 
task.  The flip side is that if someone is willing to write up the plan, there 
is probably at least one person willing to work on the problem.

I'd expect in most cases the vote to be pretty clear cut.  I think each vote 
would have to be limited to the top 5 (or so) most important projects, which is 
probably decided by the person running the vote (but once again, I think the 
seasoned developers would have a pretty good idea).  Certainly anything that has 
a dependency on it should almost always be on that list.  And certainly opinions 
could be solicited for what should be on the voting list.

As stated in my original message:  The reason that only the developers vote on 
the next project to work on is because it is the developers doing the work.  The 
testers are important, but for the most part, they are not going to help get the 
project get done.  Likewise for the players.  A big concern I have is that if it 
is opened up to non developers, we'll get a vote that basically none of the 
developers (or too few to for meaningful team) agree with.  So the players say 
'foo should be done first', and developers say 'I could care less about foo'. 
End result, foo is never done, and this system fails completely - if the vote 
has no meaning, why do a vote?

I didn't really state it, but my expectation is that for the top priority 
project, as many developers as needed work on it.  I'd think that in most cases, 
that would probably top out at 4-6.  If only 1-2 people are going to work on 
each project, there really isn't any point to this process - the person working 
on the project would just go an do it, and can coordinate with that other person 
(can probably find 1 other person that agrees with that project)

  My hope is that by concerted effort, things get completed in a timely fashion 
(I think also working as a group may make people work harder/finish things up, 
because in some sense, people are depending on them.  If I individually choose 
to work on foo, no one is really harmed/waiting for me if it takes 6 months to 
complete).  The current process is basically the individuals work on projects, 
and they sometimes get completed.  That really isn't working if our goal is to 
complete the stuff on that list.

The idea behind the lead sending out a project detail isn't a 'this is how I'm 
going to do it, tough luck', but rather provide everyone on the list with a 
detail on what/how they think it should be done.  That doesn't stop further 
discussion.  I just think it will save time for the person to do something like 
'I think skills should be redone.  Here is my list on how they should be redone 
- opinions' vs a 'skill should be redone.  Any thoughts?'  Both solicit 
opinions, but in the first case, you provide some starting ideas.  In a sense, 
the person writing that is probably putting his opinions down first, rather than 
waiting for feedback, and then putting his plan down.

  Another reason for this is that the person leading/working on the project is 
more likely to do so if the plan is one he likes.  If the idea/plans that come 
out of discussion are such that the lead developer things 'this is idiotic', how 
likely do you really think it is he is going to spend much work on that?  He 
doesn't think it is the right direction.

----

  I've said it before, and I'll say it again:  Crossfire is a volunteer project. 
  There really isn't any way to force anyone to do anything.

  So the point here is to try and get something in place so that people will 
want to do the work, and the best way to do that is to make sure those doing the 
work have as much say into what is going to be done as possible.  That certainly 
doesn't mean that others opinions are ignored, but there are lots of 
considerations to take into account - complexity of suggested changes, other 
side effects, willingness to do those changes.

  And last point:  For quite some time, the mode of operation has been long and 
varied discussion about all sorts of points, with developers going off working 
on what they want to work on.  The end result of that is very few of the 
'important' projects on the TODO list get done.  so I would hardly say the 
current method is working especially well.


From mwedel at sonic.net  Mon Jul  2 00:30:59 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Sun, 01 Jul 2007 22:30:59 -0700
Subject: [crossfire] Project: New Intro
In-Reply-To: <46855F98.1090908@telus.net>
References: <46855F98.1090908@telus.net>
Message-ID: <46888D93.90105@sonic.net>


  Going back to original topic now

Alex Schultz wrote:
>I propose that we focus on what content the player sees first
> in the game because after all, it not only is the first part to leave an
> impression, but also how effective it is at teaching the player impacts
> all of their other experiences while new to the game. I believe we
> should redesign the intro of crossfire, and expand it beyond the newbie
> house and such we have now, I believe into it's own island or walled
> town. Scorn was in some ways intended to be a newbie town, but really
> many areas of it require level 10 or higher to be effective and it has
> become a transportation nexus. Scorn certainly needs reorganization, but
> instead of turning it into a newbie town I believe it would be more
> effective to make a brand new one of the first two or three levels in
> which the player would be taught alot about how the world works and how
> to play.

  First question on this:  It has been suggested that the character creation get 
completely redone, with spiffy interface, etc, instead of the the current 'in 
game' method.

  Does this proposal address this at all, or is this more based on what the 
player does once the character is created, and leaves the creation aspect itself 
still on a TBD list?

> 
> On the maps mailing list one new newbie house was created though didn't
> really finish being polished: This could be used as part of it but much
> more would certainly be needed. We should create a checklist of things
> to do for this new introduction to CF and should have a clear listing of
> who is working on what. Teamwork and organization would be key in
> achieving this. I propose the following as a checklist to start with
> though it would be expanded as things go along:
> 
> -Decide on what newbies need to learn before getting into the game
> -Decide how to sort this into the different maps, and add each of these
> maps to the checklist
> -Decide how to lay the maps out in a small isolated (island or walled) town
> -Integrate with the CF world.

  That all looks good to me.  A small town on an island works out really good. 
A few questions remain:

Is this just an island for tutorial purposes (this is how you cast a spell, this 
is how you search for a trap, etc), or is this more designed as a low level area?

  In both cases, does one see a 'ship to mainland' type thing which is a one way 
ticket off the island to scorn (or perhaps other towns?  Maybe replace the nexus 
with this town, and experienced players can hop right over to the ship to navar 
city if they really want to).




From alex_sch at telus.net  Sun Jul  1 23:57:56 2007
From: alex_sch at telus.net (Alex Schultz)
Date: Sun, 01 Jul 2007 22:57:56 -0600
Subject: [crossfire] Organizing efforts, was Re:  Project: New Intro
In-Reply-To: <46888B93.2060705@sonic.net>
References: <46855F98.1090908@telus.net> <4686FA14.8020105@sonic.net>
	<46888B93.2060705@sonic.net>
Message-ID: <468885D4.8090305@telus.net>

Mark Wedel wrote:
> Having project leaders before the project is worked on/voted on makes sense. 
> And as I think about it more, it would generally be good to have the detailed 
> project plan before voting, so people actually know what they are voting on. 
> OTOH, writing up project plans for all the potential things to do is a daunting 
> task.  The flip side is that if someone is willing to rite up the plan, there 
> is probably at least one person willing to work on the problem.
>   
Well, I would say perhaps not the full detailed plan, but at least some
sort of outline of what would need to be done. I wouldn't want this
requirement to make the process too much effort really.

> I'd expect in most cases the vote to be pretty clear cut.  I think each vote 
> would have to be limited to the top 5 (or so) most important projects, which is 
> probably decided by the person running the vote (but once again, I think the 
> seasoned developers would have a pretty good idea).  Certainly anything that has 
> a dependency on it should almost always be on that list.  And certainly opinions 
> could be solicited for what should be on the voting list.
>
> As stated in my original message:  The reason that only the developers vote on 
> the next project to work on is because it is the developers doing the work.  The 
> testers are important, but for the most part, they are not going to help get the 
> project get done.  Likewise for the players.  A big concern I have is that if it 
> is opened up to non developers, we'll get a vote that basically none of the 
> developers (or too few to for meaningful team) agree with.  So the players say 
> 'foo should be done first', and developers say 'I could care less about foo'. 
> End result, foo is never done, and this system fails completely - if the vote 
> has no meaning, why do a vote?
>   
Well, so far as I can see, two valid concerns have come up on both sides
of this:
1) Only developers vote and the interests of what makes the game fun and
what players want is lost
2) Both developers and players vote and that tips the scale to a project
that developers are highly disinterested in and thus little gets done
about the 'chosen' project

Because of these issues, I don't believe we can simply have just
developers, or just developers and players as the voting pools. The way
I believe this could be solved to satisfy both concerns would be by
making this "Top 5" list to vote on, heavily influenced by polling
players about what interests them of the larger list of projects. This
way, what players are interested in will be remembered and will
influence the process, but the selected project will not end up being
one that will disenchant developers.

>   And last point:  For quite some time, the mode of operation has been long and 
> varied discussion about all sorts of points, with developers going off working 
> on what they want to work on.  The end result of that is very few of the 
> 'important' projects on the TODO list get done.  so I would hardly say the 
> current method is working especially well.
Agreed. :)


Alex Schultz


From nicolas.weeger at laposte.net  Mon Jul  2 15:42:22 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Mon, 2 Jul 2007 22:42:22 +0200
Subject: [crossfire] Organizing efforts, was Re:  Project: New Intro
In-Reply-To: <20070701064346.GA869@cthulhu.desy.de>
References: <20070701064346.GA869@cthulhu.desy.de>
Message-ID: <200707022242.25614.nicolas.weeger@laposte.net>

> Is there a list of deciders?  Who needs to nod, before something could
> be implemented?
>
> If there is no such list, create it.  Or better extend the developer
> list with the responsibilities.

There is no formal decision process. The closest is this list, I guess.

> Creating a detailed document and nobody likes the idea is a waste of
> time.

Indeed. But sometimes it's useful to sum up a long discussion :)

> Instead of discuss it all over again, send the link to the archive.

For that you need someone to find the link, or copy conversation to the wiki - 
and most of the time no one does that...

Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'al?atoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070702/5a0fd38b/attachment.pgp 

From nicolas.weeger at laposte.net  Mon Jul  2 16:39:54 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Mon, 2 Jul 2007 23:39:54 +0200
Subject: [crossfire] Items blocking view
In-Reply-To: <200706112334.49514.nicolas.weeger@laposte.net>
References: <200706112334.49514.nicolas.weeger@laposte.net>
Message-ID: <200707022339.54446.nicolas.weeger@laposte.net>

Hello.

> I'm wondering the reason of the blockview behaviour. Is there a compelling
> reason for that?

Since I had no reply, and considering map_layer makes stacking checks kind of 
obsolete, I removed the 'keep blocksview items on top' logic, thus fixing the 
bug :)

Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'al?atoire !]


From mwedel at sonic.net  Mon Jul  2 17:02:47 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Mon, 02 Jul 2007 15:02:47 -0700
Subject: [crossfire] Organizing efforts, was Re:  Project: New Intro
In-Reply-To: <468885D4.8090305@telus.net>
References: <46855F98.1090908@telus.net>
	<4686FA14.8020105@sonic.net>	<46888B93.2060705@sonic.net>
	<468885D4.8090305@telus.net>
Message-ID: <46897607.6020700@sonic.net>

Alex Schultz wrote:
> Mark Wedel wrote:
>> Having project leaders before the project is worked on/voted on makes sense. 
>> And as I think about it more, it would generally be good to have the detailed 
>> project plan before voting, so people actually know what they are voting on. 
>> OTOH, writing up project plans for all the potential things to do is a daunting 
>> task.  The flip side is that if someone is willing to rite up the plan, there 
>> is probably at least one person willing to work on the problem.
>>   
> Well, I would say perhaps not the full detailed plan, but at least some
> sort of outline of what would need to be done. I wouldn't want this
> requirement to make the process too much effort really.

  Yeah, outline would be fine.  Something more than 'spells should be 
rebalanced', but less than a final plan.  As said, once the project is decided, 
there would be more discussions, so you probably don't want to spend a large 
amount of time on a detailed plan that may have lots of changes/additions.

  So I'd probably say two levels of plans:

Brief overview - used in the voting stage, maybe about a paragraph long.  Can be 
informal.

Details plan:  Used to divide up work - I'd note that this plan may be more 
functional (maps of this nature is needed), because that may be easier to divide 
work parts into, where as the overview may be a broader design goal.

  Note that I'd tend to expect that most discussions would be more in the nature 
of broader design guidelines, and the lead would then have to take those 
discussions and form it into the more functional plan of what changes are needed 
to get there.

  The reason I think this is the case that in order to really be able to have 
many people work on one project, they need to have somewhat detailed idea of 
what is expected/needed.

  To use the beginning map discussion as an example - right now, discussions are 
broadly based on type of maps and the like needed.  But at some point, that 
needs to get transformed into a list of the maps needed with a brief 
description, so that I, or other people, could sign up to make some of those 
maps and know what is needed.


> Well, so far as I can see, two valid concerns have come up on both sides
> of this:
> 1) Only developers vote and the interests of what makes the game fun and
> what players want is lost
> 2) Both developers and players vote and that tips the scale to a project
> that developers are highly disinterested in and thus little gets done
> about the 'chosen' project
> 
> Because of these issues, I don't believe we can simply have just
> developers, or just developers and players as the voting pools. The way
> I believe this could be solved to satisfy both concerns would be by
> making this "Top 5" list to vote on, heavily influenced by polling
> players about what interests them of the larger list of projects. This
> way, what players are interested in will be remembered and will
> influence the process, but the selected project will not end up being
> one that will disenchant developers.

  One thought here might be to do something similar to what was done with the 
voting for versioning control system.  Use a form of selective voting, open it 
up to everyone, but categorize the different vote takers, eg, developers, 
testers, players.

  thus, if developers vote foo as #1, and bar as #4, and players vote bar as #4 
but foo as #5, but both developers and players vote qubit as #2, then maybe 
qubit is done instead, as it has general support from both sides.

  I agree that we want the players involved.  I just think that if the players 
drove the process, things may not work.  I expect that there are a lot more 
players than developers, so their votes if taken individually could swamp the 
results (if only 25% of the players agreed on something, that could still be 
more votes than all the developers if they agreed on a single thing).

  So I'd probably say now that the vote should be open to everyone, but the 
person running the vote (most likely me) can weigh the input from different 
groups of people in different ways.  Probably one list of preferences from 
developers, and another from non developers, and hope something on that list 
coincides.


From nicolas.weeger at laposte.net  Mon Jul  2 17:11:15 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Tue, 3 Jul 2007 00:11:15 +0200
Subject: [crossfire] Unused features
Message-ID: <200707030011.18556.nicolas.weeger@laposte.net>

Hello.

I started a wiki page at 
http://wiki.metalforge.net/doku.php/dev_todo:functions_implemented_but_not_yet_used 
to list features that aren't used. Probably some are missing.

Just so map makers, archetype makers, coders have some ideas or free time :)

Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'al?atoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070703/d076dbc9/attachment.pgp 

From alex_sch at telus.net  Mon Jul  2 19:09:03 2007
From: alex_sch at telus.net (Alex Schultz)
Date: Mon, 02 Jul 2007 18:09:03 -0600
Subject: [crossfire] Organizing efforts, was Re:  Project: New Intro
In-Reply-To: <46897607.6020700@sonic.net>
References: <46855F98.1090908@telus.net>	<4686FA14.8020105@sonic.net>	<46888B93.2060705@sonic.net>	<468885D4.8090305@telus.net>
	<46897607.6020700@sonic.net>
Message-ID: <4689939F.7080403@telus.net>

Mark Wedel wrote:
>  One thought here might be to do something similar to what was done with the 
> voting for versioning control system.  Use a form of selective voting, open it 
> up to everyone, but categorize the different vote takers, eg, developers,
> testers, players.
>
>   thus, if developers vote foo as #1, and bar as #4, and players vote bar as #4 
> but foo as #5, but both developers and players vote qubit as #2, then maybe 
> qubit is done instead, as it has general support from both sides.
>
>   I agree that we want the players involved.  I just think that if the players 
> drove the process, things may not work.  I expect that there are a lot more 
> players than developers, so their votes if taken individually could swamp the 
> results (if only 25% of the players agreed on something, that could still be 
> more votes than all the developers if they agreed on a single thing).
>
>   So I'd probably say now that the vote should be open to everyone, but the 
> person running the vote (most likely me) can weigh the input from different 
> groups of people in different ways.  Probably one list of preferences from 
> developers, and another from non developers, and hope something on that list 
> coincides.
One thought about this, if we want a decent amount of player
involvement, there should probably be a web-based system (integrated
with forum logins or wiki logins?), or in-game system, to collect votes.
If this is agreed on I could see if I could quickly get something
together as it should be very trivial to code something simple for this
task.

Alex Schultz


From lalo.martins at gmail.com  Tue Jul  3 11:08:15 2007
From: lalo.martins at gmail.com (Lalo Martins)
Date: Tue, 3 Jul 2007 16:08:15 +0000 (UTC)
Subject: [crossfire] On the software side of "reorganizing the world"
Message-ID: <f6ds9e$eb6$1@sea.gmane.org>

I've been busy, so I have mostly lurked through this discussion, although 
it's very interesting to me.  This week I have some time, so I'm writing 
a detailed braindump that I should post later.

Meanwhile, here's an idea I had when working on Pupland; I didn't pursue 
it, but it could be very useful if this proposal really goes forward.

What I think we need is a "world editor".

Editing the world right now is very messy and hard (which is why nobody 
merged Pupland yet, after what, getting close to 10 years of Bigworld).  
It's difficult to do, the tools are sub-optimal, and the most obvious 
ways mess up elevation.  (The discussion of whether the current elevation 
values are even useful belongs elsewhere, in the discussion about 
weather).

Ideally, I'd like an UI on at least the magicmap scale, maybe farther, 
where I can lay mountains, rivers, forests, marshes, sea/land, and 
preferably copy large chunks right out of an older map (say, Lone Town) 
and paste into the world.  Also control elevation by hand, using an 
interface similar to map editors in god games (eg, Sim City).  And define 
things like regions right there, too.

If someone wants to pursue that, either as a separate tool or a mode for 
the new editor, I'd be happy to contribute, although I don't know where 
to start if I were to write it myself.

best,
                                               Lalo Martins
-- 
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
                           -----
personal:                    http://lalo.hystericalraisins.net/
technical:                    http://www.hystericalraisins.net/
GNU: never give up freedom                 http://www.gnu.org/



From lalo.martins at gmail.com  Tue Jul  3 21:42:05 2007
From: lalo.martins at gmail.com (Lalo Martins)
Date: Wed, 4 Jul 2007 02:42:05 +0000 (UTC)
Subject: [crossfire] classes & guilds
References: <4686EDDC.9060203@sonic.net> <20070701122736.GB869@cthulhu.desy.de>
Message-ID: <f6f1dr$gp$1@sea.gmane.org>

Ok, here's my take on the whole thing; this is a description of
a scenario that would attract me as a player and a contributor,
and by no way the Only Single Truth.  I should also say I'm an
RPG (pen-and-paper) player and author, and this certainly puts
some bias into my point of view (for the better, I hope).

Skill proficiency
=================

I'm really happy about this idea.  May I suggest these names:

- Dabbler, amateur, or untrained
- Professional, advanced, or trained
- Master

I could even like it if examining a player reveals her "master"
skills -- which usually won't be more than a few anyway.

In defense of Mark's view of how it works (levels are effective
the same way, but need more exp), I'd like to say: Crossfire
levels are not a function of experience.  They are just that: a
measure of how effective a skill is due to experience.  So
pitching a self-taught amateur that took years to get to
level 20 against a professional who got to this level before
"graduating", should get an approximately even match.

The comparison with an untalented black-belt vs. a talented one
is IMO not fair.  A better way to think about it is comparing
two fighters who were given black belts by the same, rigorous
master, in which case they should have more or less the same
skill.  Then again, maybe by "talented" you actually mean (in
game terms) that one has better Dexterity or Strength; this
would obviously make a difference and is unrelated to level.

That said, I'd put a cap on levels.  If we retain the current
level system (110/115), I'd cap amateurs at 40 and professionals
at 90.  (Master is of course uncapped, or capped by the system's
own limits, currently 110).

It would also be interesting to introduce "difficult" items; for
example, weapons that require pro level in their skills.
Despite appearances, it's just not possible to fight with a
longsword or a battle axe if you've never been trained on it.
(You can self-train, but you'll probably hurt yourself a lot in
the process, and it would take ages.)

Training to increase proficiency should take time.  A way to
represent that could be:

- The system only considers the proficiency for the "instance"
  of the skill with highest level; so if you're amateur archer
  20 and pro archer 18, you're still amateur.

- But new experience goes entirely to the higher proficiency.

- Upon acquiring a new version of the skill, it's initialized to
  the exp corresponding to N levels below the current version,
  where N might be hardcoded, or might be defined by the object
  that gave you the skill (the mentor).  For fighting skills I'd
  say 2 to 5, for magic possibly more.

So the time required to train yourself into a pro is represented
by the experience required to "catch up" to you previous level.

Character creation
==================

Get rid of classes entirely, moving that stage to in-game.

During creation, you choose species and, let's say, nationality.
The combination of those defines your starting town and initial
skills.  As far as weapons go, for example, I'd give amateur
two-handed weapons to all humanoids (everyone can wield a club
or chair), amateur clawing to whoever has claws.

Then you can optionally pass through a tutorial area in your
home town (probably impossible to enter again after you leave).  
I'm uncertain whether this area should give any exp at all.

Then you are free to roam your chosen home town, get the lay of
the land, buy booze, talk on the tavern, whatever.  Or even go
adventuring if you're crazy enough.  (There should be some kind
of benefit for these characters -- maybe societies charge
membership fees?)

To do this well, we should add a few more towns.  It has been
exhaustively discussed to add an underground city for dragons
somewhere (near the Hatchery would be appropriate), and maybe
one for dwarves.  There's at least one elven village that could
be expanded for that purpose.

One thing I'd like to see is a "wild" village somewhere, where
we could put the current northman, barbarian and swashbuckler
concepts.

Acquiring a profession
======================

On each starting town there would be a number of buildings where
you'd find professional guilds.  This is maybe overloading the
meaning of guilds we already have in the game, but it's closer
to the traditional meaning.  An alternative is not to call them
guilds -- call them societies, or better, something more
class-relevant, like "academies" for magic and "monasteries" for
priests and paladins.  (Even then, the thieves society is
probably still "The Thieves Guild" in at least one town :-P)

Here we can add some flavor.  Some of those would admit only
some species, some only natives.  And they could/should be all
different.  For example, to become a "fighter" equivalent in
Scorn, you join the Royal Order of Chivalry, where you get
professional one-handed and two-handed weapons but no archery;
in Navar, you'd instead join the Citizens Guard Corps, getting
one-handed and archery.  More obviously, each magical academy
would only offer two skills, which if I remember my maths
correctly, gives us 6 possibilities currently, up to 10 if we
implement necromancy as suggested.

Joining a society should have a cost, probably in money,
although that would be a problem if it's the first thing you do
in the game.  How hard would it be to implement debt?  It should
also have some ongoing cost.  One idea I like is: to actually
enter the premises, you need to pay your fee, which then lets
you in and out for some time (a week?) before you have to pay
again.  This value could be tied to level (overall level?  Sum
of relevant skills?  Highest relevant skill?).

I'd also like to make them more or less social, so it would be
reasonable to have savebeds in them, and "lounge areas" like the
Scorn dragon guild does.  It would be interesting to add
bulletin boards to them; even better, one inside (for members)
and one outside.

More importantly, your application to join should be rejected if
you have "conflicting" skills.  On the starting societies, these
would be any skills at pro level at all.

Oh, only tangentially related: I'd take that opportunity to
"regionalize" the choices of gods.  One possibility is that
praying at an altar doesn't "convert" you, you need be
"converted" on that god's society (although it shouldn't be
required to be a member; probably a chapel on a separate
entrance).  So even though you could still have small
"representative" temples of all gods in the major cities, you
can't become a follower there.

Learning new skills
===================

New skills, at amateur level, should be IMO taught at a relevant
society.  The Royal Order of Chivalry can teach you amateur
archery and smithery, and the Arcane Academy of Scorn has
alchemy and one spell type it doesn't teach at pro.  For a
price, of course; probably very high.

Advancing
=========

Then at other places in the world, preferably far from the
starting towns, you get other societies that teach you more.
I'd even be happy to partially reuse existing maps.  To get pro
alchemy, you go to the Nurnberg Alchemy Society (existing map,
but unfinished); to join, you're required to have amateur level
alchemy, which is only learnable in magic academies, so fighters
are barred.  The Tower of Demonology could reasonably have a new
section added, where someone who has amateur summoning can learn
it up to pro.

These further societies are still societies in all senses,
including recurring costs if you want to go back there (and we
should think up some perks to encourage that).

In terms of RPG, they are similar to "prestige classes".

Some current classes could be available only this way.  The
"warlock" could be replaced by one academy somewhere that
teaches fighters to do amateur magic, and another elsewhere
(Lake Country comes to mind) that teaches mages to fight.  A
similar logic goes for the "devotee".  Ninjas could be an
"improvement" over thieves.  Maybe even paladins...

Rationales and arguments
========================

This gives characters more "involvement" with their, er,
"classes".  It also, on a crowded server (which we hope to get
if we make CF2 cool enough), facilitates characters meeting
others of the same society and forming parties.  Conversely, if
you need one mage for you party of fighters, you know where to
go; just stand in front of the Academy for a while.  Or if you
want to "hire" one, post on the Academy's bulletin board.

It also opens the field to even zanier ideas and gaming
styles.  Merchants Guild anyone?



best,
                                               Lalo Martins
-- 
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
                           -----
personal:                    http://lalo.hystericalraisins.net/
technical:                    http://www.hystericalraisins.net/
GNU: never give up freedom                 http://www.gnu.org/



From crossfire at kahnert.de  Wed Jul  4 03:25:11 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Wed, 4 Jul 2007 10:25:11 +0200
Subject: [crossfire] classes & guilds
In-Reply-To: <468884B9.4000105@sonic.net>
Message-ID: <20070704082511.GA18372@cthulhu.desy.de>

On Sun, Jul 01, 2007 at 09:53:13PM -0700, Mark Wedel wrote:
> I am not adverse to all races/classes starting with all skills (save
> those intrinsic ones like Nicolas mentions), but with a fair number
> being really poor versions.

Sure, I don't want to see flying dwarfs doing flame touchs, either. ;-)


> 1) skills operate the same, just harder to get levels in ones you are
> not good at.

This will end up with all characters having the same skill level, just
takes longer to get some of them.


> 2) Skills operate different.  A person with the good version of
> evocation at level 10 casts spells much more effectively than a person
> with crappy evocation at level 10.  I'd think that in this model, the
> exp gain should be the same - that is to say that the crappy version
> needs the same exp total as the good version to get to level 10.

Could be made, it's a bit easier to implement.


> The difference here is that it becomes harder with the bad version,
> because the spells don't do as much damage, so you need more of them,
> etc.  I say that level gain should be the same, or close, as otherwise
> you are really punishing those with poor versions of the skills

Sure, it's intended to be a punishment.  Stay with your class if you
like the easy way. ;)


> - not only is the skill not as effective, but you need more exp.  You
> can of course do that, but then at some point, it is almost what is
> the point of offering such skills in the first place.

Having the skill from the very first beginning just means, that they're
able to gain xp in them.  This offers the possibilty to eventually
master them - after long and hard working on them.

This doesn't mean that you have to train them, it's just the natural
ability of an intelligent being to learn something new. ;)


> Note also that in many cases, point #2 really looks like point #1.

I don't think so.


> so effectively this just means that the bad version of level 10 is the
> same as the good version at level 3.  So you don't really gain much in
> this case, except for guilds that look at minimum level (but then the
> question comes up, should they also take the version of the skill into
> account?

No, definitely just the level, because the "affinity value" of the level
will become better through the guidance of the guild masters.

The level is only checked to proof that you life the guild rules.


> At some level, it almost seems that a bunch of complexity is being
> added, and internal at some level, everything is getting adjusted
> skill level, and using method #1 in that case is a lot easier.

Method #1 won't give you the chance of fine tuning the classes.  They
will become the same sooner or later, but not with method #2.


> The original point of redoing skills/classes was the general complaint
> that at higher levels, all classes look alike,

Not only higher levels.  This equality is reached pretty fast.


> becuase all classes/races have the same skills at high levels.  From
> some of the discussions here, I'm not sure if everyone actually thinks
> that is an issue,

It is an issue for sure.  If the high level human warrior decides to
learn magic and will even outclass the fireborn sorcerer, because the
human warrior is also able to wear rings and amulets AND magical armour
to become a much more powerfull mage then the fireborn, than the system
is extremely unbalanced.

What's the point of playing a magical creature like fireborn, if every
barbarian is able to get the power up with items to the same value (30)
of a fireborn?  Out of the fireborn description:

    Their insubstantial nature makes them both
    very weak and very quick.  Their minds are
    agile, and they are able to commune well with
    the gods. However, their area of excellence
    is magic. They spellcast more powerfully than
    any other race, and mana flows into them
    readily. They can even cast cold spells with
    devastating effectiveness.  They all know a
    basic fire spell.

I can't confirm that.  Fireborns are probably the weakest mages of all.


> and instead of fixing the classes/skills, the idea is to enforce/add
> differentation by guilds and special perks.

Both will do the job.


> In that case, this could be the easiest:
>
> 3) There is no classes - every starts with same version of all the
> skills, and what they become is based on what skills they use.  A
> person using magic would be in the mages guild, a person using melee
> skills in the fighter, etc.

So far it's fine.


> This becomes a pure case of you are what you practice.  Characters may
> look the same at higher level, OTOH, if the guilds do offer special
> benefits, maybe not.

The guilds have to play a central role of the concept, or it ends up the
same.


> This doesn't require any code changes - the real change that would be
> needed is some new way for characters to get starting equipment (as
> that is one of the big differences between classes right now - mages
> start with spellbooks, fighters with arms and armor).

I don't think that this will change anything.

I'll explain my idea (with the modifications out of the discussion) in
detail in an extra mail.  Hopyfully this will give the big picture.

    J?rgen




From crossfire at kahnert.de  Wed Jul  4 03:25:59 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Wed, 4 Jul 2007 10:25:59 +0200
Subject: [crossfire] classes & guilds
In-Reply-To: <468884B9.4000105@sonic.net>
Message-ID: <20070704082559.GB18372@cthulhu.desy.de>

Race / Class / Skill / Guild

1) Races primary set the max stat value and adds some intrinsic skills like
   levitation, clawing, flame touch, ...

   Problem here is the maximum (magic improved) hard limit of stats to 30.
   Why should an elf or gnome be able to get the same con value as a dragon?
   Just remove this hard limit.  The limit will be reached with body slots
   and item power.

   For example, the maximum natural con value for an elf would still be 18
   and for a dragon 26.  But with weared items giving a sum of +12 con the
   elf would reach 30 but the dragon a con value of 38.

   
   About the stat potion issue.  It's easy to give a character with xp 0 a
   perfect body by drinking a lot of stat potions.  This could be changed,
   if only one stat increases by reaching a new level.  Which stat will be
   random as long as you didn't used a stat potion.  If you've drunk a stat
   potion, the last quaffed stat potion will overwrite the random selection.

   An additional effect of the stat potion will be, that this stat will
   increase by 1 as long as you don't drink another one.  Than the old
   effect vanishes and the new one will take effect.

   For example.  str 16, con 15, now you drink a strength stat potion, you
   will get str 17.  After that, you drink a constitution stat potion, your
   str will drop back to 16 and your con rises to 16.  Another con stat
   potion will have no effect, your con stays at 16.  Now you reach a new
   overall level and your con will be permanent set to 16.


   And the races needs more balance of the advantages / disadvantages.  For
   example the fireborns are far to weak.  Levitation isn't that useful and
   nothing special - everybody is able to levitate by spell or items if not
   already an intrinsic leviation is available.  Flame touch does only fire
   damage, so no chance to break doors or walls or usable against fire
   immune creatures.  The dragon clawing also do physical damage, too.
   That's much better.  And besides that, everybody is able to use weapons
   doing fire damage and much more.  Every body slot missing needs some real
   compensation.  Being unable to use weapons is a real disadvantage,
   because all those weapon improvement - either selfmade, god given or just
   by the weapon - aren't available.  What's the bonus for that for a
   fireborn?

   Other races may need some tuning, too.  Removing 2 con and giving 2 cha
   isn't the same, so the "netto skill change" of 0 is somewhat misleading.

   Balancing the race attributes needs more discussion.


2) Classes don't have any distinctions at the moment.  Just remove them as
   an attribute of the character and replace it by something like a title.
   "You are what you do" will be the new motto.  Classes as a concept will
   still exists, but won't be a fixed attribute of the character - see
   guilds.


3) Skills needs bigger changes to work well with the "classes via guilds"
   system.  The goal is to have real distinctions between high level
   character; not those uniform ones we have right now (everybody can do
   everything on the same level).

   For that we introduce different versions of skills (up to master degree).
   The pitfall is to create complexity without effect.  If a master skill of
   level 10 is the same as novice on the same level, you end up again with
   everyone having everything on the same level.

   Or you deny classes to learn some skills which are not likely for the
   class.  This will work good in party oriented game engines, but not so
   well with CF.

   That's why I prefer a more sophisticated skill system.  This is based on
   the gained experience (xp) which defines the level of a skill; nothing
   new so far.  And another skill "capability value" (I formerly called it
   "affinity value").

   The capability value will be a range between 5 and 0.2 and is used as an
   divisor for the xp gain and also for the effect of the skill.  Having a
   capability value below 1 means, you gain faster xp and makes more impact.

   The level of the skill is used for guild rule checking and still for all
   the other checks e.g. ability to learn a new spell.  But I also think it
   would be a good idea to use it for item usage (weapons, rods, ...)
   instead of item power or in combination with it.  This is a different
   topic, so I won't extend it here.

   The capability value can be improved after reaching a new overall level.
   The capability value of the five skills where the character gains most xp
   between two levels will become reduced by the following formula:

      Cn - new capability value
      Co - old capability value

      Cn = Co - Co * 0.04

   Starting with the capability value of 5 you'll get this grades after x
   advances:

      capability    grade        advances
      -----------------------------------
      5.0  - 3.4   Unskilled      1 - 10
      3.4  - 2.3   Novice        11 - 20
      2.3  - 1.5   Apprentice    21 - 30
      1.5  - 1.0   Amateur       31 - 40
      1.0  - 0.65  Adept         41 - 50
      0.65 - 0.44  Expert        51 - 60
      0.44 - 0.29  Master        61 - 70
      0.29 - 0.20  Grand Master  71 - 80

   After 80 advances you reached the lowest possible value of 0.2.  That's
   not the same with level 80 of that skill!

   For example, between level 4 and 5 (8000 xp needed) a player used skill A
   to get 500 xp of those 8000, skill B 1500, skill C 750, skill D 2000,
   skill E 250, skill F 1000 and skill G 2000.  The five best skills (D, G,
   B, F and C) will be reduced by the formula above.  The other two skills
   won't - not enough training to become better there (see guilds for
   exceptions).

   If the character just used a single skill to get those 8000 xp for the
   new level, only this skill will get one advance.  The other four advances
   are lost.

   This system can be tuned by having more or less skills which will become
   better after level gain.  Or by using percentages, like all skills above
   5% of the xp gain for the new level will be improved.

   We also need to change the xp table because it's now much harder to gain
   levels than before (for low level characters).


   In combination with the guilds this will result into a clear distinction
   between members of different class guilds.


4) Guilds play a central role in this concept.  After character generation,
   in the HallOfSelection, the player won't choose the class for the
   character, but the class guild to join.  The difference is, you're able
   to leave a guild to join another one, to learn a new profession.

   Changing the guild is not as easy as it sounds.  The character has to
   fulfill the guild rules.  For example members of the warrior guild have
   to make sure that the fighting skills are much higher than all others.  A
   warrior having a higher skill in magic than fighting won't be accepted or
   even become ostracized.

   Guilds will have a bunch of skills they teach.  Without a teacher you
   never ever get a chance to advance over amateur grade of the skill
   (lowest capability value of 1.0).  So you have to be member of the guild
   to reach the "adept" up to "grand master" grade.

   The choice of the profession will limit the capability but not the skill
   level.  Think about the skill level as a measurment of how much time you
   spent for the skill.  And the capability is how good you master it.

   The "guild skills" will advance every [overall] level as long as you got
   a few xp in them.  If the top 5 skills (where the character got most xp
   between two levels) aren't guild skills, but there are also xp gains in
   guild skills, more than 5 skills will be advanced.  That's because the
   guild masters are able to teach the skills and offers deeper knowlegde.

   If the character just uses one "guild skill", only this one skill will
   advance.  Without using a skill / training no learn effect at all.

   This can't be abused, because if a fighter kills just one monster each
   with one handed weapons, two handed weapons, missile weapons and karate
   and gaining most xp with magic, than the fighter will become ostracized
   of the guild after a few levels, because the fighter no longer follows
   the guild rules.

   The guild rules for the warrior guild could look like this.  The skills
   missile weapons, one handed weapons and two handed weapons has to be at
   least twice as high as magic skills.  Also at least one of clawing, flame
   touch and / or karate (depending on the race) has to be twice as high as
   the magic skills.

   For example a warrior with

      karate              9
      one handed weapons 12
      two handed weapons 11
      missile weapons     7

   will be rejected to enter the guild and getting advantages over the guild
   if at least one of the magic skills evocation, praying, pyromancy,
   sorcery, summoning or use magic item is 4 or higher.

   Maybe we also add alchemy, inscription, literacy, sense curse, sense
   magic and probalby more or all other skills, to make a more clear
   distinction between the guilds.  Needs to be balanced between all the
   possible class guilds.

   
   The guild will offer an "apartment" for the player.  A uniq room for the
   character to place stuff.  This room will also be extentable after
   solving some quests for the guild.  For example teleporters to other
   regions, a magic box like in the extended scorn apartment, ...

   This extensions of the "apartment" (should be called a room if it's part
   the guild) are fixed to the guild the character solved the quests for.
   Don't make the rewards like teleporters moveable it the character changes
   the guild.  Betraying the way of living of the guild should be a
   punishment.  Enforce more role play gaming.


   Also good class items are also available through the guild.  For example
   the pyromancer will be able to get meteor swarm once the level is high
   enough and the quest is solved for it.  No other than the pyromancer as a
   member of the pyromancer guild will get access to this powerful spell.




From crossfire at kahnert.de  Wed Jul  4 08:16:11 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Wed, 4 Jul 2007 15:16:11 +0200
Subject: [crossfire] classes & guilds
In-Reply-To: <f6f1dr$gp$1@sea.gmane.org>
Message-ID: <20070704131611.GA19250@cthulhu.desy.de>

On Wed, Jul 04, 2007 at 02:42:05AM +0000, Lalo Martins wrote:
> I could even like it if examining a player reveals her "master"
> skills -- which usually won't be more than a few anyway.

Do you have an idea how it could looks like?  Maybe by clicking on the
character, extending the equipment list.


> So pitching a self-taught amateur that took years to get to level 20
> against a professional who got to this level before "graduating",
> should get an approximately even match.

I don't think so.  Having a master able to teach you the deepest
knowledge (which was gained over generations) is something else than
practicing by your own for years.


> The comparison with an untalented black-belt vs. a talented one is IMO
> not fair.  A better way to think about it is comparing two fighters
> who were given black belts by the same, rigorous master, in which case
> they should have more or less the same skill.

I can't confirm that.  They won't have the same skill.  In fact there
can be huge differences between them, even with the same master teaching
them at (and over) the same time.

It's a matter of fact that there are different natural talents for
skills.


> Then again, maybe by "talented" you actually mean (in game terms) that
> one has better Dexterity or Strength; this would obviously make a
> difference and is unrelated to level.

Nope, even with nearly same physical appearance, they will differ.


> That said, I'd put a cap on levels.  If we retain the current level
> system (110/115), I'd cap amateurs at 40 and professionals at 90.
> (Master is of course uncapped, or capped by the system's own limits,
> currently 110).

I don't think that this will change much.  Check out the characters
running around. Do you think they have much skills over 40?  Fighters
tend to stop training sorcery after reaching town portal.  A level cap
of 40 won't change that...


> It would also be interesting to introduce "difficult" items; for
> example, weapons that require pro level in their skills.

I like that idea.  But didn't you said level 20 should be level 20 no
matter of the version of the skill? ;)

I would simply check the level, not the grade of the skill.


> Despite appearances, it's just not possible to fight with a longsword
> or a battle axe if you've never been trained on it.

That would mean you need a lot of skills.  For every weapon type a new
skill.  And to stay fair, each spell needs to get an own skill level,
too.

I consider that as an overkill.

Just check the level of e.g. one handed weapons and assume that they
owner trained other weapons as well.


> (You can self-train, but you'll probably hurt yourself a lot in
> the process, and it would take ages.)

That's what I try to introduce with capability values of the skills. It
should take long and the best grade should be amateur.


> Training to increase proficiency should take time.  A way to
> represent that could be:
>
> - The system only considers the proficiency for the "instance"
>   of the skill with highest level; so if you're amateur archer
>   20 and pro archer 18, you're still amateur.

I don't get that.  How could you be level 20 and simultaneous level 18
of the same skill?


> - But new experience goes entirely to the higher proficiency.
>
> - Upon acquiring a new version of the skill, it's initialized to
>   the exp corresponding to N levels below the current version,
>   where N might be hardcoded, or might be defined by the object
>   that gave you the skill (the mentor).  For fighting skills I'd
>   say 2 to 5, for magic possibly more.

You lost me on the first point. I can't follow your train of thoughts.



> Character creation
> ==================
>
> Get rid of classes entirely, moving that stage to in-game.

Agreed.


> During creation, you choose species and, let's say, nationality.

The nationality aspect is nice.  Maybe hard to combine with the idea of
having regions of the same level niveau.


> The combination of those defines your starting town and initial
> skills.

I would like to see regions for players of the same level.  You either
need much more of those regions (for every nationalty an own beginning
region) or stay with mixed maps.  But mixed maps lead newbies into
death.  Having a cave of goblins next to one with dragons won't urge
newbies recommending this game to others...


> I'd take that opportunity to "regionalize" the choices of gods.  One
> possibility is that praying at an altar doesn't "convert" you, you
> need be "converted" on that god's society

On the one hand you're saying, that you should be able to master every
skill by your own to the same level as others with a teacher.  On the
other hand you deny that for the praying skill.  I think that's
inconsistent.


> New skills, at amateur level, should be IMO taught at a relevant
> society.

How do you learn magic skills if you're a warrior?  Or are you allowed
to enter all societies?  Or won't you ever get a chance to learn magic
skills as a warrior?


> It also, on a crowded server (which we hope to get if we make CF2 cool
> enough), facilitates characters meeting others of the same society and
> forming parties.  Conversely, if you need one mage for you party of
> fighters, you know where to go; just stand in front of the Academy for
> a while.

Wouldn't it be much easier to use "chat" instead of camping in front of
a guild? ;)

Besides that, I think CF needs much more party support to make this work
well - if ever on a tiled 2D map.  I don't see much parties going deeper
at raffle2 after the trolls are dead.  A CF party is just used to level
up a character fast, nothing more.

    J?rgen




From alex_sch at telus.net  Wed Jul  4 09:01:12 2007
From: alex_sch at telus.net (Alex Schultz)
Date: Wed, 04 Jul 2007 08:01:12 -0600
Subject: [crossfire] Max State Cap (was: Re: classes & guilds)
In-Reply-To: <20070704082559.GB18372@cthulhu.desy.de>
References: <20070704082559.GB18372@cthulhu.desy.de>
Message-ID: <468BA828.9070808@telus.net>

Juergen Kahnert wrote:
>    Problem here is the maximum (magic improved) hard limit of stats to 30.
>    Why should an elf or gnome be able to get the same con value as a dragon?
>    Just remove this hard limit.  The limit will be reached with body slots
>    and item power.
>
>    For example, the maximum natural con value for an elf would still be 18
>    and for a dragon 26.  But with weared items giving a sum of +12 con the
>    elf would reach 30 but the dragon a con value of 38.
One quick note about this, is that removing that hard limit isn't so
simple as "just" removing it. There is an issue that a notable number of
areas in the code do assume a max of 30 or give unreasonable bonuses if
stats are over 30. I would agree the stat cap of 30 should be removed,
but just noting, it would also require reworking most of the formulas
that give bonuses based on stats.

Alex Schultz


From crossfire at kahnert.de  Wed Jul  4 10:15:09 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Wed, 4 Jul 2007 17:15:09 +0200
Subject: [crossfire] Max State Cap (was: Re: classes & guilds)
In-Reply-To: <468BA828.9070808@telus.net>
Message-ID: <20070704151509.GB19250@cthulhu.desy.de>

On Wed, Jul 04, 2007 at 08:01:12AM -0600, Alex Schultz wrote:
> One quick note about this, is that removing that hard limit isn't so
> simple as "just" removing it.

I didn't looked into the code.  I just wrote down what I think will
improve gameplay.

I wouldn't consider this hard limit as critical which needs to be fixed
asap.  Anyway, it can't be wrong to put some more priorities on gameplay
instead of "what's easy to code". ;)

    J?rgen




From alex_sch at telus.net  Wed Jul  4 09:21:54 2007
From: alex_sch at telus.net (Alex Schultz)
Date: Wed, 04 Jul 2007 08:21:54 -0600
Subject: [crossfire] classes & guilds
In-Reply-To: <20070704082511.GA18372@cthulhu.desy.de>
References: <20070704082511.GA18372@cthulhu.desy.de>
Message-ID: <468BAD02.6060409@telus.net>

Juergen Kahnert wrote:
>> 1) skills operate the same, just harder to get levels in ones you are
>> not good at.
>>     
>
> This will end up with all characters having the same skill level, just
> takes longer to get some of them.
>   
>> 2) Skills operate different.  A person with the good version of
>> evocation at level 10 casts spells much more effectively than a person
>> with crappy evocation at level 10.  I'd think that in this model, the
>> exp gain should be the same - that is to say that the crappy version
>> needs the same exp total as the good version to get to level 10.
>>     
>
> Could be made, it's a bit easier to implement.
Both of the above two points would work well in conjunction IMHO.

>> The original point of redoing skills/classes was the general complaint
>> that at higher levels, all classes look alike,
>>     
>
> Not only higher levels.  This equality is reached pretty fast.
>   
In my experience, this tends to occur between levels 30 to 50 normally,
but sometimes a little earlier and sometimes a little later depending on
the player's style and how those levels are gained.

>> becuase all classes/races have the same skills at high levels.  From
>> some of the discussions here, I'm not sure if everyone actually thinks
>> that is an issue,
>>     
>
> It is an issue for sure.  If the high level human warrior decides to
> learn magic and will even outclass the fireborn sorcerer, because the
> human warrior is also able to wear rings and amulets AND magical armour
> to become a much more powerfull mage then the fireborn, than the system
> is extremely unbalanced.
>   
Actually, it is an issue for sure, as at high levels indeed races and
classes get good at things with too similar difficulty, however your
example of this is quite flawed: Rings and amulets are often much more
powerful for spellcasting than armour or swords. Thus the fact that
fireborn can wear up to 4 rings and 2 amulets at a time far outweighs
their lack of armour and swords so far as spellcasting is concerned. Of
course, this advantage of Fireborns becomes smaller after hitting stat
caps (30) because then the additional rings/amulets can only help by
attunement or mana regeneration bonuses.

> What's the point of playing a magical creature like fireborn, if every
> barbarian is able to get the power up with items to the same value (30)
> of a fireborn?  Out of the fireborn description:
>
>     Their insubstantial nature makes them both
>     very weak and very quick.  Their minds are
>     agile, and they are able to commune well with
>     the gods. However, their area of excellence
>     is magic. They spellcast more powerfully than
>     any other race, and mana flows into them
>     readily. They can even cast cold spells with
>     devastating effectiveness.  They all know a
>     basic fire spell.
>
> I can't confirm that.  Fireborns are probably the weakest mages of all.
>   
Well actually, though classes are indistinct often, Fireborn are not at
all. Yes every barbarian could get 30 power as well, but in this
particular case: the amount of items it would take to achieve that would
be rather high. Also, Fireborn DO have a unique bonus besides stats:
they do have an intrinsic mana regeneration bonus that is independent of
stats, and while it well known it does help Fireborn notably.


>> and instead of fixing the classes/skills, the idea is to enforce/add
>> differentation by guilds and special perks.
>>     
>
> Both will do the job.
>   
Agreed

Alex Schultz


From alex_sch at telus.net  Wed Jul  4 09:48:43 2007
From: alex_sch at telus.net (Alex Schultz)
Date: Wed, 04 Jul 2007 08:48:43 -0600
Subject: [crossfire] Max State Cap (was: Re: classes & guilds)
In-Reply-To: <20070704151509.GB19250@cthulhu.desy.de>
References: <20070704151509.GB19250@cthulhu.desy.de>
Message-ID: <468BB34B.4090404@telus.net>

Juergen Kahnert wrote:
> On Wed, Jul 04, 2007 at 08:01:12AM -0600, Alex Schultz wrote:
>   
>> One quick note about this, is that removing that hard limit isn't so
>> simple as "just" removing it.
>>     
>
> I didn't looked into the code.  I just wrote down what I think will
> improve gameplay.
>
> I wouldn't consider this hard limit as critical which needs to be fixed
> asap.  Anyway, it can't be wrong to put some more priorities on gameplay
> instead of "what's easy to code". ;)
Yep, just thought I'd make note of what else would be affected by it and
would need tweaking as to make sure that won't be forgotten. I agree it
would help gameplay, though not something with asap priority indeed :)

Alex Schultz


From lalo.martins at gmail.com  Wed Jul  4 13:11:38 2007
From: lalo.martins at gmail.com (Lalo Martins)
Date: Wed, 4 Jul 2007 18:11:38 +0000 (UTC)
Subject: [crossfire] classes & guilds
References: <f6f1dr$gp$1@sea.gmane.org>
	<20070704131611.GA19250@cthulhu.desy.de>
Message-ID: <f6gnso$6a2$1@sea.gmane.org>

Also spracht Juergen Kahnert (Wed, 04 Jul 2007 15:16:11 +0200):
> On Wed, Jul 04, 2007 at 02:42:05AM +0000, Lalo Martins wrote:
>> I could even like it if examining a player reveals her "master" skills
>> -- which usually won't be more than a few anyway.
> 
> Do you have an idea how it could looks like?  Maybe by clicking on the
> character, extending the equipment list.

Yes, that's what I thought.

>> So pitching a self-taught amateur that took years to get to level 20
>> against a professional who got to this level before "graduating",
>> should get an approximately even match.
> 
> I don't think so.  Having a master able to teach you the deepest
> knowledge (which was gained over generations) is something else than
> practicing by your own for years.

This is represented by the caps.  "The deepest knowledge" is the highest 
levels.

Also, you're missing a point.  Read the preceding part again. "Crossfire 
levels are not a function of experience.  They are just that: a measure 
of how effective a skill is due to experience."  Levels are a measure of 
effectiveness; that's what they mean, at least in this game.  So two 
people of level 20 have the same ability, because that's what level 20 
means; if one of them had less, then he wouldn't have level 20.

>> The comparison with an untalented black-belt vs. a talented one is IMO
>> not fair.  A better way to think about it is comparing two fighters who
>> were given black belts by the same, rigorous master, in which case they
>> should have more or less the same skill.
> 
> I can't confirm that.  They won't have the same skill.  In fact there
> can be huge differences between them, even with the same master teaching
> them at (and over) the same time.

Then I'm sorry, we seem to have a fundamental difference of philosophy 
wrt. the real life.  I don't believe in that.

Bear in mind, I'm not talking about two people training for the same 
time.  I'm talking about two people being awarded the same degree by the 
same (rigorous) master.  The person who's talented will get there 
faster.  The not-very-talented will take a long time.  The untalented 
will never get there.  I've seen it happen myself many times on martial 
arts schools.

>> That said, I'd put a cap on levels.  If we retain the current level
>> system (110/115), I'd cap amateurs at 40 and professionals at 90.
>> (Master is of course uncapped, or capped by the system's own limits,
>> currently 110).
> 
> I don't think that this will change much.  Check out the characters
> running around. Do you think they have much skills over 40?  Fighters
> tend to stop training sorcery after reaching town portal.  A level cap
> of 40 won't change that...

Er, do you really play on the servers?  I routinely see people with 
skills of levels above 100, because that's the only way you can level up 
at that point.

Besides, it still does make a huge difference for things like weapon 
skills.

Finally, there has been talk of redistributing spell levels, and I'm 
taking for granted that this *will* be done for 2.0.  The current spell 
levels are artifacts from when the highest level was, I don't remember 
exactly, 40 or 50.

>> It would also be interesting to introduce "difficult" items; for
>> example, weapons that require pro level in their skills.
> 
> I like that idea.  But didn't you said level 20 should be level 20 no
> matter of the version of the skill? ;)
> 
> I would simply check the level, not the grade of the skill.

You got me there :-)  But what I meant to represent here is that someone 
who had formal training is likely to have more breadth than the self-
taught.  The examples I use below -- longsword and battle axe -- are 
really though, and it's unlikely someone will ever bother to spend the 
time to learn them, if they have to actually live their lives as an 
active adventurer.  Other weapons go beyond that into the barroque: I 
think someone would have to be really incredibly skilled already before 
they could self-teach a kusari, for example, without dying in the process.

>> Despite appearances, it's just not possible to fight with a longsword
>> or a battle axe if you've never been trained on it.
> 
> That would mean you need a lot of skills.  For every weapon type a new
> skill.  And to stay fair, each spell needs to get an own skill level,
> too.
> 
> I consider that as an overkill.

Oh no, sorry, I'm not proposing different skills.  I'm just saying, an 
untrained person will use the tools (weapons in this case) that are 
easier to grasp, while someone with formal training will have more 
breadth.


>> Training to increase proficiency should take time.  A way to represent
>> that could be:
>>
>> - The system only considers the proficiency for the "instance"
>>   of the skill with highest level; so if you're amateur archer 20 and
>>   pro archer 18, you're still amateur.
> 
> I don't get that.  How could you be level 20 and simultaneous level 18
> of the same skill?


From nicolas.weeger at laposte.net  Wed Jul  4 17:26:59 2007
From: nicolas.weeger at laposte.net (Nicolas Weeger)
Date: Thu, 5 Jul 2007 00:26:59 +0200
Subject: [crossfire] Players in transports
Message-ID: <200707050027.02699.nicolas.weeger@laposte.net>

Hello.

Should the players in a transport appear in the 'maps' output? Should they 
count as players in the map the transport is in?

Currently they don't, so there is an issue: potentially a map could be reset 
with a player in a transport on it.

So either players in transport should count as players on a map, or the reset 
test should include players in transports :)


I think both options are fun, btw: not counting players let them "hide" 
somewhere, counting ensures the count on the map is correct.


Nicolas
-- 
http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref 
de l'al?atoire !]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070705/d87c2212/attachment.pgp 

From mwedel at sonic.net  Wed Jul  4 19:18:43 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Wed, 04 Jul 2007 17:18:43 -0700
Subject: [crossfire] Players in transports
In-Reply-To: <200707050027.02699.nicolas.weeger@laposte.net>
References: <200707050027.02699.nicolas.weeger@laposte.net>
Message-ID: <468C38E3.6060609@sonic.net>

Nicolas Weeger wrote:
> Hello.
> 
> Should the players in a transport appear in the 'maps' output? Should they 
> count as players in the map the transport is in?

  yes and yes.
> 
> Currently they don't, so there is an issue: potentially a map could be reset 
> with a player in a transport on it.
> 
> So either players in transport should count as players on a map, or the reset 
> test should include players in transports :)
> 
> 
> I think both options are fun, btw: not counting players let them "hide" 
> somewhere, counting ensures the count on the map is correct.

  But that wasn't really the point of transports - it wasn't a mechanism for 
them to hide.

  But the output of the maps command is really an out of game command (if one 
were to think of the people living the the crossfire world, they don't really 
have any command like that, so normally would not know where people are). So 
what exactly it should and should not show could be a matter of debate.

  That said, someone riding a horse should hardly be hidden.  Passengers on a 
ship, perhaps yes.  OTOH, in the later case, what does 'who' say?  If it just 
points them back at the map, then to some extent, they are not really hidden - 
it just depends on what command you use, and IMO, both commands should say the 
same thing.

  A more relevant question may be what to do about hidden wizes.  Should they 
show up in the maps command?  Probably not, but for consistency perhaps, the 
map->players count has to accurately reflect them (Swapping out a map with a wiz 
on it would be bad).




From mwedel at sonic.net  Wed Jul  4 19:27:13 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Wed, 04 Jul 2007 17:27:13 -0700
Subject: [crossfire] Max State Cap (was: Re: classes & guilds)
In-Reply-To: <468BB34B.4090404@telus.net>
References: <20070704151509.GB19250@cthulhu.desy.de>
	<468BB34B.4090404@telus.net>
Message-ID: <468C3AE1.5000709@sonic.net>

Alex Schultz wrote:
> Juergen Kahnert wrote:
>> On Wed, Jul 04, 2007 at 08:01:12AM -0600, Alex Schultz wrote:
>>   
>>> One quick note about this, is that removing that hard limit isn't so
>>> simple as "just" removing it.
>>>     
>> I didn't looked into the code.  I just wrote down what I think will
>> improve gameplay.
>>
>> I wouldn't consider this hard limit as critical which needs to be fixed
>> asap.  Anyway, it can't be wrong to put some more priorities on gameplay
>> instead of "what's easy to code". ;)
> Yep, just thought I'd make note of what else would be affected by it and
> would need tweaking as to make sure that won't be forgotten. I agree it
> would help gameplay, though not something with asap priority indeed :)

  changing the cap isn't that hard.

  However, this has been done before - cap raised from 25 to 30, with a lot of 
the same discussions (too easy for any class to max out stats, etc).

  the basic problem is that unless the cap is really high (50+), it may not make 
much difference if better and better items show up.  Perhaps related to that is 
a change that raised the max level - when that happened, then it made sense for 
those really high level quests to give out some good items that balanced with 
it, so you now got better items, and so getting that max stat became easier again.

  This can not be taken one piece at a time - the entire character life cycle 
needs to be examined, in particular:

- Is there a max level in the game?  If so, what should be it?
- Is there a max stat value in the game?  If so, what should it be?
- What should be the highest stat adjustment any single item in the game should 
give out?

  Last question is somewhat important.  IF the answer is say 5, then you 
probably at minimum need the stat cap at least 25 higher than max natural stats 
(get 4 rings of that and it is 20.  Or 2 rings, sword, amulet, etc).



From mwedel at sonic.net  Wed Jul  4 20:09:26 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Wed, 04 Jul 2007 18:09:26 -0700
Subject: [crossfire] classes & guilds
In-Reply-To: <20070704082511.GA18372@cthulhu.desy.de>
References: <20070704082511.GA18372@cthulhu.desy.de>
Message-ID: <468C44C6.8090906@sonic.net>

Juergen Kahnert wrote:

>> 1) skills operate the same, just harder to get levels in ones you are
>> not good at.
> 
> This will end up with all characters having the same skill level, just
> takes longer to get some of them.

  But it would be easy enough to put in level caps for some skills.

  I know some people don't like level caps that are less than max stats.  By in 
my mind, if you have different quality of skills, such that amateur, advanced, 
and master all can get to level 110, but amateur level 110 = master level 30, 
I'd maintain you are effectively doing level caps, your just implementing it in 
a different way.

  So maybe the question is more for those against level caps:  Why?  If the idea 
is you want to be able to get any skill up to equivalent proficieny as other 
classes (but maybe it takes 10 times as long, whatever), then pretty much all of 
the proposed systems don't allow that.


>> so effectively this just means that the bad version of level 10 is the
>> same as the good version at level 3.  So you don't really gain much in
>> this case, except for guilds that look at minimum level (but then the
>> question comes up, should they also take the version of the skill into
>> account?
> 
> No, definitely just the level, because the "affinity value" of the level
> will become better through the guidance of the guild masters.

  But IMO, you have to be very careful how well the affinity value can get 
adjusted.  Otherwise, you get the same case of bunches of classes maybe looking 
the same.

  Maybe they get broken down into 3 or 4 major classes - fighter, mage, cleric, 
thief.  But if all the fighters look the same at high level, is that OK?  Maybe 
it is, but one complaint is that all characters look the same at high level. 
Having all the characters look the same out of 3 or 4 classes is some 
improvement, but is that what the goal is, or something different.



From mwedel at sonic.net  Wed Jul  4 20:29:55 2007
From: mwedel at sonic.net (Mark Wedel)
Date: Wed, 04 Jul 2007 18:29:55 -0700
Subject: [crossfire] classes & guilds
In-Reply-To: <f6f1dr$gp$1@sea.gmane.org>
References: <4686EDDC.9060203@sonic.net> <20070701122736.GB869@cthulhu.desy.de>
	<f6f1dr$gp$1@sea.gmane.org>
Message-ID: <468C4993.7000802@sonic.net>


  Just a note - I go into pretty much all discussions with some thought on the 
code involved.  Maybe people don't think that is quite the right approach.  But 
my thought is that the greatest designed system in the world is meaningless if 
it is too complicated to code in a timely fashion.


Lalo Martins wrote:
>
> In defense of Mark's view of how it works (levels are effective
> the same way, but need more exp), I'd like to say: Crossfire
> levels are not a function of experience.  They are just that: a
> measure of how effective a skill is due to experience.  So
> pitching a self-taught amateur that took years to get to
> level 20 against a professional who got to this level before
> "graduating", should get an approximately even match.

  Fine by me.  It sounds like from that description, amateurs gain exp more 
slowly than professionals, but if both are level 10 in the same skill, they are 
effectively equivalent?  This sounds like one of the models I put out - in this 
case, the skill names just make it easier to know what skill version you have?


> That said, I'd put a cap on levels.  If we retain the current
> level system (110/115), I'd cap amateurs at 40 and professionals
> at 90.  (Master is of course uncapped, or capped by the system's
> own limits, currently 110).

  Also reasonable.  Ideally, the caps could be set by skill, so for some skills, 
maybe amateur cap is 30, for others, amateur cap is 50. Either way, that isn't 
hard to do.

> 
> It would also be interesting to introduce "difficult" items; for
> example, weapons that require pro level in their skills.
> Despite appearances, it's just not possible to fight with a
> longsword or a battle axe if you've never been trained on it.
> (You can self-train, but you'll probably hurt yourself a lot in
> the process, and it would take ages.)

  It has been suggested that there be class or racial items (something only a 
dwarf can wear, or a ring only a mage can put on). But with all these 
discussions, class based items are a bit meaningless, so skill level items makes 
more sense.  Question then is - do we care what version of the skill the person 
has?  Eg, is it sorcery level 20 (amateur, professional, or master), or master 
sorcery level 20 only?  That could make a big difference.

> 
> Training to increase proficiency should take time.  A way to
> represent that could be:
> 
> - The system only considers the proficiency for the "instance"
>   of the skill with highest level; so if you're amateur archer
>   20 and pro archer 18, you're still amateur.
> 
> - But new experience goes entirely to the higher proficiency.
> 
> - Upon acquiring a new version of the skill, it's initialized to
>   the exp corresponding to N levels below the current version,
>   where N might be hardcoded, or might be defined by the object
>   that gave you the skill (the mentor).  For fighting skills I'd
>   say 2 to 5, for magic possibly more.
> 
> So the time required to train yourself into a pro is represented
> by the experience required to "catch up" to you previous level.

  This gets a bit messier to code, as now you have multiple versions of 
effectively the same skill.  If I do the skills command (or just the output in 
the client), does it now show two different archery skills?

  Making such a change is quite a bit more widespread in the code, since each 
skill is differentiated by a subtype number - things would have to get changed 
to resolve to basically different subtypes (3 subtypes for each skill). 
Experience also gets a little trickier.

  It'd be a lot easier to just convert (or add/remove) the amateur and replace 
it with the professional version.  The problem of course is now you are lower 
skill level, so may not be able to cast some spells, weapon to hit could go 
down, hp go down, etc, which would seem odd.

  I wonder if instead, it could be recorded something like 'player was level 20 
in this skill before it got updated', and things look at that for min casting 
level, etc.  I'd have to think about if that is easier to do than multiple skills.

> 
> Character creation
> ==================
> 
> Get rid of classes entirely, moving that stage to in-game.

  <Much about character creation removed>

  Interesting ideas, but my quick thoughts/notes:

- Alex recently started another topic about redoing the intro/low level area.  I 
thinking having 1 intro area is much better than 5-6 different intro areas.

- While maybe not everyone would use it, I would guess some people would want an 
expedited creation method (I just want to player a fighter - I don't want to 
wander around a village for for 10 minutes talking to folks to get the skills I 
need)

- I might put this as a part of phase 2 - I don't see that this is actually a 
requirement related to any of the changes above.  It would seem to be a lot of 
work, and I'm not sure I'd put it at the same priority as redoing the 
skills/classes/races themselves.


> Learning new skills
> ===================
> 
> New skills, at amateur level, should be IMO taught at a relevant
> society.  The Royal Order of Chivalry can teach you amateur
> archery and smithery, and the Arcane Academy of Scorn has
> alchemy and one spell type it doesn't teach at pro.  For a
> price, of course; probably very high.

  Or maybe even a quest (bring me a ....).  But yes, that seems reasonable.  You 
don't say so, but I take it that skillscrolls then disappear from the game?

> 
> Advancing
> =========
> 
> Then at other places in the world, preferably far from the
> starting towns, you get other societies that teach you more.
> I'd even be happy to partially reuse existing maps.  To get pro
> alchemy, you go to the Nurnberg Alchemy Society (existing map,
> but unfinished); to join, you're required to have amateur level
> alchemy, which is only learnable in magic academies, so fighters
> are barred.  The Tower of Demonology could reasonably have a new
> section added, where someone who has amateur summoning can learn
> it up to pro.
> 
> These further societies are still societies in all senses,
> including recurring costs if you want to go back there (and we
> should think up some perks to encourage that).

  That all seems fine.



From alex_sch at telus.net  Wed Jul  4 21:19:16 2007
From: alex_sch at telus.net (Alex Schultz)
Date: Wed, 04 Jul 2007 20:19:16 -0600
Subject: [crossfire] Max State Cap (was: Re: classes & guilds)
In-Reply-To: <468C3AE1.5000709@sonic.net>
References: <20070704151509.GB19250@cthulhu.desy.de>	<468BB34B.4090404@telus.net>
	<468C3AE1.5000709@sonic.net>
Message-ID: <468C5524.7000108@telus.net>

Mark Wedel wrote:
>   changing the cap isn't that hard.
>
>   However, this has been done before - cap raised from 25 to 30, with a lot of 
> the same discussions (too easy for any class to max gmout stats, etc).
>
>   the basic problem is that unless the cap is really high (50+), it may not make 
> much difference if better and better items show up.  Perhaps related to that is 
> a change that raised the max level - when that happened, then it made sense for 
> those really high level quests to give out some good items that balanced with 
> it, so you now got better items, and so getting that max stat became easier again.
>   
My thought on this issue with raising the cap, is that if better and
better items show up, THAT is the problem. Given the current state of
things, we could lower item bonuses and natural starting stats instead,
however I believe that it would be easier to change or remove the caps
AND be strict about not having too powerful items.

>   This can not be taken one piece at a time - the entire character life cycle 
> needs to be examined, in particular:
>
> - Is there a max level in the game?  If so, what should be it?
> - Is there a max stat value in the game?  If so, what should it be?
> - What should be the highest stat adjustment any single item in the game should 
> give out?
>
>   Last question is somewhat important.  IF the answer is say 5, then you 
> probably at minimum need the stat cap at least 25 higher than max natural stats 
> (get 4 rings of that and it is 20.  Or 2 rings, sword, amulet, etc).
What I'm pondering right now, is why should we need artificial caps on
level or stats at all really? Why not instead just make the
items and bonus calculations balanced with eachother? I think that caps
are unnecessary if that is done right really.

Alex Schultz


From alex_sch at telus.net  Wed Jul  4 23:18:17 2007
From: alex_sch at telus.net (Alex Schultz)
Date: Wed, 04 Jul 2007 22:18:17 -0600
Subject: [crossfire] Organizational Infrastructure (was: Re: Organizing
	efforts)
In-Reply-To: <4689939F.7080403@telus.net>
References: <46855F98.1090908@telus.net>	<4686FA14.8020105@sonic.net>	<46888B93.2060705@sonic.net>	<468885D4.8090305@telus.net>	<46897607.6020700@sonic.net>
	<4689939F.7080403@telus.net>
Message-ID: <468C7109.5030802@telus.net>

Hi,

Well that the discussion on organizing efforts seems to have died down a
bit I'll sum up that the consensus seems to be from what I have seen here:
    -The idea of organizing and focusing on a mini-project is good
    -Some kind of procedure for selecting mini-projects to focus on
would be good
    -Projects should have a leader responsible for setting out the
direction of it (and perhaps other duties for it)
    -The idea of some form of vote deciding which project seems good, so
long as it avoids either players or developers drowning out the other's
interests
    -Projects should have a leader and outline before being on the
voting list, and if selected should have the leader create a detailed
plan shortly afterwards

So therefore, the main points that need to be decided are:
    -How exactly should the voting/decision process work?
    -What infrastructure should be used to coordinate the project after
it has been selected?
    -What infrastructure should be used for the decision making process?

On the first point, of how the voting process should work, well that's
already been touched on a little bit, with one favorable option looking
like taking a poll similar to what was done with the switch away from
SVN, keeping track of both developer and player views and trying to
select that which appeals to both sides.

On the the infrastructure used to coordinate projects, I think that the
usual of the wiki, IRC, and mailing list should serve the job fine. If
different infrastructure should be used for a project for some reason or
another that could be dealt with on a per-project basis, not a big deal
at all.

The third issue though, of what infrastructure should be used for
deciding what project, is a tricker question I believe. It could be
handled manually on the mailing list like with the version control vote,
however there are two issues with that IMHO: 1) It isn't of sufficient
accessibility to players and 2) it takes notable manual effort to set up
each time (not a critical issue, but it would be nice to make future
attempts at deciding a project as effortless as possible).
I believe that due to both of those issues would be solved by a
dedicated but simple web based interface for this, however perhaps that
would be overkill or someone else has a better idea. So what
infrastructure should we use to plan/decide?

Alex Schultz


From crossfire at kahnert.de  Thu Jul  5 00:25:02 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Thu, 5 Jul 2007 07:25:02 +0200
Subject: [crossfire] classes & guilds
In-Reply-To: <468C44C6.8090906@sonic.net>
Message-ID: <20070705052502.GA14332@cthulhu.desy.de>

On Wed, Jul 04, 2007 at 06:09:26PM -0700, Mark Wedel wrote:
>   But it would be easy enough to put in level caps for some skills.

I bet it will. ;)


> I know some people don't like level caps that are less than max stats.
> By in my mind, if you have different quality of skills, such that
> amateur, advanced, and master all can get to level 110, but amateur
> level 110 = master level 30, I'd maintain you are effectively doing
> level caps, your just implementing it in a different way.

Basically, yes, I do the level cap on the grade - without a master
earlier with one later.  The result is technical similar, but not the
same for the gameplay.


> So maybe the question is more for those against level caps:  Why?

If you have a level cap of 30 in a skill, this becomes a boring skill
once reached this limit.

Splitting the skill into two values (xp and grade) without limiting xp,
there is always something to do.  Savvy? ;)

People love to form their characters, and after reaching a limit it's
all done.  Nothing more to do.  That's it.  Boredom.  Stagnancy.

Having xp open end will change that.  And maybe even after level 100
you're able to increase your grade by your own (without a master) will
add another good feeling.  It wouldn't make a big difference, because at
this high levels you can't form much, but the feeling stays, there is no
end.


> But IMO, you have to be very careful how well the affinity value can
> get adjusted.  Otherwise, you get the same case of bunches of classes
> maybe looking the same.

Sure, but reducing the amount of classes to sharpen the remaining ones
won't be bad.

If you introduce new roles (classes), make sure that this new class is
something new.  Or make it a special subject of an existing class.

For example we could make the mage guild with different schools inside.
There are masters for pyromancy, for sorcery, ...

Or for each of the schools a new guild and just say that this is a
different area of expertise for mages.

It's also possible to have similar guilds teaching up to different
grades.  A mage guild with a grand master in sorcery, but only expert in
pyromance, a master in evocation, ...


> Maybe they get broken down into 3 or 4 major classes - fighter, mage,
> cleric, thief.  But if all the fighters look the same at high level,
> is that OK?

There is no chance to avoid that; without disproportional lot of work.

But if you have a system allowing you to define a class which will
definitely differ from others, you still have the option to add new
classes.

We need to avoid to create 3 or 4 general classes not allowing us to add
new ones without letting them look a bad choice compared with the older
ones.

As long as there is enough space for new classes which will add real
benefits, we won't end up with 3 or 4 classes looking all the same.

    J?rgen




From crossfire at kahnert.de  Thu Jul  5 00:34:53 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Thu, 5 Jul 2007 07:34:53 +0200
Subject: [crossfire] Max State Cap (was: Re: classes & guilds)
In-Reply-To: <468C3AE1.5000709@sonic.net>
Message-ID: <20070705053453.GB14332@cthulhu.desy.de>

On Wed, Jul 04, 2007 at 05:27:13PM -0700, Mark Wedel wrote:
> changing the cap isn't that hard.
>
> However, this has been done before - cap raised from 25 to 30, with a
> lot of the same discussions (too easy for any class to max out stats,
> etc).
>
> the basic problem is that unless the cap is really high (50+),

Why always the same value?  Just make the cap for example +10 on the
stat value.  Or max +50% on it.  Whatever.  This way you keep the race
modifiers without making all the same.

For example an elf with con of 10 is allowed to increase it with a +50%
cap up to 15.  After reaching the maximum con for this race (18), the
maximum will be +50% = 27 con.

A dragon will achieve a maximum con of 26 * 1.5 = 39.

Only for the humans there won't be any changes, because natural max 20
+50% will result into all 30.

    J?rgen




From crossfire at kahnert.de  Thu Jul  5 00:52:13 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Thu, 5 Jul 2007 07:52:13 +0200
Subject: [crossfire] unbalanced races (was: classes & guilds)
In-Reply-To: <468BAD02.6060409@telus.net>
Message-ID: <20070705055213.GC14332@cthulhu.desy.de>

On Wed, Jul 04, 2007 at 08:21:54AM -0600, Alex Schultz wrote:
> however your example of this is quite flawed: Rings and amulets are
> often much more powerful for spellcasting than armour or swords.

Often, but not always.  Just to list some:

- Wizard Hat
- cloak of the Magi
- Staff of the Magi
- bracers of magical power


> Thus the fact that fireborn can wear up to 4 rings and 2 amulets at a
> time far outweighs their lack of armour and swords so far as
> spellcasting is concerned.

Yes, 4 rings and 2 amulets sound much.  But in fact it's just 2 more
rings and 1 more amulet.  And this should compensate the lack of 8(!)
body parts?

Someone with feets just need to take on Idaten boots and is faster than
a fireborn.  Still leaving enough slots for other stuff...


> Also, Fireborn DO have a unique bonus besides stats: they do have an
> intrinsic mana regeneration bonus that is independent of stats, and
> while it well known it does help Fireborn notably.

Sure, this will compensate another slot, see above of the list with
magical items.


Nobody said that all races should have the same power.  But a bit more
balance could help.  Especially if there are parts of the game some
races can't participate like making their own weapons.

    J?rgen




From crossfire at kahnert.de  Thu Jul  5 01:18:30 2007
From: crossfire at kahnert.de (Juergen Kahnert)
Date: Thu, 5 Jul 2007 08:18:30 +0200
Subject: [crossfire] classes & guilds
In-Reply-To: <f6gnso$6a2$1@sea.gmane.org>
Message-ID: <20070705061830.GD14332@cthulhu.desy.de>

On Wed, Jul 04, 2007 at 06:11:38PM +0000, Lalo Martins wrote:
> Also spracht Juergen Kahnert (Wed, 04 Jul 2007 15:16:11 +0200):
> >> The comparison with an untalented black-belt vs. a talented one is
> >> IMO not fair.  A better way to think about it is comparing two
> >> fighters who were given black belts by the same, rigorous master,
> >> in which case they should have more or less the same skill.
> >
> > I can't confirm that.  They won't have the same skill.  In fact
> > there can be huge differences between them, even with the same
> > master teaching them at (and over) the same time.
>
> Then I'm sorry, we seem to have a fundamental difference of philosophy
> wrt. the real life.  I don't believe in that.

<OT>
Maybe you don't see that with karate.  Than look into education
institutes.

There are people learing all the same, writing the same exam, getting
the same mark.  But as soon as they encounter something new, they never
saw / learnt before, some of them (with the natural talent) are able to
combine the learnt stuff and solve the problems, the others not.

I'd once a professor who said an exam is just another lesson to learn
something.  Lot of students complained about that it's far to hard,
because they never learnt to solve such kind of problems.  That was
wrong.  It just separated the wheat from the chaff...

There was, there are and there will be always people doing better than
others on the same [education] level.
</OT>


> Finally, there has been talk of redistributing spell levels, and I'm
> taking for granted that this *will* be done for 2.0.  The current
> spell levels are artifacts from when the highest level was, I don't
> remember exactly, 40 or 50.

Yes, this needs to get fixed, too.


> I'm just saying, an untrained person will use the tools (weapons in
> this case) that are easier to grasp, while someone with formal
> training will have more breadth.

Agreed, I also think that a level on items would be a good thing.


> > On the one hand you're saying, that you should be able to master
> > every skill by your own to the same level as others with a teacher.
> > On the other hand you deny that for the praying skill.  I think
> > that's inconsistent.
>
> Er, no, I never said that, where did I?

In fact, you never said that, it just sounds like that.  I can't see the
special thing why changing the cult needs help from others...

Just watch your steps if you're running around in valriel or gorokh
before you pray. ;-P


> Only by joining an "advanced" society as I described later, one that
> only admits you if you are a warrior and then teaches you some magic
> -- making you the equivalent of today's "warlock".

And you end up with characters looking all the same, because they will
make a tour through all the guilds to achieve all the skills...


> > Besides that, I think CF needs much more party support to make this
> > work well - if ever on a tiled 2D map.  I don't see much parties
> > going deeper at raffle2 after the trolls are dead.  A CF party is
> > just used to level up a character fast, nothing more.
>
> That is at least partially true, maybe completely.  But I'm assuming
> we'll address that for 2.0 as well.  Even if we don't, it's worth
> making it easier to party, if the cost isn't very high, because then
> we're more encouraged to improve partying later, in 2.x :-)

But how?  I've no good ideas how to improve the party support on a tiled
2D map game that it will really work.  Which doesn't mean that it can't
be what I can't imagine. ;-)

    J?rgen




From lalo.martins at gmail.com  Thu Jul  5 01:41:47 2007
From: lalo.martins at gmail.com (Lalo Martins)
Date: Thu, 5 Jul 2007 06:41:47 +0000 (UTC)
Subject: [crossfire] classes & guilds
References: <4686EDDC.9060203@sonic.net>
	<20070701122736.GB869@cthulhu.desy.de> <f6f1dr$gp$1@sea.gmane.org>
	<468C4993.7000802@sonic.net>
Message-ID: <f6i3ra$gge$1@sea.gmane.org>

Also spracht Mark Wedel (Wed, 04 Jul 2007 18:29:55 -0700):
> Just a note - I go into pretty much all discussions with some thought on
> the code involved.  Maybe people don't think that is quite the right
> approach.  But my thought is that the greatest designed system in the
> world is meaningless if it is too complicated to code in a timely
> fashion.

It's good to have different perspectives.  I'm clearly going as a pen-and-
paper author, shooting for both flavor and game balance.  Juergen is 
coming from some other perspective which I won't try to guess.  And since 
the code needs to get written eventually, of course it's useful to have a 
code perspective ;-)

> Lalo Martins wrote:
>>
>> In defense of Mark's view of how it works (levels are effective the
>> same way, but need more exp), I'd like to say: ...
> 
> Fine by me.  It sounds like from that description, amateurs gain exp
> more
> slowly than professionals, but if both are level 10 in the same skill,
> they are effectively equivalent?  This sounds like one of the models I
> put out - in this case, the skill names just make it easier to know what
> skill version you have?

In fact it's exactly the model you put out.  You'll notice the paragraph 
starts with "In defense of Mark's view" -- last I checked you're the only 
Mark here ;-)

I'm not really proposing a new idea in this paragraph, rather, I'm 
exposing my understanding of the *current* meaning of levels in the 
Crossfire rule system.  Which, IMO, supports your model.  Sure, it could 
be changed; but I see no compelling reason to change, since the desired 
effects can be achieved with your model.

>> That said, I'd put a cap on levels...
> 
> Also reasonable.  Ideally, the caps could be set by skill, so
> for some skills,

I think so, yeah.  Maybe put the values on the actual archetypes.

>> Training to increase proficiency should take time.  A way to represent
>> that could be:
(...)
> 
>   This gets a bit messier to code, as now you have multiple versions of
> effectively the same skill.  If I do the skills command (or just the
> output in the client), does it now show two different archery skills?

Presumably just the "active" one.  Yeah, messy :-(

> It'd be a lot easier to just convert (or add/remove)