Character Classes

Discuss the IceBlink Engine

Character Classes

Postby youngneil1 » Mon Jan 28, 2013 6:57 pm

In preparation of Jeremy's next month's work on IceBlink, I would ike to get a little brainstorming started about which info we need for the class templates (to fill in our custom made classes):

Character Classes
Up first, I would like to remark that many pieces of info could theoretically appear at different places: take the info on which class can learn which skill. It could be listed in table/class for skills (a list of tags for each skill with the classes that can learn it) or it could be in the character class template/class (a list of skills the class can learn, for each classs). Then there might be skills for only certain races - that info could be again in skills templates/classes or - this time - in the races template/class. In the end, it's hard for me to say what's the best way here. Probably it's best if Jeremy assigns this in the most effiecient way in the end. I will hint at potential "double" info below.

Been thinking on this "double" problem a little more: Worst thing would be to have the info stored indeed at two independent places. This would be a huge source for mistake/contradiction and would cause double editing effort. So, all the info on which class and race can use use which skills, traits, spells, items, etc., but also which traits are neccessary for which skills or which attributes allow to use which item etc, should only appear once (or, hint at what comes below: the places of appearance should be dynamically linked, so changes to one, change the other, too. Items, skills, traits, spells, etc. would - when it comes to the question of usuability/availability - therefore in the editor best access global variables on the MasterClass object for each class.).

[Note: I imagine something like a class KnightErrantClass, inherting all kinds of stuff from classes above it. Of this KnightErrantClass one MasterKnightErrant object is instanced. This again is the template for all player character individual objects of that character class, like the JonTheKnightErrant object and the CurtTheKinght Errant object. Changes to properties of the MasterKnightErrant object can be applied to the JonTheKnightErrant and CurtTheKinght Errant objects by some button in the toolset? Like creatures or props on the map could be updated in such a way, see disucssion about this]

So far, so easy. But now come conflicting principles:

1. Long central info is good for overview (one list contained in the MasterClass object with the 200 spells the player characters of this class habe access to - barring of course further checks for thetr level, attrbutes, whatnot etc. - is better than checking to 200 spells individually for that specfic MasterClass's class tag)
2. When adding something new, it's nice to lay down dependencies right away on the added object (when adding a new spell, it 's easier to fill in the tags of the MasterClass objects that can use the spell into the spell template than to open up each MasterClass object for every character class and manually add it there; even more obvious for items that which are constantly added)
3. Growth of small groups of elements becomes a pain in the ass when the dependencies are defined in the larger group (adding one character class and then having to go through 2000 items separately will be no fun)

When looking at this picture in sum, I think it's best to have most dependencies (skills, traits, items, spells, other speciall abilities) defined as proeprties the MasterClass object of each class (due to points 1 and 3 above: for overview and because character classes is a very small group of elements).

Still, it would be cool to have in the toolset remote access to these properties (global variables then) via wziard tools for new objects created (to do justice to point 2 above). Example: I add in a new sword, which has a drop down menu for character classes allowed to use this item. When making a change to that list, it actually changes a global variable/property of the MasterClass object in question. A direct change in the MasterClass object would automatically change the setting dispalyed in the wizard tool for that item in the tool set. It would be connected in both directions.

Furthermore, we should use category pyramids wherever possible. This way large lists of items/spells/etc. can be made accessible/unaccessible for a chaarcter class with much less effort. When there's e.g. a hierachy like weapons/bladed weapons/daggers, all daggers or even all bladed weapons could be made accessible/inaccessible for a character class very easily (instead of having to address all their individual tags, dagger 01, dagger02b, etc.). This should include an override in favour of definitons of a more specific level of hierarchy over the general level, e.g.: Mages cannot use swords, but the sword Merlin's Blade is specifically designed to be usable by mages. It's restriction status would override the general rule. These categoires and hierarchies for everything that character classes and races might be restricted/allowed to use should be freely definable by the module author (and apply not only to items, but also skills, spells, traits and special abilities).

This directly leads to the next topic:

We would need a system for resolving conflicting rules for usage allowance (i.e. warriror class allows to use two-handed swords, but one-armed race forbids use of two-handed swords, or above example with Merlin's Blade):

Starting point for determining whether a specific character can use an item / has acceess to a skill on level up / can learn a spell / can choose a trait on level up would be a check in his perosnal JonTheKnightErrant object. The info found their might be stored in hierarchy layers (e.g. Weapons/bladed weapons/daggers). The specific info existing on the most detailed layer would be the relevant one. That info would be in the form of global variables, accessible via the wizards for adding new items, skills, spells, traits, sepcial-abilities in the toolset.

[Question: Waht of race? Is race already a property of the JonTheKnightErrant object? Propbably.]

[Conflicting rules continued]

[cannot sue as default]
[can use as override first levle]
[is prohibited as overrdie second level]

[small elemnts in categories]

For starters just an unsorted brainstorming list - to be sorted and better explained later:

ClassName
ClassTag
StartingHP [this migth be a fixed number or a random number]
StartingSP [this migth be a fixed number or a random number]
HPPerLevelUp (beginning with second level) [this migth be a fixed number or a random number; probably it should be allowed to change that number for certain level ranges]
SPPerLevelUp (beginning with second level) [this migth be a fixed number ora random number; probably it should be allowed to change that number for certain level ranges]
EXP table linked to this class (or algorithm for determining it)
BaseAttackBonusDevelopment (algorithm for its increase ove rteh levels; or just an array with all levels that shall get +1 inceare in it)
REFSaveBonusDevelopment (algorithm for its increase ove rteh levels; or just an array with all levels that shall get +1 inceare in it)
FORTSaveBonusDevelopment (algorithm for its increase ove rteh levels; or just an array with all levels that shall get +1 inceare in it)
WILLSaveBonusDevelopment (algorithm for its increase ove rteh levels; or just an array with all levels that shall get +1 inceare in it)
NumberOfStartingSkillPoints
NumberOfSkillPointsPerLevelUP (beginning with second level) [this migth be a fixed number or a random number; probably it should be allowed to change that number for certain level ranges]
NumberOfAttacksPerRoundOnCertainLevel (here the moduel author could specify at which level a second attack become available; further more he could place the info how much worse this attack's to hit bonus shall be compared to the main attck; finally even half attcks, e.g. an extra attck every two rounds could be allowed, like with a 1.5 notation, meaning 3 attcks in two rounds)
ArmorTypesAllowed [potential double to item class;]
WeaponTypesAllowed [potenetial double to item class;]
OtherItemTypesAllowed [potenetial double to item class;]

[MasterTrainingRequirementToAdvance]
[traits]
[skills]
[spells]
[other special abilities]
[attribute requirements to take class]
[race requirements to take class]
[InfluenceOfFactionStandingOnEXPRequired]
[ClassDescriptionText]

[work in progress; to be continued]
Last edited by youngneil1 on Tue Jan 29, 2013 12:14 pm, edited 1 time in total.
User avatar
youngneil1
Backer
Backer
 
Posts: 4967
Joined: Sat Dec 08, 2012 7:51 am

Re: Character Classes

Postby youngneil1 » Tue Jan 29, 2013 12:12 pm

Slowly closing in on the topic. Yeesh, that's heavy stuff for a (mostly) non-coder. Do I make any sense in the stuff written above so far (heavily updated today, btw)?
User avatar
youngneil1
Backer
Backer
 
Posts: 4967
Joined: Sat Dec 08, 2012 7:51 am


Return to General Engine Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

cron