am 54c6e0aa: Merge "Final L-Preview Guidelines for Android TV Games Staged at http://boku.mtv.corp.google.com:9195/preview/tv/games/index.html" into klp-modular-dev
* commit '54c6e0aa1f27e5ecf3db64710563a305d78e9d39':
Final L-Preview Guidelines for Android TV Games Staged at http://boku.mtv.corp.google.com:9195/preview/tv/games/index.html
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
-<p>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.</p>
+<div id="qv-wrapper">
+<div id="qv">
+ <h2>In this document</h2>
+ <ol>
+ <li><a href="#display">Display</li></a></li>
+ <li><a href="#control">Input Devices</li></a></li>
+ <li><a href="#manifest">Manifest</li></a></li>
+ <li><a href="#gpgs">Google Play Game Services</li></a></li>
+ <li><a href="#web">Web</a></li>
+ </ol>
+</div>
+</div>
-<h2>Overview</h2>
-<p>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:</p>
+<p>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.</p>
+
+
+<h2 id=display>Display</h2>
+<p>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.</p>
+<h3>Shared display</h3>
+<p>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.</p>
+<p>Some mechanisms you can implement to address the problem of one player’s eavesdropping
+on another’s information are:</p>
<ul>
-<li>Display</li>
-<li>Control</li>
-<li>Manifest</li>
-<li>Google Play Game Services</li>
-<li>Web</li>
+<li>A blinder on the screen to help conceal information. For example, in a
+turn-based game like a word or card game, one player at a time might view the display. When the
+player finishes a move, the game allows him or her to cover the screen with a blinder that
+blocks anyone from viewing secret information. When the next player begins a turn, the blinder
+opens to reveal his or her own information.</li>
+<li>A companion app, running on a phone or tablet, can enable a player to conceal
+information.</li>
</ul>
-<h2>Display</h2>
-<p>Large and centrally situated, the television screen imposes limitations, but also opens up new opportunities for immersive gameplay.</p>
-<h3>A shared display</h3>
-<p>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.</p>
-<p>Some mechanisms you can implement to address the problem of one player’s “eavesdropping” on another’s information are:</p>
-<ul>
-<li>A player might place a "blinder" on the screen to help conceal information. For example, in a turn-based game like a word or card game, one player at a time might view the display. When the player finishes a move, the game allows him or her to cover the screen with a “blinder” that blocks anyone from viewing secret information. When the next player begins a turn, the blinder opens to reveal his or her own information.</li>
-<li>A second screen, such as a handset or larger device, can enable a player to conceal information. For information on implementing second-screen support, see <a href="http://developer.android.com/reference/android/app/Presentation.html">Presentation</a> on the Android developer site.</li>
-</ul>
-<h3>No touch interface</h3>
-<p>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.</p>
-<p>See the <a href=#control>Control</a> 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.</p>
<h3>Landscape display</h3>
-<p>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.</p>
-<a id=control><h2>Control</h2>
-<p>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.</p>
+<p>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.</p>
+
+<h2 id="control">Input Devices</h2>
+<p>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.</p>
<h3>D-pad</h3>
-<p>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:</p>
-<p>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".</p>
-<p>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.</p>
-<p>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 <code>Accept</code>, and the B button to <code>Cancel</code>. You can also offer flexibility in the form of remappability. For more information on button mapping, see <a href="http://developer.android.com/training/game-controllers/controller-input.html">Handling Controller Actions</a>.</p>
-<p>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.</p>
-<p>For more information on querying controller capabilities, see <a href="http://developer.android.com/training/game-controllers/compatibility.html">Supporting Controllers Across Android Versions</a>.</p>
+<p>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 <strong>Tap to skip</strong>.</p>
+<p>How you shape the player's interaction with the controller can be key to achieving a great user
+experience:
+ <ul>
+ <p><li><strong>Communicate Controller Requirements up Front</strong> - Use 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,
+make this fact 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.</p>
+ <p><li><strong>Use Consistent Button Mapping</strong> - Intuitive and flexible button mapping is key to a good user experience. For example,
+you can adhere to accepted custom by using the A button to <code>Accept</code>, and the B button to
+<code>Cancel</code>. You can also offer flexibility in the form of remappability. For more
+information on button mapping, see <a
+href="http://developer.android.com/training/game-controllers/controller-input.html">Handling
+Controller Actions</a>.</p>
+ <p><li><strong>Detect Controller Capabilities and Adjust Accordingly</strong> - Query the controller about its capabilities in order to optimize the match between
+controller and game. 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. When, however, 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 <a
+href="http://developer.android.com/training/game-controllers/compatibility.html">Supporting
+Controllers Across Android Versions</a>.</p>
+ </ul>
<h3>Back-button behavior</h3>
-<p>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.</p>
-<p>With this principle of "linear navigation" in mind, you <b>may</b> use the back button to leave an in-game menu (opened by a different button) and return to gameplay.</p>
+<p>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.</p>
+<p>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 <a
+href="http://developer.android.com/design/patterns/navigation.html">Navigation with Back and
+Up</a>. To learn about implementation, refer to <a
+href="http://developer.android.com/training/implementing-navigation/temporal.html">Providing Proper
+Back Navigation</a>. </p>
<h3>Handling multiple controllers</h3>
-<p>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 <a href="http://developer.android.com/reference/android/view/InputDevice.html#getControllerNumber(">Input Devices</a>) on the Android developer site.</p>
+<p>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 <a href="http://developer.android.com/reference/android/view/InputDevice.html
+#getControllerNumber(">Input Devices</a>) on the Android developer site.</p>
<h3>Handling disconnects</h3>
-<p>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.</p>
-<p>The dialog should also offer troubleshooting tips (e.g., "Check your Bluetooth connection").</p>
-<h2>Manifest</h2>
-<p>Games are displayed in a separate row from regular apps in the launcher. Android TV uses the <code>android:isGame</code> flag to differentiate games from non-game apps. You can assign it a value of either <code>true</code> or <code>false</code>. For example:</p>
+<p>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.</p>
+<p>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 <a
+href="http://developer.android.com/training/game-controllers/controller-input.html">Supporting Game
+Controllers"</a>. Specific information about Bluetooth connections is at <a
+href="http://developer.android.com/guide/topics/connectivity/bluetooth.html">Bluetooth</a>.</p>
+
+<h2 id="manifest">Manifest</h2>
+<p>Games are displayed in a separate row from regular apps in the launcher. Android TV uses the
+<code>android:isGame</code> flag to differentiate games from non-game apps. You can assign it a
+value of either <code>true</code> or <code>false</code>. For example:</p>
<pre class="fragment"><application>
- . . .
- <meta-data android:name="isGame" android:value=["true" | "false"]/>
-android:isGame=["true" | "false"] >
- . . .
-</application>
-</pre><h2>Google Play Game Services</h2>
-<p>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.</p>
+ ...
+< android:isGame=["true" | "false"] >
+ ...
+</application></pre>
+
+<h2 id="gpgs">Google Play Game Services</h2>
+<p>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.</p>
<h3>Achievements</h3>
-<p>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.</p>
-<h3>Sign-on</h3>
-<p>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.</p>
+<p>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 <a
+href="https://developers.google.com/games/services/android/achievements">Achievements in
+Android</a>.</p>
+<h3>Sign-in</h3>
+<p>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 <a
+href="https://developers.google.com/games/services/training/signin">Implementing Sign-in on
+Android</a>.</p>
<h3>Saving</h3>
-<p>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.</p>
-<p>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 <code>Settings</code> screen.</p>
+<p>We highly recommend using Play Services <a
+href="https://developers.google.com/games/services/common/concepts/cloudsave">Cloud Save</a> 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.</p>
+<p>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 <code>Settings</code> screen. For
+specifics on implementing Cloud Save, see <a
+href="https://developers.google.com/games/services/android/cloudsave">Cloud Save in Android</a>.</p>
<h3>Multiplayer experience</h3>
-<p>A game offering a multiplayer experience must allow at least two players to enter a room.</p>
-<h2>Web</h2>
-<p>Android TV games do not support a full web browser. You should therefore avoid using generic URLs in your game.</p>
-<p>Webviews will work for logins to services like Google+ and Facebook. </p>
+<p>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 <a
+href="https://developers.google.com/games/services/android/realtimeMultiplayer">Real-time
+Multiplayer</a> and <a href="">Turn-based Multiplayer</a> documentation on the Android developer
+site.</p>
+
+<h2 id="web">Web</h2>
+<p>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.</p>
+<p class="note"><strong>Note:</strong> You can use the {@link android.webkit.WebView} class for logins to services like Google+ and
+Facebook. </p>