Analysis of hybrid vs single stat armors at max level
"Yes, but I feel having a mod which changes which stats it grants based on the alignment of the item (e.g. only evasion on pure dex gear, evasion and armour on dex/str gear) would be unnecessarily confusing. It's also impossible with the way mods are right now, and would take a large amount of work to implement. Mods have a set list of stats, and that's what they apply. I do think having hybrid defense mods (e.g. a mod for increased evasion and increased armour) and limiting them to only spawn on the right types would potentially be a good idea, but I'm not entirely sure of the balance consequences, and such things aren't really my call. | |
|
^ they wouldn't actually need to change what they modify based on the alignment of the item. You could have it modify all three mitigation stats equally; since 130% of 0 is still 0, the effect would be the same. A "+30% dex mitigation" item would therefore grant 30% evasion on a pure dex armor, 30% evasion and 30% armor on a str/dex armor, and 30% evasion and 30% ES on a dex/int armor. All one modifier, since your inputs are going to be different depending on the underlying item type.
It'd just be a matter of replacing "+30% armor" with "+30% mitigation for str-aligned items" (and, I suppose, you might want to make sure you can't double-up these mods on hybrid armors). Granted, I don't know how things are handled on your back-end, so this may be harder than it sounds. From a pure logic-gate perspective, it's quite simple. ------ "And 'Do what thou willst' shall be the whole of the law." -- Aleister Crowley "First, love; then, do what thou willst." -- St. Augustine "Whatever is done out of love always takes place beyond good and evil." -- Friedrich Nietzsche Last edited by SinisterDexter#3081 on Dec 7, 2011, 5:38:08 PM
|
|
"If you do that, they won't be described on separate lines like you were suggesting before. And there'd actually be no reason to have the different versions, it could just be one mod for "increased defenses" which increased the defenses of whatever armour piece it spawned on. That may or may not be a good thing. Last edited by Mark_GGG#0000 on Dec 7, 2011, 5:41:00 PM
| |
" Couldn't you just call the modifier named something like +% mitigation or +% protection (or even +% defense, since that term isn't claimed in PoE nomenclature) and have it increase whatever is granted on the armor? I would recommend having (some) nodes in the passive tree do the same thing (+% defense, which applies to all types). |
|
|
Yeah, you're right, a single defenses percentage modifier is the easiest way to go. Assuming that the premise of the thread is accurate and hybrid armors are underpowered, what's the downside?
------
"And 'Do what thou willst' shall be the whole of the law." -- Aleister Crowley "First, love; then, do what thou willst." -- St. Augustine "Whatever is done out of love always takes place beyond good and evil." -- Friedrich Nietzsche |
|
"Having one version per type of armour which can only spawn on that armour is equivalent but nicer on magics where you'd have evasive armours getting different prefixes to physical damage reduction ones. | |
" That, is actually a really efficient solution since it would neatly cover all item types with one simple enchantment. As for the descriptions that show up in the item name, just drop anything that comes up zero so the players don't have to see weird clutter. Using a couple quick examples from the OP to illustrate your idea. " lvl 60 Str armor (421 AR) 421 AR x 130% == 547 AR lvl 60 Str/Int armor (210 AR / 69 ES) 210 AR x 130% == 273 AR 69 ES x 130% == 90 ES I must say. That could work, and it's a really clear and easy solution. However from a developers perspective this is also a bit awkward since you've now effectively lumped the enchantment for seven different things, into one thing. If they need to adjust that for balance it becomes trickier because changing that one thing, affects many things. Also there is the question of prefixes or suffixes. It will confuse the number crunchers a bit if they keep seeing the same item prefix/suffix on seven different enchantments. Not that they won't figure it out in the end but it is something to keep in mind. ----------------------------
Joined: September 28, 2011 Beta-Key: November 29, 2011 (Big Thanks to Literature) |
|
"It's already called "increased defenses" and there's a passive which does it for shields. "That can't be done,(if I'm understanding you correctly). A mod has no information about the armour piece it's on, only it's own stats, which it displays. In the case where it's all done by one mod regardless of armour type which increases all defenses, there are two options: 1) It's displayed as "Increased Defenses" and works like the existing shield passive, applying the same increase to all the item's defenses (ES/armour/evasion). This may confuse some people who consider resistances should be a 'defense' as well. 2) It spells out the three x% increased armour, x% increased evasion, and x% increased energy shield on separate lines. This has the disadvantage that it's always showing at least one stat that has no relevance to the armour piece it's on. My own personal preferred solution is to have 6 different mods, each only occurring on their own armour type, each of which increases the two relevant defenses, because that makes it explicit in all cases what's being modified and also means the mods will have different names and thus let magics have different prefixes for the different types. | |
" Fair enough. Any thoughts on resolving the similar issue that many passive nodes only increase 1 type of mitigation, thus making them less useful for hybrid armor users? (unless I am mistaken in how these apply) Maybe I am overreacting to this being a potential problem. Last edited by Britannicus#3214 on Dec 7, 2011, 6:57:32 PM
|
|
" If I am understanding you correctly this is precisely what I keep trying to suggest. Basically add eight new enchantments to cover each of the various hybrid armor types. For clarity I am ignoring the fact that there will no doubt be multiple tiers of each enchantment so they can scale properly on higher level items. STR/DEX +armor AND +evade %armor AND %evade STR/INT +armor AND +evade %armor AND %evade DEX/INT +evade AND +shield %evade AND %shield STR/DEX/INT +armor AND +evade AND +shield %armor AND %evade AND %shield I realize this seems overly complicated. And it's true that it is a complex solution. But it's also a smart solution that better for a couple reasons. From a developers standpoint having so many different enchantments here makes it easier to balance things. Rather than changing one thing and worrying about how it affects other things you can adjust each category individually. Balancing things now becomes as simple as updating a spreadsheet. As you said Prefix/Suffix style names can be individually tailored to better fit each armor type. It may be a small cosmetic difference that many people don't even notice but it's these small touches that make a better game in the end. Meanwhile the existing single stat enchantments can be retained, removed, or rescaled as desired for the hybrid armor types. If they are retained for the hybrid armor types this should be done by cloning them. What this means is our original six enchantments get copied creating 18 brand new enchantments. Like before cloning them may seem complicated, and it is. But it's also smart. Using cloned enchantments here leave the option open to tailor the prefix/suffix names and it makes balance much much easier. And lastly, the six single stat enchantments we already have can remain right where they are on the single stat equipment. Using both hybrid enchantments and cloned enchantments here actually brings the grand total up to 24 new enchantments (many more if you count the scaled higher tier versions). But it's the smart way to do things. And complicated as this all is it's something that gets quietly buried under the hood. The average guy doesn't need to know how an engine works. He just wants one that sounds good. ---------------------------- Joined: September 28, 2011 Beta-Key: November 29, 2011 (Big Thanks to Literature) Last edited by DoctorZuber#7774 on Dec 7, 2011, 7:07:35 PM
|
|
