Difference between revisions of "User:Mindtheblob/notes"

From Wildermyth Wiki
Line 63: Line 63:
+1 [[Stat#Health|Health]]
+1 [[Stat#Health|Health]]


'''Occupies theme slot:''' head
==== Bear Arm (L) ====
==== Bear Arm (L) ====


  {{Quote|{{Data description|Bear Arm (L) (theme piece)}}}}
  {{Quote|{{Data description|Bear Arm (L) (theme piece)}}}}


'''Occupies theme slot:''' left arm
==== Bear Arm (R) ====
==== Bear Arm (R) ====


  {{Quote|{{Data description|Bear Arm (R) (theme piece)}}}}
  {{Quote|{{Data description|Bear Arm (R) (theme piece)}}}}


'''Occupies theme slot:''' right arm
==== Bear Leg (L) ====
==== Bear Leg (L) ====


Line 77: Line 80:
+1 [[Stat#Health|Health]]<br />
+1 [[Stat#Health|Health]]<br />
-0.5 [[Stat#Speed|Speed]]
-0.5 [[Stat#Speed|Speed]]
'''Occupies theme slot:''' left leg
==== Bear Leg (R) ====
==== Bear Leg (R) ====


Line 83: Line 88:
+1 [[Stat#Health|Health]]<br />
+1 [[Stat#Health|Health]]<br />
-0.5 [[Stat#Speed|Speed]]
-0.5 [[Stat#Speed|Speed]]
'''Occupies theme slot:''' right leg


== Theme abilities ==
== Theme abilities ==

Revision as of 00:21, 11 February 2022

I think everybody involved here sees the value of having a bot update the game data for the wiki. The issue seems to be more with the presentation of said data. And to a lesser extent, some underlying differences in views on the wikis purpose.

I started writing some thoughts on this yesterday.

Theme Pieces

I think a sub section for every theme piece has merit and consistency, but admittedly, the scrolling through of repetition of related abilities will not please the reader, as has been discussed here. The difference to the game UI being, that instead of clicking on information one by one, the information is displayed in its entirety without reader choice, control, or filtering.

Perhaps there could still be some way of finding a middle ground?

Has separating effects (abilities) given by themePiece aspects into its own section of a theme page below theme pieces been discussed? There, they could be displayed once by effect id, requirements, and the current tool tips, which I feel are perfectly excellent.

Since these theme related abilities are effects of aspects, first given with theme pieces, then targeted with theme piece aspects, I wouldn't see it breaking the logic of the code to have a) a separate sections for abilities and b) some disclosure for dependent theme piece combinations. If and when any given effect requires [x, y, z, å] theme piece aspects. An effect like bearHug is given in either arm, but it won't be enabled until the aspect requirements of the effect are met in the effect's targets.

Non-existent upgrades

In my opinion, the foreseeable more confusing matter has to do with non-existent upgrades. Showing a Thorn Lash+ when there isn't such a thing in the game files is confusing to the reader, as well as any future wiki contributor.

So take the botanical upgrades, since there is no ability upgrade aspect along the lines of theme_vine_upgrade nor is there any hint towards anything of the sort present or being planned for in the formulae of the theme's abilities, I don't quite see the case for it to exist in the wiki presentation, except for anticipating it based on a pattern.

But anticipating based on patterns in current presentation doesn't feel like the purpose of a game wiki. A case can be made to guard for future changes, but even this relies on the assumption that patterns will not be broken. Take the one-upgrade-per-theme -pattern. There is nothing restricting other theme piece related abilities and their upgrades to being added.

It's perfectly possible to add a leap ability for bear legs, and have a separate upgrade for it alongside of the Bear Swipes+ (theme_bear_upgrade) upgrade (tried this out today just to be sure :snappingturtle:). But it's not something we're going to anticipate.

The best possible scenario would be for the automated code to know how to validate an upgrade aspect as related to a theme piece's ability effect, and thus be worthy of an upgrade mention and tooltip. For common and class skills this won't be a problem because the upgraded ability is already specified in the upgrade aspect .json under "upgradeForAbility", which the theme upgrades lack.

But could there be a workaround? For example, since we know upgrade aspect id's appear in ability effects as part of formulae, could this knowledge be applied as something of the sort to be used to validate that an upgrade aspect does in fact modify an effect? (There might be exceptions where this does not apply?)

But if that is difficult to implement, I think a better scenario is to not present non-existent upgrades, whether that is done by commenting out or other means.

I agree it is beneficial to the reader to know there is no upgrade, but displaying these non-upgrades, to my eye at least, dilutes the purpose. It's more akin to showing non-facts than hiding facts. That being said, if a bot is able to find a new upgrade and implement it accordingly, well that's just awesome.

Beary Beary

Beartouched is a theme that can be gained by a hero from the event The Shape Of Things To Come.

<self> contains the soul of an old bear.
A fully transformed Beartouched Warrior.


Specifics

The alternative "Ghost" skin, unlocked after completing the "Bears are Scary" achievement.
Ability upgrade to Bear Swipes.

The hero gains Bear Tattoos and their history will include:

In slaying the bear's spirit, <Hero> him/herself took on the Essence of the Bear.

Changing the hero's hair color will change this theme's base appearance.

Theme pieces

Bear Tattoos

Ursine tattoos mark <self>'s face.

+1 Health

Occupies theme slot: head

Bear Arm (L)

<self>'s left arm is bearish.

Occupies theme slot: left arm

Bear Arm (R)

<self>'s right arm is bearish.

Occupies theme slot: right arm

Bear Leg (L)

<self>'s left leg is bearish.

+1 Health
-0.5 Speed

Occupies theme slot: left leg

Bear Leg (R)

<self>'s right leg is bearish.

+1 Health
-0.5 Speed

Occupies theme slot: right leg

Theme abilities

Swipes

UI DiamondRed.png single action, ends turn

Swipes

x damage, 1 shred, range 1.6 (Melee)

Take a swipe at up to two adjacent targets.

Damage: (4 to 6) + 1/2(Bonus Damage + Potency)

Requires: Bear Arm (L) or Bear Arm (R)

Upgrade
UI DiamondRed.png single action, ends turn

Swipes+

x damage, 1 shred, range 1.6 (Melee)

Take a swipe at up to two adjacent targets.

Damage: (5 to 7) + (Bonus Damage + Potency)

Requires: Bear Arm (L) or Bear Arm (R)

Bearhug

UI DiamondRed.png single action, ends turn

Bear Hug

x damage, range 1.6 (Melee)

<self> grabs an enemy, dealing damage and stunning them.

Damage: (3 to 5) + (Bonus Damage + Potency)

Requires: Bear Arm (L) and Bear Arm (R)

Theme conflicts

A Beartouched hero will not be eligible for any of these additional themes:

If a hero has any of these themes, it is not possible to also become Beartouched:

Gallery