-
Notifications
You must be signed in to change notification settings - Fork 13
Abilities/Stats should not use HeroId/Name #34
Comments
That's true for single heros, but what about heroes with a different set of abilities for each form?
|
That is simply to solve. You put the applicable field into applicable abilities, so you add a form into each ability. ie: {
"id": "NovaPermanentCloakSniper",
"form": "Worgen",
"trait": true,
"icon": "storm_ui_icon_nova_personalcloaking.dds",
"name": "Permanent Cloak, Sniper",
"description": "Gain Stealth when out of combat for 3 seconds. Taking damage, attacking, or channeling reveals you.\nBasic Attack range is 20% further than other ranged Heroes, and you see 10% further than other Heroes."
} |
Since abilities are child elements of heroes (or "forms" as this discussing is calling them), it follows a logical progression in object-orientated languages. |
I don't quite understand what you wrote, but I could just be tired. Are you saying something like heroes/forms have abilities, thus In pseudocode
vs
|
An Ability belongs to a Form of a Hero.
So, to access Greymane's Worgen abilities, |
I already wrote that above. My point is that you can simplify the tree and it still makes perfect sense from OOP. If you must have Forms as a true object then the tree could look like.
To access Greymane's Worgen it would be |
It is fairly redundant to have a hero object that has at the top level id and then within stats/abilities have the heroId/Name as the only key off of them to then access the real data.
It should look like this:
The text was updated successfully, but these errors were encountered: