-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[task] Research Skill and Item Framework #55
Comments
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: That way UI only gets updated when the actual values change instead of that mess ummorpg had 👍 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 😂) |
The comments above written by fhiz and davil on discord respectivley |
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. |
Stats Research Part 1:
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)
The text was updated successfully, but these errors were encountered: