(57)【要約】  マップデータを処理して簡易化したマップデータのタイルを提供する方法であって、マップデータから少なくとも１つの地図上の特徴を除去することにより、簡易化したマップデータのタイルを提供する。この方法はさらに、マップデータのタイルにおいて、タイルの境界を跨ぐ地図上の各特徴に対して提供される少なくとも１つのエッジノードを規定する。この方法は、ゲームのプレイに使用されるユーザデバイスにマップデータのタイルを提供してもよい。【選択図】  図１１
2017511510.tif 000002
【特許請求の範囲】
【請求項１】
マップデータから少なくとも１つの地図上の特徴を除去して簡易化したマップデータのタイルを提供するためにマップデータを処理することと、
前記マップデータのタイルにおいて、前記タイルの境界を跨ぐ地図上の各特徴に対して提供される少なくとも１つのエッジノードを規定することと、
前記マップデータのタイルをユーザデバイスに提供することと
を含むコンピュータで実行される方法。
【請求項２】
前記マップデータのタイルは、コンピュータ実行ゲームのプレイで使用される、請求項１に記載の方法。
【請求項３】
データベースに前記マップデータを記憶することを含む、請求項１又は２に記載の方法。
【請求項４】
前記処理は、前記マップデータを記憶したデータベースにクエリを行うことを含む、請求項１〜３のいずれかに記載の方法。
【請求項５】
前記処理は、前記マップデータをフィルタリングすることを含む、請求項１〜４のいずれかに記載の方法。
【請求項６】
前記処理はさらに、複数の多角形で規定された少なくとも１つの地理的特徴に対して、前記複数の多角形を１つの多角形に結合することを含む、請求項１〜５のいずれかに記載の方法。
【請求項７】
前記処理はさらに、各々、ゲームにおいて１つ以上のゲーム対象物を配置可能な位置を規定する複数のマーカを生成することを含む、請求項１〜６のいずれかに記載の方法。
【請求項８】
各マーカは、独自の識別子を有する、請求項７に記載の方法。
【請求項９】
互いに隣接し、相互の間の境界を跨ぐ地図上の各特徴に提供される少なくとも１つのエッジノードを含む少なくとも２つのマップデータのタイルを取得することと、
前記マップデータのタイルの少なくとも一部をレンダリングすることと
を含む、コンピュータで実行される方法であって、
前記隣接したタイルの各エッジノードを合致させることにより、前記境界を跨ぐ前記地図上の特徴を接合することを含む方法。
【請求項１０】
前記接合することにより、コンピュータ実行ゲームのゲーム要素が地図上の特徴に沿って１つのタイルから前記隣接したタイルへ移動できるようにする、請求項９に記載の方法。
【請求項１１】
ユーザデバイスの位置を判定し、マップを表示することを含み、表示される前記マップは、前記ユーザデバイスの位置に応じて決まる、請求項９又は１０に記載の方法。
【請求項１２】
前記マップデータは、複数のマーカを含み、各マーカは、ゲームが１つ以上のゲーム対象物を配置することができる位置を規定し、前記方法は、少なくとも１つのマーカを使用して少なくとも１つのゲーム対象物の位置を制御することを含む、請求項９、１０、又は１１に記載の方法。
【請求項１３】
マップデータを記憶するように構成されたデータベースと、
前記マップデータを処理して前記マップデータから少なくとも１つの地図上の特徴を除去することにより、簡易化したマップデータのタイルを提供するとともに、前記マップデータのタイルに、前記タイルの境界を跨ぐ地図上の各特徴に対して提供される少なくとも１つのエッジノードを規定するように構成された、少なくとも１つのプロセッサと、
前記マップデータのタイルをユーザデバイスに提供するように構成された出力部と
を備える装置。
【請求項１４】
前記マップデータのタイルは、コンピュータ実行ゲームのプレイで使用される、請求項１３に記載の装置。
【請求項１５】
前記少なくとも１つのプロセッサは、前記データベースにクエリを行うように構成される、請求項１３又は１４に記載の装置。
【請求項１６】
前記少なくとも１つのプロセッサは、前記マップデータをフィルタリングするように構成された、請求項１３、１４、又は１５に記載の装置。
【請求項１７】
前記少なくとも１つのプロセッサは、複数の多角形で規定された少なくとも１つの地理的特徴に対して、前記複数の多角形を１つの多角形に結合するように構成された、請求項１３〜１６のいずれかに記載の装置。
【請求項１８】
前記少なくとも１つのプロセッサは、複数のマーカを生成するように構成され、各マーカは、ゲームが１つ以上のゲーム対象物を配置することができる位置を規定する、請求項１４又はそのいずれかの従属項に記載の装置。
【請求項１９】
タイル状データを記憶するように構成されたメモリと、
前記メモリから、互いに隣接し、相互の間の境界を跨ぐ地図上の各特徴に提供される少なくとも１つのエッジノードを含む、少なくとも２つのマップデータのタイルを取得し、
前記マップデータのタイルの少なくとも一部をレンダリングしてレンダリング済みマップデータを生成し、
前記レンダリング済みマップデータを前記ユーザデバイスのディスプレイに出力するように構成された、少なくとも１つのプロセッサと
を備えた、ユーザデバイスの装置であって、
前記プロセッサは、前記隣接したタイルの前記エッジノードを合致させることにより、前記境界を跨ぐ前記地図上の特徴を接合するように構成された装置。
【請求項２０】
前記接合することにより、コンピュータ実行ゲームのゲーム要素が地図上の特徴に沿って１つのタイルから前記隣接したタイルへ移動できるようにする、請求項１９に記載の装置。
【請求項２１】
前記合致することは、隣接したタイルの各エッジノード間の論理的接続をメモリに記憶することを含む、請求項１９又は２０に記載の装置。
【請求項２２】
前記装置の位置を判定するように構成された位置判定機を備え、前記プロセッサは、表示されるマップが前記位置に応じて決まるように前記ディスプレイを制御する、請求項１９、２０、又は２１に記載の装置。
【請求項２３】
前記マップデータは、複数のマーカを備え、各マーカは、１つ以上のゲーム対象物を配置可能な位置を規定し、前記少なくとも１つのプロセッサは、少なくとも１つのマーカを使用して、少なくとも１つのゲーム対象物の位置を制御する、請求項１９〜２２のいずれかに記載の装置。
【請求項２４】
コンピュータプログラムであって、少なくとも１つのプロセッサによって実行されると、請求項１〜１２のいずれかに記載の前記方法を実施するコンピュータ実行可能な指示を備える、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明のいくつかの実施形態は、マップデータの処理又はマップデータの使用に関連しうる。これは、コンピュータ実行ゲームに関連するものでありうる。
【０００２】
本発明のいくつかの実施形態は、コンピュータデバイスのインタフェース上の表示ゲーム対象物に対するユーザの関与に応じたユーザインタフェースの制御に関連しうる。
【０００３】
本発明のいくつかの実施形態は、オンライン環境で実行可能なコンピュータゲームのユーザすなわちプレーヤーに関与するユーザインタフェースを有するコンピュータデバイスに関連しうる。
【背景技術】
【０００４】
ユーザインタフェースを有するユーザデバイスやコンピュータデバイス上で実行されるコンピュータゲームの設計者は、多くの技術的課題や検討事項に直面している。例えば、利用可能なコンピュータデバイスやリソースが限られた中で、制御可能なユーザインタフェースを設計することである。
【０００５】
バッテリ電力を過度に消費しないでモバイルデバイス上の位置ベースのゲームを提供する際、いくつかの技術的課題がある。
【発明の概要】
【課題を解決するための手段】
【０００６】
一態様によると、マップデータから少なくとも１つの地図上の特徴を除去して簡易化したマップデータのタイルを提供するようにマップデータを処理することと、前記マップデータのタイルにおいてタイルの境界を跨ぐ地図上の各特徴（each map feature）に対して提供される少なくとも１つのエッジノードを規定することと、マップデータのタイルをユーザデバイスに提供することとを含む方法を提供する。
【０００７】
この方法は、装置で実施されてもよい。この装置は、サーバであってもよい。この処理は、少なくとも１つのプロセッサで実施されてもよい。タイルマップデータは、ユーザデバイスに送信されてもよい。
【０００８】
前記タイルマップデータは、ゲームのプレイに使用されてもよい。
【０００９】
この方法は、データベースにマップデータを記憶することを含んでもよい。
【００１０】
前記処理は、マップデータを記憶したデータベースにクエリを行うことを含んでもよい。
【００１１】
前記処理は、データベースに対して１つ以上のＳＱＬクエリを作成することを含んでもよい。
【００１２】
前記処理は、マップデータをフィルタリングすることを含んでもよい。
【００１３】
前記処理はさらに、複数の多角形で規定された少なくとも１つの地理的特徴（geographic feature）について、複数の多角形（ポリゴン）を結合して１つの多角形を提供することを含んでもよい。
【００１４】
前記処理はさらに、各々、ゲームにおいて１つ以上のゲーム対象物を配置可能な位置を規定する複数のマーカを生成することを含んでもよい。
【００１５】
各マーカは、独自の識別子を有してもよい。
【００１６】
他の態様によると、互いに隣接し、相互の境界を跨ぐ地図上の各特徴に提供される少なくとも１つのエッジノードを含む少なくとも２つのマップデータのタイルを取得することと、タイル状のマップデータの少なくとも一部をレンダリングすることと、隣接したタイルのエッジノードを合致させることにより、境界を跨ぐ地図上の特徴を接合することとを含む方法を提供する。
【００１７】
前記接合することは、論理的接合であってもよい。
【００１８】
これにより、コンピュータ実行ゲーム中のゲーム要素が地図上の特徴に沿って１つのタイルから隣接したタイルに移動するようにしてもよい。
【００１９】
前記合致させることは、レンダリングの一部であってもよい。
【００２０】
この方法は、ユーザデバイスで実施されてもよい。
【００２１】
前記レンダリングすることは、レンダリング済みのマップデータを提供することをさらに備えてもよく、この方法は、レンダリング済みのマップデータをディスプレイに提供することを含んでもよい。
【００２２】
前記取得することは、ユーザデバイスのメモリから少なくとも１つのマップデータのタイルを取得することと、サーバから少なくとも１つのマップデータのタイルを受信することとのうちの少なくとも１つを含んでもよい。
【００２３】
この方法は、ユーザデバイスの位置を判定することと、マップを表示することとを含んでもよく、表示されるマップは、ユーザデバイスの位置に応じて決まる。
【００２４】
マップデータは、複数のマーカを含んでもよく、各マーカは、ゲームにおいて１つ以上のゲーム対象物を配置可能な位置を規定し、前記方法は、少なくとも１つのマーカを使用して少なくとも１つのゲーム対象物の位置を制御することを含んでもよい。
【００２５】
一態様によると、マップデータを処理し、該処理することによって、マップデータから少なくとも１つの地図上の特徴を除去して簡易化したマップデータのタイルを提供することを含む方法を提供する。
【００２６】
一態様によると、マップデータのタイルにおいて、タイルの境界を跨ぐ地図上の各特徴に対して提供される少なくとも１つのエッジノードを規定することを含む方法を提供する。
【００２７】
一態様によると、マップデータを記憶するように構成されたデータベースと、少なくとも１つの地図上の特徴を除去することにより、簡易化したマップデータのタイルを提供するようにマップデータを処理するとともに、該マップデータのタイルに、タイルの境界を跨ぐ地図上の各特徴に対して提供される少なくとも１つのエッジノードを規定するように構成された、少なくとも１つのプロセッサと、マップデータのタイルをユーザデバイスに提供するように構成された出力部とを備えた装置を提供する。
【００２８】
この装置は、少なくとも１つのサーバによって提供されてもよい。
【００２９】
このマップデータのタイルは、コンピュータ実行ゲームのプレイに使用されてもよい。
【００３０】
前記少なくとも１つのプロセッサは、データベースにクエリを行うように構成されてもよい。
【００３１】
前記少なくとも１つのプロセッサは、データベースに対して１つ以上のＳＱＬクエリを作成するように構成されてもよい。
【００３２】
前記少なくとも１つのプロセッサは、マップデータをフィルタリングするように構成されてもよい。
【００３３】
前記少なくとも１つのプロセッサは、複数の多角形によって規定される少なくとも１つの地理的特徴について、複数の多角形を１つの多角形に結合するように構成されてもよい。
【００３４】
前記少なくとも１つのプロセッサは、複数のマーカを生成するように構成されてもよく、各マーカは、ゲームにおいて１つ以上のゲーム対象物を配置可能な位置を規定する。
【００３５】
各マーカは、独自の識別子を有してもよい。
【００３６】
一態様によると、タイル状データを記憶するように構成されたメモリと、前記メモリから、互いに隣接し、相互の間の境界を跨ぐ地図上の各特徴に提供される少なくとも１つのエッジノードを含む少なくとも２つのマップデータのタイルを取得し、前記マップデータのタイルの少なくとも一部をレンダリングしてレンダリング済みマップデータを生成し、該レンダリング済みマップデータをユーザデバイスのディスプレイに出力するように構成された少なくとも１つのプロセッサとを備えたユーザデバイスの装置であって、前記少なくとも１つのプロセッサは、隣接したタイルのエッジノードを合致させることにより、境界を跨ぐ地図上の特徴を接合するように構成された装置を提供する。
【００３７】
これにより、コンピュータ実行ゲームのゲーム要素を地図上の特徴に沿って１つのタイルから隣接したタイルに移動させてもよい。
【００３８】
前記メモリは、キャッシュメモリであるように構成されてもよい。代替又は追加として、このメモリは、サーバに送られるリクエストに応じて少なくとも２つのマップデータのタイルを記憶するように構成されてもよい。
【００３９】
この装置は、サーバから少なくとも１つのマップデータのタイルを受信するように構成された入力部を備えてもよく、受信した少なくとも１つのマップデータのタイルはメモリに記憶される。
【００４０】
前記合致することは、隣接したタイルの各エッジノード間の論理的接続をメモリに記憶することを含んでもよい。
【００４１】
この装置は、装置の位置を判定するように構成された位置判定機を備えてもよく、プロセッサは、表示されるマップがこの位置に応じて決まるようにディスプレイを制御するように構成されている。
【００４２】
マップデータは、複数のマーカを備えてもよく、各マーカは、ゲームにおいて１つ以上のゲーム対象物を配置可能な位置を規定し、少なくとも１つのプロセッサは、少なくとも１つのマーカを使用して少なくとも１つのゲーム対象物の位置を制御するように構成される。
【００４３】
一態様によると、マップデータを処理して簡易化したマップデータのタイルを提供するように構成された少なくとも１つのプロセッサを備えた装置であって、プロセッサは、マップデータから少なくとも１つの地図上の特徴を除去することにより、簡易化したマップデータのタイルを提供するように構成された装置を提供する。
【００４４】
一態様によると、マップデータのタイルにおいて、タイルの境界を跨ぐ地図上の各特徴に対して提供される少なくとも１つのエッジノードを規定するように構成された少なくとも１つのプロセッサを備えた装置を提供する。
【００４５】
一態様によると、プロセッサにより実行されると、プロセッサに以下のことを実施させるプログラムコード指示を備えるプログラムを提供してもよい。以下のこととは、マップデータを処理してマップデータから少なくとも１つの地図上の特徴を除去することにより、簡易化したマップデータのタイルを提供することと、マップデータのタイルにおいてタイルの境界を跨ぐ地図上の特徴に対して提供される少なくとも１つのエッジノードを規定することと、マップデータのタイルをゲームのプレイに使用されるユーザデバイスに提供することとである。
【００４６】
一態様によると、プロセッサによって実行されると、プロセッサに以下のことを実施させる指示を記憶するコンピュータ可読記憶装置を提供してもよい。以下のこととは、マップデータを処理してマップデータから少なくとも１つの地図上の特徴を除去することにより、簡易化したマップデータのタイルを提供することと、マップデータのタイルにおいてタイルの境界を跨ぐ地図上の特徴に対して提供される少なくとも１つのエッジノードを規定することと、マップデータのタイルをゲームのプレイに使用されるユーザデバイスに提供することとである。
【００４７】
一態様によると、プロセッサによって実行されると、プロセッサに以下のことを実施させるプログラムコード指示を含むプログラムを提供してもよい。以下のこととは、互いに隣接し、相互の間の境界を跨ぐ地図上の特徴に提供された少なくとも１つのエッジノードを含む少なくとも２つのマップデータのタイルを取得することと、マップデータのタイルの少なくとも一部をレンダリングしてレンダリング済みマップデータを提供することと、レンダリング済みのマップデータをユーザデバイスのディスプレイに出力することと、隣接したタイルのエッジノードを合致させることにより、ゲーム要素を地図上の特徴に沿って１つのタイルから隣接したタイルに移動させることとである。
【００４８】
一態様によると、プロセッサによって実行されると、プロセッサに以下のことを実施させる指示を記憶するコンピュータ可読記憶装置を提供してもよい。以下のこととは、互いに隣接し、相互の間の境界を跨ぐ地図上の各特徴に対して少なくとも１つのエッジノードを含む少なくとも２つのマップデータのタイルを取得することと、マップデータのタイルの少なくとも一部をレンダリングしてレンダリング済みマップデータを提供することと、レンダリング済みのマップデータをユーザデバイスのディスプレイに出力することと、隣接したタイルのエッジノードを合致させることにより、ゲーム要素を地図上の特徴に沿って１つのタイルから隣接したタイルに移動させることとである。
【００４９】
一態様によると、ユーザデバイスのディスプレイにある目的地を含むマップを表示することと、マップに表示される１つ以上のエンティティ（entity）を生成することと、エンティティのうちの１つを選択し、選択されたエンティティをマップのルートに沿って目的地まで案内することとを含む方法を提供する。
【００５０】
この方法は、ユーザデバイスの位置を判定することを含んでもよく、表示されるマップは、ユーザデバイスの位置に応じて決まる。
【００５１】
この方法は、マップをユーザデバイスの位置とともに表示することを含んでもよい。
【００５２】
表示されるマップは、現実のワールドマップの少なくとも一部であってもよい。
【００５３】
このマップは、他のユーザに関連付けられた１つ以上の他の目的地を有してもよい。
【００５４】
前記ルートは、マップの１つ以上の道路又は通路を含んでもよい。
【００５５】
前記目的地は、ユーザデバイスのユーザに関連付けられてもよい。
【００５６】
この方法は、エンティティが目的地に案内されたとき、報酬を提供することを含んでもよい。
【００５７】
前記１つ以上のエンティティは、ユーザデバイスによって生成されてもよい。
【００５８】
前記ディスプレイは、タッチスクリーンであってもよく、選択することは、選択対象のエンティティ上のタッチスクリーンをタッチすることを備えてもよい。
【００５９】
前記選択されたエンティティを案内することは、選択されたエンティティを、ユーザデバイスとのやりとり（interaction）によって規定されたルートに従わせることを備えてもよい。
【００６０】
前記案内することは、ユーザデバイスのコントローラにより、選択されたエンティティを目的地に案内することを含んでもよい。
【００６１】
一態様によると、目的地を含むマップを表示するように構成されたディスプレイと、ディスプレイのマップ上に表示される１つ以上のエンティティを生成するように構成されたコントローラと、入力部とを備え、エンティティのうちの１つ以上が選択され、選択された１つ以上のエンティティがマップのルートに沿って目的地に案内されるように構成された装置を提供する。
【００６２】
前記コントローラは、少なくとも１つのプロセッサと、１つ以上のプログラムのためのコンピュータコードを含む少なくとも１つのメモリとを備え、少なくとも１つのメモリとコンピュータコードとは、少なくとも１つのプロセッサと連携して、コントローラの１つ以上の機能を提供するように構成されてもよい。
【００６３】
この装置は、ユーザデバイスの位置を判定するように構成された位置判定機（location determiner）を備え、表示されるマップは、ユーザデバイスの位置に応じて決まるようにしてもよい。
【００６４】
前記ディスプレイは、マップをユーザデバイスの位置とともに表示するように構成されてもよい。
【００６５】
前記ディスプレイは、現実のワールドマップを少なくとも部分的に表示するように構成されてもよい。
【００６６】
前記ルートは、マップの１つ以上の道路又は通路を含んでもよい。
【００６７】
前記目的地は、ユーザデバイスのユーザと関連付けられてもよい。
【００６８】
前記コントローラは、エンティティが目的地に案内されたとき、報酬を提供するように構成されてもよい。
【００６９】
前記ディスプレイは、タッチスクリーンであってもよく、前記入力部は、あるエンティティを選択しようとするとき、その表示されたエンティティは、このディスプレイ上のそのエンティティが表示された位置をタッチすることによって選択されるように、タッチスクリーンによって提供されてもよい。
【００７０】
前記選択されたエンティティの案内は、選択されたエンティティをユーザデバイスとのやりとり（interaction）によって規定されたルートに従わせることを備えてもよい。
【００７１】
前記コントローラは、選択されたエンティティを目的地に案内するように構成されてもよい。
【００７２】
他の態様によると、プロセッサによって実行されると、プロセッサに以下の動作を実施させるプログラムコード指示を備えたプログラムを提供する。以下の動作とは、ユーザデバイスのディスプレイに目的地を含むマップを表示することと、マップに表示される１つ以上のエンティティを生成することと、選択されたエンティティを表示されたマップのルートに沿って目的地まで案内することとである。
【００７３】
他の態様によると、プロセッサによって実行されると、プロセッサに以下の動作を実施させる指示を記憶するコンピュータ可読記憶装置を提供する。以下の動作とは、ユーザデバイスのディスプレイ上に目的地を含むマップを表示することと、マップに表示される１つ以上のエンティティを生成することと、選択されたエンティティを表示されたマップのルートに沿って目的地まで案内することとである。
【００７４】
一態様によると、装置において、コンピュータ実行ゲームにおいて第２ユーザにより選択された、第１ユーザの同一性と関連付けられた項目を示す情報を、第２ユーザが使用中でコンピュータ実行ゲームを実施中のユーザデバイスから受信することと、前記情報を処理して第１ユーザの同一性を判定することと、第１ユーザに関連付けられたユーザデバイスに、項目の選択を示すメッセージを送信することとを含む方法を提供する。
【００７５】
前記項目は、マップ上の目的地と関連付けられてもよい。
【００７６】
前記情報は、目的地と関連付けられたマップ上の位置を示す情報と、項目を特定する情報と、目的地を示す情報とのうちの少なくとも１つを含んでもよい。
【００７７】
前記情報を処理して第１ユーザを判定することは、情報を使用して、装置のデータベース内に第１ユーザを見つけることを含んでもよい。
【００７８】
この方法は、項目を第２ユーザの同一性と関連付けることを含んでもよい。
【００７９】
この方法は、項目を、第２ユーザの同一性と関連付けられた１つ以上の目的地と関連付けることを含んでもよい。
【００８０】
この方法は、第１ユーザに関連付けられたユーザデバイスに送られるメッセージにおいて、第２ユーザに関連付けられた同一性情報を送信することを含んでもよい。
【００８１】
一態様によると、ユーザデバイスのユーザ入力部から受信した入力に応じて、第１ユーザと、ユーザデバイスで実行されているコンピュータ実行ゲームにおけるマップの第１目的地と関連付けられた項目について第２ユーザが行った選択を前記ユーザデバイスが検出することと、前記選択に応じて前記ユーザデバイスが、第２ユーザに関連付けられた１つ以上の第２目的地に関連付けられた前記項目を特定する情報をゲームサーバに送信することとを含む、方法を提供してもよい。
【００８２】
前記情報は、目的地に関連付けられたマップ上の位置を示す情報、項目についての情報、及び目的地を示す情報のうちの少なくとも１つを含んでもよい。
【００８３】
この方法は、第２ユーザに関連付けられた同一性情報をゲームサーバに送信することを含んでもよい。
【００８４】
一態様によると、装置であって、コンピュータ実行ゲームにおいて第２ユーザにより選択された第１ユーザの同一性に関連付けられた項目を示す情報を、第２ユーザが使用中でコンピュータ実行ゲームを実行中のユーザデバイスから受信するように構成された入力部と、前記情報を使用して第１ユーザの同一性を判定する少なくとも１つのプロセッサと、第１ユーザに関連付けられたユーザデバイスに前記項目の選択を示すメッセージを送信するように構成された出力部とを備える装置を提供してもよい。
【００８５】
前記項目は、マップ上の目的地に関連付けられてもよい。
【００８６】
前記情報は、目的地に関連付けられたマップ上の位置を示す情報、項目を特定する情報、及び目的地を示す情報のうちの少なくとも１つを備えてもよい。
【００８７】
この装置は、情報と第１ユーザとの間の関連性を記憶するデータベースを備えてもよく、前記少なくとも１つのプロセッサは、データベース内の第１ユーザを見つけるために情報を使用するように構成される。
【００８８】
前記プロセッサは、項目をデータベース内の第２ユーザの同一性と関連付けるように構成されてもよい。
【００８９】
前記プロセッサは、項目を第２ユーザの同一性と関連付けられた１つ以上の目的地と関連付けるように構成されてもよい。
【００９０】
前記プロセッサは、第２ユーザと関連付けるように構成された同一性情報をメッセージ内で提供されるようにしてもよい。
【００９１】
一態様によると、ユーザデバイス内の装置であって、第２ユーザである該デバイスのユーザからの入力を受信するように構成された入力部と、前記入力部によって受信された入力に応じて、第１ユーザと、コンピュータ実行ゲーム内のマップの第１目的地とに関連付けられた項目について第２ユーザが行った選択を検出する少なくとも１つのプロセッサと、第２ユーザの１つ以上の第２目的地に関連付けられた項目を特定する情報をゲームサーバに送信する出力部とを備えた装置を提供する。
【００９２】
前記情報は、目的地と関連付けられたマップ上の位置を示す情報、項目についての情報、及び目的地を示す情報のうちの少なくとも１つを含む。
【００９３】
前記少なくとも１つのプロセッサは、第２ユーザに関連付けられるように構成された同一性情報を出力によりゲームサーバに送信させてもよい。
【００９４】
一態様によると、ユーザインタフェースからの入力に応じて、コンピュータ実行ゲーム中の探索アルゴリズムを選択することと、表示されたコンピュータ実行ゲームのマップ上の位置にゲーム要素を提供するように構成された探索アルゴリズムを動作させて、項目の１つ以上のサブ項目がその位置に存在するか否かを判定することとを含む方法であって、前記選択、動作及び判定の各ステップを、前記項目の前記サブ項目のすべてが検出されるまで反復される方法を提供する。
【００９５】
この方法は、サブ項目のすべてが検出されたとき、その項目を異なるユーザによって選択できるようにすることを含む。
【００９６】
この方法は、サブ項目のすべてが検出されたとき、その項目を異なるユーザによって選択できるようにするサーバに情報を送信することを備えてもよい。
【００９７】
一態様によると、ユーザデバイスのユーザから入力を受信するように構成された入力部と、ディスプレイと、入力部からの入力に応じて、コンピュータ実行ゲーム内の探索アルゴリズムを選択し、該探索アルゴリズムは、表示されたコンピュータ実行ゲームのマップ上の位置にゲーム要素が提供されるようにディスプレイを制御するように構成され、該探索アルゴリズムを動作させて、項目の１つ以上のサブ項目がその位置に存在するか否かを判定するプロセッサとを備えたユーザデバイス内の装置であって、前記選択、動作、及び判定は、前記項目のサブ項目のすべてが検出されるまでプロセッサによって反復される装置を提供する。
【００９８】
前記プロセッサは、サブ項目のすべてが見つけられたとき、項目を異なるユーザによって選択できるように構成されてもよい。
【００９９】
この装置は、送信機を備えてもよく、サブ項目のすべてが見つけられたとき、送信機は、項目を異なるユーザが選択できるようにする情報をサーバに送信するように構成される。
【０１００】
プロセッサに搭載されると、プロセッサにこの方法を実施させるように制御するプログラムコード手段を備えたコンピュータプログラム製品も提供してもよい。以下の詳細な説明及び添付の請求項において、その他の種々の態様及びさらなる実施形態も説明する。
【図面の簡単な説明】
【０１０１】
以下に、添付の図面を参照して、いくつかの実施形態を例示のみを目的として説明する。
【０１０２】
【図１】キャッシュされたマップタイルがユーザデバイスのある位置において利用可能であるか否かを判定する方法のフロー図である。
【図２】図１のフロー図の１つの分岐をより詳細に示す図である。
【図３】図１のフロー図の他の分岐をより詳細に示す図である。
【図４】マップ上のユーザデバイスの位置を表示する方法を示す図である。
【図５】ゲーム要素を表示及び制御する方法を示す図である。
【図６】図５の方法で表示された画像を示す図である。
【図７】接近モード及び非接近モードを備えた方法を示す図である。
【図８】ゲーム内で構築を行う方法を示す図である。
【図９】ユーザデバイスを模式的に示す図である。
【図１０】実施形態が提供されうるシステムを模式的に示す図である。
【図１１】マップデータの処理方法を示す図である。
【図１２】ユーザデバイスにおける処理済みマップデータの使用方法を示す図である。
【図１３】マップデータの処理をサポートする装置を模式的に示す図である。
【図１４】２つの隣接したタイルを模式的に示す図である。
【図１５ａ】マップを簡易化するための一例としての多角形低減を示す図である。
【図１５ｂ】マップを簡易化するための一例としての多角形低減を示す図である。
【図１６】いくつかの実施形態において使用されるデータ構造を模式的に示す図である。
【図１７】１人のユーザに関連付けられた項目を他のユーザが選択する方法を示す図である。
【図１８】項目の複数のサブ項目を収集する方法を示す図である。
【発明を実施するための形態】
【０１０３】
一実施形態に係るユーザデバイス又は演算装置２００の模式図を図９に示す。図示のブロックはすべて、好適な回路によって実現される。各ブロックは、ハードウェア及び／又はソフトウェアで実現されてもよい。ユーザデバイスは、コントローラ２１０を有してもよい。コントローラ２１０は、１つ以上のプロセッサ２１５と、１つ以上のメモリ２２０とを有する。コントローラ２１０はまた、グラフィックスコントローラ２２５及びサウンドコントローラ２３０を有するものとして示されている。グラフィックスコントローラ２２５及びサウンドコントローラ２３０の一方、他方、又は両方は１つ以上のプロセッサ２１５によって提供されてもよいことは勿論である。
【０１０４】
グラフィックスコントローラ２２５は、動画出力２３５を提供するように構成される。サウンドコントローラ２３０は、音声出力２４０を提供するように構成される。コントローラ２１０は、インタフェース２４５を有し、デバイスが、インターネット又はその他の通信インフラ等のネットワーク２５０で通信できるようにする。
【０１０５】
動画出力２３５は、ディスプレイ２５５に提供される。音声出力２４０は、スピーカーやイヤホン等のオーディオデバイス２６０に提供される。
【０１０６】
装置２００は、入力装置２６５を有する。入力装置２６５は、任意の好適な形式を採ることができ、キーボード、マウス、タッチスクリーン、ジョイスティック、又はゲームコントローラのうちの１つ以上とすることができる。ディスプレイ２５５は、いくつかの実施形態において、例えば、一体型タッチスクリーンにより入力装置２６５も提供してよい
ことは勿論である。
【０１０７】
コントローラ２１０のブロックは、バス等の相互接続、又はその他任意の好適な相互接続、及び／又はポイント間通信によって互いに通信するように構成される。
【０１０８】
いくつかの実施形態において、コントローラ２１０は、少なくとも部分的に、１つ以上の集積回路によって実行されてもよいことは勿論である。
【０１０９】
ユーザデバイス２００は、例示のみを目的として示されている。代替の実施形態において、１つ以上の部品が省略されてもよい。代替又は追加として、いくつかの実施形態では、１つ以上の他の部品を備えてもよい。代替又は追加として、１つ以上の部品が組み合わせられてもよい。
【０１１０】
図３は、いくつかの実施形態におけるシステム３００を模式的に示している。システム３００は、ゲームプレーヤーの詳細、プロフィール、及びゲームデータのデータベースを記憶するサーバ３２０を備える。実際には、１つ以上のデータベースが提供されてもよい。２つ以上のサーバが提供される場合、データバースは、１つのデータベースに設けられてもよく、又は２つ以上のサーバ３２０に設けられてもよい。サーバ３２０は、ゲームデータ機能も有してよい。これは、コンピュータゲームプログラムを記憶するメモリと、ゲームプログラムを動作させるプロセッサとを備えてもよい。
【０１１１】
サーバは、例えば、インターネット３１０を介して、１つ以上のユーザデバイス３０５と通信してもよい。実施形態は、異なるシステム構造で展開されてもよいことは勿論である。例えば、コンピュータゲームは、ユーザデバイス２００のメモリ２２０に記憶され、ユーザデバイス２００のプロセッサ２１５上で動作するコンピュータゲームとして実現されてもよい。しかしながら、サーバ３２０は、いくつかの実施形態において、ゲームのいくつかの要素を取り扱ってもよい。単なる例示であるが、Ｊａｖａ（登録商標）ゲームアプレットをユーザデバイス２００に提供してもよく、Ｊａｖａアプレットの局所的動作により、例えば、ユーザデバイス２００上のゲームプレイの際のグラフィックス、サウンド、及びユーザ操作機能（user interaction）を生成する。一部のデータは、サーバ３２０に戻され、他のプレーヤー３０５との交信（interaction）を可能にしてもよい。
【０１１２】
いくつかの実施形態において、ゲームは、例えば、サーバ３２０等のシステムのメモリに記憶され、ゲームサーバのプロセッサ上で動作するコンピュータプログラムとして実現されてもよい。データストリーム又はアップデートがユーザデバイス２００に供給されることにより、ユーザデバイス２００は、ユーザデバイス２００のブラウザ内のグラフィックス及びサウンドをレンダリングし表示する。この代替又は追加として、ゲームの１つ以上の態様は、ユーザデバイスのコントローラによって制御されてもよい。
【０１１３】
好適な実施形態において、ユーザデバイスはモバイルデバイスであってもよく、ゲームのいくつかの態様はユーザデバイスの位置に関連してもよい。しかしながら、いくつかの実施形態において、モバイルデバイスが使用されなくてもよいことは勿論である。
【０１１４】
図１を参照する。ステップＳ１において、ユーザデバイスの位置を判定（determine）する。いくつかの実施形態において、ユーザデバイスの座標情報を判定してもよい。このステップでは、任意の好適な位置判定技術を使用してもよい。いくつかの実施形態では、ＧＰＳ、ＧＬＯＮＡＳＳ、Ｇａｌｉｌｅｏ等、衛星ベース位置判定技術を使用してもよい。代替又は追加として、他の位置ベース技術を使用してもよい。例えば、モバイルテレコミュニケーションネットワークからの位置情報を使用してもよい。
【０１１５】
ステップＳ２において、ユーザデバイスの現在位置を含むマップが利用可能であるかを判定する。特に、現在位置を含むマップタイルが記憶されているか否かを確認するために、この判定がなされる。
【０１１６】
いくつかの実施形態において、マップ情報はマップタイルによって提供されてもよい。各マップタイルは、地理的領域をカバーしていてもよい。いくつかの実施形態において、隣接したマップタイルは、各々、その２つの隣接したタイルの境界間の重複部分を提供するため、同一情報部分を含んでもよい。他の実施形態において、隣接したタイル間の重複領域がなくてもよい。
【０１１７】
各タイルは、そのタイルに含まれる座標の範囲を規定する範囲情報で規定されてもよい。その判定は、ユーザデバイスの座標がいずれかのタイルの範囲に収まるか否かの判定を含んでもよい。ユーザデバイスの座標が２つ以上のタイルの範囲に収まっている場合、タイル縁部からさらに遠く離れてユーザデバイスの座標を有するタイルを選択してもよい。
【０１１８】
現在位置を含むマップタイルが既に記憶されていると判定された場合、図２に示す方法を実施する。一方、メモリに記憶した現在位置を含むマップがないと判定された場合、図３の方法を実施する。
【０１１９】
マップ情報又はタイルは、キャッシュメモリ又はその他任意の好適なメモリに記憶されてもよい。
【０１２０】
図２を参照する。ステップＴ１において、キャッシュマップタイルが少なくとも部分的に表示される。
【０１２１】
ステップＴ２において、追加マップ情報が要求されるか否かを確認する判定を行う。これは、例えば、マップタイルに対するユーザデバイスの位置に応じて実施されてもよい。例えば、ユーザデバイスがキャッシュマップタイルの縁部領域に位置している場合、追加マップ情報が必要であり、追加マップ情報は既に記憶されているマップタイル内にないと判定されうる。
【０１２２】
いくつかの実施形態において、ユーザデバイスが移動する方向についての判定が行われてもよく、これにより、追加マップ情報が必要であると判定が行われうる。
【０１２３】
追加情報マップ情報が必要であると判定された場合、ステップＴ３において、追加マップ情報がリクエストされる。いくつかの実施形態において、このリクエストにはゲーム情報のリクエストも含まれてよい。
【０１２４】
ステップＴ５において、アップデート済みのマップ情報が受信され、任意で表示されてもよい。
【０１２５】
追加情報がリクエストされ受信されるこのような実施形態においては、少なくともいくつかの追加情報も表示されてよい。
【０１２６】
一方、追加マップ情報が必要ないと判定された場合、ユーザデバイスは、ステップＴ４において、ゲームサーバからのゲームアップデートを要求してもよい。
【０１２７】
ステップＴ６において、受信したゲーム情報の少なくとも一部を表示してもよい。
【０１２８】
ステップＴ７において、新たなマップデータと任意で追加情報をメモリに記憶してもよい。
【０１２９】
いくつかの実施形態において、図２に示すステップは任意の好適な順に実施されてもよいことは勿論である。例えば、新たなデータの記憶は、データ受信直後に行われてもよい。いくつかの実施形態において、キャッシュマップの表示は、任意の追加マップ情報が必要か否かに関して判定が行われた後にのみ、行われてもよい。
【０１３０】
いくつかの実施形態において、ユーザデバイスは、アップデート済みのゲーム情報を具体的に要求しない。代わりに、サーバが、ユーザデバイスに対してアップデート済みのゲーム情報をプッシュ配信する。
【０１３１】
図３は、現在位置を含むマップがないと判定されたときに実施されるステップを示す。ステップＡ１において、ユーザデバイスは、サーバに対しマップデータの送信を要求する。
【０１３２】
ステップＡ２において、ユーザデバイスは、リクエストしたマップデータをサーバから受信する。Ａ３において、受信したマップデータを表示し記憶する。
【０１３３】
追加マップデータが必要であるこのような実施形態においては、ユーザ装備から送信される情報には、判定されたユーザデバイスの位置が含まれてもよいことは勿論である。
【０１３４】
図４を参照する。ステップＢ１において、マップデータに対するユーザデバイスの位置についての判定を行う。これは、ユーザデバイスの座標を使用し、ユーザデバイスの座標をマップタイル座標と比較することによって実施してもよい。
【０１３５】
ステップＢ２において、ユーザデバイスは、表示されたマップデータ上に重ねて表示される。いくつかの実施形態においては、ユーザデバイスの位置は表示されない。
【０１３６】
いくつかの実施形態において、マップは最初に、表示されたマップの中央にユーザデバイスを配置した状態で、ディスプレイに表示される。この場合、ユーザデバイスの位置を表示してもよく、ユーザデバイスを表示しなくてもよい。
【０１３７】
図４のステップは、例えば、マップの表示に先立って任意のステップとともに実施されてもよい。
【０１３８】
従って、マップデータは、タイルの形式でメモリに記憶される。いくつかの実施形態において、ゲームデータは、マップ画像をレンダリングするために局所的に記憶されたマップデータを使用する。マップデータは、静的データであり、１層で提供される。
【０１３９】
いくつかの実施形態において、静的マップデータは、道路、公園、水域、農地、及び／又はその他のデータを備えてもよい。いくつかの実施形態において、マップデータは、建造物データを含まなくてもよい。その他の実施形態において、マップデータは、重要ランドマーク等、いくつかの建造物データを含むことができる。
【０１４０】
ゲームデータは、別個に記憶され、マップデータの上に重ねられた他の層で提供される動的データである。ゲームデータ及びマップデータは、別個に記憶される。ゲームデータは、マップデータに対して規定される座標の形式であってもよい。ゲーム要素の座標を使用して、ゲーム要素をマップ上に表示する。ゲーム要素は、建造物、エンティティ等であってもよい。いくつかの実施形態において、マップデータに対するユーザデバイス座標が判定され記憶される。
【０１４１】
いくつかの実施形態において、サーバのみが動的ゲームデータのアップデートを提供できるような機構が設けられてもよいことは勿論である。これは、例えば、ユーザデバイスがゲームサーバに動的ゲームデータが最後にアップデートされた時間を示す情報を提供することによって達成されてもよい。これは、例えば、プレーヤーがゲームにサインインしたときに、又は周期的になされてもよい。代替又は追加として、サーバは、周期的にゲームデータをユーザデバイスにプッシュ配信してもよい。ユーザデバイスにデータをプッシュ配信することは、サーバが現在ゲーム中でないユーザデバイスにデータをプッシュ配信するのを試みることがないように、ハンドシェイク手順後のみに実施してもよい。
【０１４２】
いくつかの実施形態において、所定数のマップタイルまで記憶するようにメモリが設けられてもよい。タイルは、直近の使用に応じて記憶されてもよい。例えば、記憶すべきより最近のマップタイルが存在する場合、直近に使用されたｎ個のタイルを最も古いマップタイルに上書きして記憶してもよい。いくつかの実施形態において、代替又は追加として、マップタイルには使用頻度に応じた重みづけがなされてもよい。
【０１４３】
いくつかの実施形態において、３レベルのタイルキャッシュがあってもよい。
【０１４４】
レベル１−タイルがゲーム場面中にゲーム対象物（game object）として存在するものの、隠れている。ここでタイルは、生成されてロード時に追加されたすべての幾何学要素及びゲームプレイ要素を含む。いくつかの実施形態において、可視タイルにさらに全半径方向の２つのタイルを加えたもの（例えば、５×５個のタイル）が保存される。いくつかの実施形態において、ここでは可視性以外の優先順位付けは行われない。
【０１４５】
レベル２−メモリキャッシュ。これは、設定された最大容量を有してもよい。これは、優先度、重みづけ、及び／又は最終使用コレクションで非直列化した（ゲームで使用可能なデータ構造である）タイルデータを保存する。
【０１４６】
レベル３−ディスクキャッシュ。これは、設定された最大容量を有し、ディスク又はメモリ上の直列化した（すなわち生のバイトである）タイルデータオブジェクトにデータを記憶する。これは、優先度、又はこれらのディスク項目の優先度を追跡する重みづけコレクションを有してもよい。タイル優先度をディスクに書き込み、ゲームアプリケーションが閉じられても、重みづけ又は優先度がセッションを超えて保持できるようにしてもよい。
【０１４７】
優先順位付けは、レベル２及びレベル３で同一の方法又は異なる方法で行われてもよい。一実施形態において、優先順位付けは、以下の通り実施される。
・各タイルに２つの値、すなわち時間及び頻度が与えられる。
・時間は、タイルが最後にアクセスされてからの時間である。
・頻度は、どの程度頻繁にそのタイルがアクセスされるかである。
・タイルがアクセスされる度に、頻度は、例えば５又はその他任意の好適な値ずつ増え、時間は０にリセットされる。
・任意で、タイルリクエストの度に、又は優先度コレクションに何かが追加されたときに、優先度コレクションは「古くなる」。コレクションが古くなったとき、コレクションの各項目は、その時間が増え、頻度が５ずつ減る。
・項目が優先度コレクションに追加されると、これらの項目はその優先度の順に分類される。コレクションが最大容量に達すると、最下位、すなわち最低優先度の項目を除外する。そして新たな項目がデフォルト優先度で挿入される。
・各タイルの優先度は、任意の好適な方法で規定されてもよく、例えば、頻度＋（１０／時間＋１）であってもよい。
【０１４８】
図５及び図６を参照する。図６は、ユーザデバイスに表示された領域６００を示している。このエリアは、本例ではいくつかの道路を有する様子が示されたマップを表示している。このマップには、後に詳述する目的地６０６も含んでよい。
【０１４９】
図６に示す例において、ユーザデバイスはタッチスクリーンを有する。しかしながら、他の実施形態では他の種別のスクリーンが使用されてもよいことは勿論である。移動エンティティ６０４もマップ上に表示される。これらの移動エンティティ６０４は、ユーザデバイス上で動作するゲームソフトウェアによって生成される。いくつかの実施形態において、エンティティの数及び／又は位置は、疑似ランダムに生成される。他の実施形態において、エンティティの数及び／又は位置は、所定パターンに従い、且つ／又は、１つ以上のゲーム因子に影響される。これらのエンティティは、スクリーンを横切って移動する。
【０１５０】
図６とともに図５を参照する。ステップＣ１において、ユーザ入力が解析される。
【０１５１】
ステップＣ２において、ユーザ入力が移動エンティティ６０４の１つを選択しているか否かを判定する。通常、これは、特定の移動エンティティの表示ポイントのタッチスクリーンをタッチしたか否かの判定である。代替又は追加として、これは、カーソル等を制御するポインタデバイス及び選択入力を使用して達成されてもよい。例えば、カーソルは、マウスによって移動可能にし、選択入力は、マウスクリックによって達成されてもよい。
【０１５２】
ステップＣ３において、ユーザ入力の移動が判定され、選択されたエンティティをユーザ入力で規定された進路に従わせる。タッチスクリーンの場合、エンティティを、タッチスクリーン上でのユーザの指の移動によって規定された進路に従わせる。
【０１５３】
ステップＣ４において、マップに対してユーザ入力で発生させたエンティティの移動が判定される。特に、エンティティが規定ルート６０２に沿って移動されたか否かを判定する。移動されていない場合、エンティティはもはや表示されていないか、入力された進路に従っていない。
【０１５４】
ステップＣ５において、エンティティが目的地６０６まで移動されたか否かを判定する。ステップＣ３、Ｃ４、及びＣ５は、エンティティが目的地に移動するまで、又はステップＣ４においてエンティティが規定ルートに沿って移動していないと判定されるまで反復して実施されてもよいことは勿論である。
【０１５５】
１つの変形例において、ユーザがエンティティをドラッグして規定ルート又は許可ルートから外そうと試みたとしても、エンティティは規定ルート又は許可ルート（道路、歩道等）を外れることができない。
【０１５６】
図５に関連して説明した方法の１つの変形例において、ユーザデバイスのユーザがエンティティを選択しさえすれば、そのエンティティは目的地に移動することができる。このエンティティは、任意の好適な方法で選択されてもよく、一実施形態においては、タッチスクリーン装置の場合、そのエンティティをタップ又はダブルタップすることによって選択される。いくつかの実施形態において、ユーザは、エンティティを選択するために３回以上そのエンティティをタップする必要があってもよい。
【０１５７】
この実施形態において、エンティティは、規定進路に沿って目的地まで移動するように制御される。ユーザデバイスのユーザでなく、ユーザデバイスのコントローラは、タイル状マップのマップ情報を使用してエンティティの進路をプロットするように構成され、それによりエンティティが表示されて、表示されたマップの規定ルートに沿って移動するように制御される。規定ルートは道路等であり、エンティティは常に、許可されたルート上に表示されるように制御されてもよい。
【０１５８】
エンティティは、コントローラによって設定された進路に従ってもよい。いくつかの実施形態において、コントローラは道路がマップ上にいかにレイアウトされているかを詳細に示すマップデータを使用してもよい。道路の各セグメントを使用して進路が構築され、送られて、エンティティがそれに従う。
【０１５９】
目的地に向かうエンティティは、マップデータ中の道路グラフを使用して自らの道を見つける。コントローラは、Ｄｉｊｋｓｔｒａアルゴリズム又はその他任意の好適なアルゴリズムを使用して、目的地までの最短経路を見つける。この進路が一旦計算されると、これを使用してエンティティの従う進路を制御する。
【０１６０】
エンティティがユーザの指の移動によって手動でドラッグされると、道路にドラッグがなされたことを確認するため、マップデータからの道路データを使用してこのドラッグを検証する。指によるドラッグが道路を外れていた場合、指が道路に戻るまで何も発生しない。指が一旦離されると、構築された進路を使用してエンティティを案内する。
【０１６１】
エンティティがコントローラの制御の下で移動し、まだユーザによる選択がなされていないとき、コントローラは、それらのエンティティを最も近い道路接続点（曲がり角又は交差点等）に向かわせ、エンティティを制御する進路としてそれを引き渡す。エンティティがこの位置に一旦到着すると、コントローラは、他の道路セグメントを歩くようにランダムに選択する。行き止まりであった場合、エンティティは、新たな道路接続点に着くまで同じ道を引き返す。
【０１６２】
いくつかの実施形態において、所定期間内にドラッグ可能なエンティティの数が限定されてもよい。いくつかの実施形態において、ユーザは、ソーシャルネットワークを介してゲームとやりとり（interact）し、ユーザの友人からより多くのエンティティをリクエストしてもよい。いくつかの実施形態において、ユーザは、ゲーム通貨又は現実のお金を使用してさらなるエンティティを購入可能であってもよい。
【０１６３】
エンティティの座標は、上述の通り、マップデータから別個に規定されることは勿論である。いくつかの実施形態において、座標データが記憶され、且つ／又は、エンティティの動きを規定する移動データが記憶されて、エンティティのゲームデータがマップデータと組み合わされて表示されると、エンティティが道路等の規定ルートに沿って移動して示される。いくつかの実施形態において、エンティティは、ユーザデバイスのコントローラによって生成される。他の実施形態において、エンティティは、ゲームサーバの制御の下、生成されてもよい。いくつかの実施形態において、エンティティは、通常、ユーザデバイスの制御の下で生成されてもよいが、状況によっては、サーバの制御の下で追加のエンティティが生成されてもよい。これは、例えば、追加のエンティティを有するプレーヤーに対する報酬であってもよい。
【０１６４】
いくつかの実施形態において、ユーザは、ユーザデバイスの位置に関わらず、ゲームをプレイできる。
【０１６５】
ステップＤ１において、ユーザは、接近ベースモードと非接近ベースモードを選択できる。いくつかの実施形態において、ユーザデバイスは、１つ以上の条件により、モードの一方を自動選択するように構成されてもよい。例えば、ユーザ装備が利用可能な位置情報を有していない場合、非接近ベースモードが選択されてもよい。例えば、ユーザデバイスは、飛行機モード等であってもよい。
【０１６６】
いくつかの実施形態において、モードは、ユーザデバイスの位置によって選択されてもよい。例えば、ユーザデバイスがそのホーム位置にあるとき、デフォルトモードが非接近ベースモードであってもよい。或いは、ホーム位置にあるとき、接近ベースモードがデフォルトモードであってもよい。いくつかの実施形態において、ユーザデバイスがその位置に最後にあったときに選択されたモードに関する情報を記憶し、ユーザデバイスがその位置にあるとき、選択モードが以前のモードとなるようにしてもよい。
【０１６７】
従って、いくつかの実施形態において、モード選択は、ユーザデバイスによってなされてもよい。
【０１６８】
いくつかの実施形態において、ユーザがユーザデバイスの入力を介してモードを選択してもよい。
【０１６９】
いくつかの実施形態において、ユーザデバイスによってモードが選択される場合、ユーザはデフォルトモードを覆すことができることは勿論である。
【０１７０】
ステップＤ２の接近ベースモードは、例えば、少なくとも図１との関連で説明したようなモードであってもよい。
【０１７１】
ステップＤ３において、非接近ベースモードが選択された場合、表示すべきマップが選択される。表示されるマップは、デフォルトマップであってもよい。いくつかの実施形態において、デフォルトオプションは、単に、前回使用されたマップであってもよい。
【０１７２】
或いは、ユーザには、選択可能なオプションのリストが提供されてもよい。いくつかの実施形態において、利用可能なマップのリストが、使用頻度の順、又は最終使用日の順に表示されてもよい。
【０１７３】
図８は、ゲームのプレーヤーが目的地を得られる方法を示す。図示の例において、目的地は建造物である。ステップＥ１において、ユーザが建造物モードを選択したことを判定する。これは、ユーザとデバイスの入力部とのやりとり（interaction）の検出である。
【０１７４】
ステップＥ２において、ユーザとのやりとりによって、ユーザ入力を介して受信した情報に基づいて、建造物の位置が判定される。タッチスクリーンの場合、これは、ユーザがマップ上での建造物の位置をタッチすることによって提供されてもよい。
【０１７５】
ステップＥ３において、ユーザが建造物を有するのに十分なゲーム通貨を有しているか否かを判定する。ゲーム通貨は、ゲームのプレイを通じて取得されるか、又は購入されるポイントであってもよい。いくつかの実施形態において、このステップは任意であってもよいことは勿論である。いくつかの実施形態において、ディスプレイは、ユーザに１つ以上の利用可能な建造物オプションを表示できてもよいことは勿論である。いくつかの実施形態において、利用可能な建造物のオプションは、関連するゲーム通貨の値を有してもよい。ユーザは、ユーザ入力とのやりとりにより、建造物オプションを選択する。このステップは、いくつかの実施形態においては任意であってもよく、ゲームプレイの何らかのモードによって任意であってもよい。
【０１７６】
ステップＥ４において、ユーザによって選択されたマップ上の位置が空いているか、又は要求された建造物を収める空間があるか否かを判定する。いくつかの実施形態において、建造物モードは、その位置が利用可能か否かについてゲームソフトウェアが最新の判定を行うことができるように、ユーザデバイスが有している情報が最新であることを確認するため、サーバとライブ交換を行う必要があってもよい。
【０１７７】
いくつかの実施形態において、ステップＥ４は、ステップＥ５の前に行われるか、これらの２つのステップが同時に実施されてもよい。
【０１７８】
ステップＥ５において、ユーザが十分なゲーム通貨を有し、その位置が空いていることを確認した上で、建造物をディスプレイに表示する。
【０１７９】
建造物についての情報は、ベースとなる静的マップデータに重ねて表示されうる動的ゲームデータに含まれる。
【０１８０】
情報は、ゲームサーバに送られ、建造物の位置と種別を確認する。
【０１８１】
いくつかの実施形態において、ユーザには、建造物又は目的地の目的について２つ以上のオプションが提供されてもよい。例えば、建造物は、店、カフェ又はレストラン、オフィス、住宅、又はその他の好適なオプションであってもよい。いくつかの実施形態において、ユーザは、特定の店種別を選択できてもよい。いくつかの実施形態において、同一種別の建造物又は目的地のクラスタ（一群）がクラスタ位置又は地理的位置に提供されてもよい。この実施形態において、デバイスのユーザは、建造物又は目的地の種別の選択肢がなくてもよい。例えば、カフェのクラスタが提供されてもよい。
【０１８２】
いくつかの実施形態において、店等へエンティティをドラッグすることにより、結果として、そのプレーヤーのゲームデータがアップデートされ、ポイント及び／又はゲーム通貨を生じてもよい。
【０１８３】
目的地は、商業目的を有してもよく、又は非商業目的のみを有してもよいことは勿論である。
【０１８４】
いくつかの実施形態において、いくつかの目的地は、慈善目的を有してもよい。例えば、慈善活動が目的地と関連付けられてもよく、エンティティを慈善活動目的地にドラッグすることにより、結果として、その慈善活動のための現実の収益を生じてもよい。
【０１８５】
このファンドレイジングの方法は、非慈善的事例で使用されてもよく、例えば、特定の事業ベンチャー等のための資金を集めてもよいことは勿論である。
【０１８６】
いくつかの実施形態において、建造物モードは、接近状況においてのみ利用可能であってもよい。
【０１８７】
いくつかの実施形態において、ユーザデバイスの位置に応じて、建造物を建てることのできる場所に地理的制限があってもよい。いくつかの実施形態において、ユーザは、ユーザデバイスから半径ｘメートルの範囲内に建造物を得るように許可されてもよい。他の実施形態において、この制限は、１つのタイル内、又はｙ個の隣接タイル内に規定されてもよい。他の実施形態において、この制限は、メモリに記憶又はキャッシュされたタイルによって規定されてもよい。例えば、ユーザは、現在のタイル又は記憶されたメモリタイル内にある場合にのみ、その建造物を得ることができる。いくつかの実施形態において、上述の制限の１つ以上が組み合わせられてもよい。例えば、ユーザは、自身の現在位置からｘメートルの範囲内の位置であるか、記憶されたマップタイル内の位置であれば、建造物を得ることができる。
【０１８８】
ゲームプレイに関連付けられた建造物データは、動的ゲームデータ内に記憶されてもよい。
【０１８９】
いくつかの実施形態において、目的地は１つ以上のリソースを要求してもよい。単なる例示として、カフェがコーヒーを要求してもよく、バーガー屋が肉とパンを必要としてもよい。いくつかの実施形態において、ユーザデバイスのコントローラは、リソースを発生又は提供するように構成されてもよい。代替又は追加として、サーバは、リソースの発生又は提供を制御するように構成されてもよい。いくつかの実施形態において、リソースは、ランダムに発生されてもよい。代替又は追加として、リソースは、定期的に発生されてもよい。代替又は追加として、プレーヤーに使用されるリソースは、より頻繁に発生されてもよい。いくつかの実施形態において、プレーヤーによって使用されるリソースが増やされ、プレーヤーに報酬を与えたり、インセンティブを与えたりしてもよい。いくつかの実施形態において、リソースは、現実の通貨又はゲーム通貨で購入できてもよい。
【０１９０】
一実施形態において、１つ以上のリソースがエンティティと同様に制御されてもよい。
【０１９１】
他の実施形態において、建造物は、要求された１つ以上のリソースを獲得するために制御可能な１つ以上の従業員又は同様の種別のエンティティを有してもよい。ルートは、１つ以上のエンティティに対して規定可能である。コレクションは、例えば、従業員型エンティティをタップするか、１つ以上のリソースをタップするか、リソースコレクションオプションを選択することにより、任意の好適な方法で始動することができる。
【０１９２】
リソースは、そのリソース上をタップすることにより、又はそのリソースを選択することによってルートに追加できる。いくつかの実施形態において、ユーザは、収集対象のリソースを選択することができる。コントローラは、リソースの収集のために従業員型エンティティに従わせるルートを判定する。いくつかの実施形態において、ユーザは、自身の指をルートに沿ってドラッグするか、又はその他任意の好適な方法で従業員型エンティティを従わせるルートを規定するように構成される。いくつかの実施形態において、このルートは記憶され、次回リソースが収集される際に使用されてもよい。上述の通り、このルートが修正され、１つ以上の追加のリソースをピックアップさせてもよい。修正ルートがデフォルトモードとして記憶される。
【０１９３】
いくつかの実施形態において、プレーヤーは、選択位置に既に存在している建造物に少なくとも１つの床を追加するよう許可される。そして異なるプレーヤーは、建造物に異なる床を有してもよい。いくつかの実施形態において、プレーヤーは、建造物に２つ以上の床を有することが許可される。
【０１９４】
いくつかの実施形態において、２つ以上の目的地を兼ねる位置にドラッグされたエンティティは、ポイント又はゲーム通貨を各目的地へシェアさせてもよい。
【０１９５】
ポイント又はゲーム通貨のシェアは、均等であってもよく、又はその他任意の好適な方法で分割されてもよいことは勿論である。
【０１９６】
いくつかの実施形態において、目的地はカテゴリに分けられてもよい。エンティティは、１つ以上の好適な目的地カテゴリを有してもよい。ユーザがエンティティをその好適な目的地カテゴリに合致する目的地に案内すると、ゲームソフトウェアは、プレーヤーに特別報酬又は追加ポイントを提供してもよい。いくつかの実施形態において、エンティティの好適な目的地カテゴリは、プレーヤーから隠される。いくつかの実施形態において、好適な目的地カテゴリは、プレーヤーに明らかにされてもよい。例えば、エンティティは、カラーコードされるか、又はタグ付けされてもよい。一実施形態において、エンティティはバルーンを有してもよく、バルーンの色が好適な目的地カテゴリを示してもよい。
【０１９７】
いくつかの実施形態において、ユーザデバイスのコントローラは、好適な目的地カテゴリをランダムに選択するように構成される。いくつかの実施形態において、コントローラは、ユーザが所定の要件（criteria）を満たす場合、そのユーザの目的地の１つ以上に合致する好適な目的地カテゴリをより多くのエンティティに提供するように構成されてもよい。所定の要件は、所有の建造物数、ゲームのプレイ時間等、１つ以上の要件を満たすことであってもよい。代替又は追加として、所定の要件は、所有の建造物数、ゲームのプレイ時間等、１つ以上の指標を満たさないことであってもよい。
【０１９８】
ゲームのいくつかの実施形態において、すべてのプレーヤーが同一の世界でプレイを行う。いくつかの実施形態において、比較的多数のプレーヤーが存在してもよい。ユーザデバイスに多数のアップデート及び／又は高容量のアップデートを与えなければならないことを回避するため、いくつかの実施形態では、疑似ライブ環境で動作してもよい。プレーヤーは、データのすべてが現実のデータ及び／又は最新のデータでないが、自身がプレイしている世界がライブであると知覚する。いくつかの実施形態において、他のユーザのアクションを考慮に入れるためにアップデートの必要があるデータである動的ゲームデータであることは勿論である。
【０１９９】
いくつかの実施形態において、これは、周期的にのみアップデートされた情報を送信することによって達成されてもよい。
【０２００】
いくつかの実施形態において、ユーザデバイスのユーザがリフレッシュを要求できるようにしてもよい。これにより、ユーザデバイスのユーザにリフレッシュの数及び頻度を制御させてもよい。
【０２０１】
いくつかの実施形態において、リフレッシュは、一定期間後に実施されてもよい。
【０２０２】
いくつかの実施形態において、リフレッシュは、一定期間後に実施されてもよいが、ユーザデバイスのユーザは、リフレッシュを要求し実施することができる。
【０２０３】
リフレッシュは、サーバがユーザデバイスにアップデート情報を提供することである。アップデート情報は、利用可能なすべてのアップデートを含むことができるか、又は利用可能なアップデートのサブセットであってもよい。
【０２０４】
いくつかの実施形態において、これは、小さな地理的領域に関するアップデート情報を提供することによって達成されてもよい。
【０２０５】
いくつかの実施形態において、これは、アップデート情報を受信した後一定の時間をかけてこのアップデート情報を適用することにより、データが徐々に変化して見えるように行ってもよい。
【０２０６】
一実施形態において、アップデート情報のファイルをサーバから受信する。このファイルは、任意の好適な形式であってもよく、一実施形態において、ＸＭＬファイルの形式であってもよい。ユーザデバイスのコントローラは、受信したファイル中にイベントの列を作るように構成され、一定の時間をかけてこのアップデートを適用する。これにより、リアルタイムのアップデートを必要とせず、ユーザからはライブプレイのように見える。そしてユーザは、ゲームのプレイ中、他の建造物が他のユーザによってアップデート又は取得されるのを見ることができる。
【０２０７】
いくつかの実施形態において、局所的に記憶されたソフトウェアは、予測可能アルゴリズムに基づいて疑似アップデート情報を生成してもよい。この場合、情報は、ゲームサーバからの現実ゲーム情報に応じてアップデートされてもよい。
【０２０８】
図１１にマップデータの処理を示す。
【０２０９】
ステップＦ１において、マップデータをデータベースに記憶する。データベースは、マップデータのサブセットを記憶してもよい。マップデータは、任意の好適なソースから取得することができる。例えば、マップデータは、Ｏｐｅｎ  Ｓｔｒｅｅｔマップデータであってもよい。Ｏｐｅｎ  Ｓｔｒｅｅｔマップは、位相的データ構造（topographical data structure）を使用する。ノードは、地理的位置を有する地点であり、座標として記憶される。これらを使用して、例えば、関心点（point of interest）又は山頂等、サイズを有さない地図上の特徴を表してもよい。経路（ways）は、ノードの順序付きリストであり、線分群又は、閉ループを形成する場合、多角形を表す。これらは、街路及び川等の線的特徴や、森、公園、及び湖等の領域を表すのに使用される。タグはキーバリューペア（key value pair）であり、その対象物のメタデータを記憶するのに使用される。このデータは、例えば、その種別、名称、及び／又は物理的特性とすることができる。タグは、通常、ノード又は経路の形態で対象物に貼り付けられる。マップデータは任意の好適なデータベースに記憶されてもよいことは勿論である。いくつかの実施形態において、マップデータは、ＳＱＬデータベースに記憶される。
【０２１０】
いくつかの実施形態において、サーバは、定期的にマップデータをデータベースにダウンロードする。他の実施形態において、マップデータは、ゲームからの具体的なリクエストに応じてダウンロードされてもよい。マップデータの一部がゲームからの具体的なリクエストに応じてダウンロードされるこの実施形態において、隣接した領域のデータもダウンロードされてもよい。
【０２１１】
ステップＦ２において、マップデータは、フィルタリングされ、マップデータから何らかの特徴を取り除く。例えば、このフィルタリングは、道路、土地及び水域の多角形、関心キー地点等、データ内のキーとなる特徴のみを保持するようになされてもよい。いくつかの実施形態において、マップデータは、サーバからクライアントデバイスにダウンロードする必要のあるデータが最小化されるように簡易化される。
【０２１２】
いくつかの実施形態において、レンダリング済みの地理的データに基づいてマップタイルを表示できるＰｙｔｈｏｎベースサーバアプリケーションを使用してもよい。マップデータは、いくつかの種別の特徴を取り除くことによって簡易化されてもよい。このフィルタリングは、道路、土地及び水域の多角形、関心キー地点等、データのキー特徴のみを保持するためになされてもよい。このアプリケーションは、Ｏｐｅｎ  Ｓｔｒｅｅｔ  Ｍａｐデータがインポートされたデータベースに対してＳＱＬクエリを作成するために使用されてもよい。
【０２１３】
従って、処理は、任意の好適な形式を採ってもよい。いくつかの実施形態において、マップデータのフィルタリングは、データを記憶したデータベースに対して１つ以上のＳＱＬクエリを作成することによって実施される。いくつかの実施形態において、各タイルに多数のクエリが作成される。このクエリは、要求されたタイルの境界ボックス内にのみ行ってもよい。このクエリは、要求された特徴のクリップ及びフィルタリングを実施してもよい。例えば、これは、地名、いくつかの道路、及び土地又は水域の多角形等、所望の特徴に対しクリップ及びフィルタリングを実施してもよい。
【０２１４】
いくつかの実施形態において、特定タイルのマップデータのフィルタリングは、そのタイルがゲームに必要とされるときのみ実施される。ゲームからのリクエストに応じて処理が実施される場合、隣接しているタイルのマップデータがさらに同時に処理されてもよいことは勿論である。
【０２１５】
いくつかの実施形態において、ステップＦ３では、マップデータの後処理が実施される。これは、カスタムライブラリを使用して実施されてもよい。いくつかの実施形態において、この処理は、タイル毎に実施されてもよい。この後処理により、マップのマーカを生成する。これらのマーカは、ユーザが建物を建てるか、又は有することのできる位置を規定する。これらのマーカを使用して、任意の目的地、対象物、建造物の位置、又は本文書で例示のみを目的として述べるような位置を規定してもよい。これらのマーカは、ゲームにおいてゲーム対象物を配置可能な位置に提供される。各マーカは、独自の識別子を有する。いくつかの実施形態において、マーカは、この独自の識別子を提供するため、地理的座標を使用してもよい。他の実施形態において、独自の識別子はその他任意の好適な形式を採ってもよい。
【０２１６】
後処理は、タイルのエッジにおけるゲートウェイノード（接続ノード）を特定するため、タイルのエッジの解析を実施してもよい。ゲートウェイ特徴（接続特徴）は、例えば、隣接するタイルにもある特徴である。一般的なゲートウェイ特徴の例として、道路、湖道路等が挙げられる。ゲートウェイノードは、タイルがゲームにダウンロードされるか、又はゲームに使用されるとき、クライアントがタイル境界を越えて多角形及び道路を統合できるようにするように特定される。換言すると、１つのタイルの１つのエッジ上の道路は、論理的に、隣接タイルのエッジ上の道路と合致し得る。これにより、ゲーム要素は、２つのタイル間の境界を跨ぐ地理的特徴に従って進む。例えば、ゲーム要素を、タイル間の境界を跨ぐ道路等に沿って移動するように制御することができる。いくつかの実施形態において、地理的特徴は、一連のノードで規定される。ノードがタイルの所定距離から外れている場合、潜在的にゲートウェイノードと考えられる。いくつかの実施形態において、ゲートウェイノードは、ゲートウェイノードと考えられるタイルのエッジの直上でなくてもよいことは勿論である。ノードがタイルのエッジの所定距離内にある場合、候補ゲートウェイノードとして考慮されてもよく、隣接タイル上の対応ノードと潜在的に合致し得る。
【０２１７】
いくつかの実施形態において、ゲートウェイ特徴は、タイル境界を跨ぐ任意のタイル形状の一部であり得る。
【０２１８】
これらの特徴は、穴接続（hole connection）を提供するためにも処理できる。マップデータを使用し、湖又は島等、いくつかの地理的特徴は複数の多角形で規定される。これらの多角形は、特定の領域がともに接続され得るところを規定する。この目的は、ダウンロードされる必要のあるデータの量を低減することである。これは、複数の多角形によって規定される地理的特徴を結合する。いくつかの実施形態において、これは、いくつかの特徴に対してなされてもよく、他の実施形態においては、複数の多角形を含むタイルのすべての特徴に対してなされてもよい。
【０２１９】
簡易な多角形は、多角形の縁部が特定方向（時計回り又は反時計回り）に旋回して伸びるとき、多角形の内側領域が常にその一方側（左側又は右側）にある多角形である。図１５ａに示す例では、穴を備えた多角形１０１は、その結果、外側境界の内部が簡易な多角形でない。
【０２２０】
穴を備えた多角形は、穴接続を使用して、簡易な多角形に変換されてもよい。穴接続の概念を説明するため、図１５ａに示す通り、１つの穴を備えた多角形を考慮する。１つの穴を備えた多角形は、内側多角形１０２と外側多角形１０３とからなる。内側多角形と外側多角形の２つの互いに視認できる頂点１０４及び１０５の間に２つの合致する縁部を導入することにより、簡易な多角形に変換されてもよく、ここで互いに視認できるとは、２つの合致する縁部が外側多角形のみを通過することが、条件として規定される。図１５ｂは、２つの新たに合致する縁部が多角形を「切断」して開放し、簡易な多角形２０１を形成する様子を示している。２つの新たに合致する縁部は、穴接続２０２として規定される。穴接続を使用して、２つ以上の多角形によって規定される土地又は水域特徴を１つの多角形に結合し、潜在的にマップデータを簡易化してもよい。これは、データの処理方法の一例であり、代替の実施形態においては、その他任意の好適な方法が使用されてもよい。
【０２２１】
処理されたマップデータは、プロトコルバッファ形式で記憶されてもよい。プロトコルバッファにより、カスタム構造中の構造化データを直列化してもよい。カスタム構造は、例えば、プロトファイル内に規定される。これらの構造は、ファイルサイズ、読み込み性能、及びレンダリング性能の点で、ゲームに最適化された形式でデータを記憶するように規定されてもよい。データは、ゲームクライアントが読み取りやすいような方法で構造化され、変換を最小化してもよい。使用される形態であるＰｒｏｔｏｃｏｌ  Ｂｕｆｆｅｒｓ（Ｇｏｏｇｌｅ（登録商標）から）は、ファイルサイズを小さく保つ。タイルは、ゲームに使用されるデータのみを含む。これにより、ゲームクライアントが使用するメモリが減り、タイルをより高速に読み込む。
【０２２２】
データの形式は、ベクトル形式であってもよい。
【０２２３】
他の実施形態において、データの異なる形式を代わりに使用することができることは勿論である。
【０２２４】
いくつかの実施形態において、タイルデータは、マーカデータ、ゲートウェイノードデータ、及び先に述べたその他任意のデータのうちの１つ以上を含み得る。いくつかの実施形態において、上述のデータはすべて、タイルデータの一部である。他の実施形態において、上述のデータのうちの１つ以上は、タイルデータとは別個に、例えば、別個のファイルで提供されてもよい。
【０２２５】
図１２は、ユーザデバイスにて行われる方法を示す。ステップＧ１において、クライアントデバイスは、サーバに処理済みマップタイルを要求する。いくつかの実施形態において、処理済みマップタイルは、例えば、隣接タイルがリクエストされた場合、ユーザデバイスに提供されてもよい。
【０２２６】
ステップＧ２において、処理済みマップタイルデータは、マップタイルのレンダリングのために処理される。
【０２２７】
２つの隣接したタイルの各ゲートウェイノードは、論理的に接続される。換言すると、一方のタイル上のゲートウェイノードは、タイルの境界に沿って、他方のタイル上の対応ゲートウェイノードと論理的に合致される。これは、ゲーム要素が移動するとき、タイル境界を跨いで規定の進路（例えば、道路）を渡って移動できることを意味する。論理的合致を使用して、許可されたゲーム要素の移動を制御するナビゲーションを行う。いくつかの実施形態において、１つ以上のゲーム要素の移動は、規定の進路、例えば、道路に従うものに制約されてもよい。ゲートウェイノードの論理的合致により、プロセッサは、境界を跨ぐ進路に沿ってゲーム要素を移動させる。これは、ゲートウェイノードの合致の結果として、タイル境界のいずれの側の進路も同一の進路であると認識されているためである。
【０２２８】
ユーザデバイスのプロセッサは、隣接したタイル上のゲートウェイノードを解析するように構成されてもよい。隣接したタイル上の合致ゲートウェイノードの各対について、プロセッサは、論理的接続を追加するように構成されてもよい。論理的接続に関する情報は、メモリに記憶されてもよい。論理的接続に関する情報は、所定のゲーム要素がいずれの進路又はルートに従うように許可されるかを制御するアルゴリズムにおいて使用されてもよい。これは、先に説明した通りであってもよい。図１４は、第１タイル４１０及び第２タイル４１２を模式的に示す。地理的特徴４２４及び４２２は、第１タイルと第２タイルとの間の境界を跨いで延びる。地理的特徴４２４は、第１タイルにゲートウェイノード４１４と、第２タイルにゲートウェイノード４１６を有する。地理的特徴４２２は、第１タイルにゲートウェイノード４１８と、第２タイルにゲートウェイノード４２０とを有する。従ってゲートウェイノード４１４は、ゲートウェイノード４１６と合致され、ゲーム要素は、これらのノードを含む進路に沿って１つのタイルから他のタイルへと移動することができる。同様に、ゲートウェイノード４１８は、ゲートウェイノード４２０と論理的に合致される。
【０２２９】
この合致は、任意の好適な技術を使用して実施されてもよいことは勿論である。
【０２３０】
いくつかの実施形態において、合致は、隣接したタイル上のゲートウェイノードが、第１タイル上のゲートウェイノードから所定距離内にあるか否かを表すために判定されてもよい。他の実施形態において、合致するか否かの判定に他の方法が使用されてもよい。
【０２３１】
合致（match）を取り扱う一例としての方法について説明する。合致したゲートウェイノードに基づき、各ゲートウェイノード間の論理的接続の一覧を記憶する。論理的接続は、第１タイル上の地理的特徴が隣接したタイル上でも連続しているか否かを判定するために使用される。この一覧は、メモリに記憶されてもよい。
【０２３２】
合致したゲートウェイノードに基づき、第１タイルと隣接したタイルの合致したゲートウェイノードに関連付けられた地理的特徴は、１つの地理的特徴に結合されてもよい。この地理的特徴はメモリに記憶されてもよい。これを使用して、ディスプレイに結合した地理的特徴を表示してもよい。ノードの論理的合致を使用して、２つのタイルを跨ぐ地図上の特徴（map feature）を接合してもよい。これを使用して、ゲーム要素等によってナビゲートされ得るルート（道路、川、進路等）を提供してもよい。この接合は、地図上の特徴がタイルの境界を跨いでいても同一の特徴として特定されるように使用されてもよい。例えば、地図上の特徴が建造物である場合、論理的接続は、共通のエンティティとしてみなされることを意味する。地図上の特徴は、勿論、その他任意の地図上の特徴であり得る。
【０２３３】
いくつかの実施形態において、結合された地理的特徴を使用して、ゲーム要素を１つのタイルから隣接したタイルまで移動させてもよい。
【０２３４】
いくつかの実施形態において、エッジノードの接合は、ナビゲーションのための接続を規定する。
【０２３５】
いくつかの実施形態において、各マップタイルは、所定のズームレベル、すなわち、所定の倍率を有する。ユーザは、１つのタイルの領域内にありズームイン又はズームアウトを希望する場合、要求されるズームレベルでその場所の異なるタイルをダウンロードする。いくつかの実施形態において、すべてのズームレベルは、それ自体のタイルセットを有してもよい。ユーザがズームイン又はズームアウトを行う場合、ユーザデバイスに事前にキャッシュされていなければ、異なるタイルをネットワークからロードする。
【０２３６】
図１３は、マップデータを処理するシステムを模式的に示す。ダウンロードされたマップデータを記憶するデータベース４００が設けられる。データベースは、ＳＱＬデータベースであってもよい。ＳＱＬクエリは、プロセッサ４０２によって提供されてもよい。ＳＱＬクエリによって得られるデータは、前述の処理を実施するライブラリ４０４に提供されてもよい。タイルマップデータは、ライブラリ４０４による処理後、タイルデータ記憶部４０６に記憶されてもよい。タイルデータ記憶部は、ローカルディスク及び／又はコンテンツ配信ネットワークに記憶されてもよい。このデータは静的２値ファイルに記憶される。
【０２３７】
図１７は、いくつかの実施形態に係る方法を模式的に示す。
【０２３８】
ステップＨ１において、ゲームのプレーヤーは、特定の場所を訪れる。換言すると、ユーザ入力を使用することにより、ユーザは、表示されたマップ上の特定位置を選択する。これは、任意の好適な方法、例えば、マップ上の位置の選択、ゲーム要素のその位置への案内、その位置の建物等の選択、可能な位置のリストからの位置の選択、又は特定位置に関する情報の入力により、選択されてもよい。これから説明する例において、この位置はレストランである。しかしながら、これは単なる例示であり、代替又は追加として、他の実施形態は他の目的地とともに使用されてもよいことは勿論である。本例において、ユーザが訪れた目的地は、他のユーザに関連付けられる。
【０２３９】
ステップＨ２において、ユーザは、この目的地から項目を選択する。本例において、この項目は、レシピであってもよい。いくつかの実施形態において、項目の選択は、項目の購入であってもよい。項目の購入には、ゲーム通貨又は現実の通貨が使用されてもよい。しかしながら、これは単なる例示である。ユーザは、ユーザ入力を介して、購入する項目を選択する。これは、ユーザがタッチスクリーン上の特定オプションをクリック又は押下するか、カーソル等を使用して項目の選択を選択することによる例であってもよい。
【０２４０】
ステップＨ３において、項目の購入又は選択に関する情報は、ユーザデバイスからサーバに送信される。これは、ユーザデバイスからサーバに送られる定期的アップデートの一部であってもよい。或いは、ユーザデバイスは、項目の選択に応じてサーバに情報をプッシュ配信してもよい。この情報は、特定の目的地を特定するデータを含む。この情報は、例えば、以下のうちの１つ以上を含んでもよい。すなわち、位置情報（例えば、マーカ）、目的地を特定する情報、及び購入した項目を特定する情報である。この特定については、以下により詳細に説明する。
【０２４１】
ステップＨ４において、サーバは、ユーザデバイスから情報を受信する。
【０２４２】
ステップＨ５において、サーバは、項目と関連付けられた、項目の所有者及び／又は目的地の所有者を特定するために受信した情報を使用する。いくつかの実施形態において、マーカ、目的地情報、及び項目の組み合わせのうちの１つ以上により、項目の所有者は、サーバによって独自に特定される。いくつかの実施形態においては、マーカ及び／又は目的地のみにより、その項目が選択された建物の所有者を特定できる。代替の実施形態において、地理的座標を代わりに使用し、特定の建物を特定することができる。
【０２４３】
ステップＨ６において、購入した項目の所有者にメッセージを送信する。このメッセージは直ちに送信されてもよく、或いは、サーバはその項目の所有者が次にこのゲーム又は関連ゲームをプレイするときまで待機するようにアレンジされてもよい。このサーバは、レシピが購入されたことを示すメッセージをユーザに勧めてもよい。これは、プライバシー設定に応じて、購入者の同一性を示すことができる。メッセージは、購入されたレシピに関連付けられたユーザがゲームをプレイ中であるか否かに応じて決められてもよい。このメッセージは、ゲームがプレイ中でない場合、プッシュ通知とすることができ、ユーザがゲームプレイ中である場合、ゲーム内メッセージとすることができる。このメッセージは、ユーザがゲームをプレイ中であると判定されるまで遅延することができる。
【０２４４】
いくつかの実施形態では、ステップＨ３において、サーバが、選択された項目と関連付けられた１つ以上の建物を示すように情報をアップデートする。いくつかの実施形態において、サーバは、選択された項目を、項目を購入した目的地と同一タイプの任意の目的地と関連付けるように情報をアップデートする。例えば、項目がレシピであり、レシピがレストランと関連付けられている場合、サーバは、このレシピを、項目の購入者が有する少なくとも１つのレストラン、いくつかの実施形態においてはすべてのレストランと関連付けるように、この情報をアップデートする。これら（レストラン）は、このレシピを購入したユーザの建物である。サーバには、この項目を購入したユーザを特定する情報が提供される。
【０２４５】
代替の一実施形態において、ユーザがその項目の関連付けを希望する位置を選択するようにユーザを促すメニューがディスプレイ上に表示される。従ってユーザは、購入した項目を自身の目的地のうちの１つに関連付ける。いくつかの実施形態において、ユーザは、項目と関連付けるべき自身の目的地の１つを選択するように促される。いくつかの実施形態において、目的地は、特定種別のものでなければならない。例えば、購入された項目がレストランと関連付けられる場合、ユーザは、購入した項目を自身のレストランのうちの１つと関連付ける。
【０２４６】
いくつかの項目は、２つ以上の異なる種別の目的地と関連付けられてもよい。
【０２４７】
上述の実施形態において、項目の購入又は選択には、サーバへのリクエスト送信が必要である。代替又は追加として、項目等の購入において、ユーザデバイス上でクライアントによるサポートが可能である。
【０２４８】
代替の実施形態において、各項目は、データベースにおいて、項目と関連付けられるユーザと関連付けられた独自の識別子を有してもよい。
【０２４９】
図１６は、一実施形態に係るデータ構造を模式的に示す。少なくとも１つの建物が少なくともいくつかのマーカ４４０と関連付けられる。マーカは、位置情報であり、上述のようなマーカである。データ構造は、建物４４２の種別を示す。建物所有者又は建物に関連付けられたユーザと関連付けられた同一性情報４４４が建物種別と関連付けられる。このユーザ同一性情報は、ゲームの各プレーヤー固有のものである。１つ以上の項目４４８及び４４６も建物種別と関連付けられる。この特定の例において、項目はレシピである。しかしながら、項目は任意の好適な形式を採ることができる。
【０２５０】
いくつかの実施形態において、１つ以上のサブ項目が各項目に関連付けられてもよい。本例では、各レシピがその種々のサブ項目４５０〜４５６と関連付けられている。本実施形態において、これらのサブ項目は、材料である。しかしながら、これらのサブ項目は任意の好適な形式を採り得る。いくつかの実施形態において、サブ項目は任意であることは勿論である。いくつかの実施形態において、１つ以上のサブ項目は、次いで、１つ以上のさらなるサブ項目等を有してもよい。
【０２５１】
従ってデータベースに記憶された情報は、以下のうちの１つ以上を備えてもよい。
マーカ−この情報は、タイル上の正確な位置を規定してもよい。
建物種別−例えば、レストラン又はコーヒーショップ。代替又は追加として、これは識別子を備えてもよい。
建物に関連付けられたユーザの同一性
建物に関連付けられた１つ以上の項目。これは、例えば、レシピを備えてもよい。この情報は、１つ以上の項目の同一性を備えてもよい。
各項目に関連付けられた１つ以上のサブ項目。いくつかの実施形態において、これらのサブ項目は、各レシピに関連付けられた材料であってもよい。
【０２５２】
データベースの保持されるこの情報により、特定位置の建物と、引いては項目とに関連付けられたユーザが特定される。
【０２５３】
いくつかの実施形態において、ゲームは、１つの項目の少なくとも１つのサブ項目を収集することを目的とする探索（scouting）機構をサポートしてもよい。いくつかの実施形態において、この目的は、１つの項目のサブ項目をすべて見つけることであってもよい。この点について、図１８は一実施形態に係る方法を示す。
【０２５４】
単なる例示であるが、項目（レシピ）は、４つのサブ項目を備えてもよい。例えば、１つ以上又はすべてのサブ項目がマップ上に配置可能であり、且つ／又は、１つ以上のサブ項目が１つ以上の他の建物から（例えば、購入によって）取得されてもよい。他の建物は、項目が関連付けられたものと同一種別であってもよく、且つ／又は、異なる種別であってもよい。
【０２５５】
ユーザは、ステップＪ１において、ユーザインタフェースを介して、探索アルゴリズムを選択する。ユーザデバイスのプロセッサは、ユーザインタフェースからの入力に応じて、探索アルゴリズムを選択してもよい。これは、ゲームにおいて探索特性を選択することによって達成されてもよい。
【０２５６】
ステップＪ２において、探索アルゴリズム（scouting algorithm）が動作する。これは、マップの目的地にゲーム要素を送る。ゲーム要素は、特定の探索ゲーム要素であってもよい。探索アルゴリズムは、いくつかの実施形態において、ゲーム要素の目的地を制御するランダム部分を有してもよい。
【０２５７】
いくつかの実施形態において、探索ゲーム要素は、１つ以上のサブ項目が見つけられてもよい目的地を有する。いくつかの実施形態において、探索ゲーム要素目的地は、必ずしも１つ以上のサブ項目を有していない。従って探索アルゴリズムは、ｍ個のサブ項目を収集するためｎ回実施される必要があってもよく、ｎはｍより大きい。
【０２５８】
ステップＪ３において、１つ以上のサブ項目が目的地に存在するか否かに関して判定がなされる。これは、プロセッサにより、又はユーザインタフェースを介してユーザによって提供された入力に応じてなされてもよい。
【０２５９】
ステップＪ４において、すべてのサブ項目が収集されたか否かに関して判定がなされる。収集されていない場合、方法はステップＪ１に戻ってもよい。いくつかの実施形態において、１つの項目に対するすべてのサブ項目が一旦収集されると、この項目は、図１７との関連で説明した通り、異なるプレーヤーにより購入又は選択が可能となってもよい。従って、一例において、あるレシピ（項目）が完全に収集されると（すべてのサブ項目がプレーヤーに所有されると）、プレーヤーのレストランのメニューに新たな料理（レシピ）として追加される。サーバに記憶された情報には、その項目が他のユーザに購入可能であるか否かを示す情報が含まれてもよい。他のユーザのユーザデバイスに提供されるこの情報は、他のユーザが、利用可能な項目を選択できるが、利用可能でない項目を選択又は購入できないようになっている。
【０２６０】
さらに種々の方法を説明した。これらの方法は、装置において実行され、その装置は任意の好適な回路で実行されることは勿論である。いくつかの実施形態は、少なくとも１つのメモリと少なくとも１つのプロセッサとによって実行されてもよい。メモリは、メモリ回路によって提供され、プロセッサは、プロセッサ回路によって提供される。いくつかの実施形態は、少なくとも１つのプロセッサ上で動作するコンピュータプログラムによって提供されてもよい。コンピュータプログラムは、少なくとも１つのメモリに記憶され、少なくとも１つのプロセッサ上で動作しうるコンピュータ実行指示を備えてもよい。
【０２６１】
ここで、以上は本発明の実施形態を説明したものであるが、本発明の範囲を逸脱することなく、開示のソリューションに対していくつかの変更及び変形がなされてもよいことにも留意されたい。
【図１】
2017511510.tif 000003
【図２】
2017511510.tif 000004
【図３】
2017511510.tif 000005
【図４】
2017511510.tif 000006
【図５】
2017511510.tif 000007
【図６】
2017511510.tif 000008
【図７】
2017511510.tif 000009
【図８】
2017511510.tif 000010
【図９】
2017511510.tif 000011
【図１０】
2017511510.tif 000012
【図１１】
2017511510.tif 000013
【図１２】
2017511510.tif 000014
【図１３】
2017511510.tif 000015
【図１４】
2017511510.tif 000016
【図１５ａ】
2017511510.tif 000017
【図１５ｂ】
2017511510.tif 000018
【図１６】
2017511510.tif 000019
【図１７】
2017511510.tif 000020
【図１８】
2017511510.tif 000021
【国際調査報告】
2017511510.tif 000022
2017511510.tif 000023
2017511510.tif 000024
2017511510.tif 000025
2017511510.tif 000026