This section complements the [larger best-practices guidance for designing for Android TV](TODO, use formal name of referenced doc, and add link). It assumes that you have read that guidance, and seeks to minimize repetition.
Because of factors including its large size, its control scheme, and its nature as a shared display, the television screen presents a number of considerations that may be new to mobile developers. This document breaks these considerations down into five sections:
Large and centrally situated, the television screen imposes limitations, but also opens up new opportunities for immersive gameplay.
A living-room TV poses design challenges for multiplayer games, in that all players can see everything. This issue is especially germane to games (such as card games or strategy games) that rely on each player’s possession of hidden information.
Some mechanisms you can implement to address the problem of one player’s “eavesdropping” on another’s information are:
A television does not have a touch interface. Your game design, therefore, need not take into account the possibility that a player’s controlling fingers might block the on-screen action. You can assume constant visibility of the entire viewing area.
See the Control section in this document and in [Design for TV](TODO, use formal name of referenced doc, and add link) for more implications of the lack of touch interface.
In mobile-device terms, a TV is always “sideways.” You can’t turn it, and there is no portrait orientation. You should always be designing your TV games to be displayed in landscape mode.
Without a touch interface, it's even more important than usual to get your controls right, so that players find them intuitive and fun to use. The separation of controller from device also introduces some other issues to pay attention to, like keeping track of multiple players' controllers, and handling disconnects gracefully.
Because of the lack of touch interface, you should be planning your control scheme based on a D-pad. Some key points to keep in mind include:
The player needs to use the gamepad in all aspects of the game–not just controlling core gameplay, but also navigating menus and ads. For this reason, you should also ensure that your Android TV game does not refer to a touch interface: for example, an Android TV game cannot tell a player to "Tap to skip".
You can avoid unhappy surprises (and resulting low ratings) by using your Play Store description to communicate to the player any expectations about controllers. If a game is better suited to a gamepad with a joystick than one with only a D-pad, you should make this clear. A player who uses an ill-suited controller for a game is likely to have a subpar experience–and penalize your game in the ratings.
You can also help ensure a good player experience by ensuring that button mapping is intuitive and flexible. For example, you can adhere to accepted custom by using the A button to Accept, and the B button to Cancel. You can also offer flexibility in the form of remappability. For more information on button mapping, see Handling Controller Actions.
Your game can also contribute to a good match between controller and game by querying the controller about its capabilities. For example, you may intend for a player to steer an object by waving the controller in the air. If a player's controller lacks accelerometer and gyroscope hardware, however, waving will not work. But when your game queries the controller and discovers that motion detection is not supported, it can switch over to an alternative, available control scheme.
For more information on querying controller capabilities, see Supporting Controllers Across Android Versions.
The Back button should never act as a toggle. For example, do not use it to both open and close a menu. Its behavior should only be linear. For example: Game play > Game pause screen > Game main screen > Android home screen.
With this principle of "linear navigation" in mind, you may use the back button to leave an in-game menu (opened by a different button) and return to gameplay.
When multiple players are playing a game, each with his or her own controller, it is important to map each player-controller pair. For information on how to implement controller-number identification, see Input Devices) on the Android developer site.
When a controller is disconnected in the middle of gameplay, the game should pause, and a dialog should appear prompting the disconnected player to reconnect his or her controller.
The dialog should also offer troubleshooting tips (e.g., "Check your Bluetooth connection").
Games are displayed in a separate row from regular apps in the launcher. Android TV uses the android:isGame flag to differentiate games from non-game apps. You can assign it a value of either true or false. For example:
<application> . . . <meta-data android:name="isGame" android:value=["true" | "false"]/> android:isGame=["true" | "false"] > . . . </application>
If your game integrates Google Play Game Services, you should keep in mind a number of considerations pertaining to achievements, sign-on, saving games, and multiplayer play.
Your game should include at least five (earnable) achievements. Only a user controlling gameplay from a supported input device should be able to earn achievements.
Your game should attempt to sign the user in on launch. If the player declines sign-in several times in a row, your game should stop asking.
We highly recommend using Play Services cloud save to store your game save. Your game should bind game saves to a specific Google account, so as to be uniquely identifiable even across devices: Whether the player is using a handset or a TV, the game should be able to pull the same game-save information from his or her account.
You should also provide an option in your game's UI to prompt the player to destroy save data. You might put the option in the game's Settings screen.
A game offering a multiplayer experience must allow at least two players to enter a room.
Android TV games do not support a full web browser. You should therefore avoid using generic URLs in your game.
Webviews will work for logins to services like Google+ and Facebook.