Damage Over Time Changes - Part 1

"

tacotiklah wrote:

I'm curious how this will affect skills like viper strike, which rely pretty heavily on poison double dipping to feel good overall.

"

Entropher wrote:

Wait, spell damage applied to burn til now??

"

Rory wrote:

Reply to this forum post with any questions you have about damage over time mechanics or design, we'll be answering them in a third post in this series.

"

mhyoung wrote:

maybe a built in calculator? I don´t really think the tooltip has enough space for that much info, but for a game that is totally based on informed decisions, we have very poor tools for decision making.

"

Cyrith3 wrote:

This seems kind of concerning. Maybe I'm just misinterpreting, so here are my concerns.

There are double dips that I would consider intuitive, and ones I would consider completely idiotic. For the latter, here is an example: projectile damage poison double dipping. This is utterly idiotic and requires knowledge that the game just doesn't provide to know it is a thing - I know my friend was making a phys/chaos bow based poison build and I had to explain this to him, the difference was hugely surprising. This wasn't really addressed in the post, though I'm sure it is a consideration, if it was not, PLEASE ADDRESS THESE.

The main concern I have is the approach. From what I gathered, it seems as though any build that does not explicitly focus on these mechanics will basically get zero value out of them.

"

This means that Increased Spell, Attack, or Weapon Damage will no longer influence your Ignite, Poison or Bleed damage at all. It also means that while modifiers to Fire Damage will still apply both to a hit and to the Ignite it causes

My reading of this was that suppose a spell deals at base, 100 damage, and ignites for 20 damage per second over 5 seconds (this includes the doubled ignite buff proposed in the post). Suppose I get 100% increased spell damage, now I have 200 damage on hit, my ignite still at only 20 dps over 5s. Suppose I get area damage, cast speed, etc, all these modifiers - my ignite will not scale from them. I appreciate the thought in saying that scaling the initial hit and the DoT from certain modifiers can be counter-intuitive, but I strongly believe that this would be even more confusing.

Suppose we have a new player who is reasonably competent in the current system, you can imagine something like: 'So ignite damage is based off the damage dealt, and deals fire damage. So if I get more fire damage I will hit harder, and presumably the ignite would also be affected by that fire damage, that sounds interesting!'. Compare this to the new system where you have 'So ignite damage is dealt based on the base damage and is scaled with fire so if I get fire damage both will increase, but if I get spell damage surely the ignite damage will increase since it is a spell effect, or would it not be counted since it doesn't have "modifiers to spell damage also increase this spell's damage over time" on it?'. Immediately more questions are brought up than before.

This is a game that rewards thought and exploration of game mechanics, and this simply adds a very bandaged 'fix' to the system that arguably doesn't need to be done. A much better approach to enable non-DoT builds would be something like passives and skill gems that do the same trick. Imagine a keystone that hugely increases your damage but removes your ability to ignite/poison/bleed. Or support gems in the same vein as elemental focus that remove the ability to damage over time but increase the damage you dealt if you would have ignited or applied bleed/poison. Making mechanics selectively apply to some things and not others just makes the game less approachable and less deep, and this can only be harmful. Furthermore taking power out of double dipping, only to just put more power into the things double dipping affected and making passives apply to both the initial and the DoT kind of just... is a rewording of the whole thing? In general this just seems BAD. Maybe I have it all wrong, but this just does not seem like a good fix to the problem.