From 2928a3e5c411ecd8582f913ce1944874941bee62 Mon Sep 17 00:00:00 2001 From: David Friedman Date: Tue, 24 Jun 2014 18:37:09 -0700 Subject: Final L-Preview Guidelines for Android TV Games Staged at http://boku.mtv.corp.google.com:9195/preview/tv/games/index.html Change-Id: I87a5394a74ca62ed84ad7ad7596a1d75b77c39f2 --- docs/html/preview/tv/games/index.jd | 188 ++++++++++++++++++++++++++---------- 1 file changed, 135 insertions(+), 53 deletions(-) diff --git a/docs/html/preview/tv/games/index.jd b/docs/html/preview/tv/games/index.jd index b9de3a4..763eada 100644 --- a/docs/html/preview/tv/games/index.jd +++ b/docs/html/preview/tv/games/index.jd @@ -1,70 +1,152 @@ -page.title=Games on TV +ikpage.title=Games on TV page.tags="controller" @jd:body -

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.

+
+
+

In this document

+
    +
  1. Display
    2. +
  2. Input Devices
    3. +
  3. Manifest
    4. +
  4. Google Play Game Services
    5. +
  5. Web
    6. +
+
+
-

Overview

-

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:

- -

Display

-

Large and centrally situated, the television screen imposes limitations, but also opens up new opportunities for immersive gameplay.

-

A shared display

-

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:

+

The television screen presents a number of considerations that may be new to mobile-game +developers. These areas include its large size, its control scheme, and the fact that all +players are viewing it simultaneously.

+ + +

Display

+

The two main things to keep in mind when developing games for the TV screen are its nature as a +shared display and the need to design your game for a landscape orientation.

+

Shared display

+

A living-room TV poses design challenges for multiplayer games, in that all players can see +everything. This issue is especially relevant 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:

-

No touch interface

-

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.

Landscape display

-

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.

-

Control

-

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.

+

A TV is always sideways: You can’t turn it, and there is no +portrait orientation. Always design your TV games to be displayed in landscape +mode.

+ +

Input Devices

+

TVs don't have touch interfaces, so it's even more important to get your controls right and make + sure 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.

D-pad

-

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.

+

Plan your control scheme around a directional pad (D-pad) control, since this control set is the +default for Android TV devices. The player needs to be able to use a D-Pad 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.

+

How you shape the player's interaction with the controller can be key to achieving a great user +experience: +

Back-button behavior

-

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.

+

The Back button should never act as a toggle. For example, do not use it to both open and close +a menu. It should only navigate backward, breadcrumb-style, through the previous screens the player has +been on. For example: Game play > Game pause screen > Game +main screen > Android home screen.

+

Since the Back button should only perform linear (backward) navigation, you may use the +back button to leave an in-game menu (opened by a different button) and return to gameplay. For +more information about design for navigation, see Navigation with Back and +Up. To learn about implementation, refer to Providing Proper +Back Navigation.

Handling multiple controllers

-

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 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.

Handling disconnects

-

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").

-

Manifest

-

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:

+

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 (for example, a pop-up dialog telling the player to +"Check your Bluetooth connection"). For more information on implementing input-device support, see Supporting Game +Controllers". Specific information about Bluetooth connections is at Bluetooth.

+ +

Manifest

+

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>
-

Google Play Game Services

-

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.

+ ... +< android:isGame=["true" | "false"] > + ... +</application> + +

Google Play Game Services

+

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.

Achievements

-

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.

-

Sign-on

-

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.

+

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. For more information on +Achievements and how to implement them, see Achievements in +Android.

+

Sign-in

+

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. Learn more about sign-in at Implementing Sign-in on +Android.

Saving

-

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.

+

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 allow the player to delete locally and +cloud-stored data. You might put the option in the game's Settings screen. For +specifics on implementing Cloud Save, see Cloud Save in Android.

Multiplayer experience

-

A game offering a multiplayer experience must allow at least two players to enter a room.

-

Web

-

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.

+

A game offering a multiplayer experience must allow at least two players to enter a room. For +further information on multiplayer games in Android, see the Real-time +Multiplayer and Turn-based Multiplayer documentation on the Android developer +site.

+ +

Web

+

We discourage including web browsing in games for Android TV. The television set is not well-suited for browsing,, either in terms of display or control scheme.

+

Note: You can use the {@link android.webkit.WebView} class for logins to services like Google+ and +Facebook.

-- cgit v1.1