A system with hysteresis is a system whose output can’t be predicted simply by looking at its current inputs. It has “path-dependence.” If you want to know what its outputs are, you have to look at the history of its inputs.
Consider a non-hysteresis example first: your stereo’s volume. If you turn the volume to 50%, it doesn’t matter if you’re turning it down from a higher volume, or up from a lower volume. It’s going to set the volume to 50%, regardless.
A typical hysteresis example is a thermostat. If you set your thermostat to 20 degrees, it doesn’t turn on the furnace at 19.9 and turn it off at 20.1. Rather, it’ll turn on at 18, and then stay on up until 22. So, if the temperature is 20 degrees, you can’t tell solely from that bit of information whether or not the furnace is on. Rather, it depends on the history of the input– in this case, the temperature.
In games, we frequently use hysteresis when mapping analog input to digital output, in order to prevent small deviations in analog input from fluctuating rapidly between discrete states. Like the thermostat, we do this with a “keep doing what you were doing” state. It often boils down to a bit of code like this, from a blog entry by Shawn Hargreaves:
const float hysteresisAmount = 0.1;
if (inputValue > threshold + hysteresisAmount)
DoSomething();
else if (inputValue < threshold - hysteresisAmount)
OtherThing();
else
KeepOnDoingWhateverYouAlreadyAre();
If you read the above-linked blog entry from Shawn, you’ll get a few good examples of hysteresis in games. You’ve probably played games which have failed to exhibit hysteresis. One I’ve seen far too many times: AI enemies keep running towards you, then running away, then towards you, then away. Hey, AI, keep doing whatever you were doing!
For now, I’m interested in hysteresis associated with player input. Shawn gave one example: if you push the analog stick just a little, you get the walk anim. If you push it a lot, you get the run anim. If the stick is in the middle, you don’t know if your character is walking or running, because we’ve built in a little “keep doing whatever you were doing” threshold in there.
That example is no longer applicable to modern games, which blend between the anims. Are there other examples of hysteresis relating to player controls? Where do we map analog player input to digital output?
One example is target selection in a third-person brawler. Which guy do I attack, when I hold the stick towards a couple of close-together dudes? The input here is the stick angle, and the output is the target. Most games will “stick” you to the same target once you’ve started beating him up, unless you press substantially far off from his angle. The game cares about the history of the input: “did you start out pointing towards this guy, or that guy? If your input is in that threshold zone, I’ll keep you pointed at the same guy.” If games don’t do this, targeting will feel jittery, and your character will look stupid as he alters his facing rapidly between two competing targets.
One tricky part of discussing hysteresis is limiting the definition. Of course games exhibit path-dependent memory– if the order of your button-presses didn’t matter, it wouldn’t be a very interesting game! So you need to define “system” very narrowly: “If I press this button, do I jump?”
Also, hysteresis describes path-dependence, not rate-dependence. A good rule of thumb– without trying to get too far into the definition of hysteresis– is to ignore any phenomena that are dependent on time. For example, if I press the jump button twice quickly, I’ll only jump once (because I’ll still be in midair). That’s not hysteresis. We want output that’s dependent on path.
Yikes! I suppose that’s more than you ever wanted to know about hysteresis. I’ve been trying to come up with more examples of hysteresis, especially related to player input. Aside from targeting, I haven’t come up with much. Let me know if anything springs to mind.
