以下、この発明の実施形態について図面を参照しながら詳細に説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。
(ゲーム配信システム1の構成)
図1は、ある実施形態に従うゲーム配信システム1の構成例を示す図である。図1に示すように、ゲーム配信システム1は、ユーザが使用する情報処理装置と、サーバ20とを含む。情報処理装置とサーバ20とは、ネットワーク80によって互いに通信可能に接続されている。
図1の例では、ユーザが使用する情報処理装置として、携帯端末10A、携帯端末10Bおよび携帯端末10C(以下、携帯端末10A、10B、10Cなどの携帯端末を総称して「携帯端末10」と表すこともある)など複数の携帯端末が示されている。携帯端末10Aと携帯端末10Bとは、無線基地局81と通信することにより、ネットワーク80と接続する。携帯端末10Cは、家屋などの施設に設置される無線ルータ82と通信することにより、ネットワーク80と接続する。携帯端末10は、タッチスクリーンを備える端末であり、例えば、スマートフォン、ファブレット、タブレットなどである。
携帯端末10は、ゲームプログラムを実行することにより、ゲームプログラムに応じたゲームをプレイする環境をユーザに対して提供する。携帯端末10には、例えば、アプリ等を配信するプラットフォームを介してダウンロードされたゲームプログラムがインストールされる。携帯端末10は、ダウンロードされたゲームプログラム、または、予めプリインストールされているゲームプログラムを実行することで、ユーザによるゲームのプレイを可能とする。携帯端末10が、ゲームプログラムを実行すると、携帯端末10と、サーバ20とが、通信して、ゲームの進行に応じてゲームに関連するデータが、携帯端末10とサーバ20との間で送受信される。
サーバ20は、ゲームのプレイに必要なデータを、適宜、携帯端末10へ送信することで、携帯端末10でのゲームのプレイを進行させる。サーバ20は、ゲームをプレイする各ユーザの、ゲームに関連する各種データを管理する。サーバ20は、携帯端末10と通信し、各ユーザのゲームの進行に応じて、画像、音声、テキストデータその他のデータを携帯端末10へ送信する。
例えば、サーバ20は、ユーザがゲームのストーリーを進行させた進行状況、ユーザが使用可能なキャラクタの情報(例えば、キャラクタの能力を示すパラメータ)、当該キャラクタが使用する道具の性能を示すパラメータその他の各種データを管理する。また、サーバ20は、ゲームの運営者がユーザに対して行なうキャンペーン、ゲームにおける不具合の発生、不具合の解消その他のゲームの運営に関連する情報等をユーザに通知する処理を行なう。
ゲームプログラムは、ユーザがゲームをプレイするモードとして、一人のユーザがプレイする場合(シングルプレイ)と、複数人のユーザが協力してプレイする場合(マルチプレイ)とに対応している。例えば、ゲーム配信システム1のサーバ20が、マルチプレイに参加するユーザを特定して各ユーザの各携帯端末10と通信すること等により、マルチプレイでゲームをプレイする環境を各ユーザに提供する。
ゲーム配信システム1は、マルチプレイに対応することにより、例えば、アクションゲームであれば、ユーザ同士が協力してゲームを進行させること、または、ユーザどうしでの対戦を可能とする。
<構成>
サーバ20のハードウェアの構成を説明する。サーバ20は、主たる構成要素として、通信IF(Interface)22と、入出力IF23と、メモリ25と、ストレージ26と、プロセッサ29とを備える。各構成要素は、通信バスを介して互いに接続されている。
通信IF22は、例えばLAN(Local Area Network)規格など各種の通信規格に対応しており、携帯端末10など外部の通信機器との間でデータを送受信するためのインタフェースとして機能する。
入出力IF23は、サーバ20への情報の入力を受け付けるとともに、サーバ20の外部へ情報を出力するためのインタフェースとして機能する。入出力IF23は、マウス、キーボード等の情報入力機器の接続を受け付ける入力受付部と、ディスプレイ等の情報出力機器の接続を受け付ける出力部とを含む。入力受付部は、一例として、PS/2コネクタ、USB(Universal Serial Bus)コネクタ等により実現される。出力部は、一例として、VGA(Video Graphics Array)コネクタ、DVI(Digital Visual Interface)コネクタ、HDMI(High Definition Multimedia Interface)(登録商標)コネクタ、Displayportコネクタ等により実現される。
メモリ25は、処理に使用されるデータ等を記憶するための記憶装置である。メモリ25は、例えば、プロセッサ29が処理を行なう際に一時的に使用するための作業領域をプロセッサ29に提供する。メモリ25は、ROM(Read Only Memory)、RAM(Random Access Memory)等により実現される。
ストレージ26は、プロセッサ29が読み込んで実行するための各種プログラムおよびデータを記憶するための記憶装置である。ストレージ26が記憶する情報は、ゲームプログラム、ゲームプログラムに関連する情報、ゲームプログラムをプレイするユーザの情報その他の情報を含む。ストレージ26は、HDD(Hard Disk Drive)、フラッシュメモリ等により実現される。
プロセッサ29は、ストレージ26に記憶されるプログラム等を読み込んで実行することにより、サーバ20の動作を制御する。プロセッサ29は、例えば、CPU(Central Processing Unit)、MPU(Micro Processing Unit)、GPU(Graphics Processing Unit)等を含む。
(携帯端末10の構成)
図2は、ある実施形態に従う携帯端末10の構成を示すブロック図である。図2を参照して、携帯端末10は、アンテナ110と、無線通信IF120と、タッチスクリーン130と、入出力IF140と、記憶部150と、音声処理回路160と、マイク170と、スピーカ180と、プロセッサ190とを備える。
アンテナ110は、携帯端末10が発する信号を電波として空間へ放射する。また、アンテナ110は、空間から電波を受信して受信信号を無線通信IF120へ送出する。
無線通信IF120は、アンテナ110等を介して他の通信機器と信号を送受信するための変復調処理などを行なう無線通信用の通信モジュールとして機能する。無線通信IF120は、チューナー、高周波回路等により実現される。無線通信IF120は、携帯端末10が送受信する無線信号の変復調や周波数変換を行い、受信信号をプロセッサ190へ出力する。
タッチスクリーン130は、ユーザからの入力を受け付ける。プロセッサ190は、当該入力に応じた情報をディスプレイ132に出力する。タッチスクリーン130は、ユーザの入力操作を受け付けるための部材(タッチパネル131)を含む。また、タッチスクリーン130は、メニュー画面や、ゲームの進行を画面に表示するための部材(ディスプレイ132)を含む。タッチパネル131は、例えば静電容量方式に従い、ユーザの指などが接近したことを検出する。ディスプレイ132は、例えばLCD(Liquid Crystal Display)、有機EL(ElectroLuminescence)ディスプレイその他の表示装置によって実現される。
入出力IF140は、携帯端末10への情報の入力を受け付けるとともに、携帯端末10の外部へ情報を出力するためのインタフェースとして機能する。入出力IF140は、一例として、USB(Universal Serial Bus)コネクタ等により実現される。
記憶部150は、フラッシュメモリ、RAM(Random Access Memory)等により構成され、携帯端末10が使用するプログラム、および、携帯端末10がサーバ20から受信する各種データ等を記憶する。
音声処理回路160は、音声信号の変復調を行なう。音声処理回路160は、マイク170から入力される信号を変調して、変調後の信号をプロセッサ190に出力する。また、音声処理回路160は、音声信号をスピーカ180に出力する。音声処理回路160は、例えば、音声処理用のプロセッサによって実現される。マイク170は、周囲の音声を音声信号に変換してプロセッサ190へ出力するための音声入力部として機能する。スピーカ180は、音声信号を音声に変換して、携帯端末10の外部へ出力するための音声出力部として機能する。
プロセッサ190は、記憶部150に記憶されるプログラムを読み込んで実行することにより、携帯端末10の動作を制御する。
携帯端末10がゲームプログラム151を実行する処理について、より詳細に説明する。ある局面において、記憶部150は、ゲームプログラム151と、ゲーム情報152と、ユーザ情報153とを記憶する。携帯端末10は、例えば、サーバ20からゲームプログラムをダウンロードして記憶部150に記憶させる。また、携帯端末10は、ゲームの進行に伴いサーバ20と通信することで、ゲーム情報152およびユーザ情報153等の各種のデータをサーバ20と送受信する。
ゲームプログラム151は、携帯端末10においてゲームを進行させるためのプログラムである。ゲーム情報152は、ゲームプログラム151が参照する各種のデータを含む。ゲーム情報152は、例えば、ゲームにおいて仮想空間に配置するオブジェクトの情報、オブジェクトに対応付けられた効果の情報(例えば、キャラクタに設定されるスキルの情報)などを含む。ユーザ情報153は、ゲームをプレイするユーザについての情報を含む。ユーザ情報153は、例えば、ゲームをプレイするユーザを識別する情報、マルチプレイ時に協力してゲームをプレイする他のユーザを識別する情報その他の情報を含む。
プロセッサ190は、ゲームプログラム151を読み込んで実行することにより、入力操作受付部191、ゲーム進行処理部192、移動操作検出部193、カメラ配置制御部194、オブジェクト制御部195、および表示制御部196として機能する。
入力操作受付部191は、タッチスクリーン130の出力に基づいて、ユーザの入力操作を受け付ける。具体的には、入力操作受付部191は、ユーザの指などがタッチパネル131に接近したことを、タッチスクリーン130を構成する面の横軸および縦軸からなる座標系の座標として検出する。
入力操作受付部191は、タッチスクリーン130に対するユーザの操作を判別する。入力操作受付部191は、例えば、(1)「接近操作」、(2)「リリース操作」、(3)「タップ操作」、(4)「ダブルタップ操作」、(5)「長押し操作(ロングタッチ操作)」、(6)「ドラッグ操作(スワイプ操作)」、(7)「ムーブ操作」、(8)「フリック操作」、その他のユーザの操作を判別する。入力操作受付部191が判別するユーザの操作は、上記に限られない。例えば、タッチパネル131が、ユーザがタッチパネル131に対して押下する圧力の大きさを検出可能な機構を有する場合、入力操作受付部191は、ユーザが押下した圧力の大きさを判別する。また、プロセッサ190は、タッチスクリーン130へのユーザの指などの接近を検出している状態を、「タッチオン状態」と判別する。プロセッサ190は、タッチスクリーン130へのユーザの指などの接近を検出しない状態を、「タッチオフ状態」と判別する。プロセッサ190は、タッチスクリーン130が逐次出力するユーザの指などの接近位置を示す座標を、「タッチナウ」の座標として受け付ける。
ここで、(1)「接近操作」とは、ユーザが指などをタッチスクリーン130に接近させる操作である。タッチスクリーン130は、ユーザの指などが接近したこと(ユーザの指などがタッチスクリーン130に接触したことを含む)をタッチパネル131により検出し、検出したタッチスクリーン130の座標に応じた信号をプロセッサ190へ出力する。プロセッサ190は、タッチスクリーン130へのユーザの指などの接近を検出しない状態から、接近を検出したときに、「タッチオフ状態」から「タッチオン状態」になったと判別する。
(2)「リリース操作」とは、ユーザがタッチスクリーン130から指を離す操作である。入力操作受付部191は、例えば、ユーザが指などをタッチスクリーン130に接触させている状態から、指を離す操作をしたときに、「リリース操作」が入力されたと判別する。プロセッサ190は、タッチスクリーン130へのユーザの指などの接近を検出している状態から、接近を検出しない状態になったときに、状態が「タッチオン状態」から「タッチオフ状態」になったと判別する。
(3)「タップ操作」とは、ユーザがタッチスクリーン130に対して指などを接近させる接近操作をした後に、接近操作をした位置でリリース操作を行なうことである。入力操作受付部191は、接近操作が検出されない状態(ユーザの指などがタッチパネル131から離れており、タッチパネル131がユーザの指などの接近を検出していない状態)から、接近操作を検出した場合に、その検出した座標を「タッチ開始位置」として保持する。入力操作受付部191は、タッチ開始位置の座標と、リリース操作をする直前に(タッチオフ状態が検出される直前に)タッチパネル131により検出されている座標とがほぼ同一である場合(接近操作が検出された座標から一定範囲内の座標においてリリース操作にかかる座標が検出された場合)に、ユーザの操作を「タップ操作」と判別する。
(4)「ダブルタップ操作」とは、ユーザがタップ操作を一定時間内に2回行なう操作である。入力操作受付部191は、例えば、ユーザの操作をタップ操作と判別してから一定時間内に、タップ操作にかかる座標で再びタップ操作を判別した場合に、「ダブルタップ操作」が入力されたと判別する。
(5)「長押し操作」とは、ユーザがタッチスクリーン130を押し続ける操作である。タッチスクリーン130は、ユーザの操作を検出して接近操作を判別してから、接近操作が検出された座標において接近操作が継続している時間が一定時間を超えた場合に、「長押し操作」(「長押し操作」を、「ロングタッチ操作」と称することもある)が入力されたと判別する。
(6)「ドラッグ操作」とは、ユーザがタッチスクリーン130に指などを接近させた接近状態を維持したまま、指をスライドさせる操作である。
(7)「ムーブ操作」とは、ユーザがタッチスクリーン130において、接近操作を維持しつつ、タッチスクリーン130に指などを接近させている位置を移動させてリリース操作を行なう一連の操作をいう。
(8)「フリック操作」は、ユーザがムーブ操作を予め定められた時間よりも短い時間で行なう操作をいう。フリック操作は、ユーザがタッチスクリーン130で指を弾くような操作である。記憶部150は、例えば、ユーザがムーブ操作を行なう時間と比較するための閾値を保持する。プロセッサ190は、ユーザがタッチスクリーン130において指などを接近させている位置を一定距離移動させるまでの時間が、当該閾値未満の場合にフリック操作が入力されたと判断する。また、プロセッサ190は、上記時間を複数の閾値と比較し得る。プロセッサ190は、上記時間が第1の閾値よりも短い場合(比較的素早く指を弾く場合)は、フリック操作が「強フリック」であると判断し、第1の閾値よりも大きく第2の閾値(第2の閾値を、第1の閾値よりも大きく設定する)よりも小さい場合に、フリック操作が「弱フリック」であると判断し得る。
ゲーム進行処理部192は、ユーザの操作に応じて、各種のプログラムを呼び出す等によりゲームを進行させる処理を行なう。例えば、ゲーム進行処理部192は、サーバ20と通信し、ゲームの進行に応じてサーバ20へデータを送信する処理、サーバ20からゲームに関連するデータを受信する処理、ゲームの進行に応じてユーザに報酬を付与する処理、時間の経過を計測する処理その他の処理を行なう。
移動操作検出部193は、タッチスクリーン130に対するユーザの入力操作に基づいて、ゲームに登場するキャラクタを移動させる入力操作を検出する。例えば、ゲームプログラム151がアクションゲーム、ロールプレイングゲーム、アクションロールプレイングゲームである場合、移動操作検出部193は、ユーザの入力操作に基づいて、ユーザの操作するキャラクタを移動させる方向を検出する。このように、移動操作検出部193は、ユーザがキャラクタの移動方向を指定する入力操作を受け付ける。
具体的には、移動操作検出部193は、ユーザがドラッグ操作を行った場合に、タッチ開始位置の座標とタッチスクリーン130の検出結果とに基づいて、キャラクタの移動方向を検出する。移動操作検出部193の詳細な処理は、後述する。
カメラ配置制御部194は、仮想空間に配置される各オブジェクトを、どのようにユーザに見せるかを決定する。具体的には、カメラ配置制御部194は、プロセッサ190がゲームプログラム151を読み込んで実行することで生成される仮想空間において、仮想カメラの配置(カメラワーク)を制御する。プロセッサ190は、仮想空間における仮想カメラの撮影画像をディスプレイ132に表示することで、ユーザに対しゲームのプレイ環境を提供する。
オブジェクト制御部195は、入力操作受付部191が受け付けたユーザの操作内容に基づいてゲームに登場する各種オブジェクト(例えば、GUI(Graphical User Interface)画面など)の生成、変形、移動などの処理を制御する。オブジェクト制御部195は、例えば、ユーザがキャラクタを移動させるためのタッチスクリーン130に対する入力操作に基づいて、キャラクタの移動方向を示すオブジェクトを生成する。
表示制御部196は、仮想カメラのカメラワークに従った画像をディスプレイ132に出力する。表示制御部196は、仮想空間内における仮想カメラの配置に応じて、ディスプレイ132の表示内容を決定し、決定した表示内容に従う画像、テキスト等の各種の情報をディスプレイ132に出力する。
(サーバ20の構成)
図3は、ある実施形態に従うサーバ20の機能的な構成を示すブロック図である。図3を参照して、サーバ20の詳細な構成を説明する。サーバ20は、プログラムに従って動作することにより、記憶部250と、制御部290として機能する。
記憶部250は、携帯端末10においてユーザがゲームを進行させるための各種プログラムおよびデータを記憶する。ある局面において、記憶部250は、ゲームプログラム251と、ゲーム情報252と、ユーザ情報253とを記憶する。記憶部250は、メモリ25およびストレージ26によって構成される。
ゲームプログラム251は、サーバ20が携帯端末10と通信して、携帯端末10においてゲームを進行させるためのプログラムである。ゲームプログラム251は、ゲームを進行させるための各種データであるゲーム情報252およびユーザ情報253等を参照して、ユーザの入力操作に応じてゲームを進行させる。プロセッサ29は、ゲームプログラム251を実行することにより、携帯端末10とデータを送受信する処理、携帯端末10のユーザが行った操作内容に応じてゲームを進行させる処理、ゲームをプレイするユーザの情報を更新する処理その他の処理を行なう。
ゲーム情報252は、ゲームプログラム251が参照する各種のデータを含む。ゲーム情報252は、オブジェクト管理テーブル252Aと、パッシブスキル管理テーブル252Bと、アクティブスキル管理テーブル252Cとを含む。
オブジェクト管理テーブル252Aは、ゲームの仮想空間内に配置されるオブジェクト、および当該オブジェクトに設定される情報を含む。携帯端末10は、仮想空間内に配置されるオブジェクトを、仮想空間内に配置される仮想カメラによって撮影した画像をディスプレイ132に表示することでゲームを進行させる。
ここで、オブジェクトとしては、例えば、携帯端末10のユーザが操作するキャラクタ(以下、「自キャラクタ」とも称する)を示すオブジェクト、自キャラクタが装着する装着対象物を示すオブジェクト、仮想空間におけるフィールドを形成する木や岩などを示すオブジェクトなど様々なものがある。プロセッサ190は、ユーザがタッチスクリーン130に対して予め定められた入力操作を行なうこと、ゲームの進行に伴い一定の条件を満たすこと、その他の様々な事象の発生を契機として、オブジェクトに対応付けられた処理を行なう。
例えば、あるオブジェクトに対してユーザがタッチスクリーン130に対して接近操作を行なうことで、プロセッサ190は、オブジェクトを、ユーザによって選択された状態とする。また、例えば、プロセッサ190は、ユーザによるドラッグ操作を受け付けることで、ユーザが移動対象とするオブジェクト(例えば、自キャラクタ)を、ドラッグ操作に応じて移動させる等の処理を行なう。また、例えば、プロセッサ190は、ユーザがオブジェクトに対して行なうタッチ操作を受け付けることで、ユーザに対し、ゲームを有利に進めるための報酬を付与する等の処理を行なう。
パッシブスキル管理テーブル252Bは、オブジェクトを識別する情報と、オブジェクトに対応付けられたパッシブスキルの情報とが対応付けられている。ここで、パッシブスキルとは、例えば、ゲームにおいて予め定められた条件が満たされたときに発動され、ユーザがゲームを有利に進行させることができるものである。例えば、パッシブスキルが発動した場合に、キャラクタの移動速度が向上する等の、ゲームを有利に進行させられる効果を発揮させる。
アクティブスキル管理テーブル252Cは、オブジェクトを識別する情報と、オブジェクトに対応付けられたアクティブスキルの情報とが対応付けられている。ここで、アクティブスキルとは、例えば、ゲームにおいて予め定められた条件が満たされたときに発動可能な状態となる。アクティブスキルが発動すると、ユーザは、ゲームを有利に進行させることができる。
ユーザ情報253は、ゲームをプレイするユーザについての情報である。ユーザ情報253は、ユーザ管理テーブル253Aを含む。ユーザ管理テーブル253Aは、各ユーザを識別する情報と、ユーザがゲームを進行させた度合いを示す情報と、ユーザがゲーム内で保有するアイテム、キャラクタ、キャラクタが使用する装着物等の情報その他の情報を含む。
制御部290は、送受信部291、サーバ処理部292、データ管理部293、マッチング部294、計測部295としての機能を含む。これらの機能は、サーバ20のプロセッサ29が、記憶部250に記憶されるゲームプログラム251を実行することにより、実現される。
送受信部291は、ゲームプログラム151を実行する携帯端末10と各種情報を送受信する。携帯端末10とサーバ20とは、オブジェクトを仮想空間に配置する要求、オブジェクトを削除する要求、オブジェクトを移動させる要求、ユーザが獲得する報酬に応じて各種パラメータを更新する要求、何らかの条件を満たした旨の通知、ゲームを進行させるための画像、音声その他のデータを送受信する。
サーバ処理部292は、サーバ20によりゲームの進行に必要な処理を行なう。サーバ処理部292は、例えば、携帯端末10から受信した情報に基づいて、ゲーム情報252、ユーザ情報253などのデータを更新する。サーバ処理部292は、更新したデータを携帯端末10に送信することでゲームを進行させる。
データ管理部293は、サーバ処理部292の処理結果に従って、記憶部250に記憶される各種データを更新する処理、データベースにレコードを追加/更新/削除する処理などを行なう。
マッチング部294は、複数のユーザを関連付けるための一連の処理を行なう。マッチング部294は、例えば、ユーザがマルチプレイを行なうための入力操作を行った場合に、ゲームを協力してプレイさせるユーザ同士を関連付ける処理などを行なう。
計測部295は、時間を計測する処理を行なう。計測部295は、例えば、仮想空間に配置される各オブジェクトについて時間の経過を計測する。また、計測部295は、携帯端末10がゲームプログラム151を実行している累計時間を計測する。サーバ20は、携帯端末10から各種の計測結果を受信する。この計測結果は、携帯端末10がゲームプログラム151を実行することにより計測される。サーバ20は、受信した各種の計測結果と、計測部295の計測結果とを照合することで、携帯端末10とサーバ20との間の、各種の時間に関する情報を同期させる。
<構成のまとめ>
以上のように、ある実施形態のゲーム配信システム1の構成を説明してきた。当該実施形態において、ゲームプログラム151は、例えばアクションロールプレイングゲームであり、仮想空間内の仮想カメラの配置に応じた画面をタッチスクリーン130に表示させることでゲームを進行させる。
例えば、ゲームプログラム151がアクションロールプレイングゲームである場合、ゲーム進行処理部192は、画像やテキストなどディスプレイ132に表示するデータを決定する処理、プレイ対象とする1以上のイベント(クエスト)をディスプレイ132に表示してイベントの選択をユーザから受け付ける処理、ユーザの操作に応じてイベントを進める処理などの基本的な処理を行なう。
(キャラクタの移動処理)
図4は、ある実施形態に従う移動操作検出部193が、ユーザの入力操作に応じてキャラクタを移動させる方向を検出する処理を示す図である。移動操作検出部193は、ユーザがタッチスクリーン130を押していない状態から、指などをタッチパネル131に接近させてタッチスクリーン130を押した位置(タッチ開始位置)を起点と設定する。入力操作受付部191は、ユーザの操作をドラッグ操作と判別している場合に、起点となるタッチ開始位置の座標と、タッチスクリーン130がユーザの指などの接近を検出している位置(タッチ継続位置)の座標とに基づいて、キャラクタを移動させる方向を検出する。
図4の分図(A)において、タッチスクリーン130からユーザの指が離れた状態から、ユーザが指をタッチスクリーン130に接近させる。入力操作受付部191は、ユーザの指がタッチパネル131に接近したことを検出し、検出した座標をタッチ開始位置としてメモリに保持する。
図4の例では、メモリが保持するタッチ開始位置の座標を、タッチ開始位置座標155として示す。入力操作受付部191は、タッチスクリーン130の検出結果(ユーザの指がタッチスクリーン130に接近している座標、および、ユーザの指がタッチスクリーン130に接近していないこと(検出結果「null」)、タッチオフ状態)を、一定フレーム分、バッファメモリ154に格納する。バッファメモリ154は、タッチスクリーン130における検出結果を、各フレームについて一定フレーム分(図4の例では、メモリ領域fp〔0〕〜メモリ領域fp〔10〕までの11フレーム分)、格納することができる。バッファメモリ154は、例えばリングバッファとして実現することができるが、これに限られない。
分図(A)の例では、ユーザがタッチスクリーン130を押した位置(タッチ開始位置の座標)を、押下位置30A(タッチスクリーン130の座標(x0,y0))として示す。
図4の分図(B)において、ユーザは、タッチスクリーン130に対してドラッグ操作を行って、タッチスクリーン130に対する押下位置を、押下位置30Aから押下位置30B(タッチスクリーン130の座標(x9,y9))まで10フレーム(メモリ領域fp〔0〕〜メモリ領域fp〔9〕までの10フレーム分)で移動させる。入力操作受付部191は、タッチスクリーン130の検出結果をバッファメモリ154に格納し、バッファメモリ154に保持される値を参照して、タッチスクリーン130に対するユーザの操作をドラッグ操作と判別する。
図4の分図(C)において、ユーザは、タッチスクリーン130を押している位置を、押下位置30Bから押下位置30C(タッチスクリーン130の座標(x14,y14))まで、5フレーム(メモリ領域fp〔10〕、fp〔0〕、fp〔1〕、fp〔2〕、fp〔3〕の5フレーム分)で移動させる。
図4の分図(D)は、分図(B)および分図(C)においてユーザが行なった入力操作に対する移動操作検出部193の検出結果を示す。プロセッサ190は、移動操作検出部193として、バッファメモリ154において、タッチスクリーン130が検出する押下位置の座標を書き込む対象となるメモリ領域がいずれであるかを示す情報(バッファメモリ154の書き込み位置)を管理している。
分図(B)において、タッチナウの座標が、座標(x9、y9)であるとする。移動操作検出部193は、入力操作受付部191の判別結果に基づいて、ユーザがドラッグ操作を行ったことを検出する。ある局面において、移動操作検出部193は、タッチ開始位置の座標31Aを起点として、座標31Aとタッチ継続位置の座標31Bとによって規定されるベクトル32B((x9−x0),(y9−y0))を、自キャラクタを移動させる方向として検出する。
分図(C)において、タッチナウの座標が、座標(x14、y14)であるとする。移動操作検出部193は、入力操作受付部191の判別結果に基づいて、ユーザがドラッグ操作を行ったことを検出する。ある局面において、移動操作検出部193は、タッチ開始位置の座標31Aを起点として、座標31Aとタッチ継続位置の座標31Cとによって規定されるベクトル31C((x14−x0),(y14−y0))を、自キャラクタを移動させる方向として検出する。
(カメラ配置制御)
図5は、ある実施形態に従う仮想空間および仮想カメラについて説明する図である。ある局面において、携帯端末10のプロセッサ190は、ゲーム進行処理部192として、仮想空間510を規定する。続いて、プロセッサ190は、オブジェクト制御部195として、仮想空間510に建物、木、岩、などのオブジェクトを含むフィールド(マップ)を形成する。オブジェクト制御部195は、仮想空間に形成されるフィールドに、携帯端末10のユーザが操作する自キャラクタ、自キャラクタを攻撃する敵キャラクタ、仮想カメラ520などのオブジェクトを配置する。プロセッサ190は、表示制御部196として、仮想カメラ520が撮影する画像530をディスプレイ132に表示する。
図6および図7を参照して、仮想カメラの視野角について説明する。図6は、仮想カメラ520の視界領域をX方向から見たYZ断面を表す図である。図7は、仮想カメラ520の視界領域をY方向から見たXZ断面を表す図である。
一例として、仮想カメラ520の視野角(視界)は、タッチスクリーン130(ディスプレイ132)の縦横の画素数に応じて定められる。図6を参照して、YZ断面における仮想カメラ520の視野角αは、ディスプレイ132の縦(長辺)の画素数に比例する。図7を参照して、XZ断面における仮想カメラ520の視野角βは、ディスプレイ132の横(短辺)の画素数に比例する。なお、他の局面において、仮想カメラ520の視野角は予め定められていてもよい。次に、カメラ配置制御部194による仮想カメラのカメラワークについて説明する。
(仮想カメラのカメラワーク−ノーマルフィールド)
図8は、ある実施形態に従うノーマルフィールドにおける仮想カメラ520のカメラワークについて説明する図である。図8の例において、ゲームプログラム151は、アクションロールプレイングゲームであるとする。プロセッサ190は、オブジェクト制御部195として、敵キャラクタのうち、比較的強力なボスキャラクタが登場しないノーマルフィールドを仮想空間510に形成する。
分図(A)を参照して、タッチスクリーン130には、ユーザが操作する自キャラクタ810、木820,830のオブジェクトが表示されている。分図(B)は、分図(A)に対応する仮想空間510を上方(Y方向)から見た状態を表す。仮想空間510には、仮想カメラ520が配置される。分図(A)においてタッチスクリーン130に表示される画像は、この仮想カメラ520の撮影する画像である。
分図(A)を参照して、ユーザは、ノーマルフィールドに配置される仮想カメラ520の撮影する画像がタッチスクリーン130に表示されている状態において、タッチスクリーン130上で指を左から右にスライドするドラッグ操作840を行なう。分図(B)を参照して、プロセッサ190は、オブジェクト制御部195として、ドラッグ操作840に応じて、自キャラクタ810を右方向850に移動する。プロセッサ190は、カメラ配置制御部194として、ドラッグ操作840に応じて、仮想カメラ520を右方向860に移動する。
図9は、図8においてドラッグ操作840を行なった後のタッチスクリーン130の表示および仮想カメラ520の配置位置について説明する図である。分図(A)および(B)を参照して、自キャラクタ810は、ドラッグ操作840に応じて、木820,830に対して右方向に平行移動した位置にいる。
上記一連の移動動作は、プロセッサ190が、移動操作検出部193、カメラ配置制御部194、およびオブジェクト制御部195として実行する。具体的には、移動操作検出部193が、タッチスクリーン130に対するドラッグ操作を受け付けている場合に、タッチ開始位置を起点とし、タッチ継続位置を終点とするベクトル方向を検出する。カメラ配置制御部194およびオブジェクト制御部195はそれぞれ、ノーマルフィールドにおいて、移動操作検出部193が検出するベクトル方向に仮想カメラ520および自キャラクタを平行移動する。
図10は、ユーザの入力操作に応じて自キャラクタ810を移動するときのユーザインタフェース(UI)画像について説明する図である。分図(A)において、オブジェクト制御部195は、ユーザがタッチスクリーン130をタッチした位置、すなわちタッチ開始位置1010にUI画像1020を表示する。
分図(B)は、分図(A)からユーザがタッチ位置を右方向にドラッグ操作1030を行なった場合のタッチスクリーン130に表示される画面である。プロセッサ190は、オブジェクト制御部195として、ドラッグ操作1030のタッチ開始位置からタッチ継続位置へと向かうように、円形状のUI画像1020を変形させた画像をタッチスクリーン130に表示する。これにより、ユーザは、タッチ開始位置1010を視認しつつタッチ継続位置を移動させることで、移動操作検出部193に自キャラクタ810の移動方向を入力できる。そのため、ユーザは、自キャラクタ810を移動させたい位置が仮想空間のいずれであっても、自キャラクタ810を容易かつ直感的に移動させることができる。その結果、ゲームのユーザに対する興趣性がいっそう向上する。
(仮想カメラのカメラワーク−ボスフィールド)
図11は、ある実施形態に従うボスフィールドにおける仮想カメラ520のカメラワークについて説明する図(その1)である。図11の例において、ゲームプログラム151は、例えばアクションロールプレイングゲームである。プロセッサ190は、オブジェクト制御部195として、敵キャラクタのうち、比較的強力なボスキャラクタが登場するボスフィールドを仮想空間510に形成する。分図(A)を参照して、タッチスクリーン130には、自キャラクタ810、およびボスキャラクタ1110が表示されている。
分図(B)は、分図(A)に対応する仮想空間510を上方から見た状態を表す。仮想空間510には、自キャラクタ810、ボスキャラクタ1110、仮想カメラ520の他、木1130のオブジェクトが存在する。分図(A)において、木1130は、ボスキャラクタ1110によって隠れているため、タッチスクリーン130に表示されていない。
分図(A)を参照して、ユーザは、ボスフィールドに配置される仮想カメラ520の撮影する画像がタッチスクリーン130に表示されている状態において、タッチスクリーン130上で指を左から右にスライドするドラッグ操作1120を行なう。分図(B)を参照して、プロセッサ190は、オブジェクト制御部195として、右方向に従うドラッグ操作1120に応じて、ボスキャラクタ1110を中心とした反時計まわりの円運動方向1140に移動するように、自キャラクタ810を移動させる。同様に、プロセッサ190は、カメラ配置制御部194として、ドラッグ操作1120に応じて、ボスキャラクタ1110を中心とした反時計まわりの円運動方向1150に移動するように仮想カメラ520を移動させる。
図12は、図11においてドラッグ操作1120を行なった後のタッチスクリーン130の表示および仮想カメラ520の配置位置について説明する図である。分図(B)を参照して、自キャラクタ810および仮想カメラ520は、ドラッグ操作1120に応じて、図11の分図(B)の状態から右斜め前方方向に移動した位置にいる。仮想カメラ520は、移動後においても、ボスキャラクタ1110の方向を向いている。これにより、分図(A)に示されるように、タッチスクリーン130には、ボスキャラクタ1110の右斜め後方に木1130が表示される。
図13は、ある実施形態に従うボスフィールドにおける仮想カメラ520のカメラワークについて説明する図(その2)である。図13において、ユーザは、図11に示される右方向のドラッグ操作1120ではなく、上方向のドラッグ操作1310を行なう。
分図(A)を参照して、ユーザは、自キャラクタ810がボスフィールドに配置される状態で、タッチスクリーン130上で指を下から上にスライドするドラッグ操作1310を行なう。分図(B)を参照して、プロセッサ190は、オブジェクト制御部195として、上方向に従うドラッグ操作1310に応じて、自キャラクタ810を上方向1320に自キャラクタ810を移動させる。同様に、プロセッサ190は、カメラ配置制御部194として、ドラッグ操作1310に応じて、仮想カメラ520を上方向1330に移動させる。
図14は、図13においてドラッグ操作1310を行なった後のタッチスクリーン130の表示および仮想カメラ520の配置位置について説明する図である。分図(A)および(B)を参照して、自キャラクタ810および仮想カメラ520の配置位置は、図13における配置位置よりも、ボスキャラクタ1110に近くなる。
(カメラワークの小括)
カメラ配置制御部194およびオブジェクト制御部195はそれぞれ、ボスフィールドに配置される仮想カメラ520が撮影する画像がタッチスクリーン130に表示されている状態において、移動操作検出部193が検出する方向に応じて、ボスキャラクタ1110を中心に、仮想カメラ520および自キャラクタ810を移動させる。
上記によれば、自キャラクタ810とボスキャラクタ1110とが戦うときに、タッチスクリーン130に常にボスキャラクタ1110が表示される。これにより、ユーザは、ボスキャラクタ1110との戦闘時において、ボスキャラクタ1110の動き(例えば、火を吹く動作など)を常に確認できる。そのため、ユーザは、ボスキャラクタ1110の動作に応じて自キャラクタ810をどのように操作すればよいか考えながら、緊張感をもってゲームを楽しむことができる。その結果、ゲームプログラム151は、ユーザに対する興趣性を向上させ得る。
一方、カメラ配置制御部194およびオブジェクト制御部195はそれぞれ、ノーマルフィールドに配置される仮想カメラ520が撮影する画像がタッチスクリーン130に表示されている状態において、移動操作検出部193が検出する方向に仮想カメラ520および自キャラクタ810を移動する。
ノーマルフィールドにおいてもボスフィールドのように常に敵キャラクタを中心としたカメラワークを採用する場合、ユーザは、ゲームをプレイするときに常に高い緊張感を感じてしまい、ゲームをプレイすることに対して億劫になり得る。そのため、ゲームプログラム151は、ボスキャラクタが登場しないノーマルフィールドにおいて、ドラッグ操作により定まる方向に仮想カメラ520および自キャラクタ810を移動させる。これにより、ユーザは、ノーマルフィールドにおいて、ほどよい緊張感を保ちながら、複数の敵キャラクタとの戦闘および、アイテム収集などを楽しむことができる。
このように、ゲームプログラム151は、ノーマルフィールドとボスフィールドにおいて仮想カメラ520のカメラワークを切り替えることによって、ユーザに対して緊張感のメリハリを提供できる。その結果、ゲームプログラム151は、ユーザに対する興趣性を向上させ得る。
(携帯端末10とサーバ20とのやりとり)
図15および16は、上記一連の仮想カメラ520のカメラワークの切り替え、およびマルチプレイを実現するための携帯端末10およびサーバ20の動作例について説明するフローチャートである。図15および16に示される処理は、プロセッサ190がゲームプログラム151を、プロセッサ29がゲームプログラム251をそれぞれ実行することにより実現される。
ステップS1505において、サーバ20のプロセッサ29は、ユーザが操作する携帯端末10からの、マルチプレイに参加するための参加リクエストを受け付ける。図15および16の例において、ゲームプログラム151および251は、例えばアクションロールプレイングゲームであるとする。
ステップS1510において、携帯端末10のプロセッサ190は、サーバ20に対してマルチプレイに参加するための参加リクエストを送信する。
ステップS1520において、サーバ20のプロセッサ29は、サーバ処理部292として、マルチプレイに参加するユーザが規定人数に達したと判断したことに応じて、サーバ側の仮想空間を規定して、仮想空間にノーマルフィールドを形成するためのオブジェクトを配置する。さらに、プロセッサ29は、送受信部291として、ノーマルフィールドを形成するためのオブジェクトの情報を携帯端末10に送信する。
ステップS1525において、携帯端末10のプロセッサ190は、オブジェクト制御部195として、サーバ20から受信した情報に基づいてゲーム情報152に格納されるオブジェクトを仮想空間510に配置する。これにより、プロセッサ190は、仮想空間510にノーマルフィールドを形成する。
ステップS1530において、携帯端末10のプロセッサ190は、オブジェクト制御部195として、ゲーム情報152に格納される自キャラクタ810の情報に従い、自キャラクタ810をノーマルフィールドに配置(生成)する。さらに、プロセッサ190は、自キャラクタ810の情報をサーバ20に送信する。
ステップS1535において、サーバ20のプロセッサ29は、データ管理部293として、携帯端末10から受信したキャラクタ情報に基づいてユーザ管理テーブル253Aに格納される自キャラクタ810の情報を保存する。なお、同ステップにおいて、プロセッサ29は、マルチプレイに参加する他の携帯端末10から、当該他の携帯端末10のユーザが操作するキャラクタ(以下、「他キャラクタ」とも称する)の情報を受信して、ユーザ管理テーブル253Aの情報を保存する。
ステップS1540において、サーバ20のプロセッサ29は、サーバ処理部292として、ユーザ管理テーブル253Aに格納される他キャラクタの情報に基づいて、ノーマルフィールドに他キャラクタを配置する。さらに、プロセッサ29は、送受信部291として、他キャラクタの情報を携帯端末10に送信する。
ステップS1545において、携帯端末10のプロセッサ190は、オブジェクト制御部195として、サーバ20から受信した他キャラクタの情報に基づいて他キャラクタを仮想空間510に形成されるノーマルフィールドに配置する。
ステップS1550において、サーバ20のプロセッサ29は、サーバ処理部292として、オブジェクト管理テーブル252Aを参照してノーマルフィールドにボスキャラクタではない敵キャラクタを配置する。また、プロセッサ29は、敵キャラクタの情報をマルチプレイに参加する各携帯端末10に送信する。
ステップS1555において、携帯端末10のプロセッサ190は、オブジェクト制御部195として、サーバ20から受信した敵キャラクタの情報に基づいて、敵キャラクタをノーマルフィールドに配置する。
ステップS1560において、携帯端末10のプロセッサ190は、移動操作検出部193として、タッチスクリーン130に対するドラッグ操作を検出し、当該ドラッグ操作のタッチ開始位置およびタッチ継続位置により定まる方向を検出する。プロセッサ190は、カメラ配置制御部194およびオブジェクト制御部195として、移動操作検出部193が検出した方向に、仮想カメラ520および自キャラクタ810を移動させる。さらに、プロセッサ190は、移動後の自キャラクタ810の仮想空間510における位置座標をサーバ20に送信する。なお、他の局面において、プロセッサ190は、仮想空間における自キャラクタ810が向いている方向、自キャラクタ810の移動速度などを併せてサーバ20に送信し得る。
ステップS1565において、サーバ20のプロセッサ29は、サーバ処理部292として、携帯端末10から受信した自キャラクタ810の位置座標に基づいて、サーバ20側の仮想空間(ノーマルフィールド)の自キャラクタ810の位置を更新する。なお、同ステップにおいて、プロセッサ29は、サーバ20側のノーマルフィールドにおける他キャラクタの位置も更新する。プロセッサ29は、更新した他キャラクタの位置情報を携帯端末10に送信する。
ステップS1570において、携帯端末10のプロセッサ190は、オブジェクト制御部195として、サーバ20から受信した他キャラクタの位置情報に基づいて、仮想空間510における他キャラクタを移動する。
ステップS1575において、サーバ20のプロセッサ29は、サーバ処理部292として、敵キャラクタを移動する。また、プロセッサ29は、送受信部291として機能し、移動後の敵キャラクタの位置情報を携帯端末10に送信する。
ステップS1580において、携帯端末10のプロセッサ190は、オブジェクト制御部195として、サーバ20から受信した敵キャラクタの位置情報に基づいて、仮想空間510における敵キャラクタを移動する。
携帯端末10およびサーバ20はそれぞれ、その他ゲームを進行するために必要な処理を実行する。ゲームを進行するために必要な処理は、一例として、自キャラクタおよび敵キャラタの攻撃処理、これら攻撃のヒット判定処理、ダメージ処理、ドロップアイテム処理、経験値処理、アイテム取得処理、などが挙げられる。
ステップS1585において、サーバ20のプロセッサ29は、サーバ処理部292として、ボスフィールドに移行するための予め定められた条件を満たしたか否かを判定する。当該予め定められた条件は、一例として、ノーマルフィールドに配置される敵キャラクタを規定数以上倒したこと、計測部295が計時する時間が規定時間に到達したこと、所定アイテムを規定数以上獲得したこと、などを含む。
プロセッサ29は、ボスフィールドに移行するための予め定められた条件が満たされたと判断した場合(ステップS1585においてYES)、処理をステップS1590に進める。そうでない場合(ステップS1585においてNO)、プロセッサ29は、処理をステップS1550に戻す。
ステップS1590において、プロセッサ29は、ボスフィールドに移行するための移行通知をマルチプレイに参加する携帯端末10に送信する。
ステップS1595において、携帯端末10のプロセッサ190は、サーバ20からボスフィールドへの移行通知を受信したか否かを判断する。プロセッサ190は、移行通知を受信したと判断した場合(ステップS1595においてYES)、処理をステップS1605(図16)に進める。そうでない場合(ステップS1595においてNO)、プロセッサ190は、処理をステップS1555に戻す。ある局面において、携帯端末10は、ステップS1555からステップS1595までの一連の処理を60fps(frames per second)で実行する。
図16を参照して、ステップS1605において、携帯端末10のプロセッサ190は、ゲーム進行処理部192および表示制御部196として、ゲーム情報152に保持される演出画像をタッチスクリーン130に表示する。
図17は、ある実施形態に従う演出画像の一例を説明する図である。ユーザは、タッチスクリーン130に表示される演出画像を見ることによって、これからボスキャラクタが登場することを理解する。また、ユーザは、演出画像を見ることによって、携帯端末10がノーマルフィールドからボスフィールドへの移行処理を行なっている間も、ゲームを楽しむことができる。なお、他の局目において、プロセッサ190は、演出画像に替えて、または演出画像に加えてボスキャラクタが登場することを示す演出動画をタッチスクリーン130に表示してもよい。
図16を再び参照して、ステップS1610において、サーバ20のプロセッサ29は、サーバ処理部292として、サーバ側の仮想空間にボスフィールドを形成するためのオブジェクトを配置する。さらに、プロセッサ29は、送受信部291として、ボスフィールドを形成するためのオブジェクトの情報を携帯端末10に送信する。
ステップS1615において、携帯端末10のプロセッサ190は、サーバ20から受信した情報に基づいて、仮想空間510にボスフィールドを形成する。これにより、仮想空間510に形成されるフィールドは、ノーマルフィールドからボスフィールドへと切り替わる。
ステップS1620、S1625、S1630、およびS1635の処理はそれぞれ、上述したステップS1530、S1535、S1540、およびS1545の処理と同様であるため、その説明は繰り返さない。プロセッサ190は、ステップS1620の処理(自キャラクタ810をボスフィールドに配置する処理)を行なうことによって、自キャラクタ810をノーマルフィールドからボスフィールドへ移動させる。
ステップS1640において、サーバ20のプロセッサ29は、サーバ処理部292として、ボスキャラクタ1110をサーバ20側のボスフィールドに配置する。また、プロセッサ29は、ボスキャラクタ1110の情報を、携帯端末10に送信する。
ステップS1645において、携帯端末10のプロセッサ190は、オブジェクト制御部195として、サーバ20から受信したボスキャラクタ1110の情報に基づいて、ボスキャラクタ1110をボスフィールドに配置する。
ステップS1650において、携帯端末10のプロセッサ190は、移動操作検出部193として、タッチスクリーン130に対するドラッグ操作を検出し、当該ドラッグ操作のタッチ開始位置およびタッチ継続位置により定まる方向を検出する。プロセッサ190は、カメラ配置制御部194、およびオブジェクト制御部195として、移動操作検出部193が検出した方向に応じて、ボスキャラクタ1110を中心に、仮想カメラ520および自キャラクタ810を移動させる。さらに、プロセッサ190は、移動後の自キャラクタ810の仮想空間510における位置座標をサーバ20に送信する。
ステップS1655、S1660、S1665、およびS1670の処理はそれぞれ、上述したステップS1560、S1565、S1570、およびS1575の処理と同様であるため、その説明は繰り返さない。
ステップS1675、およびステップS1680において、サーバ20のプロセッサ29、および携帯端末10のプロセッサ190はそれぞれ、ボスキャラクタ1110を倒したか否かを判断する。
ある局面において、プロセッサ190は、自キャラクタ810および他キャラクタのボスキャラクタ1110に対する攻撃により、ゲーム情報152に保持されるボスキャラクタ1110の体力(ヒットポイント)が0になると、ボスキャラクタ1110を倒したと判断する。同様に、プロセッサ29は、自キャラクタ810および他キャラクタのボスキャラクタ1110に対する攻撃により、オブジェクト管理テーブル252Aに保持されるボスキャラクタ1110の体力が0になると、ボスキャラクタ1110を倒したと判断する。
プロセッサ190およびプロセッサ29はそれぞれ、ボスキャラクタ1110を倒したと判断した場合(ステップS1675においてYES、ステップS1680においてYES)、経験値処理およびドロップアイテム処理などの各種処理を行なった上で、一連のマルチプレイを終了する。そうでない場合(ステップS1675においてNO、ステップS1680においてNO)、プロセッサ190およびプロセッサ29はそれぞれ、処理をステップS1650、ステップS1655に戻す。
上記の例において、携帯端末10のプロセッサ190は、仮想空間510にノーマルフィールドを形成した後に、同一の仮想空間510にボスフィールドを形成する構成であった。他の局面において、プロセッサ190は、複数の仮想空間を管理可能に構成され、第1の仮想空間にノーマルフィールドを形成し、第2の仮想空間にボスフィールドを形成する構成であってもよい。
かかる場合、ステップS1510において、プロセッサ190は、サーバ20からノーマルフィールドおよびボスフィールドを形成するためのオブジェクトの情報を受信し得る。プロセッサ190は、第1の仮想空間にノーマルフィールドを形成するとともに、当該ノーマルフィールドに自キャラクタ810、他キャラクタ、および敵キャラクタなどのオブジェクトを配置する。また、プロセッサ190は、第2の仮想空間にボスフィールドを形成する。
上記構成によれば、携帯端末10のプロセッサ190は、図16に示されるステップS1615の処理を予め実行できる。したがって、プロセッサ190は、ノーマルフィールドからボスフィールドへと遷移するための処理に要する時間を短くできる。これにより、ユーザは、よりシームレスにノーマルフィールドからボスフィールドへと移行して、ボスキャラクタとの戦闘を楽しむことができる。その結果、ゲームのユーザに対する興趣性が向上し得る。
さらに他の局面において、サーバ20のプロセッサ29も同様に、複数の仮想空間を管理可能に構成され、ノーマルフィールドを形成する仮想空間と、ボスフィールドを形成する仮想空間とが異なる仮想空間であってもよい。かかる場合、プロセッサ29は、図16に示されるステップS1610を予め実行できる。当該構成によれば、ゲーム配信システム1は、さらにノーマルフィールドからボスフィールドへと遷移するための処理に要する時間を短くできる。
(ボスフィールドへの移行制御に関する他の構成)
上記の例において、ボスフィールドへ移行するための予め定められた条件が満たされた場合、自キャラクタ810は必ずノーマルフィールドからボスフィールドへと移動する構成であった。他の局面において、プロセッサ190は、ステップS1660において、演出画像に替えて、または演出画像に加えて、ノーマルフィールドからボスフィールドへと移行するか否かを問い合わせる画像を表示してもよい。
図18は、ある実施形態に従うノーマルフィールドからボスフィールドへ移行するか否かを問い合わせる画像例を説明する図である。図18を参照して、タッチスクリーン130には、ボスキャラクタ1110と、ボスフィールドへ移行するか否かを問い合わせるメッセージ1810と、YESボタン1820と、NOボタン1830とが表示されている。
ユーザは、ボスキャラクタ1110と戦いたい場合、換言すれば、ノーマルフィールドからボスフィールドへと移行したい場合、メッセージ1810の問い合わせに対する肯定を示すYESボタン1820をタッチする。携帯端末10のプロセッサ190は、YESボタン1820の押下に応じて、その旨を知らせる信号をサーバ20に送信して、処理をステップS1615に進める。サーバ20は、当該信号を受信して、処理をステップS1610に進める。
一方、ユーザは、ボスキャラクタ1110と戦いたくない場合、メッセージ1810の問い合わせに対する否定を示すNOボタン1830をタッチする。プロセッサ190は、NOボタン1830の押下に応じて、その旨を知らせる信号をサーバ20に送信して、処理をステップS1555に戻す。サーバ20は、当該信号を受信して、処理をステップS1550に戻す。
さらに他の局面において、サーバ20は、ステップS1505においてマルチプレイを受け付けるユーザの数(たとえば、8人)よりも、ボスフィールドへ移行可能なユーザの数(たとえば、4人)を少なく規定する。この場合、携帯端末10のプロセッサ190またはサーバ20のプロセッサ29は、ボスフィールドへ移行するための予め定められた条件を満たしたと判断したことに応じて、ボスフィールドへ移行するユーザを選定する。プロセッサ29は、ステップS1590において、選定したユーザが操作する携帯端末10に対して、ボスフィールドへ移行する旨の移行通知を送信する。一例として、プロセッサ29は、ボスフィールドへ移行するユーザを、ランダムで選定する。
さらに他の局面において、プロセッサ29は、ボスフィールドへ移行可能なユーザの数よりも、ノーマルフィールドに存在する自キャラクタ810と他キャラクタとの合計人数が少ない場合に、当該差分人数分のノンプレイヤキャラクタをボスフィールドに配置し得る。ノンプレイヤキャラクタとは、自律動作を行ない、自キャラクタ810および他キャラクタとともにボスキャラクタ1110と戦うキャラクタのことをいう。
(他キャラクタを示すユーザインタフェース)
次に、ノーマルフィールドにおけるユーザインタフェースと、ボスフィールドにおけるユーザインタフェースとの相違について説明する。
図19は、ノーマルフィールドにおけるユーザインタフェース例を説明する図である。分図(A)を参照して、タッチスクリーン130には、自キャラクタ810と、木1910,1920と、ボスキャラクタではない敵キャラクタ1930と、他キャラクタ1940とが表示されている。すなわち、タッチスクリーン130に表示される画像は、ノーマルフィールドの画像である。他キャラクタ1940の上部には、当該キャラクタを識別するための情報として、当該キャラクタの名前1950が表示されている。
分図(B)は、分図(A)に対応する仮想空間510を上方(Y方向)から見た状態を表す。仮想カメラ520の視界外の仮想空間510には、他キャラクタ1960、1970、1980、および1990が存在する。
分図(A)を再び参照して、ノーマルフィールドに自キャラクタ810が存在する状態において、タッチスクリーン130には、仮想カメラ520の視界外に存在する他キャラクタの情報は表示されていない。
ある局面において、ユーザは、ノーマルフィールドにおいて、必ずしも他キャラクタと協力して敵キャラクタ1930を倒すとは限らない。そのため、ノーマルフィールドに自キャラクタ810が存在する状態において、タッチスクリーン130に仮想カメラ520の視界外に存在する他キャラクタの情報を表示した場合、ユーザによっては当該情報が邪魔になり得る。
したがって、携帯端末10のプロセッサ190は、ノーマルフィールドに自キャラクタ810が存在する状態において、タッチスクリーン130に仮想カメラ520の視界外に存在する他キャラクタの情報を表示しない。これにより、ゲームプログラム151は、限られたタッチスクリーン130のスペースを有効利用できる。
図20は、ある実施形態に従うボスフィールドにおけるユーザインタフェース例を説明する図である。分図(A)を参照して、タッチスクリーン130には、自キャラクタ810と、ボスキャラクタ1110と、他キャラクタ1940とに加え、さらに、UI画像2010、2020が表示されている。すなわち、タッチスクリーン130に表示される画像は、ボスフィールドの画像である。
分図(B)は、分図(A)に対応する仮想空間510を上方(Y方向)から見た状態を表す。仮想カメラ520の視界外の仮想空間510には、他キャラクタ1970、および1980が存在する。
分図(A)を再び参照して、UI画像2010は、仮想カメラ520の視界外の他キャラクタ1980の存在を示す画像である。UI画像2010は、仮想カメラ520が撮影する画像の端部の、自キャラクタ810と他キャラクタ1980との位置関係に応じた位置に表示される。UI画像2020の上部には、自キャラクタ810と他キャラクタ1980との距離を示すUI画像2030が表示される。換言すれば、プロセッサ190は、仮想カメラ520が撮影する画像に、当該画像の自キャラクタ810と他キャラクタ1980との位置関係に応じた位置に、他キャラクタの情報を示す画像を重ね合わせた画像をタッチスクリーン130に表示する。
分図(A)において、ユーザは、UI画像2010および2030を見て、自キャラクタ810の右上方向に3m離れた位置に他キャラクタが存在することを認識する。同様に、ユーザは、UI画像2020および2040を見て、自キャラクタ810の左下9mの位置に他キャラクタが存在することを認識する。
ある局面において、ノーマルフィールドと異なり、ユーザは、ボスフィールドにおいて、他キャラクタと協力してボスキャラクタ1110と戦う。このような状況において、ユーザは、仮想カメラ520の視界外の他キャラクタの情報も必要とする。したがって、プロセッサ190は、タッチスクリーン130に、仮想カメラ520の視界外の他キャラクタの情報を表示する。
上記によれば、ゲームプログラム151は、ユーザが必要とする情報を、ユーザが必要とするときに、タッチスクリーン130に表示できる。さらに、ゲームプログラム151は、タッチスクリーン130の、自キャラクタ810と仮想カメラ520の視界外の他キャラクタとの位置関係に応じた位置に、他キャラクタの情報を表示する。これにより、ユーザは、当該情報を直感的に理解できる。
なお、他の局面において、タッチスクリーン130の、自キャラクタ810と仮想カメラ520の視界外の他キャラクタとの位置関係に応じた位置に表示する他キャラクタの情報は、距離の情報以外に、図21に示されるように他キャラクタを識別する識別情報2110、2120であってもよい。例えば当該識別情報は、他キャラクタの名前であり得る。
さらに他の局面において、プロセッサ190は、ノーマルフィールドにおいても、仮想カメラ520の視界外の他キャラクタの情報を表示する構成であってもよい。ユーザは、ノーマルフィールドにおいても他キャラクタと協力して敵キャラクタを倒したり、他キャラクタとのコミュニケーションを楽しみ得るためである。一例として、携帯端末10のプロセッサ190は、ノーマルフィールドにおいて、自キャラクタ810と他キャラクタとの距離および方位を示すレーダー画像を表示し得る。なお、この場合においても、プロセッサ190は、タッチスクリーン130の、自キャラクタ810と仮想カメラ520の視界外の他キャラクタとの位置関係に応じた位置には、他キャラクタの情報は表示しない。
図22は、ボスフィールドにおいて仮想カメラ520の視界外の他キャラクタとのコミュニケーションをとるための動作例について説明する図である。分図(A)を参照して、ある局面において携帯端末10のプロセッサ190は、ボスフィールドにおいて、タッチスクリーン130にチャット開始ボタン2210を表示する。プロセッサ190は、チャット開始ボタン2210の押下に応じて、メッセージ画像2230、2240を含むメッセージ画像群2220を表示する。
分図(B)を参照して、プロセッサ190は、メッセージ画像2230の押下に応じて、自キャラクタ810の上部にメッセージ2250を表示する。
ある局面において、プロセッサ190は、サーバ20から、他キャラクタを操作するユーザによるメッセージ画像2240の押下を示す信号を受信する。当該他キャラクタが仮想カメラ520の視界内(たとえば、分図(B)における他キャラクタ1940)に存在する場合、プロセッサ190は、当該他キャラクタの上部にメッセージ画像2240を表示する。
一方、当該他キャラクタが仮想カメラ520の視界外に存在する他キャラクタである場合、プロセッサ190は、当該他キャラクタの存在を示すUI画像の近くにメッセージ画像2240を表示する。一例として、プロセッサ190は、自キャラクタと他キャラクタとの距離を示すUI画像から予め定められた距離(たとえば、3cm)内の領域にメッセージ画像を表示する。分図(B)に示される例において、プロセッサ190は、UI画像2040の上にメッセージ画像2240を表示する。
上記によれば、ユーザは、ボスフィールドにおいても、他キャラクタとの円滑なコミュニケーションを楽しむことができる。その結果、ゲームのユーザに対する興趣性が向上し得る。
なお、他の局面において、プロセッサ190は、チャット開始ボタン2210の押下に応じて、メッセージ画像群2220に替えて、またはメッセージ画像群2220に加えて、文字入力を受け付けるためのUI画像を表示する構成であってもよい。かかる場合、ユーザは、他キャラクタと、より自由度の高いコミュニケーションを図れる。
<付記>
(付記1) ゲームプログラム(151)は、タッチ操作による入力操作を受け付けるタッチスクリーン(130)と、プロセッサ(190)とを備える携帯端末(10)で実行される。ゲームプログラムは、プロセッサに、仮想空間(510)を規定するステップと、仮想空間に、複数のフィールドのうちの1のフィールドを形成するステップと、仮想空間に形成されるフィールドに、仮想カメラ(520)と、携帯端末のユーザが操作する自キャラクタ(810)と、他の携帯端末のユーザが操作する他キャラクタとを配置するステップと、複数のフィールドのうちの第1のフィールドにおいて、タッチスクリーンに対するドラッグ操作を受け付けている場合に、ドラッグ操作におけるタッチスクリーンのタッチ開始位置と、タッチ継続位置との位置関係により定まる方向に自キャラクタおよび仮想カメラを移動させるステップ(S1560)と、複数のフィールドのうちの第2のフィールドにおいて、タッチスクリーンに対するドラッグ操作を受け付けている場合に、定まる方向に応じて、第2のフィールドに配置される敵キャラクタを中心に、自キャラクタおよび仮想カメラを移動させるステップ(S1650)と、第2のフィールドに配置される仮想カメラの視界領域に他キャラクタが存在しない場合に、当該仮想カメラが撮影する画像に、当該画像の端部の自キャラクタと他キャラクタとの位置関係に応じた位置に、他キャラクタの情報を示す画像を重ね合わせた画像をタッチスクリーンに表示するステップと、第1のフィールドに配置される仮想カメラの視界領域に他キャラクタが存在しない場合に、当該仮想カメラが撮影する画像に、当該画像の端部の自キャラクタと他キャラクタとの位置関係に応じた位置に、他キャラクタの情報を示す画像を重ね合わせることなく、当該仮想カメラが撮影する画像をタッチスクリーンに表示するステップとを実行させる。
これにより、ユーザは、他キャラクタと協力してボスキャラクタと戦うときに、タッチスクリーン上で、仮想カメラの視界外に存在する他キャラクタの情報を確認できる。また、実施形態に従うゲームプログラムは、タッチスクリーン上の、自キャラクタと当該他キャラクタとの位置関係に応じた位置に、当該他キャラクタの情報を表示する。このように、実施形態に従うゲームプログラムは、ユーザの必要とする情報を、ユーザが必要とするときに、ユーザの理解しやすい形態で表示するため、ゲームの興趣性を向上し得る。
(付記2) (付記1)において、他キャラクタの情報は、他キャラクタを識別する情報を含む。
これにより、ユーザは、タッチスクリーン上で、仮想カメラの視界外に存在する他キャラクタの識別情報(たとえば、他キャラクタの名前)を確認できる。ユーザは、どの他キャラクタがどの方向にいるのかを理解できるため、より戦略的にボスキャラクタと戦うことができる。
(付記3) (付記1)または(付記2)において、他キャラクタの情報は、自キャラクタと他キャラクタとの距離の情報を含む。
これにより、ユーザは、タッチスクリーン上で、自キャラクタと仮想カメラの視界外に存在する他キャラクタの距離および方位を確認できる。そのため、ユーザは、より戦略的にボスキャラクタと戦うことができる。
(付記4) (付記1)から(付記3)のいずれかにおいて、ゲームプログラムは、第2のフィールドに配置される仮想カメラの撮影する画像に他キャラクタの情報を示す画像を重ね合わせた画像をタッチスクリーンに表示するステップは、他キャラクタを操作するユーザと連絡を取るためのメッセージおよび画像のうち少なくとも一方を他キャラクタの情報を示す画像から予め定められた距離内の領域に表示することを含む。
これにより、ユーザは、仮想カメラの視界外に存在する他キャラクタのうち、どの方位にいる他キャラクタがメッセージを発信しているのかを直感的に理解できる。そのため、ユーザは、仮想カメラの視界外に存在する他キャラクタとの連携をより取りやすくなり、より戦略的にボスキャラクタと戦うことができる。
(付記5) (付記1)から(付記4)のいずれかにおいて、ゲームプログラムは、第1のフィールドに配置される仮想カメラが撮影する画像をタッチスクリーンに表示している場合において、第1の条件が満たされると、自キャラクタを第1のフィールドから第2のフィールドに移動させ、第2のフィールドに配置される仮想カメラが撮影する画像をタッチスクリーンに表示するように切り替えるステップを、プロセッサにさらに実行させる。
これにより、ユーザは、ボスキャラクタが登場しないノーマルフィールドにおいても、ボスキャラクタが登場するかもしれないというほどよい緊張感を感じながらゲームを楽しむことができる。
(付記6) (付記5)において、切り替えるステップは、第1の条件が満たされると、第1のフィールドに配置される仮想カメラが撮影する画像から第2のフィールドに配置される仮想カメラが撮影する画像に切り替わる前に、予め定められた画像をタッチスクリーンに表示することを含む。
これにより、ゲーム配信システム1は、ユーザが演出画像または演出動画像を見ている間に、ノーマルフィールドからボスフィールドへと遷移するための処理を実行できる。ユーザは、ゲーム配信システム1がノーマルフィールドからボスフィールドへと遷移するための処理を行なっている間も、当該演出画像または演出動画像を見ることによってゲームを楽しめる。また、当該演出画像または演出動画像は、ユーザの来るボスキャラクタとの戦闘に対する期待感を高めることができる。
(付記7) (付記5)または(付記6)において、切り替えるステップは、第1の条件が満たされると、自キャラクタを第1のフィールドから第2のフィールドに移動させるか否かをユーザに問い合わせることと、問い合わせに対して肯定する回答を得た場合に、自キャラクタを第1のフィールドから第2のフィールドに移動させ、第2のフィールドに配置される仮想カメラが撮影する画像をタッチスクリーンに表示することとを含む。
これにより、ユーザは、自身の気分に応じてボスキャラクタとの戦闘を行なうか否かを決定できる。
(付記8) (付記5)または(付記6)において、切り替えるステップは、第1の条件が満たされると、第1のフィールドに配置される自キャラクタと他キャラクタとの中から、予め定められた人数のキャラクタを抽出することと、抽出されたキャラクタの中に自キャラクタが含まれている場合、自キャラクタを第1のフィールドから第2のフィールドに移動させ、第2のフィールドに配置される仮想カメラが撮影する画像をタッチスクリーンに表示することとを含む。
これにより、ユーザは、自キャラクタがボスフィールドへ移行できるか否かを楽しむことができる。
(付記9) (付記8)において、切り替えるステップは、第1のフィールドに配置される自キャラクタおよび他キャラクタの合計人数が、予め定められた人数未満である場合に、合計人数と予め定められた人数との差分の数だけ、自律動作を行なうノンプレイヤキャラクタを第2のフィールドに配置することを含む。
これにより、ユーザは、ノーマルフィールドに配置される自キャラクタおよび他キャラクタの合計人数が少ない場合であっても、ノンプレイヤキャラクタと協力してボスキャラクタとの戦闘を楽しむことができる。
以上のようにゲーム配信システム1を構成する携帯端末10およびサーバ20の動作について説明してきたが、携帯端末10で行われる各処理をサーバ20で行なうこととしてもよいし、サーバ20で行われる処理を携帯端末10で行なうこととしてもよい。
例えば、携帯端末10は、タッチスクリーン130に対するユーザの入力操作を受け付けて、受け付けた操作内容をサーバ20へ送信する。サーバ20は、ユーザの入力操作を携帯端末10から受け付けて、ゲームを進行させるための各処理を行い、仮想カメラの配置に基づいて携帯端末10に表示させるための表示画面を生成し、生成した表示画面を、逐次、携帯端末10に表示する。このように、ゲームを進行させるための処理の大部分をサーバ20が担うこととしてもよい。また、ゲームを進行させるための処理の大部分を携帯端末10が担うこととしてもよい。
今回開示された実施形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。