amp.dev には、AMP のあらゆる利用方法に関する情報を掲載しています。ウェブサイト、ストーリー、広告、メールについては、色分けして整理しています。全体的なドキュメントのセクションも、できるだけシンプルにナビゲーションできるように設計されました。ガイドやチュートリアルは、AMP デベロッパー ワークフローのステージごとに分割されています。そのため、プロセスの各段階で AMP サイトの構築を成功につなげるために必要なリソースと安心感が得られるようになっています。


ウェブサイト、ストーリー、広告、メールを網羅するドキュメント
ampbyexample.com の既存リソースと ampstart.com のテンプレートは、すべて移行されて amp.dev の各セクションに組み込まれています。さらに、AMP で作成できるさまざまな可能性をギャラリー形式で参照できるユースケースなど、新しいセクションも追加しています。現在、このセクションにはまだ数項目しかありませんが、今後数か月間で拡大してゆく予定です。


amp.dev のユースケース セクション
新しいサイトへのスムーズな移行を実現するため、しばらくの間、AMPproject.org はそのままの状態にします。しかし、近いうちにリダイレクトを設定して AMPproject.org をクローズする予定です。現在は、各サイトに今後の変更についてお知らせするバナーを追加しています。このブログ(今皆さんが読んでいるもの)は、既に blog.amp.dev に移行されています。


最後になりますが、AMP Project はコミュニティによる作業なので、このサイトをできる限り最高のものにするためのフィードバックの共有をお待ちしています。皆さんの感じたことや、修正する必要がある問題を把握できるように、すべてのページの下に、フィードバック フォームにリンクしたバナーを作成しています。今までと同じく、amp.dev は GitHub の AMP Project ドキュメント リポジトリでメンテナンスされているので、すべての中身を確認することができます。GitHub の Issue もそこから送ることができます。


何か月もの間、この件に協力してくださった Jung von Matt TECH の皆さん、本当にどうもありがとうございました。今後も AMP Project とともに、amp.dev のさらなる進化に取り組んでいきます。

投稿者: amp.dev コア メンテナンス担当、Paul Bakaus、Sebastian Benz、Crystal Lambert、Matt Ludwig



Reviewed by Yusuke Utsunomiya - Mobile Solution Consultant, gTech



来る 6 月 29 日(土)開催の Google Play Indie Games Festival 2019 ファイナルイベントにて、会場を盛り上げる MC に、よしもとクリエイティブ・エージェンシーのカジサックさん、タケトさんのお二人が決定しました。

ファイナルイベント参加登録はお早めに :


本イベントでは、選出された トップ 20 タイトルが展示され、その場で体験いただけます。一般参加者イベント参加登録ページよりご登録ください。



今年注目のインディーゲームに輝くタイトルはどれか、皆さんもぜひ会場で応援ください!

トップ 20 作品へのオンライン投票受付中:


6 月 24 日 17 時まで、トップ 20 作品の中から一人一票投票できるオンライン投票を実施しています。オンライン投票で選出された 1 タイトルは「オンライン投票最優秀賞」としてファイナルイベントにて賞が授与されます。今年の注目タイトルはあなたの一票で決まるかもしれません。お気に入りの作品を見つけてみてください。



Posted by Tomoko Tanaka - Developer Product Marketing Manager, Google Play

Christiaan Prins                               Max Gubin
プロダクト マネージャー             ソフトウェア エンジニア

本日は、ML Kit に 2 つの新機能がリリースされたことをお知らせします。それは、言語識別スマート リプライです。

この 2 つの機能は、イメージや動画の処理に特化していた既存の API とは違うことに気づいた方もいらっしゃるでしょう。ML Kit が目指しているのは、分野を問わず ML を活用してもらえるように、強力で使いやすい API を提供することです。そのため、自然言語処理(NLP)用のソリューションで ML Kit を拡張できたことをうれしく思っています。
NLP は、文字や音声などの自然言語データの分析や生成を扱う ML の一分野です。今回、すばらしいことに、テキストの言語を識別する API と、チャットアプリで応答候補を提案する API の提供を開始できました。どちらの機能も、ML Kit SDK の最新バージョンがあれば完全に端末上だけで動作します。対応しているのは、iOS(9.0 以降)および Android(4.1 以降)です。


以前のメッセージの内容を元に応答を提案する
メッセージング アプリに登場している新機能に、通知アクションやアプリ内部でいくつかの応答候補をユーザーに提案するというものがあります。この機能は、忙しいときにすばやく応答したい場合や、長いメッセージを書き始める場合に極めて便利です。
新しい Smart Reply API を使うと、皆さんのアプリでも短時間で同じことを実現できます。この API は、会話内の直近 10 個のメッセージに基づいて提案を行いますが、以前のメッセージが 1 個しかなくても動作します。これは完全に端末上だけで動作するステートレスな API なので、メモリにメッセージの履歴を保持することも、サーバーにメッセージを送信することもありません。

textPlus アプリは、スマート リプライを使って応答候補の提案を行っている。
私たちは、スマート リプライが十分実用に耐えられるように、textPlus などのパートナーと密に連携してきました。そして現在、最新バージョンの textPlus アプリには、アプリ内で応答候補を提案する機能が実装されています(上のスクリーンショット)。
皆さんのアプリにも、簡単な関数を呼び出すだけでスマート リプライを追加することができます(この例では Kotlin を使っています)。
val smartReply = FirebaseNaturalLanguage.getInstance().smartReply
smartReply.suggestReplies(conversation)
        .addOnSuccessListener { result ->
            if (result.status == SmartReplySuggestionResult.STATUS_NOT_SUPPORTED_LANGUAGE) {
                // The conversation's language isn't supported, so the
                // the result doesn't contain any suggestions.
            } else if (result.status == SmartReplySuggestionResult.STATUS_SUCCESS) {
                // Task completed successfully
                // ...
            }
        }
        .addOnFailureListener {
            // Task failed with an exception
            // ...
        }
スマート リプライのインスタンスを初期化し、直近のメッセージのリストを suggestReplies に渡すと、コールバックで提案のリストを含む result を受け取ることができます。
Smart Reply API の詳しい使い方については、ドキュメントをご覧ください。
さらに詳しく...
デベロッパーとしてこの新しい API をアプリに組み込むのは簡単ですが、内部で何が行われているのかについて知りたい方もいるでしょう。スマート リプライの中枢部分には、TensorFlow Lite で実行される機械学習モデルと、SentencePiece テキスト エンコーディング [1] および Transformer [2] に基づく最新アーキテクチャが存在します。
しかし、API の開発を始めたときに気づいたのですが、デベロッパーがアプリで使えるソリューションを提供するために必要なのは、中核となる提案モデルだけではありませんでした。たとえば、悪口に応答する場合や個人的な不幸や困難が起きている場合は提案を避けられるように、問題となる可能性があるトピックを検知するモデルを追加しました。また、中核となるモデルのトレーニングが行われていない言語に対して提案を行うことがないように、言語識別の機能も含めました。スマート リプライ機能は、まず英語のサポートからリリースされます。


テキストの一部から言語を識別する
与えられたテキスト文字列が何語かというのは、検出が難しいものの役に立つ情報です。言語に依存する機能は、たくさんのアプリに搭載されています。たとえば、スペルチェック、テキストの翻訳、スマート リプライなどの機能が思い浮かぶでしょう。言語を特定したい場合、ユーザーに尋ねる代わりに、新しい Language Identification API を使うことができます。

ML Kit は、110 種類の言語のテキストを認識します。通常は、いくつかの単語さえあれば、正確に判断できます。また高速に処理でき、iOS や Android を搭載したスマートフォンでは、1 ミリ秒から 2 ミリ秒以内に応答を返します。
Smart Reply API と同じように、関数を呼び出すことで言語を識別できます(この例では Kotlin を使っています)。
val languageIdentification =
    FirebaseNaturalLanguage.getInstance().languageIdentification
languageIdentification
    .identifyLanguage("¿Cómo estás?")
    .addOnSuccessListener { identifiedLanguage ->
        Log.i(TAG, "Identified language: $identifiedLanguage")
    }
    .addOnFailureListener { e ->
        Log.e(TAG, "Language identification error", e)
    }
identifyLanguage 関数に何文字かのテキストを渡すと、コールバックで BCP-47 言語コードを受け取ることができます。確実に言語を識別できない場合、ML Kit は未確定(undetermined)を示すコード und を返します。Language Identification API から、可能性のある言語のリストとその信頼値を受け取ることもできます。
Language Identification API の詳しい使い方については、ドキュメントをご覧ください。


さっそく使ってみましょう
ML Kit を拡張して自然言語 API を提供できることをとても嬉しく思っています。ぜひ 2 つの新しい NLP API を試してみて、感想をお聞かせください。お気づきの点などは、いつでも Firebase Talk Google Group からご連絡ください。

さらのほかの API やカテゴリを追加して ML Kit を拡張し、皆さんが今まで以上にスマートな体験をユーザーに提供できるようになることを楽しみにしています。Google I/O での ML Kit の発表もお楽しみに。

Reviewed by Khanh LeViet - Developer Relations Team


Google I/O 2019 で発表されたコンテンツから、日本のデベロッパー様へ向けて最新技術とビジネスの情報を発信する、Google I/O Extended: Recap Live Japan 2019 の YouTube Live 配信を行います。

YouTube Live を通して、Google デベロッパー アドボケイトがお伝えする情報を広くお届けするとともに、さらに、Twitterでハッシュタグ #RecapLiveJP がついた投稿からピックアップした皆さまからの質問に直接お答えいたします。

なお、万全を期して望みますが、機器や回線の状況によりYouTube Live の配信ができない場合もございます。その際はご理解くださいますようお願いいたします。

YouTube Live 配信スケジュール:

日時:6 月 7 日(金) 16 時 30 分 - 18 時 30 分 (予定)
配信 URL:こちらよりご覧いただけます。

プログラム:

  • オープニング:松内 良介 / パートナー デベロッパー アドボケイト
  • Android & Google Play:荒木 佑一 / デベロッパー プログラム エンジニア
  • Gaming:松田 白朗 / デベロッパー アドボケイト
  • Firebase & ML Kit:Khanh LeViet / デベロッパー アドボケイト
  • ML & AI:佐藤 一憲 / スタッフ デベロッパー アドボケイト, Cloud Platform
  • Design:鈴木 拓生 / デベロッパー リレーションズ プログラム マネージャー
  • Web & Chrome:えーじ / デベロッパー アドボケイト
  • Q & A:松内 良介 / パートナー デベロッパー アドボケイト
*プログラムは予告なく変更になることがあります。



Posted by Tomoko Tanaka - Developer Product Marketing Manager, Google Play



ディープ ラーニングでタップ可能性を予測する
多くの場合、デザイナーはインターフェースが操作できることを表すために、要素の色や立体感などの視覚特性を使います。青字で下線の付いたリンクはその一例です。こういったよく使われる表現は便利ですが、特定のデザインの中で利用した場合、常にわかりやすいものになるとは限りません。さらに、デザインのトレンドの進化とともに、従来からの表現方法も常に変化し刷新されるので、不確実さや間違いの原因になる可能性もあります。

ユーザーがこの変化する環境をどのように知覚するかを理解するため、実際のモバイルアプリのタップ可能性に影響しうる表現方法について分析しました。具体的には、要素の種類(例: チェックボックス、テキスト ボックスなど)、場所大きさ文字です。最初に行ったのは、最大 3,500 個のアプリから抽出した最大 2 万個の重複しないインターフェース要素について、タップできると感じるかどうかをクラウドソーシングのボランティアにラベル付けしてもらうことでした。テキスト ボックスを除けば、ユーザーは種類による表現をほぼ確実にタップできるものと考えました。場所による表現とは、要素の画面上の場所のことです。この情報は、モバイルアプリの一般的なレイアウト デザインから得ることができます。下の図をご覧ください。
場所ごとにタップできる要素とタップできない要素の精度を表したヒートマップ。赤くなるほど精度が高い。要素をタップできないとラベル付けしたユーザーの精度は、インターフェースの上中央に近づくほど上がる。要素をタップできるとラベル付けしたユーザーの精度は、インターフェースの下中央に近づくほど上がる。
要素の大きさによる影響はかなり少ないものの、タップできない大きな要素があると混乱を生む可能性があることがわかりました。ユーザーは、が明るく文字数が少ないほどタップできる要素ととらえる傾向を示しましたが、文字の意味合いもタップできるかどうかの判断に大きな影響を与えていました。

これらのラベルを利用して、簡単なディープ ニューラル ネットワークをトレーニングしました。このネットワークは、ユーザーがインターフェース要素をタップできると感じるかタップできないと感じるかの可能性を予測するものです。このモデルは、インターフェースのある要素に対して、画面上の要素の空間的状況(場所)、要素の意味や機能(文字種類)、見た目(大きさやピクセルの生データ)などのさまざまな特徴を使います。ニューラル ネットワーク モデルは、ピクセルの生データから特徴を抽出するために畳み込みニューラル ネットワーク(CNN)を利用し、テキストの内容や要素の特性を表現するために要素の意味について学習させた埋め込み(embedding)を使います。その後、これらの特徴を組み合わせたものを全結合ネットワーク層に入力し、その出力として、要素がタップできるかを表す二値分類を生成します。



モデルの評価
このモデルを使うと、各インターフェース要素がタップできるかどうかについて、デベロッパーやデザイナーが指定した実際の(または意図した)要素の状態が、ユーザーの感覚(モデルの予測結果)とずれている部分を自動的に診断できます。次の例では、モデルは 73% の確率でユーザーが "Followers" や "Following" などのラベルをタップできると考えると予測しています。しかし実際は、これらのインターフェース要素はタップできるようにプログラムされていません。


人間のユーザーと比べた際のモデルの動作について、とりわけ人間の判断があいまいになる場合について理解するため、2,000 個の重複しないインターフェース要素がタップできると感じるかどうかをクラウドソーシングで 290 人のボランティアにラベル付けしてもらい、もう 1 つの独立したデータセットを作成しました。ここでは、1 つの要素を、5 人のユーザーがそれぞれラベル付けしました。その結果、サンプルの 40% 以上の要素に異なるラベルが付いたことがわかりました。次の図に示すように、この不確定性の部分でも、モデルと人間の感覚はかなり一致しています。
同じデータセットの各要素について、モデルが予測したタップできる可能性(Y 軸)と、人間のユーザーによるラベルの一致度合い(X 軸)でプロットした散布図。
要素がタップできるかどうかについてユーザーの意見が一致している場合、モデルも明確な答えを出す傾向にあります。つまり、ユーザーがタップできると判断したものは 1 に近い確率を、タップできないと判断したものは 0 に近い確率を出すことが多くなっています。人間の意見が一致していない要素(X 軸の真ん中に近いもの)は、モデルの判断も不確かになります。全体では、タップできる UI 要素を特定することにおいて、モデルは人間の感覚にかなり近い精度を実現できました。具体的には、平均の精度は 90.2% で、再現率は 87.0% でした。


タップ可能性の予測は、ユーザー インターフェースのユーザビリティの問題を解決するために機械学習を使ってできることの一例に過ぎません。インタラクションのデザインやユーザー エクスペリエンスの研究には、多くの難題があります。ディープ ラーニングのモデルは、ユーザー エクスペリエンスに関する大規模で多様なデータセットを精製し、インタラクションの動作について科学的な理解を進める手段を提供してくれます。


謝辞
この研究は、Google の夏季インターンである Amanda Swangson 氏と、ディープ ラーニングおよびヒューマン コンピュータ インタラクションのリサーチ サイエンティストである Yang Li 氏が共同で行いました。


Reviewed by Hak Matsuda - Developer Relations Team
Share on Twitter Share on Facebook



Google Play Indie Games Festival では、 トップ 20 に選出された作品へ一般の皆さんが投票できるオンライン投票を行います。本日より開始し、 6 月 24 日 17 時までの期間中、Google Play ストアの特設ページにて一人一票投票することができます。

オンライン投票はこちらから

Google Play Indie Games Festival 2019 トップ 20 :


今年も、たくさんの応募の中から、さまざまなジャンルのゲームがトップ 20 に選ばれました。オンライン投票で選出された 1 タイトルは「オンライン投票最優秀賞」としてファイナルイベントにて賞が授与されます。


今週末 6月1日・2日開催の BitSummit 7 Spirits の Google Play ブースに設けられる、オンライン投票のリアル出張所でも試遊し、投票可能です。あなたの一票でオンライン投票優秀賞が決まるかもしれません。お気に入りの作品で楽しんでみてください。


Posted by Tomoko Tanaka - Developer Product Marketing Manager, Google Play
Share on Twitter Share on Facebook

Share on Twitter Share on Facebook

Shobhit Chugh
プロダクト マネージャー

Firebase Crashlytics を使うと、クラッシュや致命的でないエラーをバージョンごとに表示できます。最新リリースには特に注目するなど、このフィルタリング機能を活用しているユーザーもいます。


しかし、バージョンの数が多すぎるのも、厄介なことかもしれません。デフォルトで、Firebase Crashlytics は認識している直近 100 個のバージョンを表示します。デベロッパーや継続的インテグレーション、デプロイ パイプラインによって作成されたデバッグ版がたくさん表示されている方は、一番重要な本番ビルドのバージョンが見えなくなってしまうかもしれません。

これが起こらないようにするには、どうすればいいでしょうか。一番シンプルな方法は、デバッグビルドでクラッシュ レポートの初期化を無効にすることです。iOS と Android のそれぞれについて、その方法を説明しましょう。

iOS

まず、iOS アプリで Crashlytics を手動で初期化しているかどうかを確認します(Firebase アプリにリンクしていた Fabric アプリの場合、そうなっています)。

Swift を使っている場合は、AppDelegate.swift で Fabric.with([Crashlytics.self]) という行を検索します 。この行が存在する場合は、手動で Crashlytics を初期化しています。存在しない場合は、自動で初期化しています。

ObjectiveC を使っている場合は、AppDelegate.m で [Fabric with:@[[Crashlytics class]]]; という行を検索します 。この行が存在する場合は、手動で Crashlytics を初期化しています。存在しない場合は、自動で初期化しています。

手動で初期化しているアプリ

手動で初期化しているアプリでは、DEBUG バージョンに対して Crashlytics を初期化しないようにするだけです。
Swift の場合
#if !DEBUG 
Fabric.with([Crashlytics.self]) 
#endif
ObjectiveC の場合
#if !DEBUG 
[Fabric with:@[[Crashlytics class]]]; 
#endif

自動で初期化しているアプリ

Firebase Crashlytics アプリは Firebase が自動的に初期化しています。Info.plist ファイルに新しいキーを追加すると、自動収集をオフにすることができます。
その後、先ほどの Swift と ObjectiveC の例で示した方法を使って初期化します。

Android

まず、Android アプリで Crashlytics を手動で初期化しているかどうかを確認します(Firebase アプリにリンクしていた Fabric アプリの場合、そうなっています)。プロジェクトで、Fabric.with を検索してください。この行が存在する場合は、手動で Crashlytics を初期化しています。存在しない場合、Crashlytics は Firebase 経由で自動的に初期化されます。

手動で初期化しているアプリ

BuildConfig.DEBUG フラグを使うと、デバッグビルドで Crashlytics を無効にすることができます。先ほど検索した Fabric.with 文を編集し、DEBUG フラグをチェックする部分を追加します。
if (!BuildConfig.DEBUG) { 
Fabric.with(this, new Crashlytics()); 
}

自動で初期化しているアプリ

src ディレクトリに debug フォルダを作成し、次のスニペットを含む AndroidManifest.xml を作成して、デバッグビルドで Crashlytics の初期化をオフにします。
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
  <application>
    <meta-data
        android:name="firebase_crashlytics_collection_enabled"
        android:value="false" />
  </application>
</manifest>
このスニペットは、すべてのデバッグ バリアントのマニフェストに結合されるので、すべてのデバッグビルドで Crashlytics が無効になります。さらに細かく制御したい場合は、除外したいすべてのバリアントについてこの方法を使うことができます。


Reviewed by Khanh LeViet - Developer Relations Team
Share on Twitter Share on Facebook

Sumit Chandel
デベロッパー アドボケート

Firebase が Game Developers Conference に帰ってきました。今年、サンフランシスコで開催されたこのイベントでは、ゲーム デベロッパー向けにさらに Firebase が強化されていたことをお伝えします!
3 月 18 日の Google Mobile Developer Day では、次のことをお知らせしました。
では、ゲーム デベロッパーのための最新の Firebase アップデートの概要をご紹介しましょう。

Firebase Crashlytics for Unity

Firebase Crashlytics が Unity でも使えるようになります!Firebase Crashlytics は、安定性の問題をリアルタイムで追跡し、優先順位をつけて修正する際に役立ちます。たくさんのクラッシュから管理しやすい問題リストを生成してくれるだけでなく、状況に関する情報を提供したり、クラッシュの重要度や発生率をまとめたりしてくれるので、短時間でクラッシュの根本原因を特定できます。パンくずリスト(エラーが発生する前にユーザーが実行したアクションのリスト)を確認すれば、問題を簡単に再現することもできます。


これまで、Crashlytics を利用できたのは Android と iOS だけでしたが、この強力なクラッシュ報告機能が Unity ゲームでも使えるようになります!

簡単に使える点は、ほかの Firebase for Unity SDK と変わりません。Crashlytics は Unity の IDE から直接組み込むことができ、その他の手順は一切必要ありません。メールや Slack、Jira、PagerDuty と連携してチームに問題のアラートを送ったり、Cloud Functions で Firebase Crashlytics トリガーを使って独自のトリガーを書いたりもできます。

もう 1 つ重要な点は、Crashlytics データを BigQuery にエクスポートして細かく分析できることです。たとえば次のように、Crashlytics イベントを報告する際にカスタムキーを記録したとしましょう。

Crashlytics.SetCustomKey("current_level", "3");

Crashlytics データを BigQuery にエクスポートすると、レベル 3 や他のレベル、あるいはイベントに使っているカスタムキーによるクラッシュの分布を確認できます。また、データスタジオ テンプレートを使ってすばやくデータを分析することもできます。これにより、Unity ゲーム開発で発生する問題の追跡や修正がかなり楽になります。
ドキュメントを参照し、Firebase Crashlytics for Unity を使ってみてください。

C++ SDK のオープンソース化

C++ デベロッパーの皆さん、Firebase for Games を組み込む際にオープンソースの SDK を使えるようになりました!これにより、Firebase ツールセットを組み込む際に、さらに細かく制御できるようになります。コードを参照して SDK の内部動作を確認したり、ゲームに合わせて変更したりすることも簡単になります。また、クライアント SDK のブランチを独自に管理し、関心のある特定の変更だけを選択して反映することもできます。まだサポートされていない他のプラットフォームがあれば、SDK を拡張することもできます。

AI を活用する Firebase Test Lab の新しいゲーム用モンキー アクション

Firebase Test Lab は、クラウドベースのアプリテスト用インフラストラクチャです。1 回の操作だけで Android や iOS のアプリをさまざまな端末や端末設定でテストし、Firebase コンソールで結果を確認できます。ネイティブ Android アプリでは、Robo テストと呼ばれる機能が画面上の UI 要素を的確に分析してクロールしています。しかし、ゲームではこれを行うことはできません。一般的に、すべての要素が GL/Vulkan/Metal のビューの中にあるからです。そこで Robo は、ランダムにタップするモンキー アクションを使います。


しかし、このようなスモークテストが終わるまでには、かなりの時間がかかることがあります。そこで、AI を活用した新しいモンキー アクションについてお知らせします。これは、Firebase Test Lab でのゲームのテストに役立てるために作られたものです。この機能によって、ロボットがゲームのユーザー インターフェースを移動し、有用なテスト結果を生成するまでの時間が大幅に短縮されます。AI を活用するものとそうでないものを比較した動画を見ると、その差がわかります。AI を活用しないモンキー アクションの動画では、ゲームを始めるまでに約 35 秒かかっています。それに対し、AI を活用するものは 13 秒しかかかりません(画面上のオレンジ色の点は、ロボットが画面をタップした場所を表しています)。



AI を活用しないモンキー アクションがゲームを始める様子。


AI を活用するモンキー アクションがゲームを始める様子。

iOS の GameCenter Authentication サポート

Firebase Authentication は、アプリにエンドツーエンドの ID ソリューションを提供します。この機能を使うと、パスワードや電話番号、Google、Facebook、Twitter などのよく使われているフェデレーション ID プロバイダを通してユーザーの認証や検証を行えます。
iOS ゲーム デベロッパーのために、Firebase Authentication が Game Center Authentication もサポートしました。既に Game Center にログインしている iOS ユーザーは、追加のログインフローを行うことなくアプリにログインできるようになります。

Reviewed by Hak Matsuda - Developer Relations Team
Share on Twitter Share on Facebook


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook



Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook


Google Play Indie Games Festival 2019 に多数ご応募いただきありがとうございました。

厳正なる審査により以下の 20 作品が選出されました。入賞されたみなさま、おめでとうございます。この中から、6 月 29 日開催のファイナルイベントでトップタイトルが決定します。

Google Play Indie Games Festival 2019 トップ 20 :

※(五十音順、敬称略)



オンライン投票は 5 月 30 日から開始。BitSummit 7 Spirits でも投票可能:

この 20 作品からお気に入りのタイトルへ投票できるオンライン投票を 5 月 30 日 から 6 月 24 日 17 時まで実施します。
オンライン投票はお一人様一票のみ有効です。最多得票数作品は 6 月 29 日開催のファイナルイベントで「オンライン投票最優秀賞」が授与されます。なお、6月1日・2日開催の BitSummit 7 Spirits の Google Play ブースに設けられる、オンライン投票のリアル出張所でも投票することが可能です。

オンライン投票の詳細は、投票開始日の 5 月 30 日にお知らせします。

Posted by Tomoko Tanaka - Developer Product Marketing Manager, Google Play
Share on Twitter Share on Facebook


Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team
Share on Twitter Share on Facebook