In porting my existing game, a platformer, I'm finding that delivering an enjoyable game experience while using the click action of the remote trackpad (button "A" as defined by Apple) to be nearly impossible. Jumping is clearly the primary action of a platformer, but using the same surface for directional control and jumping greatly reduces the acuracy of both. It's easy to underestimate the frequency and the degree by which the user's thumb naturally varies pressure on a D-pad, physical and virtual alike. This reults in unintended jumps or terminations of jumps, while intentionally pressing to jump often results in subtle movements that initiate an unintended change of hero direction. I'll probably file a feature request for access to the volume down or Siri buttons, but I'm not really sure that's the best solution, nor can I reasonably expect action on it before release. In the mean time, what are others doing? If you're designing a game, are you using the trackpad click or "A" to trigger the primary action as directed by the docs, or have you gone the direction I'm considering and swapped your "A" and "X" actions, making the trackpad reaponsible for a secondary action that happens to require less precision such as "fire"?
Will your game respect trackpad clicks for primary actions?
This won't address all the issues you mention, but rather than watching for events, you can look at the raw thumb position on the trackpad. That might allow you to circumvent some of the "subtle movements that initiate an unintended change of hero direction", by adding a "dead zone" around the click space.
Another option would be to use the accelerometer to input the directional control of your avatar (twist left to run left, twist right to run right), and then use the touch for the jump, instead of a click. This feels a lot more light and precise than the more imperative click action, and might really suit the context of a run-and-jump platformer game. I've found this control style to be really intuitive with the Siri remote. I'm not doing a platformer, but the controls for my particular use were very easy to internalize using that scheme.
Thanks. Those are interesting thoughts, particularly the second one. It's well worth experimenting with accelerometer data. It doesn't intuitively sound precise in the context of a platformer, but my intuition doesn't really matter until I've actually tried it! 🙂
The problem with trackpad input isn't so much that GCMicroGamepad's interpretation of the data is off, but that the physical act of clicking can so dramatically change the position of ones thumb on the trackpad that the amount of hysteresis required to fliter it out would make the trackpad unuseably imprecise under most circumstances. Again, I'm speaking in the context of a platformer or many other types of action games. It's fine if we're all writing puzzle games, board games, or similar. Likewise, it's fine in any game where the two actions don't have to be performed simultaniously. In absence of access to another, separate button, I think a lot of us have to make tough decisions about which of our game actions are most useable when mapped to the trackpad click versus the play/pause button, even if that choice violates the convention of the trackpad being "A", the primary, most used action and play/pause being "X", the lesser, secondary action.