2013年11月9日土曜日

動画番組 Things Every Android Game Developer Should Know の概要

ゲーム開発者の方々を対象に 2013 年 3 月 29 日に公開された動画番組 "Things Every Android Game Developer Should Know 2.0" にて、 Google+ Sign-in 機能、品質を高めていただく上での留意事項、および In-app Billing Version 3 についての解説が、Mountain View オフィスの Wolff Dobson, Dan Galpin, Bruno Oliveira によって提供されております。 この番組は 2012 年 6 月 29 日の Google I/O 2012 での Dan Galpin, Ian Ni-Lewis による講演 "Ten Things Game Developers Should Know" の続編です。

この番組が 2013 年 3 月に公開されたあと、 Google は Google Play Game Services を提供開始しました。 このため、一部の内容については最新の状況と若干異なっているのですが、大部分は 2013 年 11 月現在においても有効かつ重要な内容です。 そこで 以下に、この動画番組 "Things Every Android Game Developer Should Know 2.0" の内容と、2012 年の "Ten Things Game Developers Should Know" の内容の一部を 日本語でお伝えしたいと思います。

(ここ数年間の Android 端末のグラフィックス性能の向上に伴い、 Google Play における Android ゲーム作品の品質の向上、およびビジネスチャンスの拡大には目覚ましいものがあります。 日本においても、 Google 東京オフィスから「みんなのゲーム人気投票 どっちのゲームが好き？」キャンペーンも含め、さまざまな支援を行っております。 今後も Android プラットフォーム上で優れたゲーム作品を ご提供いただくために、この番組を お役立ていただけましたら幸いです。)



導入部 [再生時刻 00:05]

  • これまでゲーム開発者の人たちから、「Google Play 上で目立つためにはどうすればいいのか？」「悪いユーザーレビューを消したい」「レビューで星を 5 つ得るにはどうすればいいのか？」「Google Play に feature 掲載してほしい」「ユーザーの人にお金を払ってもらうにはどうすればいいのか？」といった お問い合わせをたくさんいただいています。 残念ながら ゲームを提供して成功することは、コマンドを一つ実行すれば達成できるほど簡単なことではありません。
  • これらのお問い合わせの中で時折、すべての中心的な存在として重要な「ユーザー」のことを忘れてしまいそうになります。 ユーザーは素晴らしい存在です。
  • そこで私たちは、最も重要な存在である ユーザーにフォーカスしたいと思います。 ユーザーを Happy にすることができ、より多くのユーザーにゲームを遊んでもらうことができれば、 Google Play においても成功する見込みが高いと言えます。
  • こういった背景から、新規ユーザーの獲得、優れた ユーザー体験の提供、および課金上の注意点について 今日はご紹介したいと思います。


Google を用いた Sign in 体験


Google+ とゲーム開発者の関係 [再生時刻 01:29]
  • ゲームにおいてユーザーを増やしていく方法の一つは、ソーシャル機能を追加することです。
  • 最近行われた あるユーザー調査では、多くのユーザーの人が Google によるサインイン (Sign-in) について (他のサインイン手法に比較して) 信頼してくださっていることが判りました。
  • 昨年 (2012 年)、Google は Google+ Sign-in という API を提供開始しました。 この機能を用いると、様々なプラットフォーム (アプリ、Web) において、ユーザーはGoogle+ のアイデンティティを用いて開発者が提供するサービスやアプリにサインインすることができるようになります。
  • Google+ は、(2013 年 3 月現在) 5 億人の人にご利用いただいており、 月間アクティブユーザー数は 1 億 3500 万人にのぼります。 約半数以上のユーザーが、モバイル端末から Google+ を利用しています。 ユーザー 1 人あたり平均で 1 日 12 分間、ストリームコンテンツをご覧いただいています。
  • 現在 Google は、数多くの Google サービスの Google+ との統合を通じて、より優れたユーザー体験を提供できるように努めています。 Google+ は、多くの Google サービスのユーザー体験を横断的に 良くしていくための背骨のようなものだと言うことができます。
  • 開発者から見ると Google+ は、
    • Android アプリのインストールを増やすための手段
    • 上手にターゲティングしながらのソーシャル共有を通じてユーザー層の成長を促す手段
    • ユーザーそれぞれにパーソナライズされた体験を提供し、ソーシャルグラフを通じたユーザーどうしの関係構築を助ける手段
    • ユーザーに信頼していただいている主体によるログイン認証を提供する手段
    として捉えることができます。

ゲームでの Google+ サインイン UI [再生時刻 03:10]
  • この機能をゲームで用いた時に どのように見えるか考えてみましょう。
  • ここで紹介するサンプルゲーム Nostalgic Racer において、 ゲームのタイトル画面に Google+ ログインのボタンが配置されています。 このボタンの表示は、あなたが提供している UI にあわせて行って頂くことができます。
  • このボタンをタップすると、 Google により提供されている承認ダイアログが表示されます。 ここには 2 つのものが含まれています。
  • 前半部分は、ユーザーの基本的なプロフィール情報やソーシャルグラフ情報に、アプリ (ゲーム) がアクセスしようとしていることについての説明です。 このダイアログでは、アプリが見ることができるソーシャルグラフはどの部分なのか (アプリに自分のソーシャルグラフの中の誰を見せるか) を、ゲームを遊んでいるユーザーは選ぶことができます。
  • 後半部分では、ユーザーがそのゲームを遊んでいることについて、ソーシャルグラフの中の誰に共有してもよいか (または共有しないか) をユーザーは選ぶことができます。
  • このダイアログの表示を編集・承認すると、ゲーム画面に戻ります。 この例では、私は Bruno Oliveira としてこのゲームにログインしている状態であることがわかります。
  • すでに Google+ アカウントをお持ちのユーザーの多くにとっては、これは とても簡単な操作となります。

インタラクティブな投稿の共有 [再生時刻 04:15]
  • ユーザーである Bruno がゲームをとても楽しんでいて、今 自分がうまくプレイしている このコースについて 誰かと共有したくなったとします。
  • Google+ のインタラクティブ投稿の機能を用いて、ユーザーは特定の友人に対してインタラクティブなメッセージを共有することができます。 この画面の例では、ゲームを遊んでいる Bruno が、友人の Todd に対し、「Todd は私より速くない」というメッセージとともに、そのゲームについての画像と「Challenge (挑戦) する」というボタンを同時に共有しています。
  • この機能は 2 つの点において重要です。 一つは、この機能はユーザー自身のソーシャルグラフの中で用いられる機能であるため、共有される相手 (そのゲームを遊んでいるユーザーの友人) は そのゲームに興味を持つ可能性が高いということです。
  • もう一つは、この共有は特定の人に宛てて行われているため、 端末の Notification 機能が活用されるということです。 このため、共有された相手 (Todd) は、 Bruno が自分に対して何かを仕掛けているということを実際に端末上で見る (知る) 可能性が高まります。
  • Google+ のストリーム上では この画面の例のように見えます。 Bruno のストリームを見ている人に対しても、「Challenge (挑戦) する」ボタンが見えるようになっています。
  • Bruno 以外のユーザーがこの「Challenge (挑戦) する」ボタンをクリックしたときには、 Web 上であれば そのゲームの Google Play アプリ詳細画面に遷移します。 一方、端末上でこのボタンがクリックされた場合には、ユーザーはそこから直接 ゲームの中の (Bruno が指定した) 特定のステージの画面に行くことができます。 端末上にゲームがまだインストールされていない場合には、Google Play 上のそのゲームのインストール画面に遷移します。
  • この機能を、ゲームのインストール数を高めていくためにご利用いただくことができます。
  • この他にも、Google+ API には、Over-the-Air install, Analytics, +1 ボタンによる共有、 Web 上での Hangout API といったさまざまな機能があります。 是非、これらの機能を活用する方法について http://developers.google.com/+ にてご確認ください。
  • [参照] Google Play Game Services — Google Developers
  • [参照] Google+ Platform — Google Developers


    • 品質上の注意点


    App Quality Guideline の紹介 [再生時刻 05:46]
    • 2012 年の Game Developers Conference の後、 Google は App Quality Guideline を公表しました。
    • Core App Quality Guideline には、 ゲーム作品が陥りがちな多くの注意事項が含まれています。
    • これまで数年にわたって Google は、 Android 標準のナビゲーション (Back ボタン対応) にゲームが適切に対応することを推奨しています。
    • Back ボタンに適切に対応しないことは、 Google Play 上でのネガティブなユーザーのレビューにもつながります。
    • ボリュームボタンについては、対応はプラットフォームに任せ、ユーザーが標準のボリューム操作 UI を使えるようにしてください。
    • Menu ボタンにも注意が必要です。 Google Play の QA チームは、何もしない Menu ボタンが画面に表示されてしまっていることを問題視します。 これを表示しないようにするには、アプリの targetSdkVersion の値を最新 (2013年3月現在は 17, 2013年11月現在は 19) の値にするようにしてください。
    • targetSdkVersion の値を最新のものにしていただくことで、プラットフォームの互換機能を使わずに済みます。 これはゲームのパフォーマンス (動作速度) の観点からも望ましいことです。
    • [参照] Core App Quality Guidelines - Android Developers
    • ユーザーに対して、不要な Notification 通知を送らないようにしてください。
    • Notification 通知を送る場合には、ユーザーが それをオン・オフしたり、どのような通知を表示する・しないを精密に設定できるようにしてください。 こうすることで、ユーザーから より良いレビューが得られるだけではなく、ユーザーが端末上の Notification 通知を完全にブロックする対策をとる可能性を減らすことができます。
    • [参照] Core App Quality Guidelines - Android Developers
    • 不要なパーミッションは利用しないでください。
    • ゲームにおいては、秘匿性の高いユーザー情報が 必要になることは ほとんどありません。
    • 昨年の Google I/O 2012 において、ゲーム開発者が避けるべきパーミッションについてご紹介しましたので こちらもあわせてご確認ください。
      • 10. Change Wifi Settings
      • 9. Receive Boot Completed
      • 8. Query Running Tasks
      • 7. Obtain Fine Location
      • 6. Read System Log
      • 5. Directly Call Phone Numbers
      • 4. Read/Write Contacts/Calendar
      • 3. Read/Write Bookmarks
      • 2. Display System Level Alerts
      • 1. Send/Receive SMS
    • この中でもとくに、SMS を送信・受信するパーミッションは避けるようにしてください。
    • これらのパーミッションを使ってしまうと、 Google Play 上での feature 掲載が難しくなります。
    • Audio (音声) についても、昨年お話いたしました。
    • ロックスクリーンにおいて音声が不用意に鳴ってしまうことは問題です。
    • [参照] Making Android Games that Play Nice | Android Developers Blog
    • 時間のかかる処理は (UIスレッドではなく) バックグラウンド・スレッドで実行してください。
    • StrictMode を用いながら開発してください。 StrictMode でアプリを実行したときに、画面が赤く点滅しないようにしてください。 Google Play に feature 掲載されるときの品質検査においてこれは実際に行われています。
    • [参照] New Gingerbread API: StrictMode. Dec 12, 2010. Android Developers Blog
    • [参照] StrictMode | Android Developers
    • ゲームのグラフィックスが、タブレットを含む画面サイズで問題ない品質になるようにしてください。 もし あなたのゲームが すべての Nexus 端末 (Galaxy Nexus, Nexus 4, Nexus 7, Nexus 10) において問題なく動作し、文字サイズやタッチ領域の大きさにおいても問題ない場合には、他のデバイスにおいても問題ない可能性が高いと言えます。
    • 私たちは、Nexus 端末の他にも、人気機種だが問題が多い機種を用いてテストすることもあります。 画面上の文字が小さ過ぎたり、タッチ領域が小さすぎたりするのは問題です。
    • Google Play での feature 掲載において用いられる Feature Graphic (1024x500 px の画像) を、見やすいようにデザインしてください。
    • 携帯電話の画面サイズにまで縮小されても見やすいように、 あまり細かい文字を Feature Graphic の中に描き込まないことをおすすめします。
    • [2013年11月注] この番組の配信の後、 Google Play の UI は新しいものになり、それまでに比べると Feature Graphic の露出の機会は減りました。 とはいえ引き続き Google Play Games アプリや、一部の Google Play feature 掲載時において Feature Graphic は引き続き必要である旨、ご理解いただけますようにお願いします。
    • Core App Quality Guideline の大部分は、そのまま検証チームに渡すことのできるテスト・ケース文書として提供されています。 是非ご活用ください。

    ゲームコントローラーへの対応 [再生時刻 09:23]
    • Android 3.0 (Honeycomb) において HID デバイスへの標準的なサポートが追加されたこともあり、 これまで多くのゲームがコントローラーへのサポートを拡大していることは喜ばしいことです。
    • サンプルゲームである Nostalgic Racer にも、ゲームコントローラーのサポートが含まれています。
    • ただし、ゲームのプレイ画面中でコントローラーがサポートされていても、メニュー画面においてはサポートされていないかもしれません。 それは残念なことです。
    • ゲーム中も、メニュー画面でも、コントローラーで操作できるようなゲームを是非開発してください。
    • ほとんどのコントローラーは、次の対応により動作させることができます。
      • 上移動 : DPAD UP
      • 下移動 : DPAD DOWN
      • 左移動 : DPAD LEFT
      • 右移動 : DPAD RIGHT
      • 決定 (Action) : DPAD CENTER, Aボタン
    • 「決定(Action)」を、 DPAD CENTER と A ボタンの両方に対応づけることを推奨している点にご注意ください。 ほとんどのゲームコントローラーでは、 DPAD の上下左右方向への対応は適切に行われています。 一方で、 X, Y, A, B という 4 つのボタンがある一般的なコントローラーにおいては、「X ボタン, Y ボタン」が DPAD CENTER に、「A ボタン, B ボタン」が BACK BUTTON に対応づけられています。 とくに A ボタンについては (BACK ではなく) 肯定的な動作を期待するユーザーが多いため、 A ボタンはデフォルトのままの挙動ではなく、決定 (Action) の肯定的な動作を対応づけることをおすすめします。
    • 他に、一部のコントロラーには以下のボタンも装備されていますが、これらは常に存在するとは限らない点にご注意ください。
      • Start : メニュー画面では、ゲーム開始。ゲーム中は、ゲーム中断
      • Select/Menu : 追加オプション (メニュー)
      • Back : Android 本体の Back ボタンと同じ
      • B : メニュー画面では Back。 ゲーム中は任意
      • A : メニュー画面では決定。 ゲーム中は任意
      • X, Y, Thumb L, Thumb R, Button TL, Button TR : 任意
    • アナログスティックに対応する時は、同時に DPAD イベントにも適切に対応してください。
    • 下記は、一般的なアナログ入力の軸です。
      • X, Y 軸 : 左スティック
      • Z, RZ 軸 : 右スティック
      • Throttle : 背面右トリガー
      • Brake : 背面左トリガー


    In-app Billing


    In-app Billing Version 3 [再生時刻 11:24]
    • In-app Billing API は、重要な API です。
    • 以前のバージョンの API は、利用方法が複雑なため、苦手意識を感じる人も多くいました。 IN_APP_NOTIFY 通知による状態の管理が必要でした。 アプリが sleep 状態のときにも通知を受け取れるように、 BroadcastReceiver を実装する必要がありました。 そしてその処理をバックグラウンドで行うために、 Service を走らせる必要がありました。 また、端末ローカルにデータベースを構築することも必要でした。 これらの処理は、難読化する必要もありました。
    • 複雑さの一つの要因は、 BroadcastReceiver の処理 (Google Play から通知をうけとる処理) を堅牢に構築することがシンプルではなかったためだったと言うことができます。
    • V2 は非同期型の API であり、アプリ内の多くのコンポーネントが協調しながら動作する必要があります。 非同期型であることが、複雑になりやすい要因の一つでした。
    • In-app Billing Version 3 API は、同期型の API であり、アプリは結果を同期的に (呼び出した後すぐに) 得ることができます。 このことにより V2 に比較して、よりコードの記述がシンプルになります。
    • V2 では、トランザクションのリストア (RESTORE_TRANSACTIONS) は高価な (重い) 処理でした。 このため、リストア処理は頻繁にではなく、注意深く行う必要がありました。
    • V3 では、Google Play はクライアント側のキャッシュを維持します。 このため、リストア処理は 以前に比べると非常に高速で軽いものになっています。 リストア処理は、何度でも行うことができ、回数に制限はありません。
    • In-app Billing Version 3 は、 Android 2.2 およびそれ以降のすべての端末においてサポートされています。 これは、現在使われている Android 端末の大部分です。
    • V3 がサポートされているかどうかをコード内で確認するには、 IInAppBillingService.isBillingSupported() を呼び出します。
    • ユーザーがどのアイテムを「所有」しているかをアプリ内で確認するには、 IInAppBillingService.getPurchases() を呼び出してください。
    • この呼び出しは、クライアント側のキャッシュを利用するため、とても高速であり、結果は同期的に (すぐに) 得ることができます。
    • ユーザーがお金を払ったあと、ゲームがアイテムを付与する処理に失敗しないように 十分に注意する必要があります。
    • これが発生すると、ユーザーの苦情、ネガティブなレビュー評価につながります。
    • そういった状況を避けるためにも、V3 においては "unamanged item" の考え方は廃止され、すべてのアイテムが "managed item" となっています。
    • 購入フローを開始するには、IInAppBillingService.getBuyIntent() を呼び出したあと、 startIntentSenderForResult() を呼び出してください。
    • 購入の結果は、アプリの Activity.onActivityResult() に返ってきます。
    • この段階で、アプリは結果を RESPONSE_CODE, INAPP_PURCHASE_DATA, INAPP_SIGNATURE という 3 つのデータにより得ることができます。
    • 最も簡単なシナリオにおいては、上記で処理は完了です。 アプリが開始するときには getPurchases() でユーザーが所有しているアイテムを確認。 購入フローを開始するときには、 getBuyItent() で Intent を取得し、それを実行。 onActivityResult にて、結果を処理する、ということになります。

    consumePurchase の使い方 [再生時刻 17:40]
    • V3 では新しく、"consumption" (消費) という概念が導入されています。 ユーザーがアイテムを購入した直後は、ユーザーはそのアイテムを所有していますが、 "consume" 処理を行うと、ユーザーはそのアイテムを所有していない状態に戻ります。
    • コード上では、 IInAppBillingService.consumePurchase() を呼び出すことでこれを行うことができます。 アイテムが購入されたときの purchaseToken をここに渡すことで、この API を呼び出すことができます。
    • consumePurchase を呼び出すべきタイミングには、大きく分けて 2 通りのシナリオがあります。
    • 一つは、実際にユーザーがアイテムを「使った」ときに呼び出す方法。
    • もう一つは、ユーザーがアイテムを買った直後にすぐに呼び出す方法です。
    • 前者の方法では、同じアイテムをユーザーは複数回買うことはできません。後者の方法を用いることで、ユーザーは同じアイテムを何度でも買うことができます。
    • 後者の方法を用いる時は、アプリの起動時 (再起動時) に必ず getPurchases() によりユーザーが所有するアイテムを確認し、それに対しすぐに consumePurchase() を呼び出すように注意してください。 ユーザーの購入直後にアプリがクラッシュした場合には、次の起動時が consumePurchase() を呼び出す適切なタイミングになります。
    • まとめると、アプリ起動時(再起動時) には getPurchases() を呼び出してユーザーの所有アイテムを確認。 必要に応じてこのタイミングで consumePurchase() 処理も行ってください。
    • ユーザーが購入遷移にすすむときには、 getBuyIntent() を呼び出して Intent を取得し、それを実行。
    • onActivityResult() に購入の結果が返ってくるので、その結果を処理。 購入に成功していたら、すぐに consumePurchase() を呼び出し。
    • consumePurchase() 処理が成功したときには、必ずユーザーに購入されたアイテムが付与されるようにデータを更新。

    In-app Billing のセキュリティ上の注意点 [再生時刻 21:45]
    • 残念ながらインターネットには、あなたの有料アイテムを無料で入手しようとしている人たちが存在しています。
    • ここでは彼らを海賊 (Pirates) と呼ぶことにします。
    • 購入処理が実行されるたびに、あなた (開発者) は その購入が正当なものかどうかをチェックする必要があります。
    • 海賊はもちろん、あなたを騙してそれが正当だと思わせようとします。 あなた (開発者) は、その嘘を見抜く必要があります。
    • 海賊を 100% ストップする方法は残念ながらありませんが、彼らの攻撃を非常に困難にすることはできます。
    • あなた (開発者) が活用できる防御手段は、 developerPayload, Signature verification, Server-side validation の 3 種類です。
    • developerPayload を用いることで、すべての購入に、開発者は何らかのユニークな名前をつけることができます。 その情報の中に正当な購入者の情報を含めておき、それを後で再度チェックすることで、 Replay attack と呼ばれる攻撃を防ぐことができます。
    • Signature をチェックすることも重要です。 Google Play が あなたのアプリに購入情報を送信する際には、それは private key を用いて署名されています。 あなたの手元にある public key を用いてそれをチェックすることで、偽造された購入情報を防ぐことができます。
    • クライアント側の処理のみでは防御は十分とはいえません。 というのは、端末そのものが hack されてしまったり、端末に搭載されている Java API が改変されている危険性もあるためです。
    • このため、購入処理の中で、署名の確認、注文番号 (Order Number) の確認の処理はサーバー側で行うことを強くおすすめします。 これらのクライアント - サーバー間の通信処理は、安全な方法によって行うようにしてください。
    • これを整理すると、Signature verification, developerPayload, Server-side verification を組み合わせていただくことで、 MITM (Man-in-the-middle; 中間者) 攻撃、 Reply 攻撃、 プラットフォーム/フレームワーク改変のいずれの攻撃からも あなたのアプリを防御していただくことができます。
    • 難読化も忘れてはいけません。
    • 実際には、これらの手法をどのように組み合わせるかについては、アプリ／ゲーム作品ごとに適切な対応が異なります。 上記の手法を参考に、あなたのアプリを適切に防御してください。
    • [参照] Security and Design - In-app Billing - Android Developers
    • もう一つお知らせがあります。 In-app Billing Version 3 においては、アイテムの価格情報を (各ユーザーの地域・国にあわせて) 自動的に取得する API が追加されました。 IInAppBillingService.getSkuDetails() メソッドを用いて、ユーザーに合わせた適切な価格表示を行っていただけますようにお願いいたします。


    Google I/O 2012 講演 "Ten Things Game Developers Should Know" の抜粋


    2012 年 6 月 29 日、Google I/O 2012 での講演 "Ten Things Game Developers Should Know" において、 Dan Galpin と Ian Ni-Lewis は ゲーム開発の上での主な注意事項を紹介しています。 このうち、"Things Every Android Game Developer Should Know" 番組では詳しく触れられていない Back ボタンの扱い、および GPU 対応テストの話題について、下記に抜粋してお伝えいたします。

    3. Back ボタン対応について [再生時刻 09:42]
    • Android 端末には、 Back ボタン、 Home ボタン、 Recent Apps ボタン、 Lock ボタン、 Volume ボタン、が装備されています。
    • これらのボタンはほとんどのゲームにおいて、プラットフォームに処理を任せるほうがベターです。 たとえば Volume ボタンの入力は、アプリが自分で処理するのではなく、ユーザーがプラットフォーム標準のボリューム制御 UI を使えるようにすることが推奨されています。
    • Back ボタンの対応は、場合によっては複雑です。 というのは、ゲームでは、実際には Activity は 1 つだけしか利用していない場合が多いためです。
    • ここでは、サンプルゲームを用いて、 Back ボタン対応について考えてみましょう。
    • これは、シンプルなアーケードゲームの例です。
    • ゲームを開始し、メニューでステージを選択し、ゲーム画面でゲームを楽しんでいます。
    • この画面で Back ボタンを押したとします。
    • この例では、ステージ選択メニューに戻っています。 これは問題ありません。 ステージを途中まで進めた状態を保存すべきかそうでないかは、ゲーム内容によります。 Back ボタンにより、1 つ前の画面に戻るのは Android ユーザーの期待にも沿っています。
    • もうひとつの方法は、「中断メニュー」をダイアログ形式で表示することです。 これは、Android のナビゲーション方式とは完全に一致する方法ではないので「ベスト」プラクティスとは呼べませんが、十分にポピュラーな対応方法であり、これに反対する理由はありません。
    • ダイアログ形式のこの中断メニューが表示されているときに Back ボタンが押されたら、何が起きるべきでしょうか。
    • ステージ選択メニューに戻るべきでしょうか？ それとも、ゲーム画面に戻るべきでしょうか？
    • 一般には、この画面は明らかに「ダイアログ」に見えるので、ダイアログのように振る舞うことが期待されます。 この場合は、おそらくダイアログが閉じられてゲーム画面に戻る、というのが期待される挙動でしょう。
    • この例から、ユーザーをできるだけ邪魔しない UI が望ましい、という原則を想起していただけましたら、と思います。
    • また、ダイアログを表示するのではなく、 (Back ボタンが押されたら) メニュー画面に戻り、そのメニュー画面から そのステージを再開 (中断した場面からの再開) できるようにするという方法もあります。 この方法は、Back ボタンに対して ダイアログを表示する方法に比較して、より Android 標準の画面ナビゲーション手法に沿っている点が優れています。
    • 最も良いのは、ユーザーは前の画面に Back ボタンでいつでも戻ることができ、同時に ゲームの進行を失わずに もともといた画面で続きを遊ぶことができる、という挙動です。
    • Back ボタンに対して、「ゲームを終了しますか？(Yes/No)」というダイアログを表示することはユーザー体験として良くありません。
    • ゲームの進行を失わないでユーザーに続きを楽しんでもらう方法は他にもたくさんあります。 このような「Yes/No」ダイアログは表示しないでください。
    • Back ボタン対応についてのまとめです。
    • ダイアログが表示されているときは、ダイアログを閉じてください。
    • メニュー表示 UI では、前の画面に戻ってください。
    • ゲーム中では、
      • 中断（ポーズ）、または
      • 下記のいずれか:
        • オプション選択ダイアログを表示
        • 前の画面に戻る
    • ゲームのタイトル画面の場合は、単にアプリを終了してください。 Y/N を聞く必要はありません
    • ユーザーが進行を失わないようにしてください。

    9. GPU 対応のテストについて [再生時刻 46:00]
    • テストについて少しお話したいと思います。
    • 現在 数多くの Android 端末が存在しており、テストの軸ごとに難易度が異なります。
    • 入力デバイスの軸、画面サイズの軸、OSバージョンの軸に対してテストを行うことは、実はそれほど難しくありません。
    • 一方、3D ゲームにおいて、グラフィックドライバー、GPU ハードウェアの軸に対してテストを行うことはシンプルではありません。 時折、ドライバーにはバグがあり、 GPU ハードウェアはそれぞれに特性が異なるためです。
    • 現在 Android 端末で用いられている主要な GPU には下記のものがあります:
      • Adreno
      • PowerVR
      • Tegra
      • Mali
      • Vivante
      • Broadcom
    • このうち、上の 4 種類 (Adreno, PowerVR, Tegra, Mali) は特に重要です。
    • 中でも、PowerVR の挙動は他の GPU と大きく異なります。 PowerVR では、material による sort により高速化が行えますが、 geometry, complexity による sort はほとんど効果がありません。 一方で、PowerVR 以外の GPU (Adreno, Tegra, Mali, ...) においては、 geometry, complexity による sort により大幅なチューニングが可能です。
    • また、テキスチャ圧縮フォーマットにもいくつかの種類があることに留意してください。 透過型ではないテキスチャについては、ETC1 を使うことができます。 透過型のテキスチャを用いるときは、何らかのメーカー固有のフォーマットを用いるか、または shader を記述する必要があります。
    • Google Play では、同じアプリの中で、利用されているテキスチャ圧縮フォーマットごとに、別々のバーションの APK (および別々の拡張ファイル) を提供していただくことができます。
    • 上記の留意事項は、3D ゲームにおいて特に重要です。 2D ゲームにおいては、これらは問題にならないかもしれません。
    投稿者 時刻:

    0 件のコメント:

    コメントを投稿

    登録: コメントの投稿 (Atom)