Dawn of Light

Currently Working on redoing the Master Level system pulling it out of hardcoded scripted mlnpc that I made years ago that has been dragged through all hell and back...
Progress Thus far -

transferred eMLLine into GameGlobals
created eMLLine to Name lookup
Created mlChoiceA and mlChoiceB in CharacterClassBase that is controlled in each of the PlayerClasses
Updated gameplayer to have MLLine as eMLLine and public facing. DB still holds int to keep constant.
Created GameMLNPC off of the old MLNPC
removed hard coding of ML lines based off class ID numbers. Pulls from class mlchoice a and b.
Added Respec into handling with respec token.
Modified all ML spec lines to handle properly with UI update/removal (issues where ability line was showing up on non casters preventing correct removal and causing MAJOR exploits)


Issues/Downsides -
Still handles off token system. No quest/xp handling in place at this time.
Breaks old scripts of MLNPC as eMLLine change in GamePlayer. May break custom scripts due to this.
Hardcoded to have 10 Spell Lines for each line. 1 through 10. Removes old line adds new line at each ML Level change or respec.
This seemed to be the best method without adding issues... Should match up to current MLNPC dbs with little to no changes.


Currently under major testing due to the dozens of updates scripts.
Posted to allow input in case something should be addressed prior creating a patch for DOL SVN.

Some question if you're working on the matter :

Is ML Level checked for anything else than ML Quest and ML Ability reward ?

I mean, if there isn't any game mechanics based upon ML Level or ML Line, having these in GamePlayer object is not really needed !

Champion Level is more like "Subclassing" for example and is used as constraint for equipping some items, it's not really used for other computation such as damage or defense, but can be seen as a "GamePlayer" Property for the Health Bonus for example...

Master Level lines have no such constraints from what I have in mind... They could be implemented using some kind of quest system I think !

DOL is sometime thought for "customization", Storm D2 is a demo of what can customization bring using DOL server, Master Level is definitely not a "standard" player skill tree, so it should be handled completely apart from GamePlayer class !

If someone where to customize the ML system totally he couldn't rely on constants, and limited player fields (2 choices only ? 10 spell by line only ? Only one line by player ?)

Either we should implement something to add "CustomSpellLines" to GamePlayer that could handle anything, either we handle this using "Script"-Like Classes

Or Maybe we could Subclass "SpellLines" and use an "Implementation Field" in database to reference some "core coded" special spell lines, the trouble with ML's skill is that they should all be considered Level 50 spells (or maybe caster level ?), but you can't handle them as a spec line (or they'll have the level they're earn at, like level 1 for ML1 etc...) and you can't handle them as baseline because they'll unlock with leveling...

Do you think there could be other way to handle custom skills ? Some way that could work with any type of new skills (for now we could handle champion and ML the same way, but maybe later updates are to come to Live DAOC...)

Ok I must Admit by Reviewing a bit around Spell Lines, this is not enough Object Oriented to come with an easy solution using new Spell Lines Implementation...

But this is definitely something interesting to work on !

Spell Line are subclass of "NamedSkill" they do have interesting properties and method to allow to derive how they are working (we could override how the "Level" is returned for fixed level spellLines), and I don't understand why so much "hardcoded" checks are made around these !!

Ok I must Admit by Reviewing a bit around Spell Lines, this is not enough Object Oriented to come with an easy solution using new Spell Lines Implementation...

But this is definitely something interesting to work on !

Spell Line are subclass of "NamedSkill" they do have interesting properties and method to allow to derive how they are working (we could override how the "Level" is returned for fixed level spellLines), and I don't understand why so much "hardcoded" checks are made around these !!

Yikes! I unleashed the beast!!!!!

Master levels I think should connect to the Player as Level, line, and xp the rest should be handled outside of the player.
Level to hold the level you have unlocked, line to the same, and xp if enabled and setup gains like champ xp in its own way.
If where going to be "like live" I think the way i'm moving them to playerclasses to pull up which they can have is the best option... Otherwise we could always move to some sort of DB table that has which you can become and so on.. But I would think this would be more of custom development that would allow new ML lines and new player choices more then 2 less hten 2 over 9,000... Maybe something in the future... But I was trying to allow more development away from that hardcoded MLNPC into a better system...

Ok let's see what we have for now :

- Players Handles Serialized list of skill
The part interesting us is SerializedSpecs and SerializedSpellLines...
The Serialized Abilities / Realm abilities could be interesting too but it's another work...

So actually When a player spec its char, the Serialized Specs are saved to database, then if any spec upgrade spell line they are also added to Serialized Spell Lines, which allow a char that leveled a spec to get its new spells.

For me the Serialized Specs is making a mirror of spell lines for this behavior, which is bad in any data storage, but this is needed anyway because Serialized SpellLines are used for something else : Master Level Lines !

Actually any ML handling happens by adding some new spell Line to a player, the ML level field and ML exp field are mostly unused, ML NPC directly append ML line name with some level to give player their spell on quest completion or when giving a token...

Once ML are in there, Specs and Spell Lines aren't mirrored anymore, thus we really need the additional spell lines added by ML NPC.

Champion Level use their own fields, (CL Level, CL Spells, CL Exp), which means they are totally handled in hardcoded manner !


- design for character skills ?

For me it should reflect how the game work, "Specialization" should be implemented as strong object oriented "career manager"
They should have some implementation for at least current behavior (Specs should give either a spell list or a style list career, some specs like "Parry" are only passive buff or checked against combat rules...) then extend it to handle Champion and Master Level (if they are able to handle this much, they should be customizable for a lot of things).

Specs for CL and ML should have some "Quest" Trigger, they should allow char to use spell after checking that they completed some quest without the quest requiring to hardcode the new skills directly into Player DB Object.

That should force to use some interface to know if every skill in career is valid for current player, with virtual implementation that could make it easy to extend.

Depending on the implementation we can fill the specs with lines from "spell lines" or styles from "style ID:ClassID", any of this is a child class of "Skill" so it won't be too hard to code

Update :

Actually thinking about ML exp and CL exp, they are specific in game player UI. For now I don't thing that handling them as "Quest" XP or other weird Quest Property would do much good, this is some "table join" that will be forgotten when Admin try to maintain their character table !

But anyway I don't think it's stupid to handle "player progress" as a World Wide Quest... I understand "AbstractRules" are here to handle fighting / targetting rules, they also care of reward actually (RP/XP...) but I don't think that's appropriate...

This could be totally handled by a quest for which every mobs is a target, responsible of changing player level, computing level xp range and earning, relying on player rules to identify enemies object and max level

After All ML's and CL's are activated after a quest, and need a quest reward to advance in level...

For now I would like to focus on "Specialization Career" !

What is missing in DOL :

Table CharClassXSpecialization, for now Specs are handled from hardcoded "BaseClass" object, here is our chance to make it dynamic using a table that tracks which specialization is acquired by which class

Fields : ID (auto inc), Class ID, Spec Keyname, Level acquired

KeyName references Specialization Table

Specialization Table need some Update

Actual Field : UUID (...), KeyName, Name (Displayed ?), Icon ID, Description (no ?)
New Field : ID (auto inc, the UUID is not needed keyname is the PK !), Implementation (track c# classes handling this spec)

Specialization should be a "Skill" implementing some career and advancement.

Typical specialization "implementation" :

LiveSpellLineSpecialization, handles spell lines containing "Spec's KeyName" as "Spec" field, if "baseline" advance on leveling, if "specline" advance on training. should handle "isBaseClass()" to not allow spec line spells for base class (if I remember correctly ?)

LiveWeaponSpecialization, handles styles retrieving style table "classID:SpecKeyName", advance only on training. (if there is any baseline style-like skill like an awarded style for a given level it could be handled in an other Career Spec)

LiveAbilitySpecialization, handles specs like Stealth, Parry, etc... no style or spells are awarded from specc'ing into this but rather ability and skill obtained from "SpecXAbility" table...

LiveCareerSpecialization, untrainable undisplayed spec, may be used to link Classes specific Ability (like Quickcast for caster, all fighter ability, etc) should rely on "SpecXAbility" which references a "specLevel" that will be used like a "baseline" advance
For easier Maintenance Career Spec could rely on trying to link Style and Spell table using the same keyname, this keyname will mostly be the "Game Class" name like "Skald Career"

Even if I have no knowledge of "baseline style", the custom Career could handle this, for spell there is mostly no use as you could already add many baseline/specline to a Specilization, they could still reference some "default" spell line that is always considered as player level (as this is a "default" spec that is meant to be virtually trained every level) that looks like an interesting feature for ML or CL which have no baseline/specline checks !!

So the first main step of this improvement would be to rely on existing tables and create a simple new one implementing all this through skill objects and remove everything that look hardcoded around char progress !

Maybe I'll have some kind of PoC (proof of concept) around tomorrow

Ok my PoC is not finished, I have a lot of data record to create to mimic the current "CharacterClassBase" Behavior...

I already went through some trouble to handle "spell lines", I had to upgrade the table design to be able to rely on data base values or I would have to hardcode which class gets which spell spec lines are they are all registered for the same spec !!

But here how it works

• ClassID ---> Collection<ClassXSpecialization>
  • Spec Ability : BaseClassCareer (don't add this for most Catacombs class that doesn't inherit their base class ability !!!)
    • Collection<SpecXAbility>
      • Class Ability 1 (Level constraint x)
      • Class Ability 2 (Level constraint y)
      • Weapon Handling (Level constraint z)
      • ...
  • Spec Spell : Spell Spec Line (subclasses : ListCaster, Hybrid, and AdvancedHybrid that can handle the two best spells)
    • Collection<SpellLines>
      • Base SpellLine (using relation => Key:ClassID or Key:0)
      • Spec SpellLine (using relation => Key:ClassID or Key:0)
      • ...[Support any number of spellline in a spec !!]...
      • #Eventually links to SpecXAbility to enable ability at given spec level (based on how stealth is working !!)
  • Spec Style : Style Spec Line (get a list of style from Style.Spec : Style.ClassID !)
    • Collection<Styles>
      • Style 1
      • Style 2
      • ...
      • #Eventually links to SpecXAbility to enable ability at given spec level (based on how stealth is working !!)
  • Spec Ability : StyleUserCareer (Optional Template to grant Tireless at level 15)
    • Collection<SpecXAbility> (1 elem only)
  • Spec Ability: PureTankCareer/AssassinCareer (if applicable grant a common Template to similar classes ! like hero, armsman, warrior have the same template of pure tank ability getting them at the same level !!)
    • Collection<SpecXAbility> (Evade Levels, Stoicism/Fury/Taunt Shout...)
  • Spec Ability : SpecificClassCareer (Template describing the class specific career abilities)
    • Collection<SpecXAbility> (Instruments Handling... Archery Abiltiy... Abilities that are class specific and can't be templated from other class)
      • Ability 1 (level constraint...)
      • Ability 2 (level constraint...)
      • Weapon Ability (level constraint...)
      • ...Optionally re-enable BaseClass Ability if this is a catacombs class that didn't inherit all of them
    • ...Live Spec Styles/Spells/Skill: BaseClass Speciality needs to be re-added to advanced class (this is meant for advanced class that don't use base class lines, mostly catacombs again !!)
      • ... Style Spec
      • ... Spell Spec
      • ... Ability Spec (Parry/Stealth...)

To explain with example :

You begin "Viking" you get Viking Spec Line (Axe, Hammer, Sword, Parry), you get VikingCareer (equip studded, small shield, axe, hammer, sword...)

Once you get "Warrior" all "Specs" from "Viking" are dropped, so you add back "VikingCareer" as it need to equip basic weapon, you add back Spec Lines (Axe, Hammer, Sword, Parry), as "Warrior" still have this from its baseclass and it's not inherited, then you add the "StyleUserCareer" all class using style get Tireless at level 15, then you add "WarriorCareer" (this will track how you get "Protect", "Evade", "Intercept", and set weapon handling like big shields, or armor handling like chain, etc...), then you add "PureTankCareer" (this add ability like Taunting Shout, Fury, Rampage, Climbing Spikes etc...), finally you add the Spec Line this class get : here it's Spec Shield only !

For a class not inheriting "Viking"

Once you get "Valkyrie" alls specs from Viking are dropped, we don't add back "VikingCareer" as Valks only equip Sword and Spear, we only add back Sword and Parry Specs from Viking (this is why there is no Spec inheritance, and Ability inheritance must be explicit !!) and additionally add Specs from Spears and Spell Lines (Odin's Will etc...), here we can still use the "StyleUserCareer" for Tireless at level 15 but we can't use "PureTankCareer" or another common career, we're gonna have to use "ValkyrieCareer" to track all abilities that weren't inherited because we haven't used "VikingCareer" for this template ! (equipping sword, equipping studded mainly...)

The purpose is to keep it "lazy", Catacombs class are mostly exceptions, but we must handle this as anybody could build custom classes on the same method, overriding "Spec" Object Implementation may allow to write custom "Spec Handler" to gather Ability/Skills/Styles/Spells in any way you would like !!

That's why all logic around base/advanced class will be kept in code, and it must be defined explicitly in database (re-add Career, re-add trainable Specs...), this way Spec keeping the same name will upgrade with their base class trained level (it will match the same string), if I were to use different spec names for each different advanced class I don't know how the training would have match the new spec

OK this is WAY weirder than I though !!

Champions are handled as Dynamic Spell Lines...

They use a unique ID from player ID to instanciate in memory lines that are all customized by the player choice to their champion specs !

This is completely crazy... Even if it's not a bad Idea this is totally not database normalized, and DOL doesn't react well to "scripted" in memory things, they get easily wiped on database reload...

At least if there were more mechanisms relying on this I would have though of something, but now Champion Lines definitely need to be converted to a "Custom Career" Handling so I can remove all this horrible code... (Gameplayer editing Skillbase cache !!)

Ok I hope I didn't do all this in vain...

I had to rewrite the Whole SKillBase class, this was a mess !

A lot of code is relying on handling directly skillBase Collection, some even try to edit them lively !

I needed these collection to reflect values added to database, so custom Specialization"Career" can retrieve their value here to assign player skills based on custom rules, for now everything works right back based on database value I used...

Next step will be to remove All hardcoded Ability assignment and Specialization assignment, relying plainly on "Career" Code to evolve a player class !

Once this is done skills will load with player specline levels only and compute the displayed skill list each time ! (Allowing for dynamic updates)

Keep up the good work!

This is update is gonna break any server that use too much class customizations...

Anything that don't use "live" values, that try to add Skills through Scripted behavior will mostly fail...

I'm trying to retain the most "Scripted" values I can, keeping in mind about old behavior like Champion or Master Level tried to work, but it's pretty hard, and some methods will need to get obsolete...

This is purely targeted at Storm RvR, and it could break a lot of "Custom" script available from user resources....

I'll try to explain more when a Commit will be ready !

but this revision is gonna be a big step.

Hmmm,

for me customization of DOL, especially at this point in its life cycle, is key. So it will be customizable but different, or are you reducing the ability to customize?

I'll wait for the more detailed explanation.

it's way more customizable, but with "Specialization" subclassing and database records...

You can link any "Spec Line" to a class, then this SpecLine will link to Abilities, Styles, Spells, you just need to implement your own "Specialization" Implementation that will manage these collections... When asked by GamePlayer, specialization will build skills lists depending on current status, for now these skills list are build "Network Compatible" to be sent right away by Packet Handler... (But honestly I even think sometimes about hanlding "custom client" if needed...)

Typically "live" spec will work the same with "baseline" and "specline" depending on training, but I added other "career" spec that are like hidden baseline spec that only adds abilities... I Intend to build special "Specialization" that will keep track of Realm Abilities trained, and even some "example" class to check for skills adding depending on Quest reward

Summary :
All Classes's Specs, Specs, Abilities, RealmAbilities, SpellLines, Styles Relations will now be handled through database mainly (with some hooks kept for customization through GameServerScripts...) using index through "specialization keyname"

Specialization are subclasses (using Database "Implementation" field for instantiating !) of Skill that handles collections of "subskills<Ability, SpellLine, Style>" compatibles for GameObject use and Network Use, which can use special requirements by checking any "GameLiving" property ! (Quest, Level, Training, Temp Property...)

With this kind of implementation some of Player database saved field will be unused (Serialized SpellLines and Abilities are mostly useless except for Scripting... These are computed each times through Specs Lines !) and other one will be used mostly as "hints" more than pure data (we only need specialization levels saved, we don't need to list each specialization there is a new Table for linking classes to Specs !)

OMG Leo, you lost me at the first chapter already i wish i'd understand what the heck you are talking about however, it sounds good

take care my friend

Argo

Oh Argo you were reading

Sorry I got this bad habit of trying to use technical word depending of who I'm speaking to

For World Builder here is a shorter summary :

new Table : Class X Specialization : Class Id -> (Spec Key, RequiredLevel), ...
new Field : Specialization.Implementation (Varchar) that can use any Classname of an object Type subclassing "Specialization" (like NPC.ClassType that allow to customize Mobs class type !!)

Specialization now links, Table SpellLine (using Field : Spec), Spec X Ability (using Field : Spec), Style (using Field : Spec KeyName)

Which mean that most skills for a gameplayer will autoload from database relations to their Specialization (Writing Custom Code to extend Specialization will allow any coder to handle these relations in the way they want...)

The new "ALL-Table Relations" around this "Class X Specialization Table" is what I called "Character Career Descriptor" as it should be enough to compute all the skills a player will get in its playthrough, The Custom "Specialization" Object that can be used through "Specialization.Implementation" Field is what I called "Career Manager Class".

If Tomorrow I want to change the "Fire Magic" of a wizard for a "Lightning Magic", it's one record in class x spec to change and it's done , If I want to make a specialization that send baseline spells as "hybrid list" and specline spells as "list caster" I can extend the class "LiveSpellLineSpecialization" dedicated to list caster, overriding the method "public virtual IDictionary<SpellLine, List<Spell>> GetLinesSpellsForLiving(GameLiving living)" to change the shape of the Spell list sent by network (... displayed in skill list and trainers...)

To make a new class it stills need some code but it will be way easier : Add a classID to GlobalConstants, Create a subclass of CharacterBaseClass with the Attribute referencing this new classID (copying another advanced class will be fine...) and just write all database records to describe the spec/skills/style/abilities/spells he will gain through leveling or training and you're done !