diff options
| -rw-r--r-- | docs/html/preview/tv/games/index.jd | 186 | ||||
| -rw-r--r-- | docs/html/training/training_toc.cs | 6 | ||||
| -rw-r--r-- | docs/html/training/tv/games/index.jd | 282 |
3 files changed, 288 insertions, 186 deletions
diff --git a/docs/html/preview/tv/games/index.jd b/docs/html/preview/tv/games/index.jd deleted file mode 100644 index 68d2d8bb5096..000000000000 --- a/docs/html/preview/tv/games/index.jd +++ /dev/null @@ -1,186 +0,0 @@ -ikpage.title=Games on TV -page.tags="controller" - -@jd:body - -<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> - -<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>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> -<h3>Landscape display</h3> -<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>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. 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> -<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 (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> attribute to differentiate games from non-game apps. Set this value - to <code>true</code> in your game's app manifest, as shown in the following code example: -</p> - -<pre class="fragment"> -<application> - ... - < meta-data android:name="isGame" android:value="true" > - ... -</application> -</pre> - - -<h3 id="gamepad">Game Controllers</h3> - -<p> - Games controllers may not be available or active for users of a TV device. In order to properly - inform users that your game requires (or just supports) a game controller, you must include - entries in the app manifest. If your game requires a game controller, you must include the - following entry in your app manifest: -</p> - -<pre> - <uses-feature android:name="android.hardware.gamepad"/> -</pre> - -<p> - If your game uses, but does not require, a game controller, include the following feature - entry in your app manifest: -</p> - -<pre> - <uses-feature android:name="android.hardware.gamepad" android:required="false"/> -</pre> - -<p>For more information about manifest entries, see - <a href="{@docRoot}guide/topics/manifest/manifest-intro.html">App Manifest</a>. -</p> - - -<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. 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 <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. 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> - diff --git a/docs/html/training/training_toc.cs b/docs/html/training/training_toc.cs index 44e31d73314c..12685ba39143 100644 --- a/docs/html/training/training_toc.cs +++ b/docs/html/training/training_toc.cs @@ -913,6 +913,12 @@ include the action bar on devices running Android 2.1 or higher." </ul> </li> + <li> + <a href="<?cs var:toroot ?>training/tv/games/index.html" + description="How to build games for TV."> + Building TV Games</a> + </li> + </ul> </li> <!-- End: Building for TV --> diff --git a/docs/html/training/tv/games/index.jd b/docs/html/training/tv/games/index.jd new file mode 100644 index 000000000000..29b055beec31 --- /dev/null +++ b/docs/html/training/tv/games/index.jd @@ -0,0 +1,282 @@ +page.title=Building TV Games +page.tags="controller" +page.article=true + +@jd:body + +<div id="qv-wrapper"> +<div id="qv"> + <h2>In this document</h2> + <ol> + <li><a href="#display">Display</a></li> + <li><a href="#control">Input Devices</a></li> + <li><a href="#manifest">Manifest</a></li> + <li><a href="#gpgs">Google Play Game Services</a></li> + <li><a href="#web">Web</a></li> + </ol> +</div> +</div> + +<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 id="shared-display">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>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 by + serving as a second screen. + </li> +</ul> + + +<h3 id="landscape-display">Landscape display</h3> + +<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 id="d-pad">D-pad</h3> + +<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 should not tell a player to <strong>Tap here to skip</strong>. +</p> + +<p> + How you shape the player's interaction with the controller can be key to achieving a great user + experience: +</p> + +<ul> + <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. + </li> + <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>. + </li> + <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>. + </li> +</ul> + + +<h3 id="back-button">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. 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 id="multiple-controllers">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>. +</p> + + +<h3 id="handle-disconnect">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 (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">Handling Controller + Actions</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> + The Android TV launcher home screen displays games in a separate row from regular apps. The TV + framework uses the <code>android:isGame</code> manifest attribute to differentiate games from + non-game apps. Set this value to <code>true</code> in your game's app manifest, as shown in the + following code example: +</p> + +<pre class="fragment"> +<application> + ... + < meta-data android:name="isGame" android:value="true" > + ... +</application> +</pre> + + +<h3 id="gamepad">Game Controllers</h3> + +<p> + Games controllers may not be available or active for users of a TV device. In order to properly + inform users that your game requires (or just supports) a game controller, you must include + entries in the app manifest. If your game requires a game controller, you must include the + following entry in your app manifest: +</p> + +<pre> + <uses-feature android:name="android.hardware.gamepad"/> +</pre> + +<p> + If your game uses, but does not require, a game controller, include the following feature + entry in your app manifest: +</p> + +<pre> + <uses-feature android:name="android.hardware.gamepad" android:required="false"/> +</pre> + +<p>For more information about manifest entries, see + <a href="{@docRoot}guide/topics/manifest/manifest-intro.html">App Manifest</a>. +</p> + + +<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-in, saving games, and multiplayer play. +</p> + + +<h3 id="achievements">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. 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 id="sign-in">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 id="saving">Saving</h3> + +<p> + We highly recommend using Play Services <a href= + "https://developers.google.com/games/services/common/concepts/savedgames">Saved Games</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 game-save information from the same user 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 saved games using Play Services, see <a href= + "https://developers.google.com/games/services/android/savedgames">Saved Games in Android</a>. +</p> + + +<h3 id="multiplayer-ux">Multiplayer experience</h3> + +<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 enabling 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> |