Back to the code. You may have expected something more complicated. I know I did when I was first writing JoyShockLibrary and JoyShockMapper. Some games will do something more complicated — they'll do something called "sensor fusion", combining a gravity vector from the accelerometer with the rotations from the gyro to know what's up and down. But I suggest not doing it for two reasons:
- Sensor fusion can be complicated. Big commercial games that are otherwise extremely well made can apply it poorly. Super Mario Odyssey, for example, uses it for aiming a tank. But when playing with the JoyCons attached to the console, they're mostly pointing up. Pitching them further up to aim up in game makes the JoyCons upside down, and the game responds by aiming down instead. It's awful. The problem isn't intrinsic to sensor fusion — World of Goo does a much better job with it — but complicated solutions are prone to problems. Just keep it simple. Your mouse doesn't care if the user is upside down, lying on their side, or holding the mouse the wrong way, so why should the gyro?
- Sensor fusion is a compromise between two sensors that disagree with each other. If the player is moving for a lot of time and the game doesn't get a chance to get its bearings, this causes increasing errors in the game's interpretation of the player's input.
Caution! If you're considering using sensor fusion to use a real world orientation for your controls in-game, it's likely better that you don't. It's much more complicated, full of compromises, easy to do poorly, and unnecessary:
- The mouse doesn't know its absolute position on the mousepad; the gyro doesn't need to know its absolute orientation.
- Sensor fusion is great for VR, AR, manipulating 3D objects freely, but this isn't VR, this is a mouse.
Now, while games with standard mouse controls sometimes do additional work (mouse acceleration, smoothing, etc), it's always optional. Always. If the player can't reduce things to essentially the "core" above,
these are bad mouse controls. Even if the changes have clear benefits, players have the reasonable expectation that they'll be able to have the cursor or aimer respond in linear proportion to their mouse input, without delay. This inspires some of the values of good gyro controls — simplicity and transferability. These controls are easy for players to understand, easy for developers to implement, and understandably form the basis for practically all games that benefit from a mouse-controlled cursor or aimer.
This
should be equally true for gyro controls. As we continue, we're going to look at doing more than just our "core" above, but everything we add will be configurable and optional. These things will include acceleration, smoothing, and we'll look at speed thresholds (which are the devil's work, but some games have them, so let's look at them). If
any game that uses the gyro to control a cursor or aimer has these features and they
can't be disabled or configured to the point that they're truly negligible, that game has
bad gyro controls. Even if they had
my preferred acceleration settings and filters and did everything "right" from my subjective point of view (which they don't), they're still
bad gyro controls if those settings and filters can't be disabled.