Not All Native Bindings are Better Than Non-Native Bindings
As a Steam Controller enthusiast, one of the first things I look for in a new video game to play is Steam Controller support. It could be as simple as a native configuration to bump it up in my consideration, but if it happens to have Native Support I used to consider that alone as a reason to support the game. Unfortunately, that has changed over a few of the games that I’ve played. While all of the games I’ve played with Native Steam Controller support look like they’re earnestly trying to provide a good experience for their game, some of them just don’t seem to grasp what the purpose of the Steam Controller API really is.
To provide some context for what I’m talking about, here’s the primary advantages to the Steam Controller API. The first it allows your program to communicate with the Steam Controller Configurator, so that your in-game button prompts can automatically align with the user’s configurations. For the end user, that just means button prompts always match their configuration (and, by extension, always matches their controller). The second is that it allows the Steam Controller to switch between actions sets based on program inputs, so the end user can configure their controller settings differently depending on whether they’re in your program’s menu, in-game, in a car, not in a car… whatever the programmer defines as a state for an action set. The third is that it simplifies configuration by removing an abstraction layer. In other words, rather than the user trying to figure out which button on the Xbox or Keyboard is mapped to “Jump,” using the Steam Controller API will allow your program’s users to map “jump” directly to a button on their controller (regardless of controller type). Fourth is that, in the case of the Steam Controller, it allows you to use mouse-like inputs for the controller.
Over the course of this site’s life span, it is my hope to review the Steam Controller support in games that my personal budget allows me access. But for now I’d like to focus on two in particular that I feel represent either end of the spectrum of Steam Controller support. The bad one is Oceanhorn: Monster of Uncharted Seas, and the good one is Defender’s Quest: Valley of the Forgotten.
(Author’s Note: This information is based on each game’s Native Implementation as of Dec 28, 2016. As of this writing neither game appears to have updated their Steam Controller configuration, but may update after publication, rendering the observations here irrelevant. I am also not making a statement about the quality of each individual game beyond detailing the problems and advantages to their respective approach to Native Steam Controller implementation.)
Oceanhorn is an adventure game clearly very heavily inspired by “The Legend of Zelda.” The Zelda games rely heavily on mapping the inventory to buttons on the various Nintendo controllers they’ve been associated with. Oceanhorn does the same, but mapped to the Xbox controller (or keyboard buttons, when using the mouse and keyboard). Because of this, the Steam Controller implementation assigns each action based on the Xbox controller button it’s associated with on screen. While understandable, given the game’s implementation, doing it this way offers no different behavior than what appears in a typical xinput emulation setup used by games without use of the native steam controller API as far as button assignment is concerned (especially since none of the on-screen graphics change to reflect your configuration). This itself wouldn’t be too bad, except that because the game uses the Native API, it depends on the game to send signals in order for any action set to change. And Oceanhorn only uses one action set to represent the gamepad. In other words, their implementation actually removed functionality rather than add it. For me, this was a deal breaker that made me refund the game, since in the sailing sections it more or less demanded that I aim my cannon using stick emulation, rather than having a separate action set that I could use to selectively aim with the gyro in the sailing sections. I’ve since learned how to disable native implementations, but it’s not intuitive, and Oceanhorn’s Native Implementation still makes it a more frustrating task.
On the other hand, Defender’s Quest takes a completely opposite approach, using the game’s Native Steam configuration in every way to empower rather than disempower. That’s no surprise, since the game’s creator was chosen to give a speech at Valve’s Dev Days on how to implement Steam Controller support, but how he did it will help illustrate what a good Steam Controller API implementation looks like. There are three action sets, that automatically activate when you enter the battle screen, map screen, or a menu (the three different types of screens in Defender’s Quest). This means that the player is able to configure each screen’s controls separately, but doesn’t need to concern themselves with manually switching between those control schemes. Each action set has its own list of actions associated with them, yet the options you can choose in each are extensive, covering several different types of play styles a user could want. For example, there is both a pause toggle, and a force pause option. There is both an open the spell menu option, and an option to pull up each individual spell you can cast (all clearly named, so you know what they do rather than what button they push). And, even better, if you choose to use these options in game, there’s a comprehensive list of icons, taken from in-game graphics, available for you to use to associate even more quickly with what the action is. The main configuration doesn’t even use these icons; it just has them available for people who may want to use them. What’s more, the game doesn’t assume that you’re using the Steam Controller as either a mouse, or a raw controller. Instead, it offers you the ability to control the mouse cursor using the trackpad, or click through a traditional console like menu system up to your personal preference. The Steam Controller, with this configuration, becomes a tool for the user to use however they want, without having to manually sort through and keep track of what does what in each situation.
As can be clearly seen from these examples, the Native Steam Controller API if applied incorrectly can actually be a detriment to your game, while on the other hand it can allow for configuration options impossible without it if done correctly. If you do happen to find yourself playing a game with an Oceanhorn-esque control scheme, do yourself a favor and select one of the template configurations so that you can effectively disable the native support, and emulate a better control scheme instead. In the meantime, stick around this site so that hopefully you can find more Defender’s Quest quality control schemes in other games. If I find one, you can be sure I’ll let you know about it!