[task] Research Skill and Item Framework

[francy51]

Stats Research Part 1:

1. ummorpg uses "update" to reflect stat changes, or it re-calculates them on demand (often happens in UI update with is the same as update).
2. my addons had to build on top of that. as update is slow, i added both a update throttle and a cache. making a simple system very complex.
3. the current research shows that there is a much simpler way that allows us to ignore update, requires no throttle and/or cache:

3.1 stat bonusses are calculated "on demand". it happens when you equip/unequip an item or apply/deactivate a skill or a buff is activated/deactivated.

3.2 the stat is then simply: baseStat + bonusStat while only the bonusStat is modified by items, skills, buffs and addons

3.3 now: ummorpg does not have a way to determine if a buff is getting deactivated, but items do. revamping the whole system requires us to have a Activate/Deactivate function in each object that can modify stats.

3.4 we could therefore derive all "stat" objects (items, skills, buffs etc.) from a single, abstract object that provides a Activate/Deactivate function.

3.5 now we just have to make sure that all derived objects (equipment, item, skills) always make use of the Activate/Deactivate functions, in order to update stats when they have to (update on demand).

3.6 idea of a simple hiearchy:

StatObject (Activate/Deactivate) -> ItemObject (Activate/Deactivate on Equip or Activate on Use) -> SkillObject (Activate/Deactive on Skill use or duration over) -> BuffObject (Activate/Deactive when applied or duration over)

[francy51]

One thing of note for UI design for stats etc too @Fhiz is that you can subscribe to any syncvar, so something like this will be magnitudes more efficient than using the Update method: [SyncVar] int strength; void Awake() { strength += OnStrengthChanged(); } delegate void OnStrengthChanged() { //update UI }

That way UI only gets updated when the actual values change instead of that mess ummorpg had :thumbsup: Probably better to subscribe in OnEnabled and unsubscribe in OnDisable also just to keep stray events from floating around, that was just a quick mock-up

One thing I did also when I rewrote ummo classic to be component based was to treat skills just like items but with their own container full of equip slots, it simplified the whole thing a ton. Very much like your base class idea, but all the usage logic lived in the base too. I used the name Action for my base class, so every Item/Skill etc was an Action. It was very nice to not need to have three different types of things to manage and instead just have Actions that could go into the skillbar or wherever.

It just treated a skill in inventory as a scroll to learn that skill and added it to special Equipment slots just for skills when you activated it (just like equipment, so that logic got reused)

In the end it really made everything much simpler than the standard way of doing it (although my description here probably makes it sound way more complicated than it actually is :joy:)

[francy51]

The comments above written by fhiz and davil on discord respectivley

[DX4D]

Suggestion: Instead of a base Abstract class, let's use an interface instead. IStatBoost (I just prefer to call in StatBoost, but that would break CLR compliance...not sure if we care?)

This is the perfect place for an interface though as we can reuse it in many different places (equipment, skills, items, boost pickups, auras, buff skills, regional bonuses, etc etc)

Implementing the interface would force the class to implement the methods we need, plus we can use the Interface just like a type (eg: if (this is StatBoost) { //do stuff } )

And, of course, the biggest benefit: multi-inheritence - We can implement multiple interfaces (StatBoost, Equippable, Usable, etc)

A system based on this concept has infinite potential for extendability, works very well, and makes it very clear what a particular Skill/Item/Equipment is capable of.