JP6437890B2 - プログラム、サーバ装置、及びゲーム制御方法 - Google Patents

Description

本発明は、プログラム、サーバ装置、及びゲーム制御方法に関する。

近年、ゲーム業界では、複数のユーザが参加可能なソーシャルアプリケーションを用いたゲームが普及してきている。この種のソーシャルアプリケーションは、端末にダウンロードされ、当該端末にインストールされて利用されるネイティブアプリケーションと、ウェブサーバ上で動作し、端末のウェブブラウザに利用されるウェブアプリケーションとに大別できる。

ネイティブアプリケーションは、スマートフォンのiPhone（登録商標）端末やAndroid（登録商標）端末といった端末のＯＳに依存するアプリケーションである。例えば、サーバ装置は、Objective-Cを搭載したiPhoneアプリケーション、又はJava（登録商標）を搭載したAndroidアプリケーション等のネイティブアプリケーションをプラットフォームから各端末に配信している。ユーザは、プラットフォームから端末に配信されたネイティブアプリケーション（例：ＲＰＧ（role playing game）、バトル、恋愛等のゲームを含む）を楽しんでいる。

但し、ネイティブアプリケーションは、iPhone端末に対応したプログラミング言語「Objective-C」と、Android端末に対応したプログラミング言語「Java」との２種類で開発する必要がある。このため、ネイティブアプリケーションは、端末のプラットフォーム特有の言語を使ったコーディング処理を介した後に、公式のマーケットプレイスを通して公開する必要がある。

一方、ウェブアプリケーションは、両プラットフォームに向けてＨＴＭＬ５（Hyper Text Markup Language 5）、JavaScript（登録商標）、ＣＳＳ３（Cascading Style Sheets 3）等の言語をベースにしたクロス開発が可能であり、公開に当たって公式のマーケットプレイスを通す必要がない。また、ウェブアプリケーションは、端末のＯＳに依存しない。

ここで、JavaScriptとは、オブジェクト指向スクリプト言語である。主にウェブブラウザなどのクライアントサイドで実装され、動的なウェブサイトの構築や、ＲＩＡ（rich Internet application）などの高度なユーザインタフェースの開発に用いられる。JavaScriptはプロトタイプベースのオブジェクト指向プログラミング言語である。

JavaScriptは、多くの場合、Ｃ言語に似た手続き型言語のようなスタイルで書かれるが、第一級関数をサポートしている（関数を第一級オブジェクトとして扱える）など、関数型言語の性質も持ち合わせるように設計されている。JavaScriptは、そのような柔軟な設計から、いくつかのアプリケーションではマクロ言語としても採用されている。また、マークアップ言語（例：ＨＴＭＬ（hypertext markup language）、ＰＨＰ（PHP: Hypertext Preprocessor））での通信方式は、リクエスト＆レスポンス方式を採用している。

リクエスト＆レスポンス方式では、ユーザによるクライアント装置の操作に応じて、クライアント装置からサーバ装置にリクエストが送信され、サーバ装置からクライアント端末にレスポンスが返信される。また、リクエスト＆レスポンス方式では、サービスに応じてシステムを動的に形成する際に、サービス実行に必要な機能群を待機させ、状況に応じて機能群を選択してサービスを実行する技術が知られている（例えば、特許文献１参照）。

図２９はリクエスト＆レスポンス方式を用いたバトルゲームを提供するゲームシステムの構成を示す模式図である。この種のバトルゲームとしては、携帯端末のユーザの操作により敵とのバトルを行うゲームであればよく、ここでは、敵であるレイドボスとのバトルを行うレイドバトルゲームを例に挙げて述べる。このレイドバトルゲームでは、通常のボス（boss）よりも強いレイドボス（raid boss）をサーバ装置Ｓｖが仮想空間に出現させる。なお、「強い」とは、例えば、ＨＰ（体力）が高いことや、攻撃によるダメージを受けにくいことを意味する。第１〜第３ユーザは、iPhone端末又はAndroid端末といった第１〜第３クライアント装置ＣＬ１〜ＣＬ３のタッチパネルを連続的にタップする等の操作により、このレイドボスとバトル（battle）する。例えば、制限時間内にレイドボスを退治できた場合にはユーザの勝ちであり、他の場合にはユーザの負けである。

具体的には、サーバ装置Ｓｖは、バトル開始時から制限時間までの間、経過時間を計測する。各クライアント装置ＣＬ１〜ＣＬ３は、各ユーザの操作に応じたリクエストをサーバ装置Ｓｖに送信する。サーバ装置Ｓｖは、リクエストに応じてレイドボスのＨＰを減少させる処理やレイドボスが防御する処理などを実行し、処理結果をレスポンスとして各クライアント装置ＣＬ１〜ＣＬ３に返信する。

しかしながら、各クライアント装置ＣＬ１〜ＣＬ３から大量のリクエストがサーバ装置Ｓｖに送信されると、サーバ装置Ｓｖに著しく処理負荷がかかる。このため、リクエスト＆レスポンス方式では、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数を制限し、他のクライアント装置ＣＬ３を強制的にロックする通信方式を用いている。

特開２００４−７０８４５号公報（段落００１５−００１７、要約書 ）

一方、以上のような通信方式では、ロックされたクライアント装置ＣＬ３は、サーバ装置Ｓｖからロックが解除された後でなければ、正常な処理を実行できないという不都合がある。

また、リクエスト＆レスポンス方式では、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間でマークアップ言語を送受信する場合、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間で複数ページに渡るヘッダ情報を送受信する必要がある。これにより、通信毎にヘッダ情報がサーバ装置Ｓｖに蓄積されるため、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数が制限されている。

本発明は上記実情を考慮してなされたもので、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、バトルゲームを実現し得るプログラム、サーバ装置、及びゲーム制御方法を提供することを目的とする。

本発明の第１の観点は、複数の携帯端末にゲームを提供するサーバ装置に、前記ゲームの一部を構成する対戦に参加するための第１の要求を前記サーバ装置に対して送信した複数の第１の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第１の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第１ステップと、前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２ステップと、前記第１ステップにおいて前記対戦の開始までの所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の一時的な１つのグループとして前記対戦に参加させる第３ステップと、前記対戦に参加しているいずれかのユーザの第１の携帯端末から対戦中のイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第１の携帯端末に送信する第４ステップとを実行させるプログラムである。

本発明によれば、クライアント装置の数を制限せずに、複数のクライアント装置をサーバ装置に接続でき、バトルゲームを実現することができる。

本発明の第１の実施形態に係るゲーム制御方法が適用されたゲームシステム及びその周辺構成の一例を示す模式図である。 同第１の実施形態におけるウェブサーバ装置の機能ブロック構成の一例を示す模式図である。 同第１の実施形態における携帯端末の機能ブロック構成の一例を示す模式図である。 同第１の実施形態におけるウェブサーバ装置と携帯端末間の接続アーキテクチャの概念を示す模式図である。 同第１の実施形態における動作を説明するためのシーケンス図である。 同第１の実施形態における動作を説明するための模式図である。 同第１の実施形態における動作を説明するための模式図である。 同第１の実施形態における動作を説明するための模式図である。 同第１の実施形態における動作を説明するための模式図である。 同第１の実施形態における動作を説明するための模式図である。 第２の実施形態における動作を説明するためのフローチャートである。 同第２の実施形態におけるログ情報の一例を示す模式図である。 同第３の実施形態における動作を説明するためのフローチャートである。 同第３の実施形態におけるレイドボス属性データの一例を示す模式図である。 同第３の実施形態における属性の優劣関係の一例を説明するための模式図である。 同第３の実施形態における属性のＨＰの一例を説明するための模式図である。 同第３の実施形態における端末属性データの一例を示す模式図である。 同第４の実施形態に係るゲーム制御方法が適用されたゲームシステム及びその周辺構成の一例を示す模式図である。 同第４の実施形態における携帯端末の用途の一例を示す模式図である。 同第４の実施形態における応援データの一例を示す模式図である。 同第４の実施形態におけるログ情報の一例を示す模式図である。 同第４の実施形態における動作を説明するためのフローチャートである。 同第４の実施形態における動作の一例を説明するためのフローチャートである。 同第４の実施形態における動作の一例を説明するためのフローチャートである。 同第５の実施形態におけるギャザリングデータの一例を示す模式図である。 同第５の実施形態におけるログ情報の一例を示す模式図である。 同第５の実施形態における動作を説明するためのフローチャートである。 同第５の実施形態における動作の一例を説明するためのフローチャートである。 一般的なリクエスト＆レスポンス方式を用いたバトルゲームを提供するゲームシステムの構成を示す模式図である。

＜第１の実施の形態＞
以下、本発明の第１の実施の形態について図面を用いて説明する。なお、以下の各装置は、それぞれハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は情報記録媒体から各装置のコンピュータにインストールされ、対応する装置の機能を実現させるためのプログラムが用いられる。

図１は本発明の第１の実施の形態に係るゲーム制御方法が適用されたゲームシステムの構成例を示す模式図である。インターネットなどを含むネットワーク１に対し、ウェブサーバ装置２が接続されると共に、本システムでユーザが使用するクライアント装置となる、複数、例えば３台の携帯端末４Ａ〜４Ｃが、無線ＬＡＮのアクセスポイント（ＡＰ）５、あるいは基地局６を介して接続される。

ウェブサーバ装置２は、バトルゲームを実現するためのゲーム制御プログラム及びイベント情報を携帯端末４Ａ〜４Ｃに提供するコンピュータである。このウェブサーバ装置２は、例えばＳＮＳ（Social Networking Service）を運営する企業が、サービスの一環としてオンラインゲームのサービスを提供するべく設置するものであり、ネットワーク１に接続される。

一方、クライアント側の携帯端末４Ａ〜４Ｃは、それぞれスマートフォン、フィーチャー・フォンなどを含み、例えば、Android又はiOSなどのＯＳ（Operating System）上で動作する携帯電話であっても良いし、さらにはノートブック型のパーソナルコンピュータ、モバイルコンピュータなどであっても良い。以下の実施形態では、説明を簡略化するために、携帯端末４Ａ〜４Ｃはいずれもタッチパネルを有するスマートフォンであるものとして説明する。

携帯端末４Ａ〜４Ｃは、上記基地局６を介してのネットワーク１との接続に加えて、例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ規格の無線ＬＡＮ（Local Area Network）であるＷｉ−Ｆｉ（登録商標）を優先的に選択可能として、上記アクセスポイント５と相互接続が可能であるものとする。

また、携帯端末４Ａ〜４Ｃは、例えば、近距離無線通信規格であるBluetooth（登録商標）技術により相互に無線接続が可能となっている。

携帯端末４Ａ〜４Ｃとしては、その機種固有のハードウェア構成、採用しているＯＳ、インストールされているアプリケーション等が多岐にわたるものとし、ウェブサーバ装置２はそれら多様な携帯端末４Ａ〜４Ｃに対応した各種アプリケーションプログラムをそれぞれに配信可能であるものとする。

上記ウェブサーバ装置２と携帯端末４Ａ〜４Ｃそれぞれの機能ブロック構成について図２及び図３を参照して述べる。

ウェブサーバ装置２は、図２に示すように、記憶装置２１、メモリ２２、プロセッサ２３及び通信部２４を備えている。

記憶装置２１は、バトルゲームを実現するためのゲーム制御プログラムｐ_ｓ３等を記憶するものであり、例えば、ハードディスクドライブ（ＨＤＤ）、光ディスクドライブ、ＤＶＤ、ＭＯなどの大容量記憶装置である。この記憶装置２１には、ＯＳ（オペレーティングシステム）ｐ_ｓ０、サーバ側ＪＳ実行環境プログラムｐ_ｓ１、Ａ社フレームワークプログラムｐ_ｓ２及びゲーム制御プログラムｐ_ｓ３が記憶されている。

ＯＳ ｐ_ｓ０、は、ウェブサーバ装置２の基本的な機能を実現するためのプログラムで
ある。

サーバ側ＪＳ実行環境プログラムｐ_ｓ１は、プロセッサ２３により実行され、後述するサーバ側ＪＳ実行環境Ｓ１を実現するためのプログラムである。

Ａ社フレームワークプログラムｐ_ｓ２は、プロセッサ２３により実行され、後述するＡ社フレームワークＳ２を実現するためのプログラムである。

ゲーム制御プログラムｐ_ｓ３は、プロセッサ２３により実行され、本発明の実施の形態に係るバトルゲームを実現するためのプログラムである。補足すると、ゲーム制御プログラムｐ_ｓ３は、複数の携帯端末４Ａ〜４Ｃが敵をそれぞれ表示し、各携帯端末４Ａ〜４Ｃのユーザの操作により敵とのバトルを行うバトルゲームを当該各携帯端末に実行させるためのプログラムである。

ここで、敵は、例えば、イベント情報によるアタック（攻撃）を受けるレイドボスとしてもよく、バトルゲームは、当該レイドボスとバトルを行うレイドバトルゲームとしてもよい。以下の説明では、敵がレイドボスであり、バトルゲームがレイドバトルゲームである場合を例に挙げて述べる。この場合、レイドバトルゲームは、例えば、バトル開始時から制限時間内にレイドボスを退治できるか否かで勝敗が決まる方式や、制限時間なしにレイドボスを退治できるか否かで勝敗が決まる方式のいずれでも実施可能である。バトル開始時は、レイドバトルゲーム開始時又はレイドボス出現時のいずれでもよい。また、「退治」とは、ＨＰ（体力）値をゼロにする方式、ダメージ値を目標値まで蓄積する方式、又は所定の弱点を攻撃する方式のいずれでも実施可能である。なお、レイドボスの設定（例、応戦する／応戦しない、ＨＰ値、ダメージ値の目標値、所定の弱点など）は、レイドバトルゲームの方式等に応じて若干変わるが、通常のボスよりも強い（＝退治しにくい）ボスであることに変わりはない。

また、ゲーム制御プログラムｐ_ｓ３は、レイドバトルゲームの様々な方式に基づくゲーム機能の他に、以下の機能（ｆ１）〜（ｆ３）をプロセッサ２３に実現させるためのプログラムを含んでいる。

（ｆ１） 各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受けると、当該各携帯端末４Ａ〜４Ｃとの接続を確立してハンドシェイク応答を返信し、各携帯端末４Ａ〜４Ｃにバトルを開始させる接続確立機能。

（ｆ２） 各携帯端末４Ａ〜４Ｃのうちのいずれかの携帯端末（例、４Ａ）からユーザの操作に応じたイベント情報を受けると、当該イベント情報をウェブソケットの通信規格に従って当該いずれかの携帯端末（例、４Ａ）以外の他の携帯端末（例、４Ｂ，４Ｃ）に送信するウェブソケット通信機能。

ここで、当該イベント情報は、ユーザの操作を示すアクション情報と、当該操作された時点から所定の期間を示す期間情報とを含んでもよい。また、当該ウェブソケット通信機能（ｆ２）においては、プロセッサ２３が、イベント情報を当該イベント情報に含まれる期間情報が示す期間内に他の携帯端末（例、４Ｂ，４Ｃ）に送信するものとしてもよい。

（ｆ３） イベント情報又は制限時間に基づいてバトルを終了させると、各携帯端末４Ａ〜４Ｃとの接続を切断する接続切断機能。

メモリ２２は、ゲーム制御プログラムｐ_ｓ３等を実行する際に必要とされるワークエリアなどとして使用される。

プロセッサ２３は、記憶装置２１に記憶されたゲーム制御プログラムｐ_ｓ３と協働して、本発明の実施の形態に係るバトルゲームを行なう他、ウェブサーバ装置２全体の制御を司るものである。

通信部２４は、ネットワーク１を介した携帯端末４Ａ〜４Ｃなどの外部装置との通信の制御を司る。

各携帯端末４Ａ〜４Ｃの機能ブロック構成は、互いに同一のため、ここでは携帯端末４Ａの機能ブロック構成を代表例に挙げて述べる。

携帯端末４Ａは、図３に示すように、記憶装置４１Ａ、メモリ４２Ａ、プロセッサ４３Ａ、通信部４４Ａ、電子コンパス４５Ａ、カメラ４６Ａ、表示部４７Ａ及びタッチパネル４８Ａを備えている。各部４１Ａ〜４８Ａの説明は、符号の末尾ＡをＢ又はＣに読み替えることにより、他の携帯端末４Ｂの各部４１Ｂ〜４８Ｂの説明又は他の携帯端末４Ｃの各部４１Ｃ〜４８Ｃの説明として読み替え可能となっている。

記憶装置４１Ａは、バトルゲームを実現するためのクライアントサイドのゲーム制御プログラムｐ_ｃ４等を記憶するものであり、例えば、ハードディスクドライブ（ＨＤＤ）などの大容量記憶装置である。この記憶装置４１Ａには、ＯＳ（オペレーティングシステム）ｐ_ｃ０、アプリケーション実行環境プログラムｐ_ｃ１、Ａ社ＤＢ接続キットプログラムｐ_ｃ２、Ａ社フレームワークプログラムｐ_ｃ３及びゲーム制御プログラムｐ_ｃ４が記憶されている。

ＯＳ ｐ_ｃ０は、携帯端末４Ａの基本的な機能を実現するためのプログラムである。

アプリケーション実行環境プログラムｐ_ｃ１は、プロセッサ４３Ａにより実行され、後述するアプリケーション実行環境Ｃ１を実現するためのプログラムである。

Ａ社ＤＢ接続キットプログラムｐ_ｃ２は、プロセッサ４３Ａにより実行され、後述するＡ社ＤＢ接続キットＣ２を実現するためのプログラムである。

Ａ社フレームワークプログラムｐ_ｃ３は、プロセッサ４３Ａにより実行され、後述するＡ社フレームワークＣ３を実現するためのプログラムである。

ゲーム制御プログラムｐ_ｃ４は、プロセッサ４３Ａにより実行され、本発明の実施の形態に係るバトルゲームのクライアント側の処理を制御するプログラムである。

メモリ４２Ａは、クライアントサイドのゲーム制御プログラムｐ_ｃ４を実行する際に必要とされるワークエリアなどとして使用される。

プロセッサ４３Ａは、記憶装置４１Ａに記憶されたゲーム制御プログラムｐ_ｃ４と協働して、本発明の実施の形態に係るバトルゲームを行なう他、携帯端末４Ａ全体の制御を司るものである。

通信部４４Ａは、ネットワーク１を介したウェブサーバ装置２などの外部装置との通信の制御を司る。また、通信部４３は、無線ＬＡＮ、ブルートゥース（登録商標）、ＷｉＦｉなどの無線通信機能をも有する。

電子コンパス４５Ａは、地磁気センサを有し、方位を測定する。

カメラ４６Ａは、撮像機能を有し、撮像した画像を記憶装置４１Ａに格納する。

表示部４７Ａは、タッチパネル４８Ａが取り付けられたディスプレイ装置である。

タッチパネル４８Ａは、ユーザの操作に応じて、操作データを入力する機能をもっている。

上記ウェブサーバ装置２と携帯端末４Ａ〜４Ｃそれぞれの機能ブロック構成に対応する電子回路のハードウェア構成自体は、きわめて一般的で周知であるものとして、その記載及び説明を省略する。

図４は、本実施形態に係るウェブサーバ装置２と携帯端末４Ａ〜４Ｃ間の接続アーキテクチャの概念を示す模式図である。同図に示すように、Ａ社が提供するオンラインのゲームプログラム又はアプリケーションプログラムを実行するに当たり、携帯端末４Ａ〜４Ｃには、例えばＡＩＲ（登録商標）などで記述された、当該ゲームプログラム又はアプリケーションプログラムのためのアプリケーション実行環境Ｃ１が実装されると共に、当該Ａ社のデータベースに接続して課金処理等を行うためのＡ社データベース接続キットＣ２が組込まれる。

これと共に、携帯端末４Ａ〜４Ｃがウェブサーバ装置２との通信を行う部分に関しては、Ａ社が開発した（ソフトウェア）クライアントサイドのフレームワークＣ３がインストールされる。

一方のウェブサーバ装置２では、オンラインゲーム及びアプリケーションを実行するための、例えばNode.js（登録商標）で記述されたサーバ側JavaScript（登録商標）実行環境Ｓ１が設けられると共に、携帯端末４Ａ〜４Ｃとの通信を行う部分には、上記フレームワークＣ３と対応するＡ社（ソフトウェア）サーバサイドのフレームワークＳ２が設けられる。

携帯端末４Ａ〜４ＣのフレームワークＣ３と、ウェブサーバ装置２のフレームワークＳ２との間では、ＨＴＭＬ５に関連した規格であるウェブソケット（WebSocket）を基盤としてアイテムの情報等が送受される。

ウェブソケットによれば、サーバクライアント間でＨＴＴＰ（hypertext transfer protocol）を使用して１回ハンドシェイクを行い、サーバクライアント間で接続が確立すると、ＨＴＴＰ（リクエスト＆レスポンス方式）を使用せずに、ウェブソケット専用のプロトコルで双方向通信が実行される。ウェブソケットによる双方向通信は、長時間の接続を前提としており、サーバ又はクライアントにより切断されるまで継続して実行される。また、ウェブソケットによる通信は、ＨＴＴＰ通信よりもヘッダ情報及び処理負荷（オーバーヘッド）が小さい利点もある。さらに、ウェブソケットによる通信は、接続状態にある全ての装置が同じデータをリアルタイムで送受信して共有できる利点もある。また、ウェブソケットでは、クライアント側とサーバ側のいずれからでも送信が可能であり、例えば、サーバ側からクライアント側にデータをプッシュ配信することが可能である。

このように、ウェブソケットによれば、処理負荷が小さいリアルタイム通信を実現できるので、従来とは異なり、クライアント装置の数を制限せずに、複数のクライアント装置をサーバ装置に接続でき、バトルゲームを実現できる。

上記フレームワークＣ３、Ｓ２は、ＯＳに依存しないスクリプト言語として、例えばJavaScriptを用いて記述されている。そのため、携帯端末４Ａ〜４ＣのＯＳがAndroid及びiOSなどのいずれのＯＳであっても同一接続環境を構築できる。

次に、以上のように構成されたゲームシステムの動作について図５のシーケンス図及び図６乃至図１０の模式図を用いて説明する。なお、以下の説明では、ウェブサーバ装置２には、予め図２に示した各プログラムｐ_ｓ１〜ｐ_ｓ３がインストールされているものとする。同様に、各携帯端末４Ａ〜４Ｃには、最初にＡ社からサービス提供を受けた際に、図３に示した各プログラムｐ_ｃ１〜ｐ_ｃ４がインストールされたものとする。また、以下の説明では、記載を簡潔にする観点から、送受信に通信部２４、４４Ａ〜４４Ｃを介在させている旨の記載を省略する。

始めに、ウェブサーバ装置２では、各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受けると、当該各携帯端末４Ａ〜４Ｃとの接続を確立してハンドシェイク応答を返信し、各携帯端末４Ａ〜４Ｃにバトルを開始させる（時刻ｔ０；接続確立工程）。例えば、ウェブサーバ装置２では、ほぼ同時刻にハンドシェイク要求を受け付けた各携帯端末４Ａ〜４Ｃを１つのグループとしてレイドバトルゲームに参加させるものとする。

次に、例えば携帯端末４Ａでは、ユーザがタッチパネル４８Ａに対し、レイドボスのＨＰ（体力）を「−１０」させる攻撃に相当するタップ操作を行った場合、図５及び図６に示すように、プロセッサ４３Ａが、当該タップ操作を示すアクション情報actＡと、当該タップ操作された時点（ｔ１１）から所定の期間１（＝ｔ１１〜ｔ１９）を示す期間情報とを含むイベント情報ivＡを作成する（時刻ｔ１１）。なお、期間１の値“１”としては、例えば、タップ操作された時点ｔ１１から＋１ずつカウントアップしてｔ１９に至るまでの間の十の位を示す値“１”が使用可能となっている。これは他の期間の値も同様である。また、カウントアップの時間間隔は任意であるが、リアルタイムでゲーム上の処理を実行する観点から、短い方が好ましい。

また、携帯端末４Ａでは、プロセッサ４３Ａが、このイベント情報ivＡによるアタックをレイドボスに加え、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行すると共に、このイベント情報ivＡを含むリクエストをウェブサーバ装置２に送信する。なお、レイドボスのＨＰを−１０させる処理は、アタックによりレイドボスがダメージを受けることに相当する。このことは、以下の説明でも同様である。

ウェブサーバ装置２では、プロセッサ２３が、図５及び図７に示すように、このイベント情報ivＡをウェブソケットの通信規格に従って他の携帯端末４Ｂ、４Ｃに送信する（時刻ｔ１２；ウェブソケット通信工程）。このとき、プロセッサ２３は、プッシュ動作により、イベント情報ivＡを当該イベント情報ivＡに含まれる期間情報が示す期間内に他の携帯端末４Ｂ、４Ｃに送信する。

他の携帯端末４Ｂ、４Ｃでは、プロセッサ４３Ｂ、４３Ｃが、このイベント情報ivＡによるアタックをレイドボスに加え、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。

また同様に、例えば携帯端末４Ｂでは、ユーザがタッチパネル４８Ｂに対し、レイドボスのＨＰ（体力）を「−１０」させる攻撃に相当するタップ操作を行った場合、図５及び図８に示すように、プロセッサ４３Ｂが、当該タップ操作を示すアクション情報actＢと、当該タップ操作された時点（ｔ２１）から所定の期間２（＝ｔ２１〜ｔ２９）を示す期間情報とを含むイベント情報ivＢを作成する（時刻ｔ２１）。

また、携帯端末４Ｂでは、プロセッサ４３Ｂが、このイベント情報ivＢによるアタックをレイドボスに加え、このイベント情報ivＢに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行すると共に、このイベント情報ivＢを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、図５及び図９に示すように、このイベント情報ivＢをウェブソケットの通信規格に従って他の携帯端末４Ａ、４Ｃに送信する（時刻ｔ２２；ウェブソケット通信工程）。このとき、プロセッサ２３は、プッシュ動作により、イベント情報ivＢを当該イベント情報ivＢに含まれる期間情報が示す期間内に他の携帯端末４Ａ、４Ｃに送信する。

他の携帯端末４Ａ、４Ｃでは、プロセッサ４３Ａ、４３Ｃが、このイベント情報ivＢによるアタックをレイドボスに加え、このイベント情報ivＢに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。

更に同様に、他の携帯端末４Ｃでは、ユーザがタッチパネル４８Ｃに対し、レイドボスのＨＰ（体力）を「−１０」させる攻撃に相当するタップ操作を行った場合、図５及び図１０に示すように、プロセッサ４３Ｃが、当該タップ操作を示すアクション情報actＣと、当該タップ操作された時点（ｔ３１）から所定の期間３（＝ｔ３１〜ｔ３９）を示す期間情報とを含むイベント情報ivＣを作成する（時刻ｔ３１）。

また、携帯端末４Ｃでは、プロセッサ４３Ｃが、このイベント情報ivＣによるアタックをレイドボスに加え、このイベント情報ivＣに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行すると共に、このイベント情報ivＣを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＣをウェブソケットの通信規格に従って他の携帯端末４Ａ、４Ｂに送信する（時刻ｔ３２；ウェブソケット通信工程）。このとき、プロセッサ２３は、プッシュ動作により、イベント情報ivＣを当該イベント情報ivＣに含まれる期間情報が示す期間内に他の携帯端末４Ａ、４Ｂに送信する。

他の携帯端末４Ａ、４Ｂでは、プロセッサ４３Ａ、４３Ｃが、このイベント情報ivＢによるアタックをレイドボスに加え、このイベント情報ivＣに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。

続いて、以上のようなイベント情報ivＡ、ivＢ、ivＣ、…に基づいてゲーム状況が進行し、例えばレイドボスのＨＰがゼロ値になったとする。

このとき、ウェブサーバ装置２では、プロセッサ２３が、イベント情報ivＡ、ivＢ、ivＣ、…に基づいてバトルを終了させる。なお、バトルの終了は、レイドボスのＨＰがゼロになった場合に限らず、例えば制限時間内にレイドボスのＨＰがゼロにならなかった場合でもよい。

いずれにしても、ウェブサーバ装置２では、プロセッサ２３が、バトルを終了させると、各携帯端末４Ａ〜４Ｃとの接続を切断する（時刻ｔｎ；接続切断工程）。

これにより、１回のレイドバトルゲームが完了する。すなわち、１回の接続確立工程と、複数回のウェブソケット通信工程と、１回の接続切断工程とにより、１回のレイドバトルゲームが完了する。

上述したように本実施形態によれば、ウェブサーバ装置２が、いずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報をウェブソケットの通信規格に従って他の携帯端末に送信する構成により、ウェブソケットの通信規格に従い、処理負荷が小さいリアルタイム通信を実現できるので、クライアント装置としての携帯端末の数を制限せずに、複数のクライアント装置としての複数の携帯端末４Ａ〜４Ｃをウェブサーバ装置２に接続でき、バトルゲームを実現することができる。

また、本実施形態によれば、リクエスト＆レスポンス形式で通信を行わず、ＨＴＭＬ５に関連したウェブソケットの通信規格を使用したバトルゲームを実現することができる。

＜第２の実施の形態＞
レイドバトルゲームでは、レイドボスが強いという設定のため、各クライアント装置ＣＬ１〜ＣＬ３の操作によって、レイドボスに大きなダメージを与えることが困難となっている。とはいえ、レイドボスが強すぎてユーザがほぼ負けるゲームは、ユーザの支持を得られない。本発明者の検討によれば、格闘ゲームの分野におけるコンボアタック（combo attack：組合せ攻撃、連続攻撃）をレイドバトルゲームに適用すると、レイドボスの強さと各ユーザの強さとが均衡し、ユーザの支持を得やすいと考えられる。なお、コンボアタックは、複数のアタックの攻撃力の合計よりも大きい攻撃力を有している。このようなコンボアタックを用いる場合、例えば、各ユーザが各クライアント装置ＣＬ１〜ＣＬ３のタッチパネルを連続的にタップする等の連携攻撃を表す操作を実行し、各ユーザの操作に応じた大量のリクエストをサーバ装置Ｓｖに送信すればよい。

しかしながら、各クライアント装置ＣＬ１〜ＣＬ３から大量のリクエストがサーバ装置Ｓｖに送信されると、サーバ装置Ｓｖに著しく処理負荷がかかる。このため、リクエスト＆レスポンス方式では、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数を制限し、他のクライアント装置ＣＬ３を強制的にロックする通信方式を用いている。

すなわち、リクエスト＆レスポンス方式では、サーバ装置Ｓｖに著しく処理負荷がかかるために、コンボアタックを用いたレイドバトルゲームの実現が困難となっている。

以上説明したように、リクエスト＆レスポンス方式では、コンボアタックを用いたレイドバトルゲームの実現が困難であるという不都合がある。また、リクエスト＆レスポンス方式では、ロックされたクライアント装置ＣＬ３は、サーバ装置Ｓｖからロックが解除された後でなければ、正常な処理を実行できないという不都合もある。

さらに、リクエスト＆レスポンス方式では、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間でマークアップ言語を送受信する場合、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間で複数ページに渡るヘッダ情報を送受信する必要がある。これにより、通信毎にヘッダ情報がサーバ装置Ｓｖに蓄積されるため、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数が制限されている。

本発明の第２の実施形態では、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、コンボアタックを用いたバトルゲームを実現し得るゲーム制御方法を提供する。

本発明の第２の実施の形態においては、ゲーム制御プログラムｐ_ｓ３は、レイドバトルゲームの様々な方式に基づくゲーム機能の他に、以下の機能（ｆ１）〜（ｆ７）をプロセッサ２３に実現させるためのプログラムを含んでいる。

（ｆ１） 互いに異なる各携帯端末４Ａ〜４Ｃの操作に応じた複数のイベント情報をコンボアタックとして受け付けるコンボ受付期間を含むコンボデータをメモリに設定するコンボデータ設定機能。

（ｆ２） 各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受けると、当該各携帯端末４Ａ〜４Ｃとの接続を確立してハンドシェイク応答を返信し、各携帯端末４Ａ〜４Ｃにバトルを開始させる接続確立機能。

（ｆ３） 各携帯端末４Ａ〜４Ｃのうちのいずれかの携帯端末（例、４Ａ）からユーザの操作に応じたイベント情報を受けると、このイベント情報を受け付けたイベント情報受付時間とこのイベント情報の送信元を表す端末識別情報とを含むログ情報をメモリに書込むログ書込機能。

（ｆ４） 当該いずれかの携帯端末（例、４Ａ）から受けたイベント情報をウェブソケットの通信規格に従って当該いずれかの携帯端末（例、４Ａ）以外の他の携帯端末（例、４Ｂ，４Ｃ）に送信するウェブソケット通信機能。

ここで、当該イベント情報は、ユーザの操作を示すアクション情報と、当該操作された時点から所定の期間を示す期間情報とを含んでもよい。また、当該ウェブソケット通信機能（ｆ４）においては、プロセッサ２３が、イベント情報を当該イベント情報に含まれる期間情報が示す期間内に他の携帯端末（例、４Ｂ，４Ｃ）に送信するものとしてもよい。

（ｆ５） ログ情報に含まれる複数の端末識別情報が互いに異なるか否かを判定すると共に、当該ログ情報に含まれる複数のイベント情報受付時間がコンボ受付期間内にあるか否かを判定するコンボ判定機能。

（ｆ６） 当該判定の結果、当該複数の端末識別情報が互いに異なり且つ当該複数のイベント情報受付時間が当該コンボ受付期間内にある場合、コンボアタックをレイドボスに加えるコンボアタック機能。

（ｆ７） イベント情報、コンボアタック又は制限時間に基づいてバトルを終了させると、各携帯端末４Ａ〜４Ｃとの接続を切断する接続切断機能。

次に、以上のように構成されたゲームシステムの動作について説明する。

コンボアタックを用いない場合の動作は、図５において説明した動作と同じであるので、コンボアタックを用いる場合の動作について説明する。

（コンボアタックを用いる場合；図１１）
コンボアタックを用いる場合、ウェブサーバ装置２は、図５に示した動作に並行して、図１１に示すように、各ステップＳＴ１〜ＳＴ８等を実行する。

始めに、ウェブサーバ装置２では、プロセッサ２３が、互いに異なる各携帯端末４Ａ〜４Ｃの操作に応じた複数のイベント情報をコンボアタックとして受け付けるコンボ受付期間を含むコンボデータをメモリ２２に設定する（ＳＴ１；コンボデータ設定工程）。この設定により、コンボアタックを用いたレイドバトルゲームが実行可能となる。なお、この設定は、例えば、ゲームステージの難易度などに応じてコンボデータが更新設定されるようにしてもよく、常に同じコンボデータが設定されるようにしてもよい。難易度に応じて更新設定される場合、例えば難易度が高いほど、コンボ受付時間を短く設定すればよい。また、コンボデータは、コンボアタックを構成するイベント情報の個数を更に含んでもよい。

続いて、ウェブサーバ装置２では、プロセッサ２３が、前述同様に、接続確立工程を実行する（時刻ｔ０）。これにより、レイドバトルゲームが開始される。

次に、例えば携帯端末４Ａでは、ユーザによるタッチパネル４８Ａのタップ操作に応じて、前述同様に、プロセッサ４３Ａが、イベント情報ivＡを作成し（時刻ｔ１１）、このイベント情報ivＡに応じたゲーム上の処理を実行すると共に、このイベント情報ivＡを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このリクエストの情報をメモリ２２に書込む（ＳＴ２）。具体的には、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ａからユーザの操作に応じたイベント情報ivＡを受けると、図１２に示す如き、このイベント情報ivＡを受け付けたイベント情報受付時間“ｔｒ１”とこのイベント情報ivＡの送信元を表す端末識別情報“４Ａ”とを含むログ情報Ｌをメモリ２２に書込む（ＳＴ２；ログ書込工程）。

また、ウェブサーバ装置２では、プロセッサ２３が、当該携帯端末４Ａから受けたイベント情報ivＡをウェブソケットの通信規格に従って他の携帯端末４Ｂ、４Ｃに送信する（時刻ｔ１２；ウェブソケット通信工程）。ステップＳＴ２と時刻ｔ１２とは、どちらが先でもよい。

また同様に、例えば携帯端末４Ｂでは、ユーザによるタッチパネル４８Ｂのタップ操作に応じて、前述同様に、プロセッサ４３Ｂが、イベント情報ivＢを作成し（時刻ｔ２１）、このイベント情報ivＢに応じたゲーム上の処理を実行すると共に、このイベント情報ivＢを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このリクエストの情報をメモリ２２に書込む（ＳＴ３）。具体的には、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ｂからユーザの操作に応じたイベント情報ivＢを受けると、図１２に示した如き、このイベント情報ivＢを受け付けたイベント情報受付時間“ｔｒ２”とこのイベント情報ivＢの送信元を表す端末識別情報“４Ｂ”とを含むログ情報Ｌをメモリ２２に書込む（ＳＴ３；ログ書込工程）。

また、ウェブサーバ装置２では、プロセッサ２３が、当該携帯端末４Ｂから受けたイベント情報ivＢをウェブソケットの通信規格に従って他の携帯端末４Ａ、４Ｃに送信する（時刻ｔ２２；ウェブソケット通信工程）。ステップＳＴ３と時刻ｔ２２とは、どちらが先でもよい。

このとき、ウェブサーバ装置２では、プロセッサ２３が、メモリ２２内のログ情報Ｌ及びコンボデータに基づいて、コンボアタックが成立するか否かを判定する（ＳＴ４）。具体的には、プロセッサ２３は、メモリ２２内のログ情報Ｌに含まれる複数の端末識別情報 “４Ａ”、“４Ｂ”が互いに異なるか否かを判定すると共に、当該ログ情報Ｌに含まれる複数のイベント情報受付時間“ｔｒ１”、“ｔｒ２”がコンボ受付期間内にあるか否かを判定する（ＳＴ４；コンボ判定工程）。例えば、イベント情報受付時間の差分の期間Δｔｒ（＝ｔｒ２−ｔｒ１）がコンボ受付期間内にあるか否かを判定すればよい。

ウェブサーバ装置２では、プロセッサ２３が、当該判定の結果、当該複数の端末識別情報が互いに異なり且つ当該複数のイベント情報受付時間が当該コンボ受付期間内にある場合、コンボアタックをレイドボスに加える（ＳＴ５；コンボアタック工程）。また、ステップＳＴ４の判定の結果、否の場合、ステップＳＴ５は省略される。

更に同様に、例えば携帯端末４Ｃでは、ユーザによるタッチパネル４８Ｃのタップ操作に応じて、前述同様に、プロセッサ４３Ｃが、イベント情報ivＣを作成し（時刻ｔ３１）、このイベント情報ivＣに応じたゲーム上の処理を実行すると共に、このイベント情報ivＣを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このリクエストの情報をメモリ２２に書込む（ＳＴ６）。具体的には、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ｃからユーザの操作に応じたイベント情報ivＣを受けると、図１２に示した如き、このイベント情報ivＣを受け付けたイベント情報受付時間“ｔｒ３”とこのイベント情報ivＣの送信元を表す端末識別情報“４Ｃ”とを含むログ情報Ｌをメモリ２２に書込む（ＳＴ６；ログ書込工程）。

また、ウェブサーバ装置２では、プロセッサ２３が、当該携帯端末４Ｃから受けたイベント情報ivＣをウェブソケットの通信規格に従って他の携帯端末４Ａ、４Ｂに送信する（時刻ｔ３２；ウェブソケット通信工程）。ステップＳＴ６と時刻ｔ３２とは、どちらが先でもよい。

このとき、ウェブサーバ装置２では、プロセッサ２３が、メモリ２２内のログ情報Ｌ及びコンボデータに基づいて、コンボアタックが成立するか否かを判定する（ＳＴ７）。具体的には、プロセッサ２３は、メモリ２２内のログ情報Ｌに含まれる複数の端末識別情報“４Ａ”、“４Ｂ”、“４Ｃ”が互いに異なるか否かを判定すると共に、当該ログ情報Ｌに含まれる複数のイベント情報受付時間“ｔｒ１”、“ｔｒ２”、“ｔｒ３”がコンボ受付期間内にあるか否かを判定する（ＳＴ７；コンボ判定工程）。例えば、イベント情報受付時間の差分の期間Δｔｒ（＝ｔｒ３−ｔｒ１）がコンボ受付期間内にあるか否かを判定すればよい。

ウェブサーバ装置２では、プロセッサ２３が、当該判定の結果、当該複数の端末識別情報が互いに異なり且つ当該複数のイベント情報受付時間が当該コンボ受付期間内にある場合、コンボアタックをレイドボスに加える（ＳＴ８；コンボアタック工程）。また、ステップＳＴ７の判定の結果、否の場合、ステップＳＴ８は省略される。

続いて、以上のようなコンボアタックに基づいてゲーム状況が進行し、例えばレイドボスのＨＰがゼロ値になったとする。

このとき、ウェブサーバ装置２では、プロセッサ２３が、コンボアタックに基づいてバトルを終了させる。なお、バトルの終了は、コンボアタックに基づいてレイドボスのＨＰがゼロになった場合に限らず、例えば、イベント情報に基づいてレイドボスのＨＰがゼロになった場合や、制限時間内にレイドボスのＨＰがゼロにならなかった場合でもよい。

いずれにしても、ウェブサーバ装置２では、プロセッサ２３が、バトルを終了させると、各携帯端末４Ａ〜４Ｃとの接続を切断する（時刻ｔｎ；接続切断工程）
これにより、コンボアタックを用いる場合の１回のレイドバトルゲームが完了する。すなわち、１回のコンボデータ設定工程と、１回の接続確立工程と、複数回のログ書込工程と、複数回のウェブソケット通信工程と、複数回のコンボ判定工程と、複数回のコンボアタック工程と、１回の接続切断工程とにより、１回のレイドバトルゲームが完了する。

上述したように本実施形態によれば、ウェブサーバ装置２が、いずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報をウェブソケットの通信規格に従って他の携帯端末に送信する構成により、ウェブソケットの通信規格に従い、処理負荷が小さいリアルタイム通信を実現できるので、クライアント装置としての携帯端末の数を制限せずに、複数のクライアント装置としての複数の携帯端末４Ａ〜４Ｃをウェブサーバ装置２に接続でき、バトルゲームを実現することができる。

また、ウェブサーバ装置２が、いずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、このイベント情報を受け付けたイベント情報受付時間とこのイベント情報の送信元を表す端末識別情報とを含むログ情報をメモリに書込み、ログ情報に含まれる複数の端末識別情報が互いに異なり且つ当該ログ情報に含まれる複数のイベント情報受付時間がコンボ受付期間内にある場合、コンボアタックを敵に加える構成により、コンボアタックを用いたバトルゲームを実現することができる。

また、本実施形態によれば、リクエスト＆レスポンス形式で通信を行わず、ＨＴＭＬ５に関連したウェブソケットの通信規格を使用したバトルゲームを実現することができる。

＜第３の実施の形態＞
レイドバトルゲームでは、レイドボスが強いという設定のため、レイドボスにほぼ勝てる熟練ユーザと、レイドボスにほぼ負ける初心者ユーザとの差が大きくなり易い。本発明者の検討によれば、熟練ユーザは得意な戦い方（得意な操作）が多いのに対し、初心者ユーザは得意な戦い方が少ない傾向がある。また、初心者ユーザは、それぞれ得意な戦い方（得意な操作）が大きく異なる傾向がある。簡単にいうと、あるユーザはタップ操作が得意であり、他のユーザはフリック操作が得意であり、更に他のユーザはスライド操作が得意である、といった傾向がある。本発明者の検討によれば、各ユーザがそれぞれ得意な戦い方があるからこそ、互いに仲間が必要で、仲間と協力する戦い方になるのに対し、現在のレイドバトルゲームでは、各ユーザの得意な戦い方が考慮されていない。

なお、レイドボスに大きなダメージを与えるような操作が得意なユーザは、初心者ユーザであっても、レイドボスに勝てる場合が多い。すなわち、レイドボスとユーザとは相性があり、相性の良いユーザはレイドボスに勝ち易いが、相性の悪いユーザはレイドボスに負け易い状況にある。このため、従来のレイドバトルゲームは、レイドボスとの相性の悪いユーザに対し、プレイするモチベーション（意欲）を低下させてしまう。

まとめると、従来のレイドバトルゲームは、サーバ装置Ｓｖに著しく処理負荷がかかる場合にロックがかかる不都合と、レイドボスとの相性によってはプレイするモチベーションを低下させる不都合とがある。

以上説明したように、レイドバトルゲームでは、レイドボスとの相性によってはモチベーションを低下させてしまうという不都合がある。また、リクエスト＆レスポンス方式によりロックされたクライアント装置ＣＬ３は、サーバ装置Ｓｖからロックが解除された後でなければ、正常な処理を実行できないという不都合もある。

さらに、リクエスト＆レスポンス方式では、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間でマークアップ言語を送受信する場合、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間で複数ページに渡るヘッダ情報を送受信する必要がある。これにより、通信毎にヘッダ情報がサーバ装置Ｓｖに蓄積されるため、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数が制限されている。

本発明の第３の実施形態では、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、且つ敵との相性によるモチベーションの低下を阻止したバトルゲームを実現し得るゲーム制御方法を提供する。

レイドボスは、全てのユーザに対して強い訳ではなく、バトルを行うときの優劣関係が巡回的に定められた複数の属性（例、グー、チョキ、パー）のうち、レイドボスの属性（例、グー）よりも優等の属性（例、パー）を持つユーザとのバトルには弱くなるように設定される。

本発明の第３の実施の形態において、ゲーム制御プログラムｐ_ｓ３は、レイドバトルゲームの様々な方式に基づくゲーム機能の他に、以下の機能（ｆ１）〜（ｆ５）をプロセッサ２３に実現させるためのプログラムを含んでいる。

（ｆ１） 各レイドボスを識別するレイドボス識別情報（敵識別情報）と、バトルを行うときの優劣関係が巡回的に定められた複数の属性のうちのいずれかの属性を示す属性情報とを含むレイドボス属性データ（敵属性データ）をメモリ２２に設定するレイドボス属性設定機能（敵属性設定機能）。なお、レイドボス属性データは、各レイドボスの集合を識別するグループ属性情報を更に含んでもよい。

（ｆ２） 各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受けると、当該各携帯端末４Ａ〜４Ｃとの接続を確立してハンドシェイク応答を返信し、各携帯端末４Ａ〜４Ｃにバトルを開始させる接続確立機能。

（ｆ３） 各携帯端末４Ａ〜４Ｃのうちのいずれかの携帯端末（例、４Ａ）からユーザの操作に応じたイベント情報を受けると、このイベント情報の送信元を表す端末識別情報と、レイドボス属性データ内のいずれかの属性情報とを含む端末属性データをメモリ２２に設定すると共に、このイベント情報をウェブソケットの通信規格に従って当該いずれかの携帯端末（例、４Ａ）以外の他の携帯端末（例、４Ｂ、４Ｃ）に送信する端末属性設定機能。

（ｆ４） 端末属性データが設定された各携帯端末のうちのいずれかの携帯端末（例、４Ａ）からユーザの操作に応じたイベント情報を受けると、当該イベント情報をウェブソケットの通信規格に従って当該いずれかの携帯端末（例、４Ａ）以外の他の携帯端末（例、４Ｂ，４Ｃ）に送信するウェブソケット通信機能。

ここで、当該イベント情報は、ユーザの操作を示すアクション情報と、当該操作された時点から所定の期間を示す期間情報とを含んでもよい。また、当該ウェブソケット通信機能（ｆ４）においては、プロセッサ２３が、イベント情報を当該イベント情報に含まれる期間情報が示す期間内に他の携帯端末（例、４Ｂ，４Ｃ）に送信するものとしてもよい。

（ｆ５） イベント情報又は制限時間に基づいてバトルを終了させると、各携帯端末４Ａ〜４Ｃとの接続を切断する接続切断機能。

次に、以上のように構成されたゲームシステムの動作について説明する。

コンボアタックを用いない場合の動作は、図５において説明した動作と同じであるので、属性を用いる場合の動作について説明する。

（属性を用いる場合；図１３）
属性を用いる場合、ウェブサーバ装置２は、図５に示した動作に並行して、図１３に示すように、各ステップＳＴ１１〜ＳＴ１４等を実行する。

始めに、ウェブサーバ装置２では、プロセッサ２３が、図１４に示す如き、各レイドボスを識別するレイドボス識別情報“ＲＢ１”、“ＲＢ２”、“ＲＢ３”、…と、バトルを行うときの優劣関係が巡回的に定められた複数の属性のうちのいずれかの属性を示す属性情報“水”、“火”、“風”、…とを含むレイドボス属性データＲＡをメモリ２２に設定する（ＳＴ１１；レイドボス属性設定工程）。なお、ここでは、グループ識別情報“Ｇ１”が更に設定されているが、グループ属性情報は省略してもよい。但し、例えば、ゲームステージの難易度などに応じてレイドボス属性データＲＡが更新設定される場合には、例えば難易度に応じてグループ識別情報、レイドボス識別情報及び属性を設定することが好ましい。また、「バトルを行うときの優劣関係が巡回的に定められた複数の属性」としては、例えば図１５に示す如き、複数の属性“水”、“火”、“風”、“土”、“雷”が使用可能となっている。各属性は、図１６に一例を示すように、各レイドボスのＨＰ（ヒットポイント）が定められていてもよい。

続いて、ウェブサーバ装置２では、プロセッサ２３が、前述同様に、接続確立工程を実行する（時刻ｔ０）。これにより、レイドバトルゲームが開始される。

次に、例えば携帯端末４Ａでは、ユーザによるタッチパネル４８Ａのタップ操作に応じて、前述同様に、プロセッサ４３Ａが、イベント情報ivＡを作成し（時刻ｔ１１）、このイベント情報ivＡに応じたゲーム上の処理を実行すると共に、このイベント情報ivＡを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このリクエストの情報をメモリ２２に書込む（ＳＴ１２）。具体的には、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ａからユーザの操作に応じたイベント情報ivＡを受けると、図１７に示す如き、このイベント情報ivＡの送信元を表す端末識別情報“４Ａ”と、レイドボス属性データＲＡ内のいずれかの属性情報“雷”とを含む端末属性データＴＡをメモリ２２に設定する（ＳＴ１２）と共に、このイベント情報ivＡをウェブソケットの通信規格に従って他の携帯端末４Ｂ、４Ｃに送信する（時刻ｔ１２；端末属性設定工程）。ステップＳＴ１２と時刻ｔ１２とは、どちらが先でもよい。

また同様に、例えば携帯端末４Ｂでは、ユーザによるタッチパネル４８Ｂのタップ操作に応じて、前述同様に、プロセッサ４３Ｂが、イベント情報ivＢを作成し（時刻ｔ２１）、このイベント情報ivＢに応じたゲーム上の処理を実行すると共に、このイベント情報ivＢを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このリクエストの情報をメモリ２２に書込む（ＳＴ１３）。具体的には、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ｂからユーザの操作に応じたイベント情報ivＢを受けると、図１７に示した如き、このイベント情報ivＢの送信元を表す端末識別情報“４Ｂ”と、レイドボス属性データＲＡ内のいずれかの属性情報“水”とを含む端末属性データＴＡをメモリ２２に設定する（ＳＴ１３）と共に、このイベント情報ivＢをウェブソケットの通信規格に従って他の携帯端末４Ａ、４Ｃに送信する（時刻ｔ２２；端末属性設定工程）。ステップＳＴ１３と時刻ｔ２２とは、どちらが先でもよい。

更に同様に、例えば携帯端末４Ｃでは、ユーザによるタッチパネル４８Ｃのタップ操作に応じて、前述同様に、プロセッサ４３Ｃが、イベント情報ivＣを作成し（時刻ｔ３１）、このイベント情報ivＣに応じたゲーム上の処理を実行すると共に、このイベント情報ivＣを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このリクエストの情報をメモリ２２に書込む（ＳＴ１４）。具体的には、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ｃからユーザの操作に応じたイベント情報ivＣを受けると、図１７に示した如き、このイベント情報ivＣの送信元を表す端末識別情報“４Ｃ”と、レイドボス属性データＲＡ内のいずれかの属性情報“火”とを含む端末属性データＴＡをメモリ２２に設定する（ＳＴ１４）と共に、このイベント情報ivＣをウェブソケットの通信規格に従って他の携帯端末４Ａ、４Ｂに送信する（時刻ｔ３２；端末属性設定工程）。ステップＳＴ１４と時刻ｔ３２とは、どちらが先でもよい。

このようにして、全ての携帯端末４Ａ、４Ｂ、４Ｃ、…の端末属性データＴＡが設定されると、属性に応じたレイドボスとのバトルが可能となる。

この例では、属性情報“水”をもつレイドボス“ＲＢ１”に対し、属性情報“雷”をもつ携帯端末４Ａのユーザが優勢にバトルを行うことができる。

また、属性情報“火”をもつレイドボス“ＲＢ２”に対し、属性情報“水”をもつ携帯端末４Ｂのユーザが優勢にバトルを行うことができる。

同様に、属性情報“風”をもつレイドボス“ＲＢ３”に対し、属性情報“火”をもつ携帯端末４Ｃのユーザが優勢にバトルを行うことができる。

よって、各ユーザは、複数のレイドボスのうち、ユーザの携帯端末の属性情報よりも劣勢な属性情報をもつレイドボスとバトルすればよい。このように、各ユーザがそれぞれ得意な戦い方があるからこそ、互いに仲間が必要で、仲間と協力する戦い方になる。本実施形態のレイドバトルゲームでは、バトルを行うときの優劣関係を巡回的に定めることにより、各ユーザの得意な戦い方が考慮されている。また、各ユーザは、あるレイドボスとの相性が悪いとしても、他のいずれかのレイドボスとの相性が良いので、モチベーションの低下が阻止されている。

以下、ウェブサーバ装置２では、プロセッサ２３が、端末属性データＴＡが設定された各携帯端末４Ａ〜４Ｃのうちのいずれかの携帯端末４Ａ、４Ｂ又は４Ｃからユーザの操作に応じたイベント情報ivＡ、ivＢ又はivＣを受けると、当該イベント情報をウェブソケットの通信規格に従って当該いずれかの携帯端末以外の他の携帯端末“４Ｂ、４Ｃ”、“４Ａ、４Ｃ”又は“４Ａ、４Ｂ”に送信する（ウェブソケット通信工程）。

また、各ユーザによる各携帯端末４Ａ〜４Ｃの操作に応じてウェブソケット通信工程が繰り返し実行され、イベント情報ivＡ、ivＢ、ivＣ、…が各携帯端末４Ａ〜４Ｃに共有される。

続いて、以上のようなイベント情報ivＡ、ivＢ、ivＣ、…に基づいてゲーム状況が進行し、例えば各レイドボスのＨＰがゼロ値になったとする。

このとき、ウェブサーバ装置２では、プロセッサ２３が、イベント情報ivＡ、ivＢ、ivＣ、…に基づいてバトルを終了させる。なお、バトルの終了は、イベント情報ivＡ、ivＢ、ivＣ、…に基づいて各レイドボスのＨＰがゼロになった場合に限らず、例えば、制限時間内に各レイドボスのＨＰがゼロにならなかった場合でもよい。

いずれにしても、ウェブサーバ装置２では、プロセッサ２３が、バトルを終了させると、各携帯端末４Ａ〜４Ｃとの接続を切断する（時刻ｔｎ；接続切断工程）
これにより、属性を用いる場合の１回のレイドバトルゲームが完了する。すなわち、１回のレイドボス属性データ設定工程と、１回の接続確立工程と、複数回の端末属性設定工程と、複数回のウェブソケット通信工程と、１回の接続切断工程とにより、１回のレイドバトルゲームが完了する。

上述したように本実施形態によれば、ウェブサーバ装置２が、いずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報をウェブソケットの通信規格に従って他の携帯端末に送信する構成により、ウェブソケットの通信規格に従い、処理負荷が小さいリアルタイム通信を実現できるので、クライアント装置としての携帯端末の数を制限せずに、複数のクライアント装置としての複数の携帯端末４Ａ〜４Ｃをウェブサーバ装置２に接続でき、バトルゲームを実現することができる。

また、ウェブサーバ装置２が、バトルを行うときの優劣関係が巡回的に定められた属性を各レイドボス識別情報及び各端末識別情報に設定する構成により、各ユーザは、携帯端末の属性情報よりも劣勢な属性情報をもつレイドボスとバトルすれば勝ち易くなっている。これにより、敵（レイドボス）との相性によるモチベーションの低下を阻止したバトルゲームを実現することができる。

また、本実施形態によれば、リクエスト＆レスポンス形式で通信を行わず、ＨＴＭＬ５に関連したウェブソケットの通信規格を使用したバトルゲームを実現することができる。

＜第４の実施の形態＞
レイドバトルゲームでは、レイドボスが強いという設定のため、各クライアント装置ＣＬ１〜ＣＬ３の操作によって、レイドボスに大きなダメージを与えることが困難となっている。とはいえ、レイドボスが強すぎてユーザがほぼ負けるゲームは、ユーザの支持を得られない。一般にレイドバトルゲームは、バトルに参加するユーザが多いほど、レイドボスを倒しやすい傾向がある。そのため、例えば、レイドバトルゲームに多数のユーザを参加させ、これら多数のユーザが多数のクライアント装置ＣＬ１〜ＣＬ３、…のタッチパネルを連続的にタップする等の連携攻撃を表す操作を実行し、多数のユーザの操作に応じた大量のリクエストをサーバ装置Ｓｖに送信すればよい。

しかしながら、多数のクライアント装置ＣＬ１〜ＣＬ３、…から大量のリクエストがサーバ装置Ｓｖに送信されると、サーバ装置Ｓｖに著しく処理負荷がかかる。このため、リクエスト＆レスポンス方式では、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数を制限し、他のクライアント装置ＣＬ３、…を強制的にロックする通信方式を用いている。

すなわち、リクエスト＆レスポンス方式では、サーバ装置Ｓｖに著しく処理負荷がかかるために、多数のユーザがバトルに参加可能なレイドバトルゲームの実現が困難となっている。

以上説明したように、リクエスト＆レスポンス方式では、多数のユーザがバトルに参加可能なレイドバトルゲームの実現が困難であるという不都合がある。また、リクエスト＆レスポンス方式では、ロックされたクライアント装置ＣＬ３は、サーバ装置Ｓｖからロックが解除された後でなければ、正常な処理を実行できないという不都合もある。

さらに、リクエスト＆レスポンス方式では、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間でマークアップ言語を送受信する場合、サーバ装置Ｓｖとクライアント装置ＣＬ１〜ＣＬ３間で複数ページに渡るヘッダ情報を送受信する必要がある。これにより、通信毎にヘッダ情報がサーバ装置Ｓｖに蓄積されるため、サーバ装置Ｓｖと接続できるクライアント装置ＣＬ１〜ＣＬ２の数が制限されている。

また、以上のようなリクエスト＆レスポンス方式を用いる場合、本発明者の検討によれば、バトルに参加するユーザに限らず、バトルに参加するユーザを応援したいユーザにとっても、同様の理由により、多数のユーザが応援に参加可能なレイドバトルゲームの実現が困難となっている。

本発明の第４の実施形態では、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、多数のユーザがバトル及び応援に参加可能なバトルゲームを実現し得るゲーム制御方法を提供する。

図１８は本発明の第４の実施の形態に係るゲーム制御方法が適用されたゲームシステムの構成例を示す模式図である。インターネットなどを含むネットワーク１に対し、ウェブサーバ装置２が接続されると共に、本システムでユーザが使用するクライアント装置となる、複数、例えば８台の携帯端末４Ａ〜４Ｈが、無線ＬＡＮのアクセスポイント（ＡＰ）５、あるいは基地局６を介して接続される。図１９に一例を示すように、各携帯端末４Ａ〜４Ｈのうち、３台の携帯端末４Ａ〜４Ｃは、バトルを行う第１の携帯端末として用いられ、５台の携帯端末４Ｄ〜４Ｈは、応援を行う第２の携帯端末として用いられる。

なお、応援を行う第２の携帯端末４Ｄ〜４Ｈとしては、例えば、バトルを行うために必要な体力値（ＨＰ）が無いか又は体力値に余裕が少ない状況の携帯端末を想定している。補足すると、各携帯端末４Ａ〜４Ｈにおけるバトル参加又は応援参加といった用途は、固定的な用途ではない。例えば、第２の携帯端末４Ｄ〜４Ｈについては、今回のバトルゲームでは応援に参加するが、敵に勝った場合などに体力値が回復し、次回のバトルゲームではバトルに参加するといった状況があり得る。逆に、第１の携帯端末４Ａ〜４Ｃについては、今回のバトルゲームではバトルに参加するが、敵に負けた場合などに体力値が減少し、次回のバトルゲームでは応援に参加するといった状況があり得る。

ウェブサーバ装置２及び携帯端末４Ａ〜４Ｈの構成については、上述の第１の実施の形態と同様なので、ここでは異なる点について説明する。

本発明の第４の実施の形態において、ゲーム制御プログラムｐ_ｓ３は、レイドバトルゲームの様々な方式に基づくゲーム機能の他に、以下の機能（ｆ１）〜（ｆ８）をプロセッサ２３に実現させるためのプログラムを含んでいる。

（ｆ１） 第２の各携帯端末４Ｄ〜４Ｈの台数に相当する応援人数の範囲と、当該応援人数の範囲に応じて第１の各携帯端末４Ａ〜４Ｃのユーザに与えることが可能なインセンティブデータとを関連付けて記述した応援データをメモリ２２に設定する応援データ設定機能。

なお、図２０に一例を示すように、応援データＳは、応援人数の範囲と、当該応援人数の範囲に応じたインセンティブデータと、第２の各携帯端末４Ｄ〜４Ｈによる応援の目標値と、当該目標値に応じた、前述のインセンティブデータとは異なる他のインセンティブデータとを関連付けて記述したデータとしてもよい（応援データＳは、応援の目標値と、他のインセンティブデータとを更に含んでもよい。）。応援の目標値としては、例えば、第２の各携帯端末４Ｄ〜４Ｈから送信されたイベント情報の単位時間当たりの個数を表すパラメータが適宜使用可能となっている。

インセンティブデータとしては、当該レイドバトルを含むＲＰＧ又は他のゲーム等で使用可能なデータであって、例えば、着せ替えアイテム、レアカード及びゲーム内通貨といった任意の種類のデータが適用可能となっている。

また、この例では、応援人数の範囲の大きさに応じて、インセンティブデータのランクが上昇し、応援の目標値が上昇し、他のインセンティブデータのランクが上昇するように、応援データＳが設定されている。ここで、応援人数の範囲の大きさに応じて、インセンティブデータのランクを上昇させた設定により、ユーザが多数の友人を応援に誘う動機づけを生じさせ、ソーシャル性の向上を図っている。なお、友人を誘う仕組みとしては、既存のプラットフォーム上にあるＥメール等が適宜使用可能となっている。また、応援人数の範囲の大きさに応じて、応援の目標値を上昇させた設定により、応援人数の増加によって応援が極端に容易になることを防ぎ、応援する意欲の維持を図っている。また、応援の目標値に応じて、他のインセンティブデータを設定したことにより、敵に勝った場合のインセンティブデータとは別に、応援によるインセンティブデータを与えることができるので、応援する意欲の向上を図ることができる。すなわち、応援データＳは、以上のような設定により、ソーシャル性の向上と、応援する意欲の維持・向上とを図っている。これに対し、従来は、バトルを応援する形態が無く、ユーザが所定の強さレベルのレイドボスとバトルを行い、勝った場合に所定のインセンティブを取得する方式であった。すなわち、従来のバトルゲームは、応援人数とは無関係の方式であった。

（ｆ２） バトルゲームへの参加募集期間中、第１の各携帯端末４Ａ〜４Ｃからバトルへの参加を求める第１ハンドシェイク要求を受けると、当該第１ハンドシェイク要求に基づき、当該第１の各携帯端末４Ａ〜４Ｃとの接続を確立して第１ハンドシェイク応答を返信し、当該第１の各携帯端末４Ａ〜４Ｃにバトルへの参加を許可する第１接続確立機能。

（ｆ３） 当該参加募集期間中及び当該バトルの実行期間中、第２の各携帯端末４Ｄ〜４Ｈからバトルの応援への参加を求める第２ハンドシェイク要求を受けると、当該第２ハンドシェイク要求に基づき、当該第２の各携帯端末４Ｄ〜４Ｈとの接続を確立して第２ハンドシェイク応答を返信し、当該第２の各携帯端末４Ｄ〜４Ｈに応援への参加を許可する第２接続確立機能。

（ｆ４） 応援への参加を許可した第２の各携帯端末４Ｄ〜４Ｈの台数を応援人数として計数する応援人数計数機能。

（ｆ５） 第１及び第２の各携帯端末４Ａ〜４Ｈのうちのいずれかの携帯端末（例、４Ａ）からユーザの操作に応じたイベント情報を受けると、このイベント情報をウェブソケットの通信規格に従っていずれかの携帯端末（例、４Ａ）以外の他の各携帯端末（４Ｂ〜４Ｈ）に送信するウェブソケット通信機能。

ここで、当該イベント情報は、ユーザの操作を示すアクション情報と、当該操作された時点から所定の期間を示す期間情報とを含んでもよい。また、当該ウェブソケット通信機能（ｆ５）においては、プロセッサ２３が、イベント情報を当該イベント情報に含まれる期間情報が示す期間内に他の携帯端末（例、４Ｂ〜４Ｈ）に送信するものとしてもよい。

また、ウェブソケット通信機能（ｆ５）は、以下の各機能（ｆ５−１）〜（ｆ５−４）を含んでもよい。

（ｆ５−１） 第１及び第２の各携帯端末４Ａ〜４Ｈのうち、第２の各携帯端末４Ｄ〜４Ｈのいずれかからユーザの操作に応じたイベント情報を受けると、図２１に一例を示すように、このイベント情報の受付時間と、このイベント情報の送信元を表す端末識別情報を含むログ情報Ｌをメモリ２２に書込むログ情報書込機能。

（ｆ５−２） 単位時間当たりの受付時間の個数を応援の計数値として計数する計数機能。

（ｆ５−３） 応援の計数値と応援の目標値とを比較し、応援の計数値が応援の目標値に到達すると、当該目標値に到達した時間を表す目標到達時間をメモリ２２に書込む到達時間書込機能。

（ｆ５−４） 第２の各携帯端末４Ｄ〜４Ｈのいずれかから受けたイベント情報を応援の計数値と共に、ウェブソケットの通信規格に従って当該イベント情報の送信元以外の他の携帯端末に送信するイベント情報送信機能。

（ｆ６） バトルの終了時に、当該計数された結果を応援人数として確定する応援人数確定機能。

（ｆ７） 敵が負けた場合に、当該確定した応援人数に関連付けられたインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信し、当該第１の各携帯端末４Ａ〜４Ｃとの接続を切断する第１接続切断機能。

ここで、第１接続切断機能（ｆ７）は、以下の各機能（ｆ７−１）〜（ｆ７−３）を含んでもよい。

（ｆ７−１） 敵が負けた場合に、当該確定した応援人数に関連付けられたインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信する第１データ送信機能。

（ｆ７−２） 敵が負けた場合で且つメモリ２２内に目標到達時間がある場合には、更に、応援データＳ内の他のインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信する第２データ送信機能。

（ｆ７−３）第１及び第２データ送信機能の処理完了後、第１の各携帯端末４Ａ〜４Ｃとの接続を切断する切断機能。

（ｆ８） バトルの終了後、体力値を回復させるデータを第２の各携帯端末４Ｄ〜４Ｈに送信し、当該第２の各携帯端末４Ｄ〜４Ｈとの接続を切断する第２接続切断機能。

また、ゲーム制御プログラムｐ_ｓ３は、以下の機能（ｆ９）をプロセッサ２３に実現させるためのプログラムを更に含んでいてもよい。

（ｆ９） バトルの実行期間中、当該バトルの制限時間から所定時間前になってもメモリ２２内に目標到達時間が無い場合に、応援を促すメッセージを第２の各携帯端末４Ｄ〜４Ｈに送信するメッセージ送信機能。

次に、以上のように構成されたゲームシステムの動作について説明する。応援を用いない場合の動作は、図５において説明した動作と同じであるので、応援を含む場合（第１及び第２の携帯端末４Ａ〜４Ｈを含む場合）の動作について説明する。

（応援を用いる場合；図２２）
応援を用いる場合、ウェブサーバ装置２は、図５に示した動作に並行して、図２２に示すように、各ステップＳＴ２２〜ＳＴ３０等を実行する。

始めに、ウェブサーバ装置２では、プロセッサ２３が、第２の各携帯端末４Ｄ〜４Ｈの台数に相当する応援人数の範囲と、当該応援人数の範囲に応じて第１の各携帯端末４Ａ〜４Ｃのユーザに与えることが可能なインセンティブデータとを関連付けて記述した応援データをメモリ２２に設定する（ＳＴ２１；応援データ設定工程）。この設定により、応援データを用いたレイドバトルゲームが実行可能となる。なお、この場合、応援データとしては、応援人数の範囲と、当該応援人数の範囲に応じたインセンティブデータとに加え、第２の各携帯端末４Ｄ〜４Ｈによる応援の目標値と、当該目標値に応じた、前述のインセンティブデータとは異なる他のインセンティブデータとを関連付けて記述したデータを設定してもよい。また、ステップＳＴ２１は、例えば、ゲームステージの難易度などに応じて応援データが更新設定されるようにしてもよく、常に同じ応援データが設定されるようにしてもよい。難易度に応じて更新設定される場合、例えば、同一の応援人数の範囲に対し、難易度が高いほど、高いランクのインセンティブデータを設定すればよい。

応援データの設定後、ウェブサーバ装置２では、プロセッサ２３が、バトルゲームへの参加募集期間の計時を開始する。

ウェブサーバ装置２では、プロセッサ２３が、参加募集期間中、第１の各携帯端末４Ａ〜４Ｃからバトルへの参加を求める第１ハンドシェイク要求を受けると、当該第１ハンドシェイク要求に基づき、当該第１の各携帯端末４Ａ〜４Ｃとの接続を確立して第１ハンドシェイク応答を返信し（時刻ｔ０）、第１の各携帯端末４Ａ〜４Ｃにバトルへの参加を許可する（ＳＴ２２；第１接続確立工程）。

ステップＳＴ２２と並行して、ウェブサーバ装置２では、プロセッサ２３が、参加募集期間中、第２の各携帯端末４Ｄ〜４Ｈからバトルの応援への参加を求める第２ハンドシェイク要求を受けると、当該第２ハンドシェイク要求に基づき、当該第２の各携帯端末４Ｄ〜４Ｈとの接続を確立して第２ハンドシェイク応答を返信し（時刻ｔ０’）、第２の各携帯端末４Ｄ〜４Ｈに応援への参加を許可する（ＳＴ２３；第２接続確立工程）。

なお、参加募集期間は第１及び第２の各携帯端末４Ａ〜４Ｈ間で同一（又は共通）であるが、時刻ｔ０の値は第１の各携帯端末４Ａ〜４Ｃにおける第１ハンドシェイク要求の送信時刻に応じて第１の各携帯端末４Ａ〜４Ｃ毎に異なる。同様に、時刻ｔ０’の値は第２の各携帯端末４Ｄ〜４Ｈにおける第２ハンドシェイク要求の送信時刻に応じて第２の各携帯端末４Ｄ〜４Ｈ毎に異なる。

ウェブサーバ装置３では、プロセッサ２３が、参加募集期間の終了後、所定の制限時間等に基づいてバトルゲームの実行を開始する（ＳＴ２４）。なお、前述したステップＳＴ２３と同様の第２接続確立工程は、バトルの実行期間中も継続して実行される（ＳＴ２５；第２接続確立工程）。また、ウェブサーバ装置３では、プロセッサ２３が、応援への参加を許可した第２の各携帯端末４Ｄ〜４Ｈの台数を応援人数として計数する（ＳＴ２６；応援人数計数工程）。

次に、ウェブサーバ装置３では、プロセッサ２３が、第１及び第２の各携帯端末４Ａ〜４Ｈのうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、このイベント情報をウェブソケットの通信規格に従っていずれかの携帯端末以外の他の各携帯端末に送信する（ＳＴ２７；ウェブソケット通信工程）。

例えば第１の携帯端末４Ａでは、ユーザによるタッチパネル４８Ａのタップ操作に応じて、前述同様に、プロセッサ４３Ａが、イベント情報ivＡを作成し、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを減少させる処理）を実行すると共に、このイベント情報ivＡを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを減少させる処理）を実行し、当該イベント情報ivＡをウェブソケットの通信規格に従って他の携帯端末４Ｂ〜４Ｈに送信する。

他の携帯端末４Ｂ〜４Ｈでは、プロセッサ４３Ｂ〜４３Ｈが、このイベント情報ivＡに応じたゲーム上の処理（レイドボスのＨＰを−１０させる処理）を実行する。

また同様に、例えば第２の携帯端末４Ｄでは、ユーザによるタッチパネル４８Ｄのタップ操作に応じて、プロセッサ４３Ｄが、イベント情報ivＤを作成し、このイベント情報ivＤに応じたゲーム上の処理（応援の計数値を増加させる処理）を実行すると共に、このイベント情報ivＤを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＤに応じたゲーム上の処理（応援の計数値を増加させる処理）を実行し、当該イベント情報ivＤをウェブソケットの通信規格に従って他の携帯端末４Ａ〜４Ｃ、４Ｅ〜４Ｈに送信する。

他の携帯端末４Ａ〜４Ｃ、４Ｅ〜４Ｈでは、プロセッサ４３Ａ〜４３Ｃ、４３Ｅ〜４３Ｈが、このイベント情報ivＤに応じたゲーム上の処理（応援の計数値を増加させる処理）を実行する。

すなわち、ステップＳＴ７では、各携帯端末４Ａ〜４Ｈから送信されたイベント情報ivＡ〜ivＨが、ウェブソケット通信により、リアルタイムで他の各携帯端末４Ａ〜４Ｈに共有される。

なお、ステップＳＴ７のうち、応援を行う第２の携帯端末４Ｄ〜４Ｈに対して、ウェブサーバ装置２は、図２３及び以下のステップＳＴ２７−１〜ＳＴ２７−４に示すように動作してもよい。

すなわち、ウェブサーバ装置２では、プロセッサ２３が、第１及び第２の各携帯端末４Ａ〜４Ｈのうち、第２の各携帯端末４Ｄ〜４Ｈのいずれかからユーザの操作に応じたイベント情報を受けると、このイベント情報の受付時間と、このイベント情報の送信元を表す端末識別情報を含むログ情報Ｌをメモリ２２に書込む（ＳＴ２７−１；ログ情報書込工程）。

また、ウェブサーバ装置２では、プロセッサ２３が、単位時間当たりの受付時間の個数を応援の計数値として計数する（ＳＴ２７−２；計数工程）。

さらに、ウェブサーバ装置２では、プロセッサ２３が、応援の計数値と応援の目標値とを比較し、応援の計数値が応援の目標値に到達すると、当該目標値に到達した時間を表す目標到達時間をメモリ２２に書込む（ＳＴ２７−３；到達時間書込工程）。なお、比較の結果、応援の計数値が応援の目標値に到達していなければ、プロセッサ２３は、ステップＳＴ２７−３を実行せず、ステップＳＴ２７−４に移行する。

ウェブサーバ装置２では、プロセッサ２３が、第２の各携帯端末４Ｄ〜４Ｈのいずれか（例、４Ｄ）から受けたイベント情報を応援の計数値と共に、ウェブソケットの通信規格に従って当該イベント情報の送信元（例、４Ｄ）以外の他の携帯端末（例、４Ａ〜４Ｃ、４Ｅ〜４Ｈ）に送信する（ＳＴ２７−４；イベント情報送信工程）。

続いて、以上のようなイベント情報及び制限時間に基づいてゲーム状況が進行し、例えば制限時間の経過が近づいてきたとする。このとき、ウェブサーバ装置２では、プロセッサ２３が、メッセージ送信機能（ｆ９）を実行することができる。すなわち、ウェブサーバ装置２では、プロセッサ２３が、バトルの実行期間中、当該バトルの制限時間から所定時間前になってもメモリ２２内に目標到達時間が無い場合に、応援を促すメッセージを第２の各携帯端末４Ｄ〜４Ｈに送信してもよい。なお、応援を促すメッセージは送信しなくてもよい。

また更に、前述したイベント情報及び制限時間に基づいてゲーム状況が進行し、例えばレイドボスのＨＰがゼロ値になったとする。

このとき、ウェブサーバ装置２では、プロセッサ２３が、イベント情報によるアタックに基づいてバトルを終了させる（ＳＴ２８）。なお、バトルの終了は、イベント情報に基づいてレイドボスのＨＰがゼロになった場合（レイドボス（敵）が負けた場合）に限らず、例えば、制限時間内にレイドボスのＨＰがゼロにならなかった場合（レイドボス（敵）が勝った場合）でもよい。

ウェブサーバ装置２では、プロセッサ２３が、バトル終了時に、ステップＳＴ６で計数された結果を応援人数として確定する（ＳＴ２９；応援人数確定工程）。

しかる後、ウェブサーバ装置２では、プロセッサ２３が、敵が負けた場合に、当該確定した応援人数に関連付けられたインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信し、当該第１の各携帯端末４Ａ〜４Ｃとの接続を切断する（ＳＴ３０；時刻ｔｎ；第１接続切断工程）。但し、プロセッサ２３は、敵が勝った場合にはインセンティブデータを送信せずに、各携帯端末４Ａ〜４Ｃとの接続を切断する（時刻ｔｎ）。

なお、ステップＳＴ３０は、前述したステップＳＴ２７−１〜ＳＴ２７−４が実行された場合には、図２４及び以下のステップＳＴ３０−１〜ＳＴ３０−３に示すように実行することができる。

すなわち、ウェブサーバ装置２では、プロセッサ２３が、敵が負けた場合に、当該確定した応援人数に関連付けられたインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信する（ＳＴ３０−１；第１データ送信工程）。

ウェブサーバ装置２では、プロセッサ２３が、敵が負けた場合で且つメモリ２２内に目標到達時間がある場合には、更に、応援データＳ内の他のインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信する（ＳＴ３０−２；第２データ送信工程）。なお、メモリ２２内に目標到達時間がなければ、プロセッサ２３は、ステップＳＴ３０−２を実行せず、ステップＳＴ３０−３に移行する。

ウェブサーバ装置２では、プロセッサ２３が、ステップＳＴ３０−１〜ＳＴ３０−２の完了後、第１の各携帯端末４Ａ〜４Ｃとの接続を切断する（ＳＴ１０−３；切断工程）。

一方、ウェブサーバ装置２では、プロセッサ２３が、バトルの終了後、体力値を回復させるデータを第２の各携帯端末４Ｄ〜４Ｈに送信し、当該第２の各携帯端末４Ｄ〜４Ｈとの接続を切断する（ＳＴ３１；時刻ｔｎ’；第２接続切断工程）。第２の各携帯端末４Ｄ〜４Ｈは、これにより体力値（ＨＰ）を回復できるので、次回以降のバトルに参加可能となることが期待できる。なお、ステップＳＴ３０とＳＴ３１とは、いずれを先に実行してもよい。

いずれにしても、ステップＳＴ３０とＳＴ３１により接続が切断されると、図２２に示した如き、１回のレイドバトルゲームが完了する。すなわち、応援データ設定工程によりレイドバトルゲームの設定が開始され、以降の各工程によりレイドバトルゲームが運営され、第１及び第２接続切断工程により、レイドバトルゲームが完了する。

上述したように本実施形態によれば、ウェブサーバ装置２が、いずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報をウェブソケットの通信規格に従って他の携帯端末に送信する構成により、ウェブソケットの通信規格に従い、処理負荷が小さいリアルタイム通信を実現できる。これにより、クライアント装置としての携帯端末の数を制限せずに、複数のクライアント装置としての複数の携帯端末４Ａ〜４Ｈをウェブサーバ装置２に接続でき、多数のユーザがバトル及び応援に参加可能なバトルゲームを実現することができる。

また、ウェブサーバ装置２は、ステップＳＴ２７−１〜ＳＴ２７−４を実行する場合、第２の各携帯端末４Ｄ〜４Ｈから受けたイベント情報による応援の計数値と応援の目標値とを比較し、応援の計数値が応援の目標値に到達すると、当該目標値に到達した時間を表す目標到達時間をメモリ２２に書込み、当該イベント情報を応援の計数値と共に、ウェブソケットの通信規格に従って当該イベント情報の送信元以外の他の携帯端末に送信する。これにより、応援の計数値（応援の度合い）を各携帯端末４Ａ〜４Ｈで共有でき、各携帯端末４Ａ〜４Ｈのユーザにおける士気の向上を図ることができる。

また、ウェブサーバ装置２は、当該バトルの制限時間から所定時間前になってもメモリ２２内に目標到達時間が無い場合であって、応援を促すメッセージを第２の各携帯端末４Ｄ〜４Ｈに送信する場合には、応援を促すメッセージにより応援のイベント情報が多数送信されることを促すため、制限時間の直前に応援の盛り上げとバトルの士気向上とを期待することができる。

また、ウェブサーバ装置２は、ステップＳＴ３０−１〜ＳＴ３０−３を実行する場合、応援が目標値に達した場合には、通常のインセンティブデータとは別に、他のインセンティブデータを第１の各携帯端末４Ａ〜４Ｃに送信するので、応援を行うユーザに対し、応援の意欲を高めることができる。

また、本実施形態によれば、リクエスト＆レスポンス形式で通信を行わず、ＨＴＭＬ５に関連したウェブソケットの通信規格を使用したバトルゲームを実現することができる。

＜第５の実施の形態＞
本発明の第５の実施形態では、クライアント装置の数を制限せずに、複数のクライアント装置をウェブサーバ装置に接続でき、多数のユーザが参加可能なバトルゲームを実現し得るゲーム制御方法を提供する。

ウェブサーバ装置２及び携帯端末４Ａ〜４Ｃの構成については、上述の第１の実施の形態と同様なので、ここでは異なる点について説明する。

本発明の第５の実施の形態において、ゲーム制御プログラムｐ_ｓ３は、レイドバトルゲームの様々な方式に基づくゲーム機能の他に、以下の機能（ｆ１）〜（ｆ７）をプロセッサ２３に実現させるためのプログラムを含んでいる。

（ｆ１） バトルゲームの参加人数の範囲と、バトルの結果に基づいて各携帯端末４Ａ〜４Ｃのユーザに与えることが可能なインセンティブデータと、敵の強さレベルを表す敵レベルデータと、バトルゲームの制限時間とを関連付けて記述したギャザリングデータをメモリに設定するギャザリングデータ設定機能。

なお、図２５に一例を示すように、ギャザリングデータＧは、参加人数の範囲と、インセンティブデータと、敵レベルデータと、制限時間と、バトルゲームに参加可能な強さレベルを表す参加レベルデータとを関連付けて記述したデータとしてもよい（ギャザリングデータＧは、参加レベルデータを含んでもよい。）。強さレベルとしては、例えば、ＨＰ（体力）や攻撃力などのように、バトルの勝敗に影響を与える数値パラメータが適宜使用可能であり、この例では、ＨＰ（体力）を用いている。

また、この例では、参加人数の範囲の大きさに応じて、インセンティブデータのランクが上昇し、敵レベルデータの値が上昇し、制限時間が長くなり、参加レベルデータの値が上昇するように、ギャザリングデータＧが設定されている。ここで、参加人数の範囲の大きさに応じて、敵レベルデータの値を上昇させた設定により、参加人数の増加によってバトルゲームが極端に容易になることを防ぎ、バトルゲームの面白さを維持している。また、敵レベルデータの値を上昇させた場合に制限時間を長くした設定により、敵レベルデータの上昇によってバトルゲームが極端に困難になることを防ぎ、バトルゲームの面白さを維持している。また、敵レベルデータの値を上昇させた場合に、参加レベルデータの値を上昇させた設定により、敵の強さレベルと、ユーザの強さレベルとのバランスをとり、バトルゲームの面白さを維持している。また、参加人数の範囲の大きさに応じて、インセンティブデータのランクを上昇させた設定により、ユーザに多数の友人を誘う動機づけを生じさせ、ソーシャル性の向上を図っている。すなわち、ギャザリングデータＧは、以上のような設定により、参加人数の範囲の大きさに応じて、バトルゲームの面白さを維持しつつ、ソーシャル性の向上を図ることができる。これに対し、従来は、参加人数とは無関係に、所定の強さレベルのレイドボスとバトルを行い、所定のインセンティブをユーザ（勝者）が取得する方式であった。すなわち、従来は、参加人数が増えると、レイドボスが相対的に弱くなってバトルゲームが極端に容易になる傾向があった。また、従来は、多数の友人を誘っても誘わなくても、インセンティブデータが同じだったので、多数の友人を誘う動機づけに乏しい傾向があった。

（ｆ２） バトルゲームの参加募集期間中、各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受けると、当該ハンドシェイク要求に基づき、当該各携帯端末４Ａ〜４Ｃとの接続を確立してハンドシェイク応答を返信し、各携帯端末４Ａ〜４Ｃにバトルゲームへの参加を許可する接続確立機能。

ここで、接続確立機能（ｆ２）は、例えば、以下の各機能（ｆ２−１）〜（ｆ２−４）を含んでもよい。

（ｆ２−１） 参加募集期間中、各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受信する要求受信機能。

（ｆ２−２） 参加募集期間中、参加人数計数機能（ｆ３）による現在の計数結果を現在の参加人数とし、現在の参加人数に基づいて、ギャザリングデータＧから参加レベルデータを抽出する参加レベル抽出機能。

（ｆ２−３） 参加募集期間中、受信したハンドシェイク要求に基づき、当該ハンドシェイク要求の送信元の携帯端末のユーザの強さレベルが、抽出された参加レベルデータが表す強さレベルよりも高いか否かを判定する判定機能。

（ｆ２−４） 当該判定の結果、高い場合に、送信元の携帯端末との接続を確立してハンドシェイク応答を返信し、当該携帯端末にバトルゲームへの参加を許可する応答返信機能。

ここで、接続確立機能（ｆ２）が機能（ｆ２−１）〜（ｆ２−４）を含む場合、弱いプレイヤ（強さレベルが低いユーザ）でも、参加募集期間中の早い時点（参加レベルデータの低い時点）で参加し、友人をバトルゲームに誘って参加人数の範囲を増やすことにより、良いインセンティブデータ（高いランクのインセンティブデータ）をもらうことができる。従って、各機能（ｆ２−１）〜（ｆ２−４）によれば、友人をバトルゲームに誘う動機づけができるので、ソーシャル性を高めることができる。なお、友人を誘う仕組みとしては、既存のプラットフォーム上にあるＥメール等が適宜使用可能となっている。

（ｆ３） バトルゲームへの参加を許可した各携帯端末４Ａ〜４Ｃの台数を当該バトルゲームの参加人数として計数する参加人数計数機能。

（ｆ４） 参加募集期間の終了後、計数された結果を参加人数として確定する参加人数確定機能。

（ｆ５） 当該確定した参加人数に基づいて、ギャザリングデータからインセンティブデータ、敵レベルデータ及び制限時間を選択してメモリに設定し、当該設定した敵レベルデータ及び制限時間に基づいてバトルゲームを開始するゲーム開始機能。

（ｆ６） 各携帯端末４Ａ〜４Ｃのうちのいずれかの携帯端末（例、４Ａ）からユーザの操作に応じたイベント情報を受けると、このイベント情報をウェブソケットの通信規格に従っていずれかの携帯端末（例、４Ａ）以外の他の携帯端末（例、４Ｂ、４Ｃ）に送信するウェブソケット通信機能。

ここで、当該イベント情報は、ユーザの操作を示すアクション情報と、当該操作された時点から所定の期間を示す期間情報とを含んでもよい。また、当該ウェブソケット通信機能（ｆ６）においては、プロセッサ２３が、イベント情報を当該イベント情報に含まれる期間情報が示す期間内に他の携帯端末（例、４Ｂ，４Ｃ）に送信するものとしてもよい。

また、ウェブソケット通信機能（ｆ６）は、以下の各機能（ｆ６−１）〜（ｆ６−２）を含んでもよい。

（ｆ６−１） 各携帯端末４Ａ〜４Ｃのうちのいずれかの携帯端末（例、４Ａ）からユーザの操作に応じたイベント情報を受けると、このイベント情報の送信元を表す端末識別情報を含むログ情報をメモリ２２に書込むログ情報書込機能。ここで、図２６に一例を示すように、ログ情報Ｌは、端末識別情報に限らず、端末識別情報と、端末識別情報毎のイベント情報受付回数とを含んでもよい。また、ログ情報は、端末識別情報に限らず、端末識別情報と、端末識別情報毎のイベント情報受付日時（図示せず）とを含んでもよい。

（ｆ６−２） いずれかの携帯端末（例、４Ａ）から受けたイベント情報をウェブソケットの通信規格に従って当該いずれかの携帯端末（例、４Ａ）以外の他の携帯端末（例、４Ｂ、４Ｃ）に送信するイベント情報送信機能。

（ｆ７） イベント情報、設定された敵レベルデータ及び設定された制限時間に基づいてバトルを終了させると、当該バトルで敵に勝った場合に、ゲーム開始機能（ｆ５）により設定されたインセンティブデータを各携帯端末４Ａ〜４Ｃに送信し、各携帯端末４Ａ〜４Ｃとの接続を切断する接続切断機能。ここで、接続切断機能（ｆ７）は、ログ情報に含まれる端末識別情報に基いて、インセンティブデータを送信してもよい。言い換えると、ログ情報内の携帯端末識別情報に基いてインセンティブデータを送信する場合、ログ情報をメモリ２２に書込むことにより、１回以上攻撃した携帯端末にインセンティブデータを受ける権利を付与することができる。インセンティブデータとしては、当該レイドバトルを含むＲＰＧ又は他のゲーム等で使用可能なデータであって、例えば、着せ替えアイテム、レアカード及びゲーム内通貨といった任意の種類のデータが適用可能となっている。また例えば、ログ情報Ｌ内のイベント情報受付回数に応じて、送信するインセンティブデータに差をつける場合、インセンティブデータの個数に差をつけてもよく、インセンティブデータの内容に差をつけてもよい。インセンティブデータの個数に差をつける場合、例えば、同一種類で異なる内容の複数のインセンティブデータを送信してもよく、異なる種類の複数のインセンティブデータを送信してもよい。なお、送信するインセンティブデータには差をつけなくてもよい。

次に、以上のように構成されたゲームシステムの動作について説明する。ギャザリングデータを用いない場合の動作は、図５において説明した動作と同じであるので、ギャザリングデータを用いる場合の動作について説明する。

（ギャザリングデータを用いる場合；図２７）
ギャザリングデータを用いる場合、ウェブサーバ装置２は、図５に示した動作に並行して、図２７に示すように、各ステップＳＴ４２〜ＳＴ５１等を実行する。

始めに、ウェブサーバ装置２では、プロセッサ２３が、バトルゲームの参加人数の範囲と、バトルの結果に基づいて各携帯端末４Ａ〜４Ｃのユーザに与えることが可能なインセンティブデータと、敵の強さレベルを表す敵レベルデータと、バトルゲームの制限時間とを関連付けて記述したギャザリングデータをメモリ２２に設定する（ＳＴ４１；ギャザリングデータ設定工程）。この設定により、ギャザリングデータを用いたレイドバトルゲームが実行可能となる。なお、この設定は、例えば、ゲームステージの難易度などに応じてギャザリングデータが更新設定されるようにしてもよく、常に同じギャザリングデータが設定されるようにしてもよい。難易度に応じて更新設定される場合、例えば難易度が高いほど、高い値の敵レベルデータを設定すればよい。

ギャザリングデータの設定後、ウェブサーバ装置２では、プロセッサ２３が、バトルゲームの参加募集期間の計時を開始する。

ウェブサーバ装置２では、プロセッサ２３が、各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受けると、当該ハンドシェイク要求に基づき、当該各携帯端末４Ａ〜４Ｃとの接続を確立してハンドシェイク応答を返信し（時刻ｔ０）、各携帯端末４Ａ〜４Ｃにバトルゲームへの参加を許可する（ＳＴ２；接続確立工程）。なお、参加募集期間は各携帯端末４Ａ〜４Ｃ間で同一（又は共通）であるが、時刻ｔ０の値は各携帯端末４Ａ〜４Ｃにおけるハンドシェイク要求の送信時刻に応じて各携帯端末４Ａ〜４Ｃ毎に異なる。

このとき、ウェブサーバ装置２のプロセッサ２３は、ステップＳＴ４２を、例えば図２８に示すように、以下のステップＳＴ４２−１〜ＳＴ４２−５を含むステップとして実行してもよい。

すなわち、プロセッサ２３は、参加募集期間中、各携帯端末４Ａ〜４Ｃからハンドシェイク要求を受信する（ＳＴ４２−１）。

プロセッサ２３は、参加募集期間中、後述するステップＳＴ４３による現在の計数結果を現在の参加人数とし、現在の参加人数に基づいて、ギャザリングデータＧから参加レベルデータを抽出する（ＳＴ４２−２）。

プロセッサ２３は、参加募集期間中、受信したハンドシェイク要求に基づき、当該ハンドシェイク要求の送信元の携帯端末のユーザの強さレベルが、抽出された参加レベルデータが表す強さレベルよりも高いか否かを判定する（ＳＴ４２−３）。

プロセッサ２３は、当該判定の結果、高い場合に、送信元の携帯端末との接続を確立してハンドシェイク応答を返信し、当該携帯端末にバトルゲームへの参加を許可する（ＳＴ４２−４）。また、プロセッサ２３は、ステップＳＴ４２−３による判定の結果、否の場合に、送信元の携帯端末との接続を終了し、当該携帯端末のバトルゲームへの参加を拒否して処理を終了する（ＳＴ４２−５）。

ステップＳＴ４２の終了後、ウェブサーバ装置２では、プロセッサ２３が、バトルゲームへの参加を許可した各携帯端末４Ａ〜４Ｃの台数をバトルゲームの参加人数として計数する（ＳＴ４３；参加人数計数工程）。これらステップＳＴ４２〜ＳＴ４３は、参加募集期間中、ハンドシェイク要求を受ける毎に実行される（ＳＴ４４）。

ウェブサーバ装置３では、プロセッサ２３が、参加募集期間の終了後、当該計数された結果を参加人数として確定する（ＳＴ４５；参加人数確定工程）。

ウェブサーバ装置３では、プロセッサ２３が、当該確定した参加人数に基づいて、ギャザリングデータからインセンティブデータ、敵レベルデータ及び制限時間を選択してメモリに設定し、当該設定した敵レベルデータ及び制限時間に基づいてバトルゲームを開始する（ＳＴ４６；ゲーム開始工程）。

次に、例えば携帯端末４Ａでは、ユーザによるタッチパネル４８Ａのタップ操作に応じて、前述同様に、プロセッサ４３Ａが、イベント情報ivＡを作成し（時刻ｔ１１）、このイベント情報ivＡに応じたゲーム上の処理を実行すると共に、このイベント情報ivＡを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＡに応じたゲーム上の処理を実行する。また、プロセッサ２３は、このリクエストの情報をメモリ２２に書込む（ＳＴ４７）。例えば、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ａからユーザの操作に応じたイベント情報ivＡを受けると、このイベント情報ivＡの送信元を表す端末識別情報“４Ａ”を含むログ情報をメモリ２２に書込む（ＳＴ４７；ログ書込工程）。

また、ウェブサーバ装置２では、プロセッサ２３が、当該携帯端末４Ａから受けたイベント情報ivＡをウェブソケットの通信規格に従って他の携帯端末４Ｂ、４Ｃに送信する（時刻ｔ１２；ウェブソケット通信工程）。ステップＳＴ４７と時刻ｔ１２とは、どちらが先でもよい。

また同様に、例えば携帯端末４Ｂでは、ユーザによるタッチパネル４８Ｂのタップ操作に応じて、前述同様に、プロセッサ４３Ｂが、イベント情報ivＢを作成し（時刻ｔ２１）、このイベント情報ivＢに応じたゲーム上の処理を実行すると共に、このイベント情報ivＢを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＢに応じたゲーム上の処理を実行する。また、プロセッサ２３は、このリクエストの情報をメモリ２２に書込む（ＳＴ４８）。例えば、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ｂからユーザの操作に応じたイベント情報ivＢを受けると、このイベント情報ivＢの送信元を表す端末識別情報“４Ｂ”を含むログ情報をメモリ２２に書込む（ＳＴ４８；ログ書込工程）。

また、ウェブサーバ装置２では、プロセッサ２３が、当該携帯端末４Ｂから受けたイベント情報ivＢをウェブソケットの通信規格に従って他の携帯端末４Ａ、４Ｃに送信する（時刻ｔ２２；ウェブソケット通信工程）。ステップＳＴ４８と時刻ｔ２２とは、どちらが先でもよい。

更に同様に、例えば携帯端末４Ｃでは、ユーザによるタッチパネル４８Ｃのタップ操作に応じて、前述同様に、プロセッサ４３Ｃが、イベント情報ivＣを作成し（時刻ｔ３１）、このイベント情報ivＣに応じたゲーム上の処理を実行すると共に、このイベント情報ivＣを含むリクエストをウェブサーバ装置２に送信する。

ウェブサーバ装置２では、プロセッサ２３が、このイベント情報ivＣに応じたゲーム上の処理を実行する。また、プロセッサ２３は、このリクエストの情報をメモリ２２に書込む（ＳＴ４９）。例えば、ウェブサーバ装置２では、プロセッサ２３が、携帯端末４Ｃからユーザの操作に応じたイベント情報ivＣを受けると、このイベント情報ivＣの送信元を表す端末識別情報“４Ｃ”を含むログ情報をメモリ２２に書込む（ＳＴ４９；ログ書込工程）。

また、ウェブサーバ装置２では、プロセッサ２３が、当該携帯端末４Ｃから受けたイベント情報ivＣをウェブソケットの通信規格に従って他の携帯端末４Ａ、４Ｂに送信する（時刻ｔ３２；ウェブソケット通信工程）。ステップＳＴ４９と時刻ｔ３２とは、どちらが先でもよい。

続いて、以上のようなイベント情報、設定された敵レベルデータ及び設定された制限時間に基づいてゲーム状況が進行し、例えばレイドボスのＨＰがゼロ値になったとする。

このとき、ウェブサーバ装置２では、プロセッサ２３が、イベント情報によるアタックに基づいてバトルを終了させる（ＳＴ５０）。なお、バトルの終了は、イベント情報に基づいてレイドボスのＨＰがゼロになった場合（ユーザが敵に勝った場合）に限らず、例えば、制限時間内にレイドボスのＨＰがゼロにならなかった場合（ユーザが敵に負けた場合）でもよい。

ウェブサーバ装置２では、プロセッサ２３が、バトルを終了させると、当該バトルで敵に勝った場合に、ステップＳＴ４６で設定されたインセンティブデータを各携帯端末４Ａ〜４Ｃに送信し（ＳＴ５１）、各携帯端末４Ａ〜４Ｃとの接続を切断する（時刻ｔｎ；接続切断工程）。ここで、プロセッサ２３は、ステップＳＴ５１の際に、例えば、ログ情報に含まれる端末識別情報に基いて、インセンティブデータを送信してもよい。これにより、ステップＳＴ４６〜ＳＴ５０の間にレイドボスを攻撃した携帯端末（実質的にバトルに参加した携帯端末）のみにインセンティブデータを送信することができる。また、プロセッサ２３は、ユーザが敵に負けた場合にはインセンティブデータを送信せずに、各携帯端末４Ａ〜４Ｃとの接続を切断する（時刻ｔｎ）。

いずれにしても、接続が切断されると、１回のレイドバトルゲームが完了する。すなわち、ギャザリングデータ設定工程によりレイドバトルゲームの設定が開始され、以降の各工程によりレイドバトルゲームが運営され、接続切断工程により、レイドバトルゲームが完了する。

上述したように本実施形態によれば、ウェブサーバ装置２が、いずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報をウェブソケットの通信規格に従って他の携帯端末に送信する構成により、ウェブソケットの通信規格に従い、処理負荷が小さいリアルタイム通信を実現できる。これにより、クライアント装置としての携帯端末の数を制限せずに、複数のクライアント装置としての複数の携帯端末４Ａ〜４Ｃをウェブサーバ装置２に接続でき、多数のユーザが参加可能なバトルゲームを実現することができる。

また、ウェブサーバ装置２は、ステップＳＴ４２−１〜ＳＴ４２−４を実行する場合、ハンドシェイク要求の送信元の携帯端末のユーザの強さレベルが、現在の参加人数に基づく参加レベルデータが表す強さレベルよりも高いか否かを判定し、高い場合、送信元の携帯端末との接続を確立してハンドシェイク応答を返信し、当該携帯端末にバトルゲームへの参加を許可する。これにより、強さレベルが低いユーザでも、参加募集期間中の早い時点で参加し、友人をバトルゲームに誘って参加人数の範囲を増やすことにより、良いインセンティブデータをもらえるようにしたので、ユーザと友人との付き合いが深まり、ソーシャル性（社交性）を高めることができる。

また、ウェブサーバ装置２は、ログ情報を用いる場合、いずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、このイベント情報の送信元を表す端末識別情報を含むログ情報をメモリに書込み、ログ情報に含まれる端末識別情報に基いて、インセンティブデータを送信する。これにより、実質的にバトルに参加した携帯端末のみにインセンティブデータを送信することができる。

また、本実施形態によれば、リクエスト＆レスポンス形式で通信を行わず、ＨＴＭＬ５に関連したウェブソケットの通信規格を使用したバトルゲームを実現することができる。

なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどのコンピュータ読み取り可能な記憶媒体に格納して頒布することもできる。

なお、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。以下に、本願の原出願の出願当初の特許請求の範囲に記載された発明を付記する。
［１］
複数の携帯端末と通信可能なプロセッサを有するサーバ装置において用いられ、前記各携帯端末が敵をそれぞれ表示し、前記各携帯端末のユーザの操作により前記敵とのバトルを行うバトルゲームを当該各携帯端末に実行させるためのゲーム制御方法において、
前記プロセッサが、前記各携帯端末から接続要求を受けると、当該各携帯端末との接続を確立し、前記接続要求に対する応答を返信することにより、前記各携帯端末に前記バトルを開始させる接続確立工程と、
前記プロセッサが、前記接続確立工程によって確立された各携帯端末との接続中に、前記各携帯端末のうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報を通信規格に従って前記いずれかの携帯端末以外の他の携帯端末に送信する通信工程と、
前記プロセッサが、前記イベント情報又は制限時間に基づいて前記バトルを終了させると、前記接続確立工程によって確立された前記各携帯端末との接続を切断する接続切断工程と、
を備える、ゲーム制御方法。
［２］
前記接続要求は、ハンドシェイク要求であり、前記接続要求に対する応答は、ハンドシェイク応答であり、前記通信規格は、ウェブソケットの通信規格である、上記［１］に記載のゲーム制御方法。
［３］
前記敵は、前記イベント情報によるアタックを受けるレイドボスであり、
前記イベント情報は、前記ユーザの操作を示すアクション情報と、前記操作された時点から所定の期間を示す期間情報とを含み、
前記通信工程においては、前記プロセッサが、前記イベント情報を当該イベント情報に含まれる期間情報が示す期間内に前記他の携帯端末に送信する、上記［１］に記載のゲーム制御方法。
［４］
前記プロセッサが、互いに異なる前記各携帯端末の操作に応じた複数のイベント情報を連続攻撃として受け付ける受付期間を含むデータを前記サーバ装置のメモリに設定するデータ設定工程と、
前記プロセッサが、前記各携帯端末のうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、このイベント情報を受け付けたイベント情報受付時間とこのイベント情報の送信元を表す端末識別情報とを含むログ情報を前記メモリに書込むログ書込工程と、
前記プロセッサが、前記ログ情報に含まれる複数の端末識別情報が互いに異なるか否かを判定すると共に、前記ログ情報に含まれる複数のイベント情報受付時間が前記受付期間内にあるか否かを判定する判定工程と、
前記プロセッサが、前記判定の結果、前記複数の端末識別情報が互いに異なり且つ前記複数のイベント情報受付時間が前記受付期間内にある場合、前記連続攻撃を前記敵に加える連続攻撃工程とをさらに具備し、
前記接続切断工程は、前記プロセッサが、前記イベント情報、前記連続攻撃又は制限時間に基づいて前記バトルを終了させると、前記各携帯端末との接続を切断する、上記［１］に記載のゲーム制御方法。
［５］
前記プロセッサが、前記各敵を識別する敵識別情報と、前記バトルを行うときの優劣関係が巡回的に定められた複数の属性のうちのいずれかの属性を示す属性情報とを含む敵属性データを前記サーバ装置のメモリに設定する敵属性設定工程と、
前記プロセッサが、前記各携帯端末のうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、このイベント情報の送信元を表す端末識別情報と、前記敵属性データ内のいずれかの属性情報とを含む端末属性データを前記メモリに設定すると共に、このイベント情報を前記通信規格に従って前記いずれかの携帯端末以外の他の携帯端末に送信する端末属性設定工程と、
前記プロセッサが、前記端末属性データが設定された前記各携帯端末のうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報を前記通信規格に従って前記いずれかの携帯端末以外の他の携帯端末に送信する通信工程とをさらに具備し、
前記接続切断工程は、前記プロセッサが、前記イベント情報又は制限時間に基づいて前記バトルを終了させると、前記各携帯端末との接続を切断する、
上記［１］に記載のゲーム制御方法。
［６］
前記各携帯端末は、第１及び第２の携帯端末を含み、前記サーバ装置は、前記第１及び第２の各携帯端末のうちの前記第１の各携帯端末のユーザの操作により前記敵とのバトルを行うバトルゲームを当該第１の各携帯端末に実行させ、前記バトルを行うユーザを応援するための前記第２の各携帯端末を当該応援に参加させ、
前記プロセッサが、前記第２の各携帯端末の台数に相当する応援人数の範囲と、前記応援人数の範囲に応じて前記第１の各携帯端末のユーザに与えることが可能なインセンティブデータとを関連付けて記述した応援データを前記メモリに設定し、
前記接続確立工程は、
前記プロセッサが、前記バトルゲームへの参加募集期間中、前記第１の各携帯端末から前記バトルへの参加を求める第１接続要求を受けると、当該第１接続要求に基づき、当該第１の各携帯端末との接続を確立し、第１接続応答を返信し、当該第１の各携帯端末に前記バトルへの参加を許可する第１接続確立工程と、
前記プロセッサが、前記参加募集期間中及び前記バトルの実行期間中、前記第２の各携帯端末から前記バトルの応援への参加を求める第２接続要求を受けると、当該第２接続要求に基づき、当該第２の各携帯端末との接続を確立し、第２接続応答を返信し、当該第２の各携帯端末に前記応援への参加を許可する第２接続確立工程とを具備し、
前記プロセッサが、前記応援への参加を許可した第２の各携帯端末の台数を前記応援人数として計数し、
前記通信工程は、前記プロセッサが、前記第１及び第２の各携帯端末のうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、このイベント情報を前記通信規格に従って前記いずれかの携帯端末以外の他の各携帯端末に送信し、
前記プロセッサが、前記バトルの終了時に、前記計数された結果を前記応援人数として確定し、
前記接続切断工程は、
前記プロセッサが、前記敵が負けた場合に、前記確定した応援人数に関連付けられたインセンティブデータを前記第１の各携帯端末に送信し、当該第１の各携帯端末との接続を切断する第１接続切断工程と、
前記プロセッサが、前記バトルの終了後、体力値を回復させるデータを前記第２の各携帯端末に送信し、当該第２の各携帯端末との接続を切断する第２接続切断工程と、
を具備する上記［１］に記載のゲーム制御方法。
［７］
前記応援データは、前記応援人数の範囲と、前記応援人数の範囲に応じた前記インセンティブデータと、前記第２の各携帯端末による応援の目標値と、前記目標値に応じた、前記インセンティブデータとは異なる他のインセンティブデータとを関連付けて記述したデータであり、
前記応援の目標値は、前記第２の各携帯端末から送信された前記イベント情報の単位時間当たりの個数を表すパラメータであり、
前記通信工程は、
前記プロセッサが、前記第１及び第２の各携帯端末のうち、前記第２の各携帯端末のいずれかからユーザの操作に応じたイベント情報を受けると、このイベント情報の受付時間と、このイベント情報の送信元を表す端末識別情報を含むログ情報を前記メモリに書込むログ情報書込工程と、
前記プロセッサが、前記単位時間当たりの前記受付時間の個数を前記応援の計数値として計数する計数工程と、
前記プロセッサが、前記応援の計数値と前記応援の目標値とを比較し、前記応援の計数値が前記応援の目標値に到達すると、前記目標値に到達した時間を表す目標到達時間を前記メモリに書込む到達時間書込工程と、
前記プロセッサが、前記第２の各携帯端末のいずれかから受けたイベント情報を前記応援の計数値と共に、前記通信規格に従って当該イベント情報の送信元以外の他の携帯端末に送信するイベント情報送信工程と、
を含んでおり、
前記第１接続切断工程は、
前記プロセッサが、前記敵が負けた場合に、前記確定した応援人数に関連付けられた前記インセンティブデータを前記第１の各携帯端末に送信する第１データ送信工程と、
前記プロセッサが、前記敵が負けた場合で且つ前記メモリ内に前記目標到達時間がある場合には、更に、前記他のインセンティブデータを前記第１の各携帯端末に送信する第２データ送信工程と、
前記第１及び第２データ送信工程の完了後、前記第１の各携帯端末との接続を切断する切断工程と、
を含む上記［６］に記載のゲーム制御方法。
［８］
前記プロセッサが、前記バトルの実行期間中、当該バトルの制限時間から所定時間前になっても前記メモリ内に前記目標到達時間が無い場合に、前記応援を促すメッセージを前記第２の各携帯端末に送信するメッセージ送信工程と、
を更に備える上記［７］に記載のゲーム制御方法。
［９］
前記プロセッサが、前記バトルゲームの参加人数の範囲と、前記バトルの結果に基づいて前記各携帯端末のユーザに与えることが可能なインセンティブデータと、前記敵の強さレベルを表す敵レベルデータと、前記バトルゲームの制限時間とを関連付けて記述したギャザリングデータを前記メモリに設定し、
前記接続確立工程は、前記プロセッサが、前記バトルゲームの参加募集期間中、前記各携帯端末から接続要求を受けると、当該接続要求に基づき、当該各携帯端末との接続を確立し、接続応答を返信し、前記各携帯端末に前記バトルゲームへの参加を許可し、
前記プロセッサが、前記バトルゲームへの参加を許可した各携帯端末の台数を前記バトルゲームの参加人数として計数し、
前記プロセッサが、前記参加募集期間の終了後、前記計数された結果を前記参加人数として確定し、
前記プロセッサが、前記確定した参加人数に基づいて、前記ギャザリングデータから前記インセンティブデータ、前記敵レベルデータ及び前記制限時間を選択して前記メモリに設定し、当該設定した前記敵レベルデータ及び前記制限時間に基づいて前記バトルゲームを開始し、
前記接続切断工程は、前記プロセッサが、前記イベント情報、前記設定された敵レベルデータ及び前記設定された制限時間に基づいて前記バトルを終了させると、当該バトルで前記敵に勝った場合に、前記設定されたインセンティブデータを前記各携帯端末に送信し、前記各携帯端末との接続を切断する、
上記［１］に記載のゲーム制御方法。
［１０］
前記ギャザリングデータは、前記参加人数の範囲と、前記インセンティブデータと、前記敵レベルデータと、前記制限時間と、前記バトルゲームに参加可能な強さレベルを表す参加レベルデータとを関連付けて記述したデータであり、
前記接続確立工程は、
前記プロセッサが、前記参加募集期間中、前記各携帯端末から接続要求を受信する要求受信工程と、
前記プロセッサが、前記参加募集期間中、前記参加人数計数工程による現在の計数結果を現在の参加人数とし、前記現在の参加人数に基づいて、前記ギャザリングデータから前記参加レベルデータを抽出する参加レベル抽出工程と、
前記プロセッサが、前記参加募集期間中、前記受信した接続要求に基づき、当該接続要求の送信元の携帯端末のユーザの強さレベルが、前記抽出された前記参加レベルデータが表す強さレベルよりも高いか否かを判定する判定工程と、
前記プロセッサが、当該判定の結果、前記高い場合に、前記送信元の携帯端末との接続を確立して接続応答を返信し、当該携帯端末に前記バトルゲームへの参加を許可する応答返信工程と、
を含む上記［９］に記載のゲーム制御方法。
［１１］
前記通信工程は、
前記プロセッサが、前記各携帯端末のうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、このイベント情報の送信元を表す端末識別情報を含むログ情報を前記メモリに書込むログ情報書込工程と、
を含んでおり、
前記接続切断工程においては、前記プロセッサが、前記ログ情報に含まれる端末識別情報に基いて、前記インセンティブデータを送信する、上記［１０］に記載のゲーム制御方法。
［１２］
複数の携帯端末が敵をそれぞれ表示し、前記各携帯端末のユーザの操作により前記敵とのバトルを行うバトルゲームを当該各携帯端末に実行させるためのサーバ装置において、
前記各携帯端末から接続要求を受けると、当該各携帯端末との接続を確立し、前記接続要求に対する応答を返信することにより、前記各携帯端末に前記バトルを開始させる接続確立手段と、
前記接続確立手段によって確立された各携帯端末との接続中に、前記各携帯端末のうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報を通信規格に従って前記いずれかの携帯端末以外の他の携帯端末に送信する通信手段と、
前記イベント情報又は制限時間に基づいて前記バトルを終了させると、前記接続確立手段によって確立された前記各携帯端末との接続を切断する接続切断手段と、
を備える、サーバ装置。
［１３］
複数の携帯端末が敵をそれぞれ表示し、前記各携帯端末のユーザの操作により前記敵とのバトルを行うバトルゲームを当該各携帯端末に実行させるためのサーバ装置に用いられるゲーム制御プログラムを記憶したコンピュータ読み取り可能な情報記録媒体において、
前記ゲーム制御プログラムは、前記サーバ装置のプロセッサを、
前記各携帯端末から接続要求を受けると、当該各携帯端末との接続を確立し、前記接続要求に対する応答を返信し、前記各携帯端末に前記バトルを開始させる接続確立手段、
前記接続確立手段によって確立された各携帯端末との接続中に、前記各携帯端末のうちのいずれかの携帯端末からユーザの操作に応じたイベント情報を受けると、当該イベント情報を通信規格に従って前記いずれかの携帯端末以外の他の携帯端末に送信する通信手段、
前記イベント情報又は制限時間に基づいて前記バトルを終了させると、前記接続確立手段によって確立された前記各携帯端末との接続を切断する接続切断手段、
として機能させる。

１…ネットワーク、２…ウェブサーバ装置、４Ａ〜４Ｃ…携帯端末、５…アクセスポイント（ＡＰ）、６…基地局、２１，４１Ａ…記憶装置、２２，４２Ａ…メモリ、２３，４３Ａ…プロセッサ、２４，４４Ａ…通信部、４５Ａ…電子コンパス、４６Ａ…カメラ、４７Ａ…表示部、４８Ａ…タッチパネル。

Claims (12)

1. 複数の携帯端末にゲームを提供するサーバ装置に、
   前記ゲームにおける対戦に参加するための第１の要求を前記サーバ装置に対して送信した複数の第１の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第１の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第１ステップと、
   前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２ステップと、
   前記第１ステップにおいて前記対戦の開始までの所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の一時的な１つのグループとして前記対戦に参加させる第３ステップと、
   前記対戦に参加しているいずれかのユーザの第１の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第１の携帯端末に送信する第４ステップと
   を実行させるプログラム。
2. 前記イベント情報は、前記ユーザの操作を示すアクション情報と、所定の期間を示す期間情報とを含み、
   前記第４ステップは、前記イベント情報を当該イベント情報に含まれる期間情報が示す期間内に、前記他のユーザの第１の携帯端末に送信するステップを含む、請求項１に記載のプログラム。
3. 前記複数の第１の携帯端末のうちの少なくとも２つの第１の携帯端末それぞれから前記ユーザの操作に応じたイベント情報を受信した場合に、当該イベント情報それぞれを受け付けたイベント情報受付時間が所定の期間内にあるか否かを判定するステップと、
   前記判定の結果、前記イベント情報受付時間が前記所定の期間内にある場合、連続攻撃を前記対戦における敵に加えるステップとをさらに含む、請求項１記載のプログラム。
4. 前記対戦における敵に関連付けられた、前記対戦を行うときの優劣関係が巡回的に定められた複数の属性のうちのいずれかの属性を示す属性情報を含む敵属性データと、前記対戦に参加しているいずれかのユーザの第１の携帯端末に関連付けられた、前記複数のうちのいずれかの属性を示す属性情報を含む端末属性データとに基づいて、前記対戦を制御するステップをさらに含む、請求項１記載のプログラム。
5. 前記第２の要求を受付けた数に関連付けられた第１のインセンティブを当該対戦に参加したユーザに付与するステップ
   をさらに含む、請求項１記載のプログラム。
6. 接続を確立した前記第２の携帯端末が送信したイベント情報を受付けるステップと、
   前記イベント情報を受け付けた数に基づくパラメータが所定の条件を満たしている場合、当該対戦に参加したユーザに対して第２のインセンティブを付与するステップをさらに含む、請求項５に記載のプログラム。
7. 前記対戦の実行期間中、当該対戦の制限時間から所定時間前になっても前記パラメータが目標値より少ない場合に、前記イベント情報の送信を促すメッセージを前記第２の携帯端末に送信するステップをさらに含む、請求項６記載のプログラム。
8. 前記対戦の終了時に、当該対戦に参加したユーザに対して、当該対戦に参加したユーザの数に応じた第３のインセンティブを付与するステップをさらに含む、請求項１乃至７のいずれか一項に記載のプログラム。
9. 前記第１ステップは、
   前記対戦の参加募集期間中、前記複数の携帯端末それぞれから前記第１の要求を受信するステップと、
   当該第１の要求の送信元の携帯端末のユーザのレベルが、前記対戦に参加しているユーザ数に応じたレベルよりも高い場合には、前記送信元の携帯端末との接続を確立するステップとを含む、請求項８記載のプログラム。
10. 前記複数の第１の携帯端末のうちのいずれかの第１の携帯端末から前記ユーザの操作に応じたイベント情報を受信したことを示すログ情報に基づいて、前記第３のインセンティブを当該第１の携帯端末に送信するステップをさらに含む、請求項９記載のプログラム。
11. 複数の携帯端末にゲームを提供するサーバ装置であって、
    前記ゲームにおける対戦に参加するための第１の要求を前記サーバ装置に対して送信した複数の第１の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第１の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第１手段と、
    前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２手段と、
    前記第１手段において前記対戦の開始までの所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の一時的な１つのグループとして前記対戦に参加させる第３手段と、
    前記対戦に参加しているいずれかのユーザの第１の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第１の携帯端末に送信する第４手段と
    を備える、サーバ装置。
12. 複数の携帯端末にゲームを提供するサーバ装置に実行させるゲーム制御方法であって、
    前記ゲームにおける対戦に参加するための第１の要求を前記サーバ装置に対して送信した複数の第１の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第１の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末との接続を確立しない第１ステップと、
    前記対戦を指定した応援に参加するための第２の要求を前記サーバ装置に対して送信した複数の第２の携帯端末との接続をウェブソケットの通信規格に従ってそれぞれ確立し、前記第２の要求を前記対戦の開始後に前記サーバ装置に対して送信した携帯端末とも接続を確立する第２ステップと、
    前記第１ステップにおいて前記対戦の開始までの所定期間内に接続を確立した全ての第１の携帯端末の各ユーザを、前記対戦が行われる間の一時的な１つのグループとして前記対戦に参加させる第３ステップと、
    前記対戦に参加しているいずれかのユーザの第１の携帯端末からイベント情報を受信した場合に、当該イベント情報を、ウェブソケットの通信規格に従って、前記対戦に参加している他のユーザの第１の携帯端末に送信する第４ステップと
    を含む、ゲーム制御方法。

Images