Deadzone variance seems to have always been a known issue; I remember stick calibration tests in a bunch of N64 games. I assume they were mostly dropped as sticks got better protected but I’m glad system-level deadzone adjustments are become standard (Sony, as usual these days, is lagging behind).
Yeah, I watched the Rayman Legends one and thought, here’s a good example of programming stick input to a different goal, mimicking a dpad, and what you’d want to do. And his analysis is good for uncovering subtle bugs like the facing/moving disconnect he finds, and the different shape of the different tests implemented which are surely meant to be the same.
It wouldn’t surprise me if the curve wasn’t understand by the programmer; it’s funny how different this conception of the data can be from the handful or rules and exceptions that get added over years to form it. Sometimes I dream about tools that can plot the result of parametric functions right in the editor as they’re worked on.
Looking at the Halo curve, it tells an obvious story of design nudges put together in response to watching players:
- I find the aim moving even when I’m not giving input, and it’s different on each controller – ok, ignore the bottom 26% and scale the rest 0-1
- we need more sensitivity on the low end – ok, I’ll make it a growing curve
- we need to turn faster when we really want to turn around – perfect, I’ll bend the curve even more
- I find that I want to slow down just a little at the top end, it feels like everything above a certain value is the same – ok, I’ll slow down the top and now we have an s-curve
It’s a design that ignores how the input device should work in favor of designing around how have adapted to use the tool. Could users be trained to use the entire input space if the game made them? Maybe…but you’re fighting against the entire rest of their experience and need their active cooperation to retrain them.
