Avatar of lightning/ avatar of cold implementation
" ...and there is no way to have additional keystones just like AoF that simply override the current rules? I don't see how it would be so hard. |
|
"So it's essentially the same as with desyncs. There are close to no such issues at all when you play other multiplayer ARPGs around the internet. But the game just desyncs. Too bad GGG has too few money to have game engine implementation as polished as those other soulless ARPGs around... :( |
|
|
i see it as lazy excuse that it loops.
Why it cant work as works blood magic and eldrich battery together? they neglect both of them and prevents anyone from picking both. Last edited by Andrius319#4787 on Jul 25, 2014, 2:10:41 PM
|
|
" It's not lazy. It's fact. If you convert fire to cold and cold to fire in the same attack, you have an endless loop in that skill. However, if you have EB and BM, you convert all ES to mana, and you remove all mana. You therefor have no ES and no mana. No possible loop. This is because life isn't being converted into anything. P.S. You also necroed this thread. Last edited by Natharias#4684 on Jul 25, 2014, 6:44:40 PM
|
|
" How about just taking cold spells or lightning spells instead of getting an avatar to do that damage? |
|
" it's not "lazy" if there are actual reasons for how it is done, or why it is not done differently. but let us do some graph theory to understand the problem. let's say we have a graph that has 5 nodes: P, L, C, F and Ch. each node gets a number attached to it, that is calculated during our calculation, then all these numbers are added up and that is our result D. So: D = P + L + C + F + Ch Now, as long as neither of these values depend on each other, you can calculate them in any order, and the result doesn't change. but if you add conversion, you create a dependency between the two nodes. So if in your calculation you "convert X% of C to F", then you must calculate C before F, otherwise you get the wrong result. This is called a topological sorting of the dependency graph. a topological sorting can only exist if the graph has no cycles. so you cannot have "C to F" and "F to C" (cycle of two) in the same calculation, neither can you have "C to F", "F to L" and "L to C" (cycle of three) or any longer cycles. if there are any of these cycles, you either have an endless loop, or one of these conversions will always result in the value of 0, or some other sort of incorrect value, as you calculate the value before all dependencies are calculated. now you have two options:
option 1 is the easiest. option 2 is more flexible, but also more computationally expensive. and it doesn't solve the problem that you need to guarantee there are never any cycles. as far as i gather from this thread (and i have no knowledge of game internals), GGG went with option 1. if you want to handle cycles without falling into an infinite loop, you cannot use topological sorting to calculate the value of D, but instead you have to solve a flow problem, which is both much more complicated to implement, and is in a much higher computational class, so takes more computing power to calculate. |
|
|
I like it like it is now, game gives you different choices depending on what kind of character you want to be considering damage type, defense stats ect.
how will it be if for every keystone/notable you have conterparts. Iron reflexes counterpart that transformes armour to evasion (evasion + dodge builds could be OP) Point Blank counterpart that gives you more damage as projectile travel fruther and less for closeups (every party would need to have sniper cause of his dps over distance) |
|
|
Sorry, nothing too substantial to contribute, just saw this...
" That kind of attitude doesn't get pizza. That kind of attitude gets a poorly made pizza-bagel that's been sitting in the fridge for a week. Now, MAKE AN AVATAR OF COLD *whip crack* |
|
" sigh it seems that i will need to say more than two words as i did in previous post. The whole question lurkering here should be: "how to balance it" or "how to implement this". yes i do know how mechanics work you described and i do understand the problem mechanics encounter. I called it lazy because code vise it isn't much work. The solution we looking for is what we want to see. If we would implement three avatars, independently (then picked one of them) they should work as normal. if ggg decides to make conversions different, lets say lightning 40% cold 30% fire 50%, let it be. When situation comes to then two or three avatars are picked, then the decision is up to ggg: If they do decide that there can work only one avatar, so be it, write additional two lines in the code and make them not work at all when picked more than one avatar. If they decide to make them work they should rewrite the code and decide how to balance it: what percentages give to every element AND what portion of overall damage will be converted, for example: lets say conversions are: fire 50%, lightning 40%, cold 45%. it would lead to 135% conversion of 300% or 45% of 100%, this would fallow to 16.7% of fire damage, 13.3% lightning damage and 15% cold damage. If they would decide that every element is left untouched to each correspond avatar the damage would increase drasticly. If they decide to (lets say cold damage) leave 33% of cold damage not reduced as there would be picked avatar of cold, and other two portions of 33%+33% would be mitigated and converted by other two avatars. As i said the whole question is "how to balance it" and not "how it doesn't work" and leave it alone. all it needs is some decisions how it should work and some code rewriting. Last edited by Andrius319#4787 on Jul 26, 2014, 3:18:28 PM
|
|
|
there is no question about balancing. if you take "deal on non-fire damage" and "deal no non-lightning damage" at the same time, you deal absolutely zero damage. BOOM. balanced.
|
|
