Steam Dev Days: Steam Controller

This is a record of the transcript and slides of a talk originally given at Steam Dev Days, October 12th 2016. For more details, please see SteamDevDays.com

Title: Steam Controller
Speakers: Jeff Bellinghausen (Valve) & Lars Doucet (Level Up Labs)
 

Hello. I’m Jeff Bellinghausen, I work on the Steam Controller team at Valve. Today Lars and I are going to discuss the benefits of integrating with the Steamworks Controller API, and how it can be used to simplify your games input code.

Before we hear Lars dive into the API itself, I want to give a quick overview of how the Steam Controller is doing in the marketplace.

One of the reasons we liked using trackpad technology when we were designing the steam controller is that they can be easily virtualized through software, allowing us to expand the controller’s functionality over time. It’s now been almost exactly a year since we shipped the first Steam Controller preorder units, and we’ve since pushed over 72 updates to Steam that specifically target the controller functionality.

Some notable updates added “activators” that let players do things like assign an action to a long press of a button,”action sets” that let players define multiple configurations that they can cycle through on the fly, and on-screen radial menus that can map up to 20 different actions to a single pad.

Soon we will be shipping an update that adds full configurability to controllers other than the Steam Controller. This means that players can pair their PS4 controller directly to their PC and use all the configurability options available to the Steam Controller, including use of the PS4 touchpad and gyro.

(plays video of DOOM footage -- I will update this with a link if it becomes available online)
 

We plan to continue actively extending the feature set for all controllers.

Customer satisfaction is very important to us, so we like to actively monitor community reviews. We’re happy that the Steam Controller has been well received by customers, and currently holds an 81% “very positive” rating on Steam, and a 4.2 out of 5 star rating on Amazon. In addition there are several active forums dedicated to the controller that we monitor to help guide our improvements.

Players have shared over 1.2 million game configurations since launch.

We announced in June that we had sold 500,000 controllers, and we’re now on track to sell a million by early next year.

We’ve been actively including the controller in Steam promotions, and have noticed similar response to what we see with software, including a persistent rise in baseline units after the sale.

This graph shows the full year of Steam Controller sales, with controllers sold as part of a software bundle in different colors. You can see that the visibility boost increases sales of the bundled controllers as well as standalone controllers.

We’re working on ways to improve discoverability of games that play well with the controller. Now that there is a significant installed base of controller users we are working on ways to promote games that they may be interested in. One of the more direct methods is to present customers with a ‘most popular with Steam Controller’ games list. Titles on this list will be easily discoverable for both new purchasers as well as existing customers. We will also continue to run focused sales that highlight hand-picked controller-friendly titles.

Since their launch, Controller and Link sales have been limited to the US, EU and Canada. We’re now expanding that to Eastern Europe, SE Asia, Latin America and Oceania. The first of these new territories are already online, and the rest will be there over the next few months.

Now I'd like to move on to the discussion of integrating the Steamworks Controller API into your title and what that means to you as a developer.

Here are a few reasons why using the Controller API means less code in your game, not more.

If you use the built-in Steamworks controller configuration UI, you don't have to build a bunch of controller-specific UI in your game.

This means that your players can fully configure their controller, and sometimes in ways you can't anticipate. We’re often surprised at the novel setups players come up with and I think you will be as well.
 

We’re adding support for all major controllers, so you can worry less about drivers and more about your game. We’ll even provide ready-to-use in-game hint glyphs.
 

Once you've done the integration, you can benefit from future Steam updates, whether they be software configuration options or new hardware support, all without having to update your game.
 

So hopefully today's session will be enough motivation for you to consider integrating the API into your game …
 

But if you can’t for some reason, I want to give you a few guidelines that will ensure customers can still have a positive experience with a controller.

First of all make sure that the game can handle simultaneous input from a gamepad and a mouse. Most preferred Steam Controller configurations use the gamepad for most functions but control the camera with the mouse. There are two things to look out for here.
 

First, make sure your engine supports character movement via the gamepad stick and camera movement from the mouse. Some games will lock out one form of input whenever the other is active.
 

Second, make sure your in-game hints are keyed off of the gamepad and keyboard, but not the mouse. This will prevent the on-screen hints from flickering back and forth between gamepad and keyboard hints.
 

Once your game is working well with the gamepad, make sure you have a good default configuration set on the Steam Partner website. This can be as simple as selecting one of the built-in templates, if they’re well matched for your title, or, you can create a custom configuration by hand and specify it by the Workshop File ID provided by Steam.

That’s it for my introduction, now I’d like to hand over the podium to Lars so he can talk about the API in detail.

 Thanks, Jeff.

Real quick, who am I and why should you care? Unlike Jeff, I don’t work for Valve. Like many of you, I’m an independent game developer, I co-founded Level Up Labs, we made a game called Defender’s Quest that did pretty well.
 

I also contribute regularly to Open Source projects, most notably the programming language Haxe, the multimedia library OpenFL, and the 2D game framework HaxeFlixel.

I also wrote some Gamasutra articles you might have read that one time.

We've been busy adding native Steam Controller support to Defender's Quest and we'll be shipping that real soon.

Speaking of Gamasutra articles, the inspiration for my part of the talk goes out to Zach Burke, who wrote The 5 Golden rules of Input. I don’t have time to cover it in depth except to list those five rules for creating a great PC gaming input experience, and here they are:

So with our destination firmly in mind, let’s survey various approaches people take to get there.

Hard coded physical inputs – IE, everybody’s input logic in their first game maker game.

This is when you directly check for specific inputs like WASD, ENTER, the “A” button on (specifically) an Xbox 360 Controller (specifically) in controller slot 1.
 

Not only can’t the player rebind the keys, the game only support the exact devices that are checked for, which in turn means you only have one set of input icons that assumes a specific device.This is very common to see with beginners, but I’ve actually seen it in some big commercial games, too.

So we’re good programmers, we know to abstract things. Instead of checking for a specific model of controller in a specific slot, you build a backend that hides all that complexity and tells if you if any connected gamepad of any model has the bottom face button (A for XBOX, X for Playstation, B for Nintendo, etc) pressed. While you’re at it, you