153 lines
9.2 KiB
Plaintext
153 lines
9.2 KiB
Plaintext
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> 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>
|
||
...
|
||
< 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. 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>
|
||
|