注: Google Maps Platform ゲームサービスは、2021 年 10 月 18 日をもって非推奨となり本サービスへのアクセスは 2022 年 12 月 31 日に終了させていただきました。主要なバグとシステム障害へのサポートおよび修正も、上記の期日で終了いたしました。ゲームサービス移行ガイドで、プロジェクトの次のステップを計画するうえで役立つリソースをご確認ください。

Playable Locations API の設計の概要

Playable Locations API は、選択して生成されたマップの地点情報（プレイアブルロケーション）のコレクションを提供します。各プレイアブルロケーションには、位置情報ゲームで修理施設やゲームの賞品などの配置地点に適した場所が Google によって選択されます。

プレイアブルロケーションは、有名なスポットの周辺や道路わきの歩道の他に、公園、遊び場、街の広場などの公共の場所にもランダムに配置されます。

このドキュメントでは、サードパーティ開発者が主要なコンセプトの理解を深め、代替データソースを使用して独自の一連のプレイアブルロケーションを生成できるように、API がどのように実装されたかを簡単に説明します。

背景

このセクションでは、使用するサポートライブラリの概要と、プレイアブルロケーションに関する基本的なコンセプトを説明します。

サポートライブラリ

このガイド全体で、次のサポートライブラリを使用します。

図書館	説明
S2 Geometry	空間インデックスの柔軟なサポート。
Protocol Buffers	通信プロトコルやデータストレージなどで使用するために構造化データをシリアル化する拡張可能メカニズム。言語やプラットフォームに依存しません。

S2 Geometry Library

S2 Geometry Library は、3 次元の球面上のデータを表す地理情報システムです。このライブラリには次の特長があります。

空間インデックスのサポート。
- 任意に分散している S2 セルの面積を集合として概算できます。
- ポイント、ポリライン、ポリゴンの集合を、メモリ内で高速に空間インデックス処理できます。
堅牢な構成演算（積、和、簡約など）とブール値の述語（含有のテストなど）。
効率的なクエリ操作（周辺オブジェクトの検索、距離の測定、重心の計算など）。
数学的述語のコレクションにより、ジオメトリックプリミティブ間の関係をテスト。
スナップ丸め。

S2 Cell Statistics

S2 Cell Statistics は、特定の QPS でデータセットをダウンロードする際にかかる時間などを計算するときに役立ちます。

S2 Geometry コードリポジトリ

S2 セルの使用を開始するときは、これらのリポジトリのクローンを作成します。

SSTables

SSTable ファイル形式は、データセットを効率的に保存、処理、交換するために使用されます。SSTable は、永続的な順序付きの、キーから値への不変マップとなっています。ここでは、キーと値はどちらも任意のバイト文字列です。

プレイアブルロケーション

一般的なロケーションは地図上の地理的位置ですが、プレイアブルロケーションは、リアルワールドゲームでゲームオブジェクトの配置場所（賞品などのスポーン地点）として使用されます。

プレイアブルロケーションの種類

キュレート済み

キュレート済みのプレイアブルロケーションは、特定の場所に存在するオブジェクトに関連付けられた地理的ポイントです。プレイスデータベースから取得したスポットの位置を表します。

自動生成

キュレート済みのプレイアブルロケーションでは条件を満たせない場合、Playable Locations API によって追加のプレイアブルロケーションが生成されます。新しく生成されるプレイアブルロケーションは、既存のオブジェクトに関連付けられていない地理的ポイントです。これらの地理的ポイントはプログラムによって生成され、歩道、公園、ビーチ、遊び場、広場などの公共の場にランダムに配置されます。

目標は、次の条件を考慮したうえで、最低限の密度以上でプレイアブルロケーションを提供することです。

条件	例
プレーヤーの安全性	ゲームの賞品が、高速道路上や軍事基地の中に現れることがない。
ゲームプレイにふさわしい場所	プレーヤーが墓所や礼拝所に侵入することがない。

Playable Location のプロパティ

ここでは、Google が実装している Playable Location オブジェクトに関連付けられたプロパティのうち、デベロッパーが位置情報ベースのゲームを構築する際に役立つ可能性があるものについて説明します。

placeId: ロケーションを一意に識別する英数字の文字列。キュレート済みプレイアブルロケーションの Place ID（Chlj79ZW1ohQwokRWPhGmWQ2K4）です。キュレート済みプレイアブルロケーションの Place ID を使って、ゲーム固有のメタデータをロケーションに追加できます。
plusCode: 生成されたプレイアブルロケーションを一意に識別する Plus Code。Plus Codes は英数字の文字列です。たとえば、23CPRV2R+WG76 のようになります。生成されたロケーションの plus code を使って、ゲーム固有のメタデータをロケーションに追加できます。
types: プレイアブルロケーションの種類を指定するプレイアブルロケーションの種類（文字列）の配列です。配列の最初の種類は「主な種類」と見なされます。たとえば、entertainment と outdoor_recreation の両方のプレイアブルロケーションを設定できます。
centerPoint: ロケーションの中心点に対応する地理座標。中心点は、ロケーションが関心のある地域内にあるかどうかを判断するために使用されます。
snappedPoint: 最寄りの道路（最寄りの道路がある場合）の歩道にスナップしたロケーションに対応する地理的座標です。ビジネスの所有者が施設内にゲームプレーヤーが入って欲しくない場合、スナップポイントを使用してゲームオブジェクトを配置します。スナップポイントを使用できない場合は、中心点を使用する必要があります。
biomeType: プレイアブルロケーションが生物群系内にある場合、このフィールドにはいずれかの BiomeType 値が入力されます。生物群系の例として、森林、湿地帯、都市部などがあります。

デザイン

ゲームのポイント選択

キュレート済みのロケーションの選択

前述のように、キュレート済みのロケーションは、ゲームプレイに適していると見なされる実世界のスポット（POI）です。以下では、これらのロケーションを生成するために使用できるデータパイプライン（選択基準とフィルタ条件を含む）の概要を説明します。このパイプラインの目的は、S2CellId をキーとしたキュレート済みのロケーションの SStable を出力し、その後にデータベースに供給して、指定された地域内でプレイアブルロケーションをリアルタイムでクエリできるようにすることです。

デベロッパーが、除外された地域（プレイアブルロケーションが存在しない地域）のジオメトリに加え、地図上の場所の候補を含む地図対象物またはプレイスリポジトリにアクセスできることを前提としています。

このパイプラインでは、許可リストとブロックリストを組み合わせて使用します。1 つのフェーズで、ゲームプレイに適するタイプの許可リスト（カフェ、図書館、花屋など）に一致するすべてのスポットを選択し、別のフィルタで、除外された地域に含まれるスポットをすべて除外します。除外された領域は、ゲームプレイには不適切と見なされる、事前定義の地図対象物のジオメトリ（境界ボックスなど）を使用して定義され、S2 カバーの生成に用いられます。これらの S2 カバー情報を使用して、選択したスポットのいずれかが除外地域に該当するかどうかを確認し、該当している場合は除外できます。次に、キュレート済みのロケーションの最終セットを、レベル 30 で中心点を S2CellId に変換してインデックスに登録します。これにより、指定した地域内のプレイアブルロケーションを範囲に基づいて検索できます。

キュレート済みのロケーションのパイプライン図。

生成されたロケーションの選択

前述のように、生成されたロケーションは、実際のスポットではゲームプレイに必要な密度がない領域でプレイアブルロケーションを補完するために使用されます。一般的には、レベル 16 の S2 セル（0.02 平方 km 以内）ごとに約 9 つのプレイアブルロケーションがあれば、位置情報ベースのゲームには十分な密度であることが判明しています。

また、このような「ランダムな」地理的ポイントの生成は、許可リストとブロックリストの組み合わせのアプローチを使用して行われます。許可リストは、ポイント（公園、歩道など）の生成に適していると思われる地図対象物のリストで、ブロックリストは、ポイントを除外すべきエリア（水域、自動車が走行する道路など）です。どちらの場合も、地図対象物のジオメトリを使用してそれぞれの領域の S2 カバーを生成し、2 つのセットを結合するとともに、重複する除外領域が含まれている領域から差し引いて、最終的な候補エリアセットを生成します。最後に、それらの領域内の地理的ポイントを「ランダム」に生成し、中心点を表すレベル 30 の S2CellId を使用してインデックス化された SStable に書き込みます。生成されたロケーションでは、プレイス ID としてplus code が使用されます。

生成されたロケーションパイプラインの図。

ロケーションパイプラインの概要

上記のように、前の 2 つのデータパイプラインの出力は、S2CellIds を使用して S2 レベル 30 でインデックスに登録された、PlayableLocation オブジェクトの 2 つの SSTable です。これらのファイルは、順序付けされた Key-Value ストアに読み込んで、空間インデックスに基づいて参照できます。選択肢の 1 つとして、Google の分散 SQL データベース Spanner があります

ロケーションに基づいて順序付けされた Key-Value のパイプライン図。

生物群系

生物群系とは、共通の環境適応特性を持つ植物と動物のコミュニティです。生物群系は、共通の物理的気候に対応して形成されます。生物群系の例として、森林、湿地帯、都市部などがあります。

プレイアブルロケーションが生物群系内にある場合、biomeType フィールドにはいずれかの BiomeType 値が入力されます。

生物群系に関する情報を使用して、さまざまなゲームオブジェクトタイプを地図に配置できます。たとえば、生物群系フィールドで値「grassland」が指定されている場合は、生物群系フィールドで値「urban」が指定されている場合とは異なる種類の生物が生息している可能性があります。

以下に、Locations パイプラインの一部として生物群系に関する情報をプレイアブルロケーションに追加するプロセスを説明します。Google の Earth Engine には、森林、草地、水などの情報クラスを持つ複数の土地被覆データセットがあり、生物群系に関する情報の入手に利用できます。生物群系に関する情報を追加するための大まかな手順として、次のことをおすすめします。

生物群系と位置情報の両方を含むデータをキュレートします。
生物群系に関する情報を、位置情報に基づいて既存のプレイアブルロケーションに割り当てます。通常は空間結合によって行います。たとえば、S2 セルレベル 17 で生物群系情報が入手可能で、プレイアブルロケーションがレベル 30 で S2CellId を使用してインデックスに登録されている場合は、次のように結合できます。
1. レベル 17 のプレイアブルロケーションを S2 セルにマッピングする: PlayableLocation.s2CellId.parent(17)
2. レベル 17 の Biome S2CellId と結合する
可能であれば、生物群系属性とともにプレイアブルロケーションを提供する。

プレイアブルロケーションへの生物群系リポジトリを示す図。

プレイアブルロケーションのクエリ

上記の推奨事項に従い、レベル 30 で S2CellIds を使用してプレイアブルロケーションがインデックス登録されると（LatLng からセル ID への変換については、S2 ライブラリをご覧ください）、範囲ベースのスキャンを行って特定の地域のプレイアブルロケーションを取得することが可能になります。

クエリ例

レベル 12（5 km^2 以内）の S2Cell にあるプレイアブルロケーションをすべて取得するには、次のクエリを実行します。

S2CellId: 0x89c2599000000000 Range Min: 0x89c2598000000001（s2CellId.rangeMin().id()） Range Max: 0x89c2599fffff（ s2CellId.rangeMax().id()）

SELECT * FROM PlayableLocations
WHERE S2CellId BETWEEN 0x89c2598000000001 AND 0x89c2599fffffffff;

間隔

ここでも、S2Library はゲーム内のプレイアブルロケーションの密度を制御するのに役立ちます。S2 レベルは階層化されているため、レベル 14 の各セルにはレベル 15 の 4 つのセルが含まれます（S2 セルの統計情報をご覧ください）。これらのプロパティは、ゲーム内にゲームオブジェクトを配置するときに活用できます。たとえば、レベル 14 のセルごとに「モンスター」を 1 つずつ配置し、同じエリアで 64 個の「宝石」を均等に配置するには、レベル 17 の各セルに「宝石」を 1 つずつ配置します（レベル 14 の各セルにはレベル 17 のセル 64 個が含まれます）。

クエリとキャッシュの相互関係

次のシーケンス図は、ゲームクライアント、ゲームサーバー、ゲームステータスデータベース、プレイアブルロケーションデータベース間の推奨ロジックフローを示しています。ゲームステータスとプレイアブルロケーションを 1 つの DB にまとめることもできますが、わかりやすくするため、ここでは分けています。

プレイアブルロケーションのクエリとキャッシュの図

不適切なロケーションの報告

以下では、プレーヤーが使用できないプレイアブルロケーションを報告できるようにして、ゲーム内でプレイアブルロケーションの品質に関するフィードバックを収集するプロセスについて説明します。これらのレポートをデータパイプラインで処理して、プレイアブルロケーションのデータベースから不適切なロケーションを削除できます。

不適切なロケーションの報告は、次の手順で実装することをおすすめします。

クライアント側でエントリポイント（モバイルまたはウェブフォーム）を作成し、ゲームデベロッパーに構造化された不適切なポイントレポートを送信できるようにします。
受信したすべてのレポートを処理するためのデータパイプラインを構築し、各ロケーションの不適切な度合いを分類するためのシグナルを生成します。
実際のユースケースに応じて、純粋な ML モデル、ML モデルと人間のハイブリッドソリューションのいずれかを使用して、モデレーションプロセスを拡張し、PlayableLocationsDB から不適切なロケーションを削除できます。

不適切なロケーションの報告を表した図。

プレイアブルロケーションが不適切かどうかを判断する際に使用できる条件の例を次に示します。

条件	例
安全でない	プレイアブルロケーションが崖の縁から 50 m 以内にある。大通りの真ん中や、車が高速で行き交う道路の近くにプレイアブルロケーションがある。
非公開エリア	立ち入り禁止の政府施設（軍事基地など）。
アクセス不可	侵入禁止のエリア。水域の中にあるランドマーク。
一時的にアクセス不可	改装工事のために閉鎖された場所。季節的に閉鎖された場所。修理のために 1 週間以上閉鎖されている道路。
文化的にデリケートな場所	墓地。礼拝所。