> 4 classes and subskills

[Sophia]

As of DSB 0.19, DSB will now allow the designer to specify the number of classes and subskills, like this:

Code: Select all

xp_classes = 4
xp_subskills = {4, 4, 4, 4}

This means that to add an additional fighter (the first class) subskill, one would need only do:

Code: Select all

xp_classes = 4
xp_subskills = {5, 4, 4, 4}

Because of GUI limitations (at least for now), only four classes will be displayed on a champion's inventory screen, but these could be any four classes out of whatever is available-- so you could always have specific classes that are only available to certain character types, or the like.

In order to make restricting classes to characters easier, I have added a something called "forbid_class" to the character exvars recognized by the base code. This forbids characters from gaining levels in certain classes. For example:

Code: Select all

ch_exvar[CHAR_STAMM].forbid_class = { false, false, true, true }
ch_exvar[CHAR_TIGGY].forbid_class = { false, true, false, false }

With this configuration, Stamm cannot gain wizard or priest xp, at all, and Tiggy cannot gain Ninja xp.

Since this is implemented as an exvar, the engine actually doesn't know or care about this. It will only work if you use xp_up, as defined in base/xp.lua, to give experience. dsb_give_xp simply blindly adds the xp given to the character's totals and will ignore forbidden classes.

None of this is set in stone yet so any comments, suggestions, etc. are of course welcome.

[Joramun]

Nice !

I would set xp_classes and subskills in global.lua ...

About the display, how are the displayed skills chosen ?
If the displayed skills are systematically the four first,
it means displaying other skills instead requires a nasty piece of code to switch skills positions...

[Remy]

I assume (since Sophia said that it could display any four out of those available) that it shows the first four Classes of those not Forbidden to that character. The game engine already takes that it into consideration - any Class with less than 500 experience isn't displayed (and Forbidden Classes would, by their nature, have 0 experience*), making room for extra Classes on the GUI.

*Okay, yes, technically, you could probably set the experience level of a Class to, say, Adept level when adding him or her to the roster, and then Forbid the Class to prevent it from going any higher; but that's a rather strange thing to do.

[Joramun]

Well, not if you consider forbidding a class as a way to stop experience gain à la Conflux.

But as far as dsb18 the 4 classes were hardcoded, and thus the problem of display didn't arise.

I suggest that the four displayed classes should be determined by a table variable INDEPENDANT of the external variable forbid_class (why not a forbid_skill .... ), and also defined in base/global.lua
It is up to the custom dungeon maker to decide if he/she wants to intertwin xp gain and level display, by overriding those definitions.

[Remy]

Forgive me, that's not quite what I meant. I assumed that Forbidding a Class would keep it's experience total below 500, so it wouldn't appear. If you going to lock experience later, you'd still want it displayed, so nothing changes, anyway. The display is not as hardcoded as you may think. It just prints each class that has experience above 500 on a line. I assume it still does that - it's just that Classes 5 and 6 (if they exist) would be overwritten by the ability score display (where Str, Dex, etc are located). For example, if a character has experience in Fighter and Wizard, the GUI doesn't leave the space between them on the display for the missing Ninja and Priest classes - they're right below each other, leaving two lines for Classes 5 and 6. There would be no need for a seperate table to tell the GUI which to display. All the designer would have to do is make sure, for that character, the Classes he doesn't want displayed never get experience: i.e. Forbidding them. If you Forbid a Class later, one that has enough experience to appear in the GUI, it would still appear, of course, so that isn't an issue (after all, Sophia said that the engine itself ignores Forbid-ness).

[zoom]

I have written more ,but I post this for now>
what about a pendant feral amulett that increases wizard level by one?
would that be displayed then and mixing everything up?
would it allow for gaining xp , due to a new maximum or s.th.?

[Sophia]

RemyR has it right. The engine itself doesn't know or care about forbiddenness-- any class that has an xp > 500 is going to be displayed. Right now, if you have xp in class 1 and class 3, they will be displayed right next to each other, without any space in between. This will leave space below for further classes. What this means is that each character can only have levels in four classes that will be displayed by the gui, but those can be any arbitrary four classes.

Right now, though, the engine tries to render the classes in the order in which they are defined, stopping at four. This may not always be the most useful.
Joramund's suggestion of being able to specify the order could work, but it could get tricky when different characters specialize in different things and a different order might be nice for each. My thought was, instead, the game engine could select the four classes in which the character had the highest advancement, and display those. Isn't that what you'd want to do most of the time anyway?

what about a pendant feral amulett that increases wizard level by one?
would that be displayed then and mixing everything up?

It has the potential to, the way things are now. It's a matter for the designer, really. Basing things on the four best classes of the character could help a lot.

[zoom]

strange thing to do: forbit a class to go any highter><

Think of a Paladin that ceased to be a paladin for whatever reasons...
She retains her levels but may not advance any further.
you could set the xp to adept and prevent from advancing.

Or, if s.o. would like to emulate AD&D...


level cap?
STamm may only learn 3 levels of Wizard skill
So he would only be able to advance to journeyman, then he has maxed wizard lvl.
so not generally prevent form advancing but have at a set limit
I would not like s.th. like that because it would be too restrictive, and I like
the way dm handles advancement...each champion may learn everything

prevent from advancing?preliminary level cap
in a dungeon level highest main class level may only be( dungeon level +1 )
because of training abuses, like joramund mentioned
so in level 3 of the dungeon , champions could advance to any class to level 4
(maybe add a bonus to some champions who may advance to dungeon level +2
like having high starting level, or having high str, but maybe not )


Also I could imagine a system where you have kind of an alignment :
4 evil classes and 4 good classes with 4 subskills for each of those 8 main classes .

Some characters can gain only gain good or evil classes.
I would not make them completely different, like spell setup or attack methods
all in all only some slight changes in usage, should still be rather similar to each other
on the big part

good aligned characters could then have a different set of skills and abilities, i.e.
cannot use the DARK BLADE, because they have not the necessary dark side fighter level.
just for restriction of some items
useful or emulation of D&D,
maybe dungeon trigger story elements?
good aligned guy may buy cheaper from shopkeeper A
bad guys have easier time in swamp level(trigger some event) and so on..

So you could have wizards of evil and wizards of light..
Fighters of justice and antipaladins,..
some special champions could have 2 wizard classes and both ninja classes?
hmmm.... introduce ninpo ,Ninja magic.

[Sophia]

I've thought some more about this issue and I've decided I'm not going to solve the problem with rendering more than 4 classes... I'm going to make it so that the designer can solve it however he/she likes.

So, I'm going to move the rendering of stats (as well as food/water bars, the default object look dialog, etc.) into Lua-controlled subrenderers.

This will give dungeon designers a lot more control over how information on the inventory screen is presented.

[Joramun]

Yay ! that's good news !!

The luazier, the better.