You are here:

The Basics List

Below is a high-level list of commonly missed items when considering high quality controller support. Some topics may be covered more in depth in further sections.

Don’t run under 20fps. Applications running under 20fps feel especially sluggish when using a controller. While 60fps is the ideal, 30+fps is also acceptable.
Include testing using HDMI for the TV-connected device and, more importantly, to support the new class of “micro-console” devices. This is important to make sure your work translates to the big screen and still maintains excellent fps. Keep in mind your application may be dealing with two screen resolutions – the device resolution and the television resolution. For instance, your device may be 720p and TV 1080p. At 1080p, your application may suffer in fps from the increased resolution. Our recommendation is to render to 720p and let the hardware scalar handle the upscale.
Auto-Detect the Controller and use by default, if available. A static call to InputDevice.getDeviceIds() and then InputDevice.getDevice(int id) should be all you need to detect whether a controller is connected on application startup. While an application is already running, you can wait for the first event from a controller if this will work in your design, and ask from which device the event came. Detecting a controller in Unity will be discussed in a later section.
Bring up a controller map at least one time if your controls are complex.

NOTE: For the typical “action buttons” on a controller, the nomenclature that will be used is Y for the button at 12 o’clock, B for 3 o’clock, A for 6 o’clock, and X for 9 o’clock. For the button in the middle of a DPAD, think TV remote control, the nomenclature that will be used is OK. YBAX and OK are commonly printed on input controllers in those positions.

In the UI . . .

Have a visual indicator of focus (highlight, arrows, etc.). A developer should remember to make space for this indicator while designing the UI. Also, keep in mind all the UI elements when designing the indicator like sliders, radio buttons, tabs, etc.

Navigation Control
Positive/OK Answer	A or X button LS or RS pressed down OK button
Negative/Cancel Answer	Y or B button Left Middle button (e.g. BACK)
UI Focus Movement	LS movement DPAD movement
Tab/Page Movement	Left and Right Bumpers Left and Right Triggers
In-Application Pause/Options	Right Middle button (e.g. START) Left Middle button (e.g. BACK)
Go Back	Left Middle button (e.g. BACK)

Use classic standards for navigation on Android. Some of these standards take into account buttons that are optional in the Android specification.
Every function must be usable from menu items to sliders. This ensures the user isn’t confused by having to use two different input methods, also gives the complete experience to the micro-console user.
Have an exit menu item in the main menu. Having exit in the main menu, as opposed to only allowing BACK to exit your application, lets the user continue to use the same navigation keys they’ve used for every other menu item, giving the sense of consistency.
Have an exit menu item in the pause menus. Since most applications have the concept of pressing the “pause” button once to pause, and pressing it again to “unpause,” there needs to be a clear way to return to the main menu. When returning to the main menu is often a destructive operation, clarity is essential.
Use of the Left Middle button (e.g. BACK) while in game can take different forms. One form is described in the bullet point above, it is used as a pause/unpause button, especially when returning to the main menu is destructive. Another form is where the first press brings up the pause menu if necessary, and a subsequent press brings you back to the main menu where there is an option to continue. This is only useful on applications where returning to the main menu is non-destructive. Use the form that best suits your application.

Remove all on-screen touch controls/elements when the controller is the primary input, in order to de-clutter the screen.
Expect multiple controllers to be connected. A user may not be using the first enumerated controller. There are certain devices that have a built in controller; for example, consider NVIDIA’s SHIELD. Further, consider the SHIELD plugged into a television (“console mode”) with the user sitting at their couch with a wireless controller in hand. Or consider a “micro-console” with several controllers already hooked to the system. In each of these scenarios, it is likely the first enumerated controller will not be the controller being used. For Unity developers, special care needs to be taken to support multiple connected controllers; this is discussed more in a following section.
Avoid developing for specific controllers, don’t limit your compatibility. The controller specification supplied here is recommended by Google and NVIDIA. It covers the supported Google controllers, as well as the “Built for NVIDIA Tegra” controllers. This covers 90% of all controllers that most users are likely to have, from console controllers to all major third party manufacturers. Unless you have a very specific reason, there should be no need to filter or otherwise code to a specific controller; this cannot be stressed enough.
Support the micro-consoles properly. This means the user is connected through HDMI and has no touchscreen; therefore your application needs to support controllers everywhere, from full UI support to gameplay. Also see Include testing using HDMI above. If necessary, be sure to abide by the particular console’s requirements.
Support Android TV properly. Very closely related to the previous bullet point, Support the micro-consoles properly, there are specific needs to be properly listed on Android TV, as well as, specific user needs to be aware of. This will be discussed in a later section.
Test using the ART runtime. As of this writing, Google has given heavy indications that the Dalvik runtime will get replaced with the new, faster ART runtime. The Android TV, ADT-1 developer unit already defaults to ART. You can change runtimes in the Settings > Developer options menu. ART runtime changes are beyond the scope of this document and are somewhat in flux. See the following link for up to date information.
https://source.android.com/devices/tech/dalvik/art.html
Make sure you’ve covered everything; double-check by reading through the quick questionnaire in the FAQ section.