Closed SonarBeserk closed 6 years ago
The nice thing about response curves is there is no objective truth. You can use literally any equation you want. Sometimes there are properties worth seeking (such as passing through the unit square), but ultimately if you like the relationship between input and output that a particular equation gives, you can just use it.
If you want to experiment, I recommend Graphmatica and Desmos. Play with the equations and constants/coefficients and see if you can find the patterns in how to change shape/position for a given curve.
The rest is just applied algebra.
Ah good to know. And so the current equations are just based on what's in curve edit otherwise? And in that case I think ill just have to spend some time tinkering.
On the same topic, I would be interested to read your thought on your equations. I did implemented a similar response curve system and ended up with similar equations for Logistic and Logic last year.
For Logisitic, I did not like the way it never reaches the interval boundaries. So I did a few modifications to always reach them.
For Logit, what trouble me in the few implementations I have seen so far is the use of X-Shift with it. In the example, I set Slope and Exponent to 1 (There is also a UI bug but it should not make it totally unreadable).
If X-Shift is > 0, it is not really a problem as the NaN value will be transformed into 0. However, for X-Shift < 0, in [0, X-Shift] the curve is nicely progressing toward 1.0. In [X-Shift, 1], the curve is a 0-constant curve. In this case, I feel like a 1-constant curve would be more adapted for a usage in a Utility System. In the general case, if I really would like to get a similar looking curve, a polynomial one seems more suited.
What are your thought on this? (Regarding the UI bug, I am currently running Curvature on Win7)
I've worked with several different variants of the Logistic and Logit curve types, and all of them have different tradeoffs. For something like Curvature I agree that passing through corners of the unit square is important, and clamping Logit to the most "recent" extreme instead of always to 0 makes a lot of sense.
The tradeoff of course for those two is increased computation time, which for Curvature is not an issue. However, I originally modified the curves from a realtime game simulation which is why they favor performance over convenient behavior. I will consider re-doing some curve equations to behave a bit cleaner. (I think the Normal Distribution one was a bit quick and dirty as well.)
Thank you for the in-depth explanation. Due to the increase of computation time, it indeed makes sense to have those equations. Looking forward to the future response curve equations document.
I am working on a similar system in Golang and wondered where you got your response curve equations. I'm primarily wondering where the shifting equations and magic numbers are coming from as "Behavioral Mathematics for Game AI" lacks this information.