(57)【要約】【課題】同期型イベントを導入するゲームを行うにあたり、特定の端末装置に対する通信の集中による通信負荷の増大を回避して、同期型イベントが安定して実行されるようにする。【解決手段】第１のユーザの端末装置と第２のユーザの端末装置との間で同期型イベントが実行中であるときに、さらに第３のユーザと第１のユーザとイベントを行うべきことになった場合、ゲームサーバは、第１のユーザとの同期型イベントが可能な条件を満たしているか否かについて判定する。条件を満たしている場合、ゲームサーバは、第３のユーザの端末装置と第１のユーザの端末装置との間で同期型イベントを開始させる。これに対して、条件を満たしていない場合、ゲームサーバは、第３のユーザの端末装置に、第１のユーザとの非同期型イベントを開始させる。【選択図】図３
2014028016.tif 000002
【特許請求の範囲】
【請求項１】
端末装置と通信する通信部と、
第１ユーザの端末装置に対して行われた操作と他のユーザの端末装置に対して行われた操作とに応じて前記第１ユーザのキャラクタと前記他のユーザのキャラクタを制御した結果を、前記第１ユーザの端末装置との通信と前記他のユーザの端末装置との通信とにより、前記第１ユーザの端末装置上で実行されるイベントと前記他のユーザの端末装置上で実行されるイベントとに共通に反映させる同期型イベントを実行する同期型イベント実行部と、
前記第１ユーザの端末装置に対して行われる操作の代替である自動処理と他のユーザの端末装置に対して行われた操作とに応じて前記第１ユーザのキャラクタと前記他のユーザのキャラクタを制御した結果を、前記他のユーザの端末装置との通信を経由して、前記他のユーザの端末装置上で実行されるイベントに反映させる非同期型イベントを実行する非同期型イベント実行部と、
前記第１ユーザの端末装置と前記他のユーザのうちの第２ユーザの端末装置との間で前記同期型イベントが実行中であるときに、さらに前記他のユーザのうちの第３ユーザの端末装置と前記第１ユーザの端末装置との間でイベントを開始させるにあたり、所定の条件を満たしている場合には、前記第１ユーザの端末装置と前記第３ユーザの端末装置との間で前記同期型イベントを開始させ、所定の条件を満たしていない場合には、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを開始させるイベント制御部と
を備えるゲーム制御装置。
【請求項２】
前記イベント制御部は、
前記非同期型イベントを開始させた後において、前記所定の条件が満たされていない状態から前記所定の条件が満たされる状態に変化するのに応じて前記同期型イベントに切り替える
請求項１に記載のゲーム制御装置。
【請求項３】
前記非同期型イベント実行部は、
前記同期型イベント実行部が前記第１ユーザの端末装置と他のユーザの端末装置とで実行させる操作入力インターフェースよりも簡易な操作入力インターフェースを他のユーザの端末装置にて実行させる
請求項１または２に記載のゲーム制御装置。
【請求項４】
前記非同期型イベント実行部は、
前記第３ユーザのキャラクタ情報と、実行中の同期型イベントにおいて使用されているのと同じ第１ユーザのキャラクタ情報とを使用して非同期型イベントを開始し、
前記同期型イベント実行部は、前記同期型イベントが開始されるタイミングで記憶部から読み出した第１ユーザのキャラクタ情報と前記同期型イベントが終了したタイミングにおける第１ユーザのキャラクタ情報との差分に基づいて、前記同期型イベントが終了したタイミングにおいて前記記憶部に記憶されている第１ユーザのキャラクタ情報を更新し、
前記非同期型イベント実行部は、非同期型イベントが開始されるタイミングで前記記憶部から読み出した第１ユーザのキャラクタ情報と前記非同期型イベントが終了したタイミングにおける第１ユーザのキャラクタ情報との差分に基づいて、前記非同期型イベントが終了したタイミングにおいて前記記憶部に記憶されている第１ユーザのキャラクタ情報を更新する
請求項１から３のいずれか一項に記載のゲーム制御装置。
【請求項５】
前記イベント制御部は、
前記通信部による第１ユーザの端末装置との通信品質が一定以上であるとの前記条件が満たされた場合に、前記第１ユーザの端末装置と前記第３ユーザの端末装置との間で前記同期型イベントを実行させ、前記通信品質が一定未満であるとして前記条件が満たされない場合に、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを実行させる
請求項１から４のいずれか一項に記載のゲーム制御装置。
【請求項６】
前記イベント制御部は、
前記同期型イベントが実行中であるときの前記第２ユーザの端末装置の数が一定以下であるとの前記条件が満たされた場合に、前記第１ユーザの端末装置と前記第３ユーザの端末装置とを対象とする前記同期型イベントを実行させ、前記第２ユーザの端末装置の数が一定より多いとして前記条件が満たされない場合に、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを実行させる
請求項１から４のいずれか一項に記載のゲーム制御装置。
【請求項７】
前記イベント制御部は、
前記第１ユーザとのイベントを申し込むために前記第３ユーザの端末装置から送信されたイベント申込を前記第１ユーザの端末装置に送信し、前記イベント申込を受け付ける操作が行われた場合に前記第１ユーザの端末装置から送信されるイベント受け付け通知を受信し、
前記イベント受け付け通知が受信されるという前記条件が満たされた場合に、前記第１ユーザの端末装置と前記第３ユーザの端末装置とを対象とする前記同期型イベントを実行させ、前記イベント受け付け通知が受信されないことにより前記条件が満たされない場合に、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを実行させる
請求項１から４のいずれか一項に記載のゲーム制御装置。
【請求項８】
端末装置と通信するする通信部と、
第１ユーザの端末装置に対して行われた操作と他のユーザの端末装置に対して行われた操作とに応じて前記第１ユーザのキャラクタと前記他のユーザのキャラクタを制御した結果を、前記第１ユーザの端末装置との通信と前記他のユーザの端末装置との通信とにより、前記第１ユーザの端末装置上で実行されるイベントと前記他のユーザの端末装置上で実行されるイベントとに共通に反映させる同期型イベントを実行する同期型イベント実行部と、
前記第１ユーザの端末装置に対して行われる操作の代替である自動処理と他のユーザの端末装置に対して行われた操作とに応じて前記第１ユーザのキャラクタと前記他のユーザのキャラクタを制御した結果を、前記他のユーザの端末装置との通信を経由して、前記他のユーザの端末装置上で実行されるイベントに反映させる非同期型イベントを実行する非同期型イベント実行部とを有するゲームシステムの制御方法であって、
前記第１ユーザの端末装置と前記他のユーザのうちの第２ユーザの端末装置との間で前記同期型イベントが実行中であるときに、さらに前記他のユーザのうちの第３ユーザの端末装置と前記第１ユーザの端末装置との間でイベントを開始させるにあたり、所定の条件を満たしている場合には、前記第１ユーザの端末装置と前記第３ユーザの端末装置との間で前記同期型イベントを開始させ、所定の条件を満たしていない場合には、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを開始させるイベント制御ステップを備えるゲームシステムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲーム制御装置及びゲームシステムの制御方法に関する。
【背景技術】
【０００２】
オンラインゲームにおける対戦ゲームなどでは同期型イベントによるものと非同期型イベントによるものとが知られている（例えば、非特許文献１参照）。
同期型イベントによるオンラインゲームでは、ゲームの参加者であるユーザのいずれもがゲームをプレイするための操作を行い、この操作がゲームの進行に反映される。一方、非同期型イベントによるオンラインゲームでは、相手のユーザに対応するキャラクタ等の操作をＮＰＣ（ノンプレイヤーキャラクター）が行うため、相手のユーザが操作を行っていなくとも、自分が操作を行いさえすればゲームが進行する。
【０００３】
同期型イベントは、参加者である各ユーザの操作がゲームの進行に反映されることから、例えば相手ユーザとの攻防を実感しながら楽しめるという利点がある。
一方、非同期型イベントは、相手のユーザが操作を行わなくともゲームを進行させることができるために、相手のユーザの都合に合わせることなく、自分の都合のよいときであればいつでもゲームを行えるという利点がある。
【０００４】
また、現状において、非同期型イベントは、例えば携帯電話やスマートフォンなどの間での無線通信を利用したゲームに多く採用されている。非同期型イベントの場合、例えばゲームを提供するサーバとプレイヤーであるユーザの端末装置との間で通信を行えばよく、他のユーザの端末装置との通信を行う必要がないことから、通信負荷が軽いというのがその理由の１つである。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】「ソーシャルゲーム総合情報誌 アプリＳＴＹＬＥ Ｖｏｌ．２」，株式会社イースト・プレス，平成２３年４月１日，ｐ.２６−ｐ.２９
【発明の概要】
【発明が解決しようとする課題】
【０００６】
例えば上記のような無線通信環境においても、同期型イベントによるゲームを行いたいという要望がある。しかし、例えば不特定多数のユーザ間で対戦などのイベントを行うようなゲームである場合、そのゲームの内容などによっては、或る１人のユーザに対して他のユーザとの同期イベントが集中するような状態が生じる可能性がある。このような状態となってしまった場合、その１人のユーザの端末装置とサーバ間の通信負荷が増大してしまい、ゲームを正常に進行させることができなくなる可能性がある。
【０００７】
本発明は、このような事情に鑑みてなされたもので、同期型イベントを導入するゲームを行うにあたり、特定の端末装置に対する通信の集中による通信負荷の増大を回避して、同期型イベントが安定して実行されるようにすることを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決するために、本発明の一態様としてのゲーム制御装置は、端末装置と通信する通信部と、第１ユーザの端末装置に対して行われた操作と他のユーザの端末装置に対して行われた操作とに応じて前記第１ユーザのキャラクタと前記他のユーザのキャラクタを制御した結果を、前記第１ユーザの端末装置との通信と前記他のユーザの端末装置との通信とにより、前記第１ユーザの端末装置上で実行されるイベントと前記他のユーザの端末装置上で実行されるイベントとに共通に反映させる同期型イベントを実行する同期型イベント実行部と、前記第１ユーザの端末装置に対して行われる操作の代替である自動処理と他のユーザの端末装置に対して行われた操作とに応じて前記第１ユーザのキャラクタと前記他のユーザのキャラクタを制御した結果を、前記他のユーザの端末装置との通信を経由して、前記他のユーザの端末装置上で実行されるイベントに反映させる非同期型イベントを実行する非同期型イベント実行部と、前記第１ユーザの端末装置と前記他のユーザのうちの第２ユーザの端末装置との間で前記同期型イベントが実行中であるときに、さらに前記他のユーザのうちの第３ユーザの端末装置と前記第１ユーザの端末装置との間でイベントを開始させるにあたり、所定の条件を満たしている場合には、前記第１ユーザの端末装置と前記第３ユーザの端末装置との間で前記同期型イベントを開始させ、所定の条件を満たしていない場合には、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを開始させるイベント制御部とを備える。
【０００９】
また、本発明のゲーム制御装置において、前記イベント制御部は、前記非同期型イベントを開始させた後において、前記所定の条件が満たされていない状態から前記所定の条件が満たされる状態に変化するのに応じて前記同期型イベントに切り替えてもよい。
【００１０】
また、本発明のゲーム制御装置において、前記非同期型イベント実行部は、前記同期型イベント実行部が前記第１ユーザの端末装置と他のユーザの端末装置とで実行させる操作入力インターフェースよりも簡易な操作入力インターフェースを他のユーザの端末装置にて実行させてもよい。
【００１１】
また、本発明のゲーム制御装置において、前記非同期型イベント実行部は、前記第３ユーザのキャラクタ情報と、実行中の同期型イベントにおいて使用されているのと同じ第１ユーザのキャラクタ情報とを使用して非同期型イベントを開始し、前記同期型イベント実行部は、前記同期型イベントが開始されるタイミングで記憶部から読み出した第１ユーザのキャラクタ情報と前記同期型イベントが終了したタイミングにおける第１ユーザのキャラクタ情報との差分に基づいて、前記同期型イベントが終了したタイミングにおいて前記記憶部に記憶されている第１ユーザのキャラクタ情報を更新し、前記非同期型イベント実行部は、非同期型イベントが開始されるタイミングで前記記憶部から読み出した第１ユーザのキャラクタ情報と前記非同期型イベントが終了したタイミングにおける第１ユーザのキャラクタ情報との差分に基づいて、前記非同期型イベントが終了したタイミングにおいて前記記憶部に記憶されている第１ユーザのキャラクタ情報を更新してもよい。
【００１２】
また、本発明のゲーム制御装置において、前記イベント制御部は、前記通信部による第１ユーザの端末装置との通信品質が一定以上であるとの前記条件が満たされた場合に、前記第１ユーザの端末装置と前記第３ユーザの端末装置との間で前記同期型イベントを実行させ、前記通信品質が一定未満であるとして前記条件が満たされない場合に、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを実行させてもよい。
【００１３】
また、本発明のゲーム制御装置において、前記イベント制御部は、前記同期型イベントが実行中であるときの前記第２ユーザの端末装置の数が一定以下であるとの前記条件が満たされた場合に、前記第１ユーザの端末装置と前記第３ユーザの端末装置とを対象とする前記同期型イベントを実行させ、前記第２ユーザの端末装置の数が一定より多いとして前記条件が満たされない場合に、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを実行させてもよい。
【００１４】
また、本発明のゲーム制御装置において、前記イベント制御部は、前記第１ユーザとのイベントを申し込むために前記第３ユーザの端末装置から送信されたイベント申込を前記第１ユーザの端末装置に送信し、前記イベント申込を受け付ける操作が行われた場合に前記第１ユーザの端末装置から送信されるイベント受け付け通知を受信し、前記イベント受け付け通知が受信されるという前記条件が満たされた場合に、前記第１ユーザの端末装置と前記第３ユーザの端末装置とを対象とする前記同期型イベントを実行させ、前記イベント受け付け通知が受信されないことにより前記条件が満たされない場合に、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを実行させてもよい。
【００１５】
また、本発明の一態様としてのゲーム制御方法は、端末装置と接続する通信部と、第１ユーザの端末装置に対して行われた操作と他のユーザの端末装置に対して行われた操作とに応じて前記第１ユーザのキャラクタと前記他のユーザのキャラクタを制御した結果を、前記第１ユーザの端末装置との通信と前記他のユーザの端末装置との通信とにより、前記第１ユーザの端末装置上で実行されるイベントと前記他のユーザの端末装置上で実行されるイベントとに共通に反映させる同期型イベントを実行する同期型イベント実行部と、前記第１ユーザの端末装置に対して行われる操作の代替である自動処理と他のユーザの端末装置に対して行われた操作とに応じて前記第１ユーザのキャラクタと前記他のユーザのキャラクタを制御した結果を、前記他のユーザの端末装置との通信を経由して、前記他のユーザの端末装置上で実行されるイベントに反映させる非同期型イベントを実行する非同期型イベント実行部とを有するゲームシステムの制御方法であって、前記第１ユーザの端末装置と前記他のユーザのうちの第２ユーザの端末装置との間で前記同期型イベントが実行中であるときに、さらに前記他のユーザのうちの第３ユーザの端末装置と前記第１ユーザの端末装置との間でイベントを開始させるにあたり、所定の条件を満たしている場合には、前記第１ユーザの端末装置と前記第３ユーザの端末装置との間で前記同期型イベントを開始させ、所定の条件を満たしていない場合には、前記他のユーザの端末装置を前記第３ユーザの端末装置とする前記非同期型イベントを開始させるイベント制御ステップを備える。
【発明の効果】
【００１６】
以上説明したように、本発明によれば、同期型イベントを導入するゲームを行うにあたり、特定の端末装置に対する通信の集中による通信負荷の増大が回避され、同期型イベントを安定して実行させることができるという効果が得られる。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施形態におけるゲームシステムの構成例を示す図である。
【図２】本実施形態におけるバトルイベントについての制御例を示す図である。
【図３】本実施形態におけるゲームサーバと端末装置の構成例を示す図である。
【図４】本実施形態におけるキャラクタ情報テーブルの構造例を示す図である。
【図５】本実施形態における同期型イベント登録テーブルの構造例を示す図である。
【図６】第１の実施形態におけるゲームサーバが実行する処理手順例を示す図である。
【図７】第１の実施形態のゲームサーバにおいて、同期型イベントを実行可能な条件を満たしているか否かを判定するための処理手順例を示す図である。
【図８】第２の実施形態のゲームサーバが同期型イベントを実行可能な条件を満たしているか否かを判定するための処理手順例を示す図である。
【図９】第３の実施形態のゲームサーバが同期型イベントを実行可能な条件を満たしているか否かを判定するための処理手順例を示す図である。
【図１０】第４の実施形態のゲームサーバが非同期型イベントから同期型イベントに切り替えるための処理手順例を示す図である。
【図１１】第５の実施形態における高度型の操作入力インターフェースによるゲーム画面と、簡易型の操作入力インターフェースによるゲーム画面の態様例を示す図である。
【図１２】第５の実施形態における記憶部が記憶する情報内容例を示す図である。
【図１３】第５の実施形態におけるアプリケーション部が有する情報内容例を示す図である。
【図１４】第６の実施形態におけるキャラクタ情報の更新処理の一具体例を示す図である。
【発明を実施するための形態】
【００１８】
＜第１の実施形態＞
［ゲームシステムの構成例］
図１は、本実施形態におけるゲームシステムの構成例を示している。この図に示すゲームシステムは、ゲームサーバ１００と複数の端末装置２００（２００−１〜２００−３）を備える。ゲームサーバ１００と複数の端末装置２００は、ネットワーク３００経由で通信する。
【００１９】
ゲームサーバ（ゲーム制御装置）１００は、ネットワーク３００経由で接続される端末装置２００に対して本実施形態のゲームを提供するサーバである。本実施形態のゲームは、例えば２人のユーザが対戦する対戦型のゲームである。このゲーム上では、ユーザごとに対応するキャラクタが対戦を行う。
端末装置２００は、ゲームの参加者であるユーザが所有するネットワーク端末である。端末装置２００には、本実施形態のゲームに対応するゲームアプリケーションがインストールされている。端末装置２００のユーザは、ゲームアプリケーションを起動させて操作を行うことで、本実施形態のゲームをプレイすることができる。
なお、この端末装置２００は、例えば携帯電話やスマートフォンなどの携帯型の無線端末である。
【００２０】
また、この図においては、端末装置２００として、第１ユーザが所有する端末装置２００−１と、第２ユーザが所有する端末装置２００−２と、第３ユーザが所有する端末装置２００−３とが示されている。
【００２１】
ここで、第１ユーザは、本実施形態のゲーム上で第２ユーザまたは第３ユーザの対戦相手となるユーザである。
第２ユーザは、同期型イベントとしてのバトルイベント（同期型バトルイベント）により第１ユーザと対戦を行うユーザである。この第２ユーザは複数存在してよい。第３ユーザは、第１ユーザとの間で同期型バトルイベントまたは非同期型イベントとしてのバトルイベント（非同期型バトルイベント）による対戦を開始するユーザである。この第３ユーザも複数存在してよい。
【００２２】
同期型バトルイベントでは、ゲームサーバ１００の通信部が第１ユーザの端末装置２００−１と他のユーザの端末装置２００と通信することにより第１ユーザの端末装置と前記他のユーザの端末装置との間で通信させる。そのうえで、同期型イベントでは、第１ユーザの端末装置２００−１に対して行われた操作と他のユーザの端末装置２００に対して行われた操作とに応じて第１ユーザのキャラクタと他のユーザのキャラクタを制御する。そして、この制御の結果を、第１ユーザの端末装置２００−１上で実行されるイベントと他のユーザの端末装置２００上で実行されるイベントとに共通に反映させるものである。
【００２３】
非同期型バトルイベントでは、第１ユーザの端末装置２００−１と他のユーザの端末装置２００との間での通信は行わない。そのうえで、第１ユーザの端末装置２００−１に対して行われる操作の代替である自動処理と第１ユーザの端末装置２００と通信しない他のユーザの端末装置に対して行われた操作とに応じて、第１ユーザのキャラクタと他のユーザのキャラクタを制御する。そして、この制御の結果を、他のユーザの端末装置２００上で実行されるイベントに反映させるものである。
【００２４】
［ゲームの概要］
本実施形態の対戦型ゲームでは、例えばユーザは、ゲームの進行において所定の過程を経ることで非常に強い力を持つ特殊キャラクタに成長させることができる。特殊キャラクタではない他の種類のキャラクタを持つ他のユーザは、この特殊キャラクタに対して戦いを挑むことができる。
ただし、特殊キャラクタは非常に強いために、他の標準的なキャラクタが１回対戦しただけでは倒すことができない。つまり、複数の標準的なキャラクタが協力しなければならない。このために、本実施形態のゲームでは、１つの特殊キャラクタが多数の標準的なキャラクタとバトルイベントを行うことになる。
図１に示した第１ユーザは、特殊キャラクタを持つユーザである。また、第２ユーザと第３ユーザは、第１ユーザの特殊キャラクタとバトルイベントを行う標準的なキャラクタを持つユーザである。
【００２５】
本実施形態の場合、上記の説明から理解されるように、特殊キャラクタを持つ第１ユーザの端末装置２００−１に対して、多数の他のユーザの端末装置２００との通信が集中するという状況が生じ得る。
この場合において、第１ユーザの端末装置２００−１に対して他のユーザの端末装置２００が接続されるごとに同期型イベントによるバトルイベントを行ったとすると、第１ユーザの端末装置２００−１は、多数の他のユーザの端末装置２００と通信を実行することとなってトラフィックが大幅に増加し、これに伴う通信負荷も増大する。このような状態となると、例えば通信データの遅延が大きくなって正常にゲームが進行できなくなる可能性がある。
【００２６】
そこで、本実施形態では、第１ユーザと多数の他のユーザとの間で行われるゲームの進行を常に正常なものとするために、以下に説明するように、第１ユーザの端末装置２００−１とゲームサーバ１００との間での通信負荷の増加を回避する。
【００２７】
［バトルイベント制御例］
図２は、本実施形態のゲームサーバ１００が実行するバトルイベントについての制御の一例を示している。
【００２８】
まず、第１ユーザの端末装置２００−１が他の端末装置２００のいずれともバトルイベントを実行していない状態において、第２ユーザが第１ユーザへのバトルイベント申込みのための操作を端末装置２００−２に対して行ったとする。この操作に応じて、第２ユーザの端末装置２００−２は、第１ユーザへのバトルイベント申込をゲームサーバ１００に対して送信する（ステップＳ１）。
なお、以降において、バトルイベント申込を送信してきた端末装置２００のユーザについては申込ユーザともいい、バトルイベント申込により対戦相手として指定されたユーザについては被申込ユーザともいう。
【００２９】
ステップＳ１によりバトルイベント申込みが送信されたとき、前述のように、第１ユーザの端末装置２００−１は、他の端末装置２００のいずれともバトルイベントを実行していない状態にある。この状態において同期型バトルイベントの実行による通信負荷の増加は生じていない。そこで、この場合のゲームサーバ１００は、バトルイベント申込みの受信に応じて、第１ユーザの端末装置２００−１と第２ユーザの端末装置２００−２との間で同期型バトルイベントを実行させる。
【００３０】
このとき、ゲームサーバ１００は、端末装置２００−１と端末装置２００−２のそれぞれと通信する。そして、端末装置２００−１と端末装置２００−２とに対して行われた操作に応じて第１ユーザと第２ユーザのキャラクタを制御する。ここでのキャラクタの制御には、キャラクタを生成するためのキャラクタ情報を、例えばバトルイベントにおける対戦結果に応じて変更する処理を含む。
そして、ゲームサーバ１００は、この制御結果を、端末装置２００−１上で実行されるバトルイベントと端末装置２００−２上で実行されるバトルイベントのそれぞれに反映させる。この場合、端末装置２００−１と２００−２上の各ゲームにおける第１ユーザのキャラクタと第２ユーザのキャラクタは、いずれもＰＣ（プレイヤーキャラクター）である。
【００３１】
次に、ステップＳ２による同期型バトルイベントが実行中の状態において、第３ユーザが第１ユーザへのバトルイベント申込みのための操作を端末装置２００−３に対して行ったとする。この操作に応じて、第３ユーザの端末装置２００−３は、第１ユーザへのバトルイベント申込をゲームサーバ１００に対して送信する（ステップＳ３）。
【００３２】
ステップＳ３による第１ユーザへのバトルイベント申込をゲームサーバ１００が受信したとき、第１ユーザの端末装置２００−１は、既に同期型バトルイベントを実行中である。この状態の場合、例えば同期型バトルイベントを実行中の第２ユーザの端末装置２００の数などによっては、通信負荷が相当に増加している状態である可能性がある。
そこで、この場合のゲームサーバ１００は、同期型バトルイベントを実行可能な所定の条件を満たしているか否かについて判定する（ステップＳ４）。なお、この所定の条件の例については後述する。
【００３３】
ステップＳ４の条件判定の結果、所定の条件を満たしていると判定した場合、ゲームサーバ１００は、第１ユーザの端末装置２００−１、第２ユーザの端末装置２００−２と第３ユーザの端末装置２００−３とで同期型バトルイベントを実行させる（ステップＳ５−１）。
この際、第１ユーザと第２ユーザの登録されている同期型イベント登録テーブルのグループに第３ユーザを追加して、第１ユーザ、第２ユーザ、第３ユーザの端末装置２００同士に操作信号等の共有を行わせて、第１ユーザ、第２ユーザ、第３ユーザの間で同期型イベントを行わせる。
【００３４】
一方、ステップＳ４の条件判定の結果、所定の条件を満たしていないと判定した場合、ゲームサーバ１００は、第３ユーザの端末装置２００−３に、第１ユーザのキャラクタとの非同期型バトルイベントを実行させる（ステップＳ５−２）。
【００３５】
非同期型バトルイベントの場合、第３ユーザの端末装置２００−３に対して行われた操作については、第１ユーザの端末装置２００−１に反映させる必要はないため、ゲームサーバ１００は、第３ユーザの端末装置２００−３上で実行されるバトルイベントに対応した端末装置２００−１との通信は実行しない。つまり、第１ユーザの端末装置２００−１は、ゲームサーバ１００との間で、第２ユーザの端末装置２００−２との同期型バトルイベントに対応する通信のみを実行する。
この場合、第３ユーザの端末装置２００−３上のゲームにおける第１ユーザのキャラクタはＮＰＣ（ノンプレイヤーキャラクター）であり、第２ユーザのキャラクタはＰＣである。
【００３６】
つまり、本実施形態では、第１ユーザの端末装置２００−１と第２ユーザの端末装置２００−２が同期型バトルイベントを実行中の状態において、さらに他のユーザがバトルイベントを申し込んできた場合、以下のように制御が行われる。
本実施形態では、同期型バトルイベントを実行するための所定の条件を満たしていれば、他のユーザを新たな第２ユーザとする同期型バトルイベントが開始される。これに対して、同期型バトルイベントを実行するための所定の条件を満たしていなければ、他のユーザを第３ユーザとする非同期型バトルイベントが開始される。
非同期型バトルイベントが実行される場合、第１ユーザの端末装置２００−１との通信は行われないことから、端末装置２００−１の通信負荷が増加することはない。このように、本実施形態では、同期型バトルイベントを導入しつつも、所定の条件に対応させて、非同期型バトルイベントの実行を並行させることにより、第１ユーザの端末装置２００−１に対する通信の集中による通信負荷の増大を回避することができる。
【００３７】
［ゲームサーバの構成例］
図３は、ゲームサーバ１００と端末装置２００の構成例を示している。なお、この図において、ネットワーク３００の図示は省略している。
【００３８】
まず、ゲームサーバ１００の構成例について説明する。
この図に示すゲームサーバ１００は、通信部１０１、同期型イベント実行部１０２、非同期型イベント実行部１０３、イベント制御部１０４及び記憶部１０５を備える。
【００３９】
通信部１０１は、ネットワーク３００経由で端末装置２００と通信する。
同期型イベント実行部１０２は、バトルイベントとして同期型イベントを実行する。
具体的には、同期型イベント実行部１０２は、後述するイベント制御部１０４により同期型イベントを実行すべきと判断された場合、同期型イベントに参加するユーザが操作する端末装置２００同士を組織化するとともに、ネットワーク３００経由で情報を共有することによって、同一のゲーム空間で行う同期型イベントを制御する。
つまり、同期型イベント実行部１０２は、イベント制御部１０４が同期型イベントを実行うべきと判断したのに応じて、同期型イベントを行うユーザを同期型イベント登録テーブルに格納し、端末装置２００同士に操作信号等の共有を行わせる。
なお、同期型イベント登録テーブルは、図６により後述するように、同期型イベントごとに対応して同期型イベントの参加者として登録されたユーザを示す情報である。この同期型イベント登録テーブルは、記憶部１０５に記憶される。そして、同期型イベントに対してユーザが新規に参加するごとに、その新規に参加したユーザを同期型イベント登録テーブルに新規に登録する。同期型イベント実行部１０２は、例えば登録されたユーザの端末装置２００間で操作信号等を共有させることにより、端末装置２００同士を組織化する。
【００４０】
一方、非同期型イベント実行部１０３は、バトルイベントとして非同期型イベントを実行する。
具体的には、非同期型イベント実行部１０３は、後述するイベント制御部１０４が非同期型イベントを実行すると判断した場合、申込ユーザの端末装置とゲームサーバ１００の間でのみネットワーク３００経由で通信を行って非同期型イベントを制御する。この場合、被申込ユーザのキャラクタは例えば非同期型イベント実行部１０３によりＮＰＣとして操作されるために、被申込ユーザの端末装置と申込ユーザの端末装置同士でデータ通信を行う必要はないためである。
【００４１】
なお、後述する端末装置２００のゲームアプリケーション部２０２にＮＰＣの操作を実行させてもよい。この場合、非同期型イベント実行部１０３は、イベント制御部１０４により非同期型イベントを実行すべきであると判断された場合、申込ユーザの端末装置２００に対してＮＰＣで操作されるキャラクタのキャラクタ情報を送信する。これとともに、非同期型イベント実行部１０３は、申込ユーザの端末装置２００に対して非同期型イベントの実行の指示のみを送信するようにしてもよい。この場合、イベント実行中においてゲームサーバ１００とネットワーク３００経由で通信を行わなくともよい。
【００４２】
イベント制御部１０４は、第１ユーザの端末装置２００−１と第２ユーザの端末装置２００−２との間で同期型イベントが実行中であるときに、さらに第３ユーザの端末装置２００−３と第１ユーザの端末装置２００−１との間でイベント（バトルイベント）を開始させるにあたり、以下のように制御する。
つまり、イベント制御部１０４は、所定の条件を満たしている場合には、同期型イベント登録テーブルに第１ユーザのユーザＩＤと第２ユーザのユーザＩＤに加えて、第３ユーザのユーザＩＤを格納する。これに応じて、同期型イベント実行部１０２は、第１〜第３のユーザの各端末装置２００同士で操作信号等の共有を行わせる。これにより、同期型イベント実行部１０２は、第１ユーザと第２ユーザとで行っている同期型イベントに第３ユーザを追加して、第１ユーザの端末装置２００−１、第２ユーザの端末装置２００−２、第３ユーザの端末装置２００−３の間で同期型イベントを実行させる。
一方、イベント制御部１０４は、所定の条件を満たしていない場合には、他のユーザの端末装置２００を第３ユーザの端末装置２００−３とする非同期型イベントを開始させる。
【００４３】
記憶部１０５は、ゲームサーバ１００が端末装置２００にゲームを提供するのに必要な各種の情報を記憶する。図３においては、このような情報として、キャラクタ情報テーブル１１０と同期型イベント登録テーブル１２０とが示される。
【００４４】
図４は、キャラクタ情報テーブル１１０の構造例を示している。この図に示すキャラクタ情報テーブル１１０は、１人のユーザに対応するテーブル構造例を示している。記憶部１０５は、図に示す構造のテーブルを、ゲーム利用者として登録したユーザごとに備える。
【００４５】
図４に示す１ユーザ対応のキャラクタ情報テーブル１１０は、ユーザＩＤ格納領域１１１とキャラクタ情報格納領域１１２を備える。
ユーザＩＤ格納領域１１１は、対応のユーザを識別するユーザＩＤを格納する領域である。
キャラクタ情報格納領域１１２は、対応のユーザが持つ１以上のキャラクタに関するキャラクタ情報を格納する領域である。
【００４６】
キャラクタ情報格納領域１１２は、さらに、キャラクタＩＤ格納領域１１２ａ、キャラクタ表示データ格納領域１１２ｂ、ヒットポイント格納領域１１２ｃ、攻撃力格納領域１１２ｄ、防御力格納領域１１２ｅ、経験値格納領域１１２ｆ及びバトルイベント状況情報格納領域１１２ｇを備える。
【００４７】
キャラクタＩＤ格納領域１１２ａは、対応のキャラクタを一意に識別するキャラクタＩＤを格納する。
【００４８】
キャラクタ表示データ格納領域１１２ｂは、対応のキャラクタを表示させるためのキャラクタ表示データを格納する。端末装置２００のゲームアプリケーション部２０２は、このキャラクタ表示データを利用してゲーム画面上にキャラクタを表示させる。
【００４９】
ヒットポイント格納領域１１２ｃは、対応のキャラクタに設定されているヒットポイントの値を格納する。
攻撃力格納領域１１２ｄは、対応のキャラクタに設定されている攻撃力を示す値を格納する。
防御力格納領域１１２ｅは、対応のキャラクタに設定されている防御力を示す値を格納する。
経験値格納領域１１２ｆは、対応のキャラクタに設定されている経験値を格納する。
【００５０】
バトルイベント状況情報格納領域１１２ｇは、対応のキャラクタについての現在のバトルイベントの状況を示すバトルイベント状況情報を格納する。
図４の例の場合、キャラクタＩＤが００００１のキャラクタのバトルイベント状況情報は、第２ユーザのキャラクタと同期型バトルイベントを実行中であることを示している。また、キャラクタＩＤが００００２のキャラクタのバトルイベント状況情報は、第３ユーザのキャラクタと非同期型バトルイベントを実行中であることを示している。また、キャラクタＩＤが００００３のキャラクタのバトルイベント状況情報は、バトルイベントの待機中であることを示している。
【００５１】
図５は、同期型イベント登録テーブル１２０を示している。同期型イベント登録テーブル１２０における１レコードが１つの同期型イベントに対応する。１つのレコードは、グループＩＤ格納領域１２１に対して、主ユーザＩＤ格納領域１２２と、複数の副ユーザＩＤ格納領域１２３−１〜１２３−ｎを含む。
グループＩＤ格納領域１２１は、対応の同期型イベントに対応して設定されたグループＩＤを格納する領域である。
主ユーザＩＤ格納領域１２２は、バトルイベント申込を受けた被申込ユーザのユーザＩＤを格納する領域である。この主ユーザＩＤ格納領域１２２にユーザＩＤが格納されることにより、そのユーザＩＤにより示されるユーザが被申込ユーザとして登録されたことになる。
副ユーザＩＤ格納領域１２３−１〜１２３−ｎは、バトルイベント申込が被申込ユーザにより受け付けられた申込ユーザのユーザＩＤが格納される領域である。この副ユーザＩＤ格納領域１２３−１〜１２３−ｎにユーザＩＤが格納されることにより、そのユーザＩＤにより示されるユーザが申込ユーザとして登録されたことになる。
本実施形態において同期型イベントに参加するユーザをこのように管理することで、例えば、副ユーザＩＤ格納領域１２３−１〜１２３−ｎに格納されたユーザのキャラクタ同士については同期型バトルイベントにおいて互いの攻撃の影響を受けないようにすることができる。
【００５２】
［端末装置の構成例］
次に、図３を再度参照して、端末装置２００の構成例について説明する。なお、図３においては、端末装置２００−１のみの構成が示されているが、残る端末装置２００−２及び２００−３も端末装置２００−１と同様の構成でよい。
【００５３】
端末装置２００は、通信部２０１、ゲームアプリケーション部２０２、表示部２０３及び操作部２０４を備える。
【００５４】
通信部２０１は、ネットワーク３００経由でゲームサーバ１００と通信を実行する。
【００５５】
ゲームアプリケーション部２０２は、本実施形態のゲームに対応する機能を実行する。例えば、ゲームアプリケーション部２０２は、ゲームに対して行われた操作に応じた操作信号をゲームサーバ１００に送信する。また、ゲームアプリケーション部２０２は、ゲームサーバ１００から送信されるゲーム制御情報に基づいて、そのときのゲームの進行状況に応じたゲーム画面を生成する。ゲーム情報には、例えば操作信号に応じてゲームサーバ１００の同期型イベント実行部１０２または非同期型イベント実行部１０３がキャラクタを制御した結果などが含まれる。ゲームアプリケーション部２０２は、生成したゲーム画面を表示部２０３に表示させる。
なお、ゲームアプリケーション部２０２の機能は、端末装置２００におけるＣＰＵ（Central Processing Unit）がゲームアプリケーションのプログラムを実行することにより実現される。ここで、上述した同期型バトルイベントと非同期型バトルイベントは、それぞれ、ゲームアプリケーション部２０２が行う公知のゲームアプリケーションのプログラムである。
【００５６】
表示部２０３は、ゲームアプリケーション部２０２の制御に応じてゲーム画面を表示する。
操作部２０４は、ゲームアプリケーション部２０２に対する操作を行うのに使用される端末装置２００の操作子や操作デバイスを一括して示している。例えば、端末装置２００の表示部２０３に対してタッチパネルが備えられる場合には、このタッチパネルが操作部２０４に含まれる。
【００５７】
［処理手順例］
図６のフローチャートは、ゲームサーバ５００が実行する処理手順例を示している。
端末装置２００のユーザは、ゲームアプリケーション部２０２により表示されるゲーム画面に対して、例えば対戦相手のユーザを指定してバトルイベントを申し込むための操作を行うことができる。この操作が行われるのに応じて、ゲームアプリケーション部２０２は、通信部２０１からネットワーク３００経由でゲームサーバ１００に対して、バトルイベント申込を送信する。
【００５８】
ゲームサーバ１００において、イベント制御部１０４は、上記のように端末装置２００から送信されるバトルイベント申込が通信部１０１にて受信されるのを待機している（ステップＳ１０１−ＮＯ）。
そして、バトルイベント申込が受信されるのに応じて（ステップＳ１０１−ＹＥＳ）、イベント制御部１０４は、バトルイベント申込により対戦相手として指定された被申込ユーザが、現在において同期型バトルイベントを実行中であるか否かについて判定する（ステップＳ１０２）。この判定は、イベント制御部１０４が、例えば、被申込ユーザのキャラクタ情報テーブルにおけるバトルイベント状況情報格納領域１１２ｇに格納されるバトルイベント状況の内容を参照すればよい。
なお、バトルイベント申込により対戦相手として指定された被申込ユーザは、図２における第１ユーザに相当する。
【００５９】
被申込ユーザが同期型バトルイベントを実行中である場合（ステップＳ１０２−ＹＥＳ）、イベント制御部１０４は、申込ユーザが被申込ユーザと同期型バトルイベントを開始できる条件を満たしているか否かについての条件判定を実行する（ステップＳ１０３）。
【００６０】
この条件判定として、第１の実施形態においては、被申込ユーザの端末装置２００と同期型バトルイベントを実行中の端末装置２００の数が一定以下であるという条件を満たしているか否かについて判定する
被申込ユーザの端末装置２００とゲームサーバ１００との間の通信の通信品質は、被申込ユーザの端末装置２００と同期型バトルイベントを実行する他の端末装置２００の数と相関関係がある。つまり、被申込ユーザの端末装置２００と同期型バトルイベントを実行する他の端末装置２００の数が多くなるのに応じて被申込ユーザの端末装置２００とゲームサーバ１００との間での通信による通信負荷が増加し、これに伴って通信品質は劣化する。そこで、ステップＳ１０３において一定以下か否かについての判定に利用する値（すなわち閾値）については、上記の相関に基づいて予め定めることができる。
本実施形態において、被申込ユーザの端末装置２００と同期型バトルイベントを実行中の端末装置２００の数が一定以下であるということは、まだ被申込ユーザの端末装置２００の通信負荷に余裕があり、同期型バトルイベントさらに追加しても通信品質を一定以上に保つことができるということである。
【００６１】
図７のフローチャートは、第１の実施形態におけるステップＳ１０３としての条件判定のための処理手順例を示している。イベント制御部１０４は、被申込ユーザの端末装置２００と現在において同期型バトルイベントを実行中の他のユーザ（第２のユーザ）の端末装置２００の数が一定以下であるか否かについて判定する（ステップＳ２０１）。なお、この判定にあたって、イベント制御部１０４は、被申込ユーザのキャラクタ情報テーブルにおけるバトルイベント状況情報格納領域１１２ｇに格納されるバトルイベント状況の内容を参照すればよい。
【００６２】
同期型バトルイベントを実行中の端末装置２００の数が一定以下である場合（ステップＳ２０１−ＹＥＳ）、イベント制御部１０４は、条件が満たされていると判定する（ステップＳ２０２）。
一方、同期型バトルイベントを実行中の端末装置２００の数が一定未満である場合（ステップＳ２０１−ＮＯ）、イベント制御部１０４は、条件が満たされていないと判定する（ステップＳ２０３）。
【００６３】
説明を図６に戻す。
イベント制御部１０４は、ステップＳ１０３における条件判定により条件が満たされているとの判定結果が得られたか否かについて判定する（ステップＳ１０４）。
条件が満たされているとの判定結果が得られた場合（ステップＳ１０４−ＹＥＳ）、あるいは、被申込ユーザの端末装置２００が同期型バトルイベントを実行中でない場合（ステップＳ１０２−ＮＯ）、イベント制御部１０４は、同期型バトルイベントを開始させるために以下の処理を実行する。
【００６４】
つまり、イベント制御部１０４は、被申込ユーザと申込ユーザとに対応して同期型バトルイベントに使用する各１つキャラクタのキャラクタ情報をキャラクタ情報テーブル１１０から読み出す（ステップＳ１０５）。
【００６５】
第１の実施形態におけるステップＳ１０５では、イベント制御部１０４は、被申込ユーザについて、申込ユーザの端末装置２００が同期型バトルイベントを実行中である場合には、同期型バトルイベントに使用されていないキャラクタのキャラクタ情報を読み出す。同期型バトルイベントに使用されていないキャラクタは、バトルイベント状況情報格納領域１１２ｇに格納されるバトルイベント状況格納情報が待機中であることを示すキャラクタである。
【００６６】
次に、イベント制御部１０４は、被申込ユーザの端末装置２００と申込ユーザの端末装置２００との間での同期型バトルイベントを同期型イベント実行部１０２に開始させる（ステップＳ１０６）。
この際、同期型イベント実行部１０２は、イベント制御部１０４がステップＳ１０５により読み出した被申込ユーザのキャラクタ情報格納領域１１２と申込ユーザのキャラクタ情報格納領域１１２に対して当該情報入力するとともに、同期型イベント登録テーブルに格納し、端末装置２００同士での操作信号等の共有を可能にする。以降において、同期型イベント実行部１０２は、被申込ユーザの端末装置２００と申込ユーザの端末装置２００に対して行われる操作に応じて被申込ユーザのキャラクタ情報と申込ユーザのキャラクタ情報を制御しながら同期型バトルイベントの処理を実行する。
【００６７】
一方、条件が満たされていないとの判定結果が得られた場合（ステップＳ１０４−ＮＯ）、イベント制御部１０４は、非同期型バトルイベントを開始させるために以下の処理を実行する。
つまり、イベント制御部１０４は、被申込ユーザと申込ユーザとに対応して同期型バトルイベントに使用する各１つキャラクタのキャラクタ情報をキャラクタ情報テーブル１１０から読み出す（ステップＳ１０７）。
次に、イベント制御部１０４は、申込ユーザの端末装置２００上での被申込ユーザとの非同期型バトルイベントを非同期型イベント実行部１０３に開始させる（ステップＳ１０８）。なお、このときに、非同期型イベント実行部１０３又はイベント制御部１０４は、被申込ユーザの端末装置２００に対して申込ユーザと非同期型バトルイベントが実行されていることを示す通知を行ってもよい。
【００６８】
＜第２の実施形態＞
［概要］
続いて、第２の実施形態について説明する。
第２の実施形態では、図６のステップＳ１０３としての条件判定の処理における条件の内容が第１の実施形態と異なる。
第２の実施形態において、申込ユーザが被申込ユーザと同期型バトルイベントを開始することのできる条件は、被申込ユーザの端末装置２００とゲームサーバ１００の通信部１０１との通信の通信品質が一定以上である、ということである。
【００６９】
ここでの通信品質として指標の一例は、被申込ユーザの端末装置２００とゲームサーバ１００の通信部１０１との間のトラフィックである。例えば、トラフィックが一定以上となると、パケットの遅延時間も大きくなって、同期型バトルイベントを正常に実行させることが難しい状態となる。
また、通信品質としての指標は、パケットエラーレートやビットエラーレートなどであってもよい。あるいは、ゲームサーバ１００が被申込ユーザの端末装置２００との通信に割り当てているＣＰＵ使用率などであってもよい。また、これらの指標を組み合わせたものを本実施形態の通信品質としてもよい。
【００７０】
［処理手順例］
図８のフローチャートは、第２の実施形態における図６のステップＳ１０３としての条件判定のための処理手順例を示している。なお、この図において、図７と同様の処理のステップについては同じ符号を付している。また、この図８は、通信品質の指標として、被申込ユーザの端末装置２００とゲームサーバ１００の通信部１０１との間のトラフィックを採用した場合の処理である。
【００７１】
ゲームサーバ１００において、通信部１０１は、例えば被申込ユーザの端末装置２００との間の通信のトラフィックを測定している。イベント制御部１０４は、このトラフィックの測定結果を通信部１０１から取得する（ステップＳ２０１Ａ）。
次に、イベント制御部１０４は、取得したトラフィックが一定以上であるか否かについて判定する（ステップＳ２０１Ｂ）。この判定は、通信品質が一定以上であるか否かについて判定することに相当する。
トラフィックが一定以上である場合（ステップＳ２０１Ｂ−ＹＥＳ）、イベント制御部１０４は、申込ユーザが被申込ユーザと同期型バトルイベントを開始することのできる条件が満たされたと判定する（ステップＳ２０２）。一方、トラフィックが一定未満である場合（ステップＳ２０１Ｂ−ＮＯ）、イベント制御部１０４は、申込ユーザが被申込ユーザと同期型バトルイベントを開始することのできる条件が満たされていないと判定する（ステップＳ２０３）。
【００７２】
このように被申込ユーザの端末装置２００とゲームサーバ１００の通信部１０１との通信の通信品質に基づいてステップＳ１０３としての条件判定を行うことにより、同期型バトルイベントについての正常な動作を確保することが可能になる。また、通信品質自体に基づくことで、条件判定を高い精度で行うことが可能になる。また、通信品質自体に基づいた条件判定とすることで、同期型バトルイベントの実行による通信負荷以外の要因で通信品質が低下するような状況にも対応して同期型バトルイベントについての正常な動作を確保することが可能になる。
【００７３】
＜第３の実施形態＞
［概要］
続いて、第３の実施形態について説明する。
第３の実施形態では、図６のステップＳ１０３としての条件判定の処理における条件の内容が第１の実施形態及び第２の実施形態と異なる。
第３の実施形態において、図６のステップＳ１０３としての条件判定の処理における条件は、被申込ユーザがバトルイベントの申込を受け付けている、というものである。
つまり、第３の実施形態では、申込ユーザからのバトルイベント申込を被申込ユーザが受け付けたのであれば同期型バトルイベントが開始される。これに対して、申込ユーザからのバトルイベント申込を被申込ユーザが受け付けないのであれば、非同期型バトルイベントが開始されるというものである。
【００７４】
［処理手順例］
図９のフローチャートを参照して、第３の実施形態におけるステップＳ１０３としての条件判定のための処理手順例について説明する。
第３の実施形態において、イベント制御部１０４は、申込ユーザの端末装置２００からのバトルイベント申込を受信するのに応じて、被申込ユーザの端末装置２００に対して、バトルイベント申込が行われたことの通知を送信する（ステップＳ２０１Ｃ）。
【００７５】
被申込ユーザの端末装置２００におけるゲームアプリケーション部２０２は、バトルイベント申込が行われたことの通知の受信に応じて、ゲーム画面上にバトルイベント申込が行われたことをユーザに通知するメッセージを表示する。この表示を見た被申込ユーザは、ゲーム画面に対して、このバトルイベント申込を受け付ける操作と、バトルイベント申込の受け付けを拒否する操作とのいずれかを行う。
例えば、被申込ユーザは、まだ同期型バトルイベントを増やしてもゲームの動作が不安定になるほど通信負荷が高くはならないと判断すれば、バトルイベント申込を受け付ける操作を行う。
【００７６】
一方、被申込ユーザは、同期型バトルイベントをこれ以上実行させると通信負荷が大きくなってゲームの動作が不安定になると思えば、バトルイベント申込の受け付けを拒否する操作を行う。また、被申込ユーザは、例えば通信負荷以外の理由で同期型バトルイベントをこれ以上行いたくないと思ったときにもバトルイベント申込の受け付けを拒否する操作を行うことができる。このように、第３の実施形態では、非同期型バトルイベントを実行できるための条件に、ユーザ自身の意図を反映させることができる。
【００７７】
被申込ユーザの端末装置２００のゲームアプリケーション部２０２は、バトルイベント申込を受け付ける操作が行われるのに応じて、バトルイベントが受け付けられたことを示すバトルイベント受付通知をゲームサーバ１００に送信する。
また、被申込ユーザの端末装置２００のゲームアプリケーション部２０２は、バトルイベント申込の受け付けを許可する操作が行われるのに応じて、バトルイベントが受け付けられたことを示すバトルイベント拒否通知をゲームサーバ１００に送信する。
【００７８】
ゲームサーバ１００において、イベント制御部１０４は、ステップＳ２０１Ｃによりバトルイベント申込が行われたことの通知を送信した後、被申込ユーザによりバトルイベント申込が受け付けられたか否かについて判定する（ステップＳ２０１Ｄ）。
イベント制御部１０４は、バトルイベント受付通知が受信されると、被申込ユーザによりバトルイベント申込が受け付けられたと判定する（ステップＳ２０１Ｄ−ＹＥＳ）。この場合、イベント制御部１０４は、申込ユーザが被申込ユーザと同期型バトルイベントを開始することのできる条件が満たされたと判定する（ステップＳ２０２）。
【００７９】
一方、イベント制御部１０４は、バトルイベント拒否通知が受信されると、被申込ユーザによりバトルイベント申込が受け付けられなかったと判定する（ステップＳ２０１Ｄ−ＮＯ）。この場合、イベント制御部１０４は、申込ユーザが被申込ユーザと同期型バトルイベントを開始することのできる条件が満たされていないと判定する（ステップＳ２０３）。
【００８０】
＜第４の実施形態＞
［概要］
続いて、第４の実施形態について説明する。
第４の実施形態において、ゲームサーバ１００のイベント制御部１０４は、非同期型バトルイベントを開始させた後において、同期型バトルイベントを実行することのできる所定の条件が満たされていない状態からこの所定の条件が満たされる状態に変化するのに応じて同期型イベントに切り替えるように制御するというものである。
これにより、非同期型バトルイベントでプレイしていたユーザが、途中から同期型バトルイベントでプレイすることができるので、できるだけ同期型バトルイベントでプレイしたいというユーザの要望に応えることができる。
【００８１】
［処理手順例］
図１０のフローチャートは、非同期型バトルイベントから同期型バトルイベントへの切り替えのためにイベント制御部１０４が実行する処理手順例を示している。
図６のステップＳ１０８により、申込ユーザの端末装置２００上で非同期型バトルイベントを開始させた後、イベント制御部１０４は、この申込ユーザの端末装置２００が被申込ユーザと同期型バトルイベントを実行できる条件を満たしているか否かについて判定する（ステップＳ３０１）。また、イベント制御部１０４は、ステップＳ３０１における条件判定により条件が満たされているとの判定結果が得られたか否かについて判定する（ステップＳ３０２）。なお、ステップＳ３０１の条件判定は、ステップＳ１０３と同様の処理でよい。
【００８２】
非同期型バトルイベントを開始したということは、申込ユーザがバトルイベント申込を行った段階では、ステップＳ１０４により条件が満たされていないと判定されている。非同期型バトルイベントが開始された後において、条件が満たされていない状態が継続していれば、イベント制御部１０４は、条件が満たされているとの判定結果が得られていないと判定して（ステップＳ３０２−ＮＯ）、ステップＳ３０１に戻ることで条件判定を繰り返し実行する。
そして、非同期型バトルイベントの開始後において、条件が満たされていなかった状態から条件が満たされた状態に変化すると、条件が満たされているとの判定結果が得られる（ステップＳ３０２−ＹＥＳ）。
この場合、イベント制御部１０４は、非同期型イベント実行部１０３がこれまで申込ユーザの端末装置２００上で実行していた非同期型バトルイベントを停止させる制御を実行する（ステップＳ３０３）。
次に、イベント制御部１０４は、これまで実行されていた非同期型バトルイベントにおいて利用されていたキャラクタ情報として、ステップＳ３０３により停止されたときの内容のキャラクタ情報を取得する（ステップＳ３０４）。
次に、イベント制御部１０４は、ステップＳ３０４により取得したキャラクタ情報を同期型イベント実行部１０２に受け渡す。そのうえで、申込ユーザの端末装置２００と被申込みユーザの端末装置２００との間で同期型イベント実行部１０２が同期型バトルイベントを開始するように制御する（ステップＳ３０５）。これにより、先に行われていた非同期型バトルイベントにおけるキャラクタ情報を引き継いで同期型バトルイベントに移行することが可能になる。
【００８３】
＜第５の実施形態＞
［概要］
次に、第５の実施形態について説明する。
第５の実施形態において、非同期型イベント実行部１０３は、同期型イベント実行部１０２が被申込ユーザ（第１のユーザ）の端末装置２００と申込ユーザ（他のユーザ）の端末装置２００とで実行させる操作入力インターフェースよりも簡易な操作入力インターフェースを申込ユーザの端末装置２００にて実行させる。
つまり、同期型イベント実行部１０２は、高度な操作が行える高度型の操作入力インターフェースのバトルイベントを端末装置２００に提供する。一方、非同期型イベント実行部１０３は、簡易な操作が行える簡易型の操作入力インターフェースのバトルイベントを端末装置２００に提供する。
【００８４】
図１１（ａ）は、同期型バトルイベントが実行されているときに申込ユーザの端末装置２００の表示部２０３において表示されるゲーム画面４００Ａの例を示している。
このゲーム画面４００Ａの表示は、例えば、同期型イベント実行部１０２が、高度型の操作入力インターフェースのプログラムにしたがって生成したゲーム制御情報を、申込ユーザの端末装置２００のゲームアプリケーション部２０２に実行させることにより実現される。
この図１１（ａ）に示すゲーム画面４００Ａには、例えば複数のボタンＢＴが配置されている。申込ユーザは、これらのボタンＢＴを使用して高度な操作を行いながらバトルイベントを進めていくことができる。
【００８５】
なお、図示は省略するが、被申込ユーザの端末装置２００においても、図１１（ａ）と同等の操作が可能なゲーム画面が表示される。この被申込ユーザの端末装置２００において表示されるゲーム画面も、同期型イベント実行部１０２が、高度型の操作入力インターフェースのプログラムにしたがって生成したゲーム制御情報を、被申込ユーザの端末装置２００のゲームアプリケーション部２０２に実行させることにより実現される。
【００８６】
図１１（ｂ）は、非同期型バトルイベントが実行されているときに申込ユーザの端末装置２００の表示部２０３において表示されるゲーム画面４００Ｂの例を示している。
このゲーム画面４００Ｂの表示は、例えば、非同期型イベント実行部１０３が、簡易型の操作入力インターフェースのプログラムを、申込ユーザの端末装置２００のゲームアプリケーション部２０２に実行させることにより実現される。
【００８７】
この図１１（ｂ）に示すゲーム画面４００Ｂにおいては、図１１（ａ）のゲーム画面４００Ａよりも少ない数のボタンＢＴが配置されている。つまり、ゲーム画面４００Ｂの操作入力インターフェースは、ゲーム画面４００Ａよりも簡易である。
【００８８】
［第５の実施形態に対応する情報内容例］
図１２は、第５の実施形態に対応して記憶部１０５が記憶する情報例を示している。この図の記憶部１０５においては、キャラクタ情報テーブル１１０と同期型イベント登録テーブル１２０に加えて、高度型操作入力インターフェースプログラム１３０と簡易型操作入力インターフェースプログラム１４０が示されている。
【００８９】
高度型操作入力インターフェースプログラム１３０は、図１１（ａ）のゲーム画面４００Ａとして示したような高度な操作入力インターフェースを実現するためのプログラムである。
同期型イベント実行部１０２は、この高度型操作入力インターフェースプログラム１３０を端末装置２００のゲームアプリケーション部２０２に実行させる。これにより、端末装置２００の表示部２０３において、図１１（ａ）のゲーム画面４００Ａが表示され、ユーザは、このゲーム画面４００Ａに対する操作を行うことができる。このとき、ゲームアプリケーション部２０２は、高度型操作入力インターフェースプログラム１３０の実行環境において、高度型操作入力インターフェース対応情報を利用してゲーム画面４００Ａを表示部２０３に表示する。これにより、ユーザは高度型操作入力インターフェースでの操作を可能とする。
【００９０】
簡易型操作入力インターフェースプログラム１４０は、図１１（ｂ）のゲーム画面４００Ｂとして示したような簡易な操作入力インターフェースを実現するためのプログラムである。
非同期型イベント実行部１０３は、この簡易型操作入力インターフェースプログラム１４０を端末装置２００のゲームアプリケーション部２０２に実行させる。これにより、端末装置２００の表示部２０３において、図１１（ｂ）のゲーム画面４００Ｂが表示され、ユーザは、このゲーム画面４００Ｂに対する操作を行うことができる。このとき、ゲームアプリケーション部２０２は簡易型操作入力インターフェースプログラム１４０の実行環境において、簡易型操作入力インターフェース対応情報を利用してゲーム画面４００Ｂ表示部２０３に表示する。これにより、ユーザは簡易型操作入力インターフェースでの操作を可能とする。
【００９１】
また、第５の実施形態に対応する端末装置２００のアプリケーション部２０２は、図１３に示すように、高度型操作入力インターフェース対応情報２１０と、簡易型操作入力インターフェース対応情報２２０とを有する。
【００９２】
高度型操作入力インターフェース対応情報２１０は、端末装置２００のアプリケーション部２０２が、高度型操作入力インターフェースプログラム１３０を実行するにあたって利用するにあたって利用する情報である。
高度型操作入力インターフェース対応情報２１０は、ゲーム画面４００Ａに表示されるボタンごとに対応する情報を格納する。高度型操作入力インターフェース対応情報２１０における１レコードは、１つのボタンに対応する情報であって、ボタンＩＤ格納領域２１１、ボタン表示情報格納領域２１２及び処理ＩＤ格納領域２１３を含む。
【００９３】
ボタンＩＤ格納領域２１１は、ゲーム画面４００Ａに表示されるボタンＢＴのうち、対応のボタンＢＴを一意に識別するボタンＩＤを格納する領域である。
ボタン表示情報格納領域２１２は、対応のボタンＢＴの表示に関連する情報であるボタン表示情報を格納する。ボタン表示情報格納領域２１２は、例えば、対応のボタンＢＴのオブジェクトとしての画像データやゲーム画面４００Ａにおける表示位置の情報などを含む。アプリケーション部２０２は、このボタン表示情報を利用してゲーム画面４００ＡにおけるボタンＢＴを表示させる。
対応処理ＩＤ格納領域２１３は、対応のボタンＢＴに対する操作が行われたときにアプリケーション部２０２が実行すべき処理を一意に識別する処理ＩＤを格納する。
【００９４】
また、簡易型操作入力インターフェース対応情報２２０は、端末装置２００のアプリケーション部２０２が、簡易型操作入力インターフェースプログラム１４０を実行するにあたって利用するにあたって利用する情報である。
簡易型操作入力インターフェース対応情報２２０は、ゲーム画面４００Ｂに表示されるボタンごとに対応する情報を格納する。簡易型操作入力インターフェース対応情報２２０における１レコードは、１つのボタンに対応する情報であって、ボタンＩＤ格納領域２２１、ボタン表示情報格納領域２２２及び処理ＩＤ格納領域２２３を含む。なお、ボタンＩＤ格納領域２２１、ボタン表示情報格納領域２２２及び処理ＩＤ格納領域２２３の定義内容については、それぞれ、高度型操作入力インターフェース対応情報２１０におけるボタンＩＤ格納領域２１１、ボタン表示情報格納領域２１２及び処理ＩＤ格納領域２１３に準ずるため、ここでの説明は省略する。
【００９５】
非同期型バトルイベントの場合、被申込ユーザのキャラクタはＮＰＣである。ＮＰＣと対戦するのに、同期型バトルイベントのときと同じ高度な操作はかえって面倒であると考えるユーザもいる。
そこで、第５の実施形態のように非同期型バトルイベントについて簡易な操作入力インターフェースとすることで、対戦相手がＮＰＣである非同期型バトルイベントのとき、申込ユーザは簡易な操作でバトルイベントをプレイすることができる。
【００９６】
また、非同期型バトルイベントにおいて簡易型の操作入力インターフェースとすることで、非同期型バトルイベントを実行している端末装置２００とゲームサーバ１００とのトラフィックを抑制することができる。これにより、ゲームサーバ１００の通信負荷が軽減され、例えば同期型バトルイベントのためにゲームサーバ１００が実行している通信の通信品質についても良好な状態が維持されることを期待できる。
【００９７】
なお、第５の実施形態においては、例えば非同期型バトルイベントを開始するにあたり、申込ユーザが、図１１（ａ）のような高度型の操作入力インターフェースと、図１１（ｂ）のような簡易型の操作入力インターフェースとのいずれかを選択できるようにしてもよい。
【００９８】
＜第６の実施形態＞
次に、第６の実施形態について説明する。
第６の実施形態において、非同期型イベント実行部１０３は、申込ユーザ（第３ユーザ）のキャラクタ情報と、実行中の同期型バトルイベントにおいて使用されているのと同じ被申込ユーザ（第１ユーザ）のキャラクタ情報とを使用して前記非同期型イベントを開始する。
つまり、第１の実施形態では、非同期型バトルイベントを開始するにあたり、そのときに実行中の同期型バトルイベントにおいて使用されていない被申込ユーザのキャラクタ情報を非同期型バトルイベントに使用することとしていた。つまり、第１の実施形態では、実行中の同期型バトルイベントで使用されている被申込ユーザのキャラクタ情報については、非同期型バトルイベントで使用しないこととしていた。
【００９９】
これに対して、第６の実施形態においては、実行中の同期型バトルイベントで使用されている被申込ユーザのキャラクタ情報を非同期型バトルイベントにおいても使用する。これにより、例えば、被申込ユーザが１つのキャラクタしか持っていなくとも、この被申込ユーザと２以上の申込ユーザとがバトルイベントを問題なく行える。
【０１００】
ただし、このように同期型バトルイベントと非同期型バトルイベントとで共通のキャラクタ情報を使用する場合には、それぞれのバトルイベントの結果が適正に反映されるようにキャラクタ情報を管理する必要がある。
【０１０１】
そこで、第６の実施形態においては、以下のように、被申込ユーザのキャラクタ情報を管理する。
同期型イベント実行部１０２は、同期型バトルイベントが開始されるタイミングで記憶部１０５に記憶されるキャラクタ情報テーブル１１０のキャラクタ情報格納領域１１２から被申込ユーザのキャラクタ情報を読み出して一時記憶キャラクタ情報を生成し、これを保持する。一時記憶キャラクタ情報は、同期型イベント実行部１０２が作業中のデータとして一時的に保持するキャラクタ情報である。つまり、同期型イベント実行部１０２は、同期型バトルイベント中におけるバトルの経過に応じたキャラクタ情報の変更を、この一時記憶キャラクタ情報に対して実行する。そして、同期型イベント実行部１０２は同期型バトルイベントが終了するのに応じて、一時記憶キャラクタ情報に基づいて、キャラクタ情報格納領域１１２のキャラクタ情報を更新する処理を実行する。
【０１０２】
同様に、非同期型イベント実行部１０３は、非同期型バトルイベントが開始されるタイミングで記憶部１０５から被申込ユーザのキャラクタ情報を読み出して一時記憶キャラクタ情報を生成し、これを保持する。非同期型イベント実行部１０３は、非同期型バトルイベント中におけるバトルの経過に応じたキャラクタ情報の変更を、一時記憶キャラクタ情報に対して実行する。そして、非同期型バトルイベントが終了するのに応じて、一時記憶キャラクタ情報に基づいて、キャラクタ情報格納領域のキャラクタ情報を更新する処理を実行する。
【０１０３】
つまり、同期型イベント実行部１０２は、同期型バトルイベントが開始されるタイミングで記憶部１０５から読み出した被申込ユーザのキャラクタ情報と同期型バトルイベントの終了したタイミングにおける被申込ユーザのキャラクタ情報との差分を生成する。そして、同期型イベント実行部１０２は、求めた差分に基づいて、この同期型バトルイベントが終了したタイミングにおいて記憶部１０５に記憶されている被申込ユーザのキャラクタ情報を更新する。
【０１０４】
また、非同期型イベント実行部１０３は、非同期型バトルイベントが開始されるタイミングで記憶部１０５から読み出した被申込ユーザのキャラクタ情報と非同期型バトルイベントが終了したタイミングにおける被申込ユーザのキャラクタ情報との差分を求める。そして、非同期型イベント実行部１０３は、求めた差分に基づいて、この非同期型イベントが終了したタイミングにおいて記憶部１０５に記憶されている被申込ユーザのキャラクタ情報を更新する。
【０１０５】
これにより、同期型バトルイベントと非同期型バトルイベントとで同じ被申込ユーザのキャラクタを使用しても、これらの同期型バトルイベントと非同期型バトルイベントのそれぞれの結果に応じた変更されたキャラクタ情報の内容が統合される。そして、この統合された内容を記憶部１０５に記憶されるキャラクタ情報に反映させることにより、キャラクタ情報を適切に管理することができる。
【０１０６】
図１４は、第６の実施形態において同期型イベント実行部１０２と非同期型イベント実行部１０３が実行する申込ユーザのキャラクタ情報の更新についての一具体例を示している。なお、この図においては図示及び説明を簡単にする便宜上、キャラクタ情報格納領域１１２に格納される情報のうちからヒットポイント格納領域１１２ｃに格納されるヒットポイントと、経験値格納領域１１２ｆに格納される経験値のみを示している。同図の説明においてヒットポイント格納領域１１２ｃと経験値格納領域１１２ｆとの領域については、キャラクタ情報１１２Ａ（１１２Ａ−１〜１１２Ａ−７）と記載する。
【０１０７】
まず、時刻ｔ１において、同期型イベント実行部１０２は、同期型イベントを開始する。この同期型バトルイベントの開始に応じて、同期型イベント実行部１０２は、申込ユーザに対応するキャラクタ情報を記憶部１０５から読み出す。
このとき、キャラクタ情報１１２Ａ−１として示すように、記憶部１０５に記憶されているヒットポイントの値は「１２０」であり、経験値の値は「１００」である。したがって、キャラクタ情報１１２Ａ−２として示すように、同期型イベント実行部１０２が時刻ｔ１において読み出したヒットポイントの値は「１２０」、経験値の値は「１００」であり、記憶部１０５に記憶されていた内容と同じである。
【０１０８】
そして、時刻ｔ１以降において、同期型イベント実行部１０２は、同期型バトルイベントを実行する。このとき同期型イベント実行部１０２は、同期型バトルイベントにおいて例えばバトルが行われるごとに、そのバトルの結果に応じて、キャラクタ情報における各情報の値を変更していく。
【０１０９】
また、時刻ｔ１から或る時間を経過した時刻ｔ２において、非同期型イベント実行部１０３は、非同期型バトルイベントを開始する。この非同期型イベント実行部１０３の開始に応じて、非同期型イベント実行部１０３は、申込ユーザに対応するキャラクタ情報を記憶部１０５から読み出す。時刻ｔ１から時刻ｔ２までにおいて、記憶部１０５に記憶される申込ユーザのキャラクタ情報に変更はない。したがって、キャラクタ情報１１２Ａ−５として示すように、時刻ｔ２において非同期型イベント実行部１０３が読み出したヒットポイントの値は「１２０」であり、経験値の値は「１００」である。
【０１１０】
そして、時刻ｔ２以降において、非同期型イベント実行部１０３は、非同期型バトルイベントを実行する。このとき非同期型イベント実行部１０３は、非同期型バトルイベントにおいて例えばバトルが行われるごとに、そのバトルの結果に応じて、キャラクタ情報における各情報の値を変更していく。
【０１１１】
そして、時刻ｔ２から或る時間を経過した時刻ｔ３において、同期型イベント実行部１０２は同期型バトルイベントを終了させる。この同期型バトルイベントが終了したタイミングにおいては、キャラクタ情報１１２Ａ−３として示すように、ヒットポイントの値は「１２０」から「８０」に変更され、経験値の値は「１００」から「１１０」に変更されている。
この場合、同期型バトルイベントの開始タイミングにおいて記憶部１０５から読み出したキャラクタ情報と同期型バトルイベントが終了したタイミングにおけるキャラクタ情報との差分は以下のようになる。つまり、ヒットポイントの差分は「−４０（＝８０−１２０）」であり、経験値の差分は「１０（＝１１０−１００）」である。
【０１１２】
上記のように同期型バトルイベントが終了した時刻ｔ３において、同期型イベント実行部１０２は、以下のように記憶部１０５に記憶されるキャラクタ情報を更新する。
つまり、この場合のヒットポイントの差分は「−４０」であるので、同期型イベント実行部１０２は、キャラクタ情報１１２Ａ−１において示される「１２０」のヒットポイントに対して「−４０」を加算することにより「８０」を求める。同期型イベント実行部１０２は、このように求めた「８０」の値により、キャラクタ情報１１２Ａ−４として示すようにヒットポイント格納領域１１２ｃに格納されるヒットポイントを更新する。
また、この場合の経験値の差分は、「１０」であるので、同期型イベント実行部１０２はキャラクタ情報１１２Ａ−１として示す「１００」のヒットポイントに対して「１０」を加算することにより「１１０」を求める。同期型イベント実行部１０２は、このように求めた「１００」の値により、キャラクタ情報１１２Ａ−４として示すように経験値格納領域１１２ｆに格納される経験値を更新する。
【０１１３】
また、時刻ｔ３から或る時間を経過した時刻ｔ４において、非同期型イベント実行部１０３は非同期型バトルイベントを終了させる。この非同期型バトルイベントが終了したタイミングにおいて、キャラクタ情報１１２Ａ−６として示すように、ヒットポイントの値は「１２０」から「９０」に変更され、経験値の値は「１００」から「１３０」に変更されている。
この場合、同期型バトルイベントの開始タイミングと同期型バトルイベントが終了したタイミングにおけるヒットポイントの差分は「−３０」であり、経験値の差分は「３０」である。
【０１１４】
この場合、非同期型イベント実行部１０３は、この時刻ｔ４において記憶部１０５に記憶されていた、キャラクタ情報１１２Ａ−４における「８０」のヒットポイントに対して差分の「−３０」を加算することにより「５０」を求める。非同期型イベント実行部１０３は、このように求めた「５０」の値により、キャラクタ情報１１２Ａ−７に示すようにヒットポイント格納領域１１２ｃに格納されるヒットポイントを更新する。
また、非同期型イベント実行部１０３は、キャラクタ情報１１２Ａ−４に示される「１１０」のヒットポイントに対して差分の「３０」を加算することにより「１４０」の値を求める。非同期型イベント実行部１０３は、このように求めた「１４０」の値により、キャラクタ情報１１２Ａ−７に示すように経験値格納領域１１２ｆに格納される経験値を更新する。
【０１１５】
これまでの説明から理解されるように、図１４（ｇ）に示す被申込ユーザのヒットポイント及び経験値は、同期型バトルイベントによるヒットポイント及び経験値の変化と、非同期型バトルイベントによるヒットポイント及び経験値の変化とが反映されている。
つまり、第６の実施形態においては、同期型バトルイベントと非同期型バトルイベントとで共通のキャラクタが使用されるのであるが、同期型バトルイベントと非同期型バトルイベントのそれぞれにより変更されたキャラクタ情報を統合することができる。そして、この統合された結果が示されるように記憶部１０５のキャラクタ情報が更新されていくものである。これにより、同期型バトルイベントと非同期型バトルイベントとで被申込ユーザに対応して同じキャラクタが使用される環境であっても、適正にキャラクタ情報を管理することができる。
【０１１６】
なお、同期型バトルイベントまたは非同期型バトルイベントが開始されるのに応じて、例えば、申込ユーザに関連するユーザの端末装置２００に対して、申込ユーザがバトルイベントを開始したことを通知してもよい。この通知は、例えば申込ユーザと友人関係にあるものとして登録されているユーザを対象として行うことができる。通知を受けた友人は、申込ユーザを加勢するために、自分も申込ユーザとしてバトルイベント申込を行うことができる。
また、この通知は、例えば被申込ユーザが端末装置２００上でゲームアプリケーションを起動させていないことにより非同期型バトルイベントが開始される場合には、被申込ユーザに対して行うようにしてもよい。
【０１１７】
また、これまでの説明において同期型イベントと非同期型イベントがバトルイベントである場合の例を示したが、同期型イベントと非同期型イベントは、バトルイベント以外の態様のものであってもよい。一例として、ユーザ同士のアバターがコミュニケーションを図るようなものであってもよい。
【０１１８】
また、例えば端末装置２００に、同期型イベント実行部１０２と非同期型イベント実行部１０３とイベント制御部１０４とに相当する機能部を設ける。そのうえで、例えばバトルイベント申込を受信した端末装置２００が、同期型イベントと非同期型イベントとについての制御を行うように構成することも可能である。このような構成では、例えばＰ２Ｐによる同期型イベントを端末装置２００間で実行させることが可能になる。
【０１１９】
また、これまでの説明においては、端末装置２００は、例えば携帯電話やスマートフォンなどの無線端末装置であることとしている。つまり、実施形態におけるゲームは無線通信を伴っている。本発明は、無線通信である場合に有効ではあるが、例えばゲームサーバ１００と端末装置２００とが有線により通信を行う環境に対しても適用できる。
【０１２０】
また、図３における各部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより同期型イベントと非同期型イベントに関する制御を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【０１２１】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。
【０１２２】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【０１２３】
１００  ゲームサーバ
１０１  通信部
１０２  同期型イベント実行部
１０３  非同期型イベント実行部
１０４  イベント制御部
１０５  記憶部
１１０  キャラクタ情報テーブル
１２０  高度型操作入力インターフェースプログラム
１３０  簡易型操作入力インターフェースプログラム
２００  端末装置
２０１  通信部
２０２  ゲームアプリケーション部
２０３  表示部
２０４  操作部
３００  ネットワーク
５００  ゲームサーバ
【図１】
2014028016.tif 000003
【図２】
2014028016.tif 000004
【図３】
2014028016.tif 000005
【図４】
2014028016.tif 000006
【図５】
2014028016.tif 000007
【図６】
2014028016.tif 000008
【図７】
2014028016.tif 000009
【図８】
2014028016.tif 000010
【図９】
2014028016.tif 000011
【図１０】
2014028016.tif 000012
【図１１】
2014028016.tif 000013
【図１２】
2014028016.tif 000014
【図１３】
2014028016.tif 000015
【図１４】
2014028016.tif 000016