chapter 5 "Guilds, Classes, and Clans"
Section I: Classes
------------------
I suspect you are already quite familiar with
the concept of classes. Some people even have very
strong feelings about classes, specifically, they
hate them.
Dead Souls 1 came with a class system, and
I decided to keep it because it sort of worked, and
many people are familiar with classes and want to
have them on their mud.
However, you don't have to use them.
That's right. Using classes is not required. You
can very easily make your Dead Souls mud completely
devoid of classes, if that's what you want.
The reason for this is that in Dead Souls, the only
thing a class does is confer on a player a class title,
like "Fighter", and load her up with skill settings appropriate
to that class. That's it. Classes do nothing more.
If you want player X to have all the skills of a
fighter and all the skills of a mage, just make it so.
They don't need to have class to have skills. Add
"kite flying" while you're at it. It doesn't matter.
Dead Souls operates on a skill system. The class system
is incidental to it and can be dispensed with entirely.
On the other hand, for those folks who appreciate
the role play and tactical elements involved in using
classes, Dead Souls provides you the ability to use
the existing stock classes, and permits you to create
your own. The files in /secure/cfg/classes describe them.
See http://dead-souls.net/ds-creator-faq.html#2.46
for the exact syntax of these files.
You'll notice that there is a field for "how important"
a skill is. What this modifier does is determine how
quickly your player's skill levels rise when her player
level rises. A fighter's magical ability does not increase
much when she is promoted a player level, but a mage's
magical ability certainly does.
For those who find classes distasteful, this kind
of "skill hobbling" is just the reason they hate classes:
they feel they are too restrictive. If you are such
an admin, just dont use classes, and whenever you award
a skill to a player, set the "how important" number
(techninally known as the "skill class" but that's a very
confusing term) to the same for everyone.
Incidentally, you don't *need* player levels either.
I will leave it as an exercise for the reader to imagine
a scheme where players do not have advancement levels.
DS1 allowed players to join more than one class.
Unfortunately, the system was buggy enough and stripped
of classes so that it was both meaningless and a bit
of a problem. Multi-classing is by default not permitted
on DS2, but it's easy enough to implement on your own.
Review the header data in the class files to see the
syntax.
However, since multiclassing isn't something I
am interested in working on right now, I will not be
assisting anyone in getting that to work.
Section II: Guilds
------------------
The concept of "guilds" carries some baggage for me. I
learned about mudding by playing on Darker Realms, an LP
mud where a "guild" was effectively a class. There was
the mage's guild, the barbarian guild, etc. There were
also guilds that blurred the distinction between class
and race, like shapeshifters, cyborg, and dragon.
When I ran into the Dead Souls 1 conception of guilds,
then, I was pretty confused. In DS1, a guild was
kind of a player-run club. There was a guild object
that made some sort of determination about who
was in or out, who was the boss, etc. My presumption is
that in later iterations of Nightmare V, these guilds
were fleshed out and worked properly. I presume this
because in DS1 they didn't, and they seemed to make some
assumptions about the lib that were not correct.
I decided to change this for DS2, and the way it now
works is that guilds are neither classes nor player-run
clubs. The plan is to have guilds be not-necessarily-class-
based affiliations a player can have with balanced
advantages and disadvantages. As of DS2.0 there is no
working sample of this, but that's the plan for post
2.1 development.
Section III: Clans
------------------
Clans serve the purpose that DS1 guilds did. They are
player-run affiliations, managed by clan objects that
confer identity and status. As of DS2.0 there is no working
sample of this, but that's the plan for post 2.1 development.
