I am planning to have a couple of articles about the Steam Dev Days, since there were some good insights about what Valve is doing and how they see their services in the coming future. Of particular interest to me is the  session dedicated to the Steam Controller. While it was not OS-specific the implications of the upcoming changes and updates are worthy enough to mention even for the Linux gaming crowd. You can watch the whole video if you’d like, but here’s a digest with some selected extracts to make the most of your time (the session was about one hour).

First, the Steam controller continues to sell well. In June 2016 it reached 500k units sold and now they are well on their way to reach 1 million by early next year, which means… another 500k units in 7 months or so, about 7k sold every month. Not bad. They have started to include the controller in sales and while they did not know what to expect, the sales on hardware apparently follow pretty much the software trends: volume increases in the same way. Gamers have been also uploading a bunch of custom configs (1.2 million game configs through the workshop).

They have also started to expand the number of territories where they ship the Steam Controller. That may be good news for you, but if you live like me in the no-man’s land archipelago known as Japan you will have to wait for more until you get an official distribution here. OK, I get it, PC gaming is not big over here, but still it’s one of the largest video games markets in the world.

The Steam Controller has been receiving about 70+ updates in the past year since launch. That’s impressible and most of these updates were completely seamless. I really like what they have done with this by making the firmware constantly upgradeable instead of making the controller “stupid” like on consoles.

But that’s not all. With an upcoming update of the Steam controller API, there will be official support for numerous popular controllers. That means that if you use that API you do not need to create controller-specific code anymore. They will first start with the PS4 controller that can basically be mapped freely just like if it were a Steam Controller.

In order to ensure that devs adopt that API, Valve will create a badge for games supporting the Steam Controller API where mappings are configured in terms of actions and not buttons. The expectation there is that the dev would publish an official configuration while leaving the freedom to the user to remap everything if they are so inclined. This also means devs would integrate the keyboard input mode of the Steam Controller when actual text input is required in-game. And more importantly, it should work directly from Big Picture Mode without requiring any additional launcher.

Those are very positive and thoughtful requirements. I am all for making more games work “natively” with the Steam Controller or any other controller for that matter, yet I am wondering if devs will go to the trouble of doing this additional integration effort just for Steam. This remains to be seen.

Up until now, dealing with controller support was a kind of mixed bag for many developers, as shown in the below extract:

So Valve’s Steam Controller API is trying to turn the problem around by implementing “actions” in your game regardless of the input model - this makes it possible to decouple the actual configuration (the input) and how it is interpreted by the game (the output, or the action). The Steam controller (and other controllers) has basically two forms in inputs, analog and digital - and the Steam Controller API will return the action associated with whatever is pressed, based on the configuration you provide or the one that’s made by the end user.

But that’s not all. The Steam Controller API also provides Action sets, to change the mapping of the controller you are using depending on the game context. As indicated you can imagine the control mapping to change in a game like GTA when you are driving or when you are walking on foot. Action sets can provide a direct solution to that kind of situation in games.

And since everything is left to the control of the end user, you can have different input configurations assigned to different controllers/players, based on their preferences. To implement the Steam Controller API in your game, you’ll need to interface with its C/C++ API. In case your game is written in a different language, you’ll have to create a bridge to translate the calls.

What’s kind of new as well is that the API is not event-based. You are constantly getting the state of everything, just as you update constantly the state of your game. It may seem strange at first but there is actually a very good reason to design things this way. Since the state of the game can change at any time (because of the action sets mentioned earlier), it’s preferable to have the Steam Controller function this way to detect the state of the game at all times without too much latency. On top of that the documentation insures that this call is “cheap” in terms of cycles so there is no reason not to use it in your games.

To handle all these different configurations the API refers to VDF files, a specific format made for the controller config, kind of like Jsons but not exactly - the Steam Controller interface in Big Picture mode is basically the GUI to write such VDF files. If I remember correctly the open source Steam Controller driver (not supported by Valve) is also trying to support VDF files.

For analog and mouse movements the API creates a vector based on the distance from the center position, and for other events it returns the action name, which has to be unique since you only get the action names from the API (you never see keypresses or the like in your game).

You can control several controllers (for example if you have a multiplayer game) through handles, and the handles are basically unsigned 64 bits integers for each controller detected. And the cool thing is that you can assign specific action sets to each controller or reset at the same time all controllers on the same action set.

The other reason why you need to update the controller’s state continuously is because the player can change the configuration mappings anytime through the Big Picture mode! It provides the added benefit of detecting also when controllers are disconnected and ensure the game reacts properly when such triggers happen.

The haptic pads can emit some kind of vibrations (“pulses”). With the Steam Controller API you can actually create very price pulses and control exactly how long you want them to emit vibrations. It could be used some kind of force feedback when the haptic pad detects a finger on its surface, for example.

The other advantage of using the Steam Controller API is that it integrates completely with Valve’s Steam Big Picture mode and the overlay GUI - as it does currently. Valve is simply calling for developers to embrace this API and not just for the Steam Controller, but for all controllers from now on (as long as they support them). The overlay also lets users call a keyboard when text fields are required in your game - you could make that completely transparent for the end user if you call the overlay when such input fields are required.

One of the issues of the current overlay keyboard is that there is no Japanese or chinese editor. Not sure if Valve is going to work on that, but since they are now shipping the Steam Controller in Asia now they might as well think about supporting it.

And the meat of the presentation was of course the upcoming support of the API for non-Steam Controllers, with the PS4 pad being the first one to benefit from it. The speaker did not want to disclose what other controllers would be supported, but one can imagine the XboxOne Controller would probably be next… and who knows, maybe the Wii and WiiU peripherals at some point?

While the PS4 gamepad is not as feature rich as the Steam Controller, you can integrate a number of its inputs through the API, such as the integrated gyro and its touchpad. That’s pretty cool since the existing native support was pretty bad so far in Steam.

Some of the added benefits of the whole “action” output of the API is that you can easily record demos of your game and replay them seamlessly by simply storing the actions in a timeline instead of keypresses as folks do usually.

In closing, the Steam Controller API needs you not to assume anything about the player or the controller.

The only problem with the Steam Controller API is that it’s basically tied to the Steam platform. If one uses this API for Steam, it cannot be reused as is for the same game on other platforms (such as GOG). So while this makes it a better experience for Steam games, this also further provides incentives to lock developers to Steam and Steam only. Well, this is not the first step Valve takes in that direction (workshop, achievements, etc…) and this is the nature of competition, but this puts GOG in a disadvantage while their Galaxy client is still not even out of beta.