(実施形態1)
以下に本発明の実施形態を説明する。実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。
まず、本実施形態のゲーム処理システム1の全体の概要について説明する。図1に示すように、ゲーム処理システム1は、ゲーム処理装置100と、ユーザが使用する通信端末200(本図中では200A,200B,200Cなどと記載)と、後述する投票を受け付けて集計する集計サーバ300と、記事の投稿を受け付けて記事を公開する記事サーバ400とを備え、これらは通信ネットワーク50によって繋がれている。通信ネットワーク50は、典型的にはインターネットである。
本実施形態のゲーム処理装置100は、複数のユーザがそれぞれ通信端末200を使ってアクセス可能な仮想空間内におけるゲームを実行する。本実施形態において行われるゲームは、ユーザからの指示に基づいてユーザキャラクタが仮想空間内のダンジョンなどを冒険する、いわゆるRPG(ロールプレイングゲーム)を題材としたソーシャルゲームである。ゲーム内では、ユーザキャラクタが他のキャラクターに遭遇したりアイテムを取得したりする様々なイベントが発生する。ゲーム処理装置100はゲームの進行を制御する。ゲーム処理装置100は、通信端末200から受信した指示に基づいてユーザキャラクタを行動させ、イベントを発生させて各ユーザキャラクタに対応付けられるゲームパラメータを変化させる。ゲームパラメータには、例えば、ユーザキャラクタが所有する仮想通貨やアイテム数を示すパラメータやユーザキャラクタの攻撃力、防御力を示すパラメータなどがある。
通信端末200はユーザによって操作される。本実施形態では、通信端末200は多機能型携帯電話機である。通信端末200は、通信機能を有するポータブルゲーム装置や、タブレット型の端末、パーソナルコンピューターなどでも良い。ユーザは、通信端末200を操作して、ゲーム処理装置100において実行されるゲームへの指示を入力する。ユーザは、自分のユーザキャラクタへのコマンドを入力する。
ユーザは、メインユーザとサブユーザに分けられる。メインユーザは、通信端末200を操作してゲーム処理装置100にアクセスし、ゲーム処理装置100によって制御されているゲームをプレイするユーザである。サブユーザは、ゲーム処理装置100によって制御されるゲームをプレイしているか否かにかかわらず、記事サーバ400と集計サーバ300にアクセスできるユーザである。N人(Nは2以上の整数)がゲームに参加しているとき、第1の通信端末200を操作する第1のユーザから見て、自分自身がメインユーザであり、他のN−1人がサブユーザである。また、未だゲームに参加していないものの、記事サーバ400と集計サーバ300にアクセス可能であって、後述する投票に参加するユーザも、サブユーザである。
なお、メインユーザが通信ネットワーク50内の予め利用登録したSNS(Social Networking Service)サーバを記事サーバ400とし、この記事サーバ400においてメインユーザが自身の友達に登録したユーザをサブユーザとしてもよい。
メインユーザは、ユーザ名とパスワードの設定を含むゲームへの参加登録を予め行っている。メインユーザは、予め設定したユーザ名(もしくは電子メールアドレスなどのID)とパスワードを入力して認証を受け、ゲーム処理装置100に接続(ログイン)し、ユーザキャラクタに対するコマンドを入力する。メインユーザがコマンドを入力すると、コマンドが確定されてから所定時間経過後に、ゲーム内イベントが発生する。コマンドが確定されてから所定時間が経過するまで(イベントが発生するまで)、メインユーザは、コマンドを入力しなくてもよく、放置していてよい。放置している間、メインユーザは、ゲームにログインしたままでもよいし、ログアウトしてもよい。
本実施形態では、コマンドが確定するタイミングは、コマンドがゲーム処理装置100によって受信され、ゲーム処理装置100によって行われる処理のキューに登録された時点である。ただし、後述するように、コマンドが確定するタイミングはこれだけに限られない。
サブユーザには、コマンドが確定されてから所定時間が経過するまでの間、メインユーザのゲームに反映させることができる、今後のゲーム展開に影響を与えるいくつかの選択肢が提示される。集計サーバ300は、コマンドが確定されてから所定時間経過するまでの間、各選択肢に対するサブユーザからの投票を受け付ける。
例えば、ゲームに参加登録しているメインユーザが「ユーザキャラクタを街Xから街Yへ移動させる」コマンドを入力すると、ゲーム処理装置100は、「ユーザキャラクタを街Xから街Yへ移動させる」旨のコマンドに対するいくつかの選択肢を設定し、記事サーバ400に通知する。選択肢は、例えば、「(A)遭遇したモンスターと戦う」「(B)遭遇したモンスターから逃げる」などである。サブユーザは、ゲームに登録していても登録していなくても、メインユーザがプレイしているゲームに、投票という形で関与できるわけである。
記事サーバ400は、各選択肢の内容をインターネット上のウェブページに掲載する。掲載される記事は、ゲームに参加しているユーザだけでなく、ゲームに参加していないユーザも閲覧可能である。各選択肢にはURI(Universal Resource Identifier)によるリンクが張られている。URIは、集計サーバ300内のリソースの場所を指す。例えば、第1の選択肢「(A)遭遇したモンスターと戦う」に対応する第1のURIと、第2の選択肢「(B)遭遇したモンスターから逃げる」に対応する第2のURIがウェブページに掲載される。サブユーザが通信端末200を操作して第1の選択肢を選択すると、通信端末200は第1のURIにアクセスする。同様に、サブユーザが通信端末200を操作して第2の選択肢を選択すると、通信端末200は第2のURIにアクセスする。
集計サーバ300は、投票期間中、サブユーザによる記事サーバ400を経由したアクセスを受け付ける。記事サーバ400に掲示されたURIへの1回のアクセスが1票となる。集計サーバ300は、投票期間が終了すると、各選択肢へのアクセス数(投票数)を集計し、集計結果をゲーム処理装置100に通知する。
ゲーム処理装置100は、コマンドが確定されてから所定時間経過した後のイベント発生時刻に、ゲーム内イベントを発生させる。例えば、ゲーム処理装置100は、「ユーザキャラクタを街Xから街Yへ移動させる」コマンドに対応するイベント「モンスターに遭遇する」を発生させる。そして、ゲーム処理装置100は、発生させたイベントに従って、メインユーザのユーザキャラクタに対応付けられるゲームパラメータを変化させる。このとき、ゲーム処理装置100は、集計サーバ300から通知された集計結果、すなわちサブユーザによる投票結果を、メインユーザがプレイしているゲームに反映させる。
例えば、第1の選択肢への投票数が第2の投票数より多ければ、第1の選択肢「(A)遭遇したモンスターと戦う」をゲームに反映させる。つまり、ゲーム処理装置100は、「モンスターに遭遇する」イベントが発生すると、ユーザキャラクタとモンスターを戦闘させ、ゲームパラメータを変化させる。一方、第1の選択肢への投票数が第2の投票数より少なければ、第2の選択肢「(B)遭遇したモンスターから逃げる」をゲームに反映させる。つまり、ゲーム処理装置100は、「モンスターに遭遇する」イベントが発生すると、ユーザキャラクタとモンスターを戦闘させずにゲームを進行させ、ゲームパラメータを変化させる。
発生したイベントによって変化されたゲームパラメータは、メインユーザの通信端末200に通知される。例えば、メインユーザが「ユーザキャラクタを街Xから街Yへ移動させる」コマンドを入力した後に一旦ログアウトし、イベントの発生後に再びゲームにログインすると、イベント内容とイベント結果が通信端末200に通知され、表示される。メインユーザは、表示されたイベント内容とイベント結果を見て、次のコマンドを入力する。ユーザは、コマンドを入力後、しばらく放置しておいてゲームの進行を待ち、次のログイン時もしくは所定時間の経過後に、ゲームの経過を見て楽しむわけである。なお、メインユーザがあるコマンドを入力後も引き続き他のコマンドを入力できてもよい。
また、サブユーザは、提示された選択肢への投票を行うことで、メインユーザがプレイするゲームに影響を与えることができる。特に、未だゲームに参加していないサブユーザには、投票できることを案内し、まずは投票することによってゲームを知ってもらい、ゲームへの関心をもってもらえるという宣伝効果が期待される。記事サーバ400に投稿される記事は、既にゲームに参加しているメインユーザに限らず、未だゲームに参加していないユーザや、このゲームを知らないユーザにも公開されるので、より多くのユーザにゲームに関心をもってもらい、より多くのユーザに参加してもらえるように導くことができる。
なお、提示された選択肢への投票は、サブユーザだけでなく、メインユーザ自身が行うことができてもよい。また、本実施形態では、1つの通信端末200からは、1つのイベントにつき1票のみ投じることができるものとし、同一の通信端末200から複数回の投票が行われた場合には、最後の投票のみ有効となる。なお、同一の通信端末200から複数回の投票が行われた場合に、最初の1回目の投票のみを有効とし、2回目以降の投票を無効とすることもできる。
本実施形態では、ゲーム処理システム1には、ゲーム処理装置100と集計サーバ300と記事サーバ400が別々に設けられているが、これらが行う処理を1つあるいは2つの装置にまとめて処理させてもよい。
次に、ゲーム処理装置100のハードウェア構成について説明する。図2に示すように、ゲーム処理装置100は、制御部101、通信部102、記憶部103を備える。ゲーム処理装置100は、メインフレームやワークステーションなどといった情報処理装置から構成される。
制御部101は、CPU(Central Processing Unit)などから構成され、記憶部103に記憶されるオペレーティングシステム(OS)やプログラム等に従ってゲーム処理装置100の各部を制御する。例えば、制御部101は、通信部102を制御して、ゲームの進行状態や結果などの情報を通信端末200に送信する。
通信部102は、NIC(Network Interface Card)やルータ、モデム、などといった所定の通信装置から構成される。通信部102は、制御部101の制御により、通信ネットワーク50に接続された通信端末200、集計サーバ300、記事サーバ400などと通信する。
記憶部103は、ワークエリアとなるRAM(Random Access Memory)などの記憶装置、ハードディスク装置やROM(Read Only Memory)などといった記憶装置から構成される。例えば、記憶部103は、ゲーム処理装置100全体を制御するためのプログラムやOSのほか、仮想空間内におけるゲームのパラメータなどを記憶する。
集計サーバ300と記事サーバ400のハードウェア構成は、ゲーム処理装置100のハードウェア構成と同じであるので、詳しい説明は省略する。
次に、通信端末200のハードウェア構成について説明する。図3に示すように、通信端末100は、通信部201、音声処理部202、出力部203、外部インターフェース(I/F)204、入力受付部205、ROM206、RAM207、制御部208、電源部209を備える。
通信部201は、マイクロフォン223に入力され音声処理部202が備えるA/D(Analog/Digital)コンバータ(図示せず)により変換された音声信号を変調し、通信部201が備えるアンテナ221を用いて音声信号を通信相手に送信する。また、通信部201は、アンテナ221を用いて音声信号を受信して復調し、音声処理部202に入力する。音声信号は音声処理部202が備えるD/A(Digital/Analog)コンバータ(図示せず)を用いて音声に変換され、スピーカー222から音声として出力される。通信部201は、通信端末200のユーザから入力される様々な指示情報をゲーム処理装置100に送信し、また、ゲーム処理装置100から送信されるゲームパラメータや画像データ、音声データ等を受信する。
音声処理部202は、ユーザの発声音等をマイクロフォン223によって集音し、音声処理部202が備えるA/Dコンバータにより音声信号に変換して通信部201に入力する。また、音声処理部202は、音声処理部202が備えるD/Aコンバータにより復調された通話音をスピーカー222から出力する。また、音声処理部202は、ゲーム処理装置100にアクセスしてプレイするゲームの音声、効果音、音楽等を再生してスピーカー222から出力する。
出力部203は、制御部208や出力部203が備える画像演算プロセッサ(図示せず)によって画像データを加工処理した後、フレームバッファに記録する。フレームバッファに記録された画像情報は、垂直同期などの所定の同期タイミングで画像信号に変換され、例えばLCD(Liquid Crystal Display)のようなディスプレイ224に出力される。ディスプレイ224の表面には、ユーザによる接触の有無や位置を検知する複数のタッチセンサを備えたタッチパネル226が重畳して配置されている。なお、以下の説明において、ディスプレイ224とタッチパネル226を合わせて「タッチスクリーン」と言う。
外部I/F204は、着脱可能なICカードやフラッシュメモリカード等の外部メモリ225と接続し、データの入出力を行う。例えば外部I/F204に接続される外部メモリ225には、通信端末200の固有の情報(例えば、加入者番号、ネットワーク識別子など)などが記憶される。なお、これらの情報は、RAM207のフラッシュメモリ領域など他の書き換え可能な記憶領域に記憶されてもよい。また、外部I/F204は、通信部201と制御部208の制御により、USB(Universal Serial Bus)接続によって通信端末200と外部機器とを接続して、外部機器との間でデータの入出力を行うことができるインターフェースを備える。なお、外部I/F204は、その他の外部機器との接続を可能にするインターフェースを更に備えていてもよい。
入力受付部205は、タッチパネル226からの操作信号を受け付けて、操作信号に対応するキーコード信号を制御部208に入力する。制御部208は、入力されたキーコード信号に基づいて操作内容を決定する。ユーザは、タッチパネル226を用いて任意の文字データを入力したり所定の操作コマンドを入力したりすることができる。操作コマンドには、例えば、アプリケーションソフトウェア(以下「アプリケーション」という。)の起動や終了、電子ファイルの作成や保存、ゲームのアプリケーションにおけるユーザからのコマンドなどがある。
ROM206は、通信端末200の全体の制御に必要なオペレーティングシステム(OS)やプログラム等を予め記憶する不揮発性メモリである。
RAM207は、制御部208が行う処理に必要なデータやプログラム等を一時的に記憶する。また、RAM207の記憶領域の一部はフラッシュメモリから構成され、電話やメールに使用するアドレス帳、通話の履歴、ダウンロードしたデータ、各種機能の設定値等を記憶する。
制御部208は、ROM206等に記憶されたOSや制御プログラムに従って、通信端末200の全体の制御を行う。制御部208は、各部に制御信号およびデータを送信、または、各部から応答信号およびデータを受信する。また、制御部208は、通信端末200の現在の時刻を計時する。なお、制御部208が実行する様々な処理の詳細は後述する。
電源部209は、通信端末200を駆動させるためのバッテリーを備える。
本実施形態の通信端末200は、図4に示すような多機能型携帯電話機である。タッチスクリーン250には、ユーザからの指示を受け付けるためのソフトウェアボタンなどが表示される。タッチスクリーン250のうちソフトウェアボタンの画像が表示された位置にユーザが指を接触させることを、簡単に「ボタンを選択する」「ボタンをタッチする」などと表現する。
通信端末200は、タッチパネル226を用いた指示の入力をユーザから受け付けるほか、音声による指示入力をユーザから受け付けてもよい。制御部208は、マイクロフォン223により集音した音声データに音声認識処理を施し、音声認識結果からユーザによる指示入力を判別し、判別した指示入力に対応する処理を実行してもよい。
通信端末200は、傾きを検出するジャイロセンサや、通信端末200にかかる加速度を検出する加速度センサを更に備えてもよい。制御部208は、ジャイロセンサや加速度センサによる検出結果を解析し、解析結果からユーザによる指示入力を判別し、判別した指示入力に対応する処理を実行してもよい。
通信端末200は、ハードウェアボタンを更に備え、タッチスクリーン250に表示されるソフトウェアボタンへのユーザ操作だけでなく、ハードウェアボタンへのユーザ操作を検出してもよい。制御部208は、押されたハードウェアボタンに予め対応付けられる処理を実行してもよい。
次に、本実施形態のゲーム処理装置100の機能的な構成について説明する。図5に示すように、ゲーム処理装置100は、指示受付手段501、パラメータ記憶手段502、更新手段503、決定手段504、選択受付手段505を備える。
指示受付手段501は、ユーザキャラクタへの指示を表す指示情報をメインユーザの通信端末200から受け付ける。メインユーザは、自身の操作対象であるユーザキャラクタに、例えば「街Xから街Yへ移動する」「アイテム○○を購入する」など、様々な指示情報(コマンド)を、通信端末200の入力受付部205を操作することにより入力する。通信端末200の入力受付部205がユーザからコマンド入力を受け付けると、制御部208は、通信部201を制御して、受け付けた指示情報をゲーム処理装置100に送信する。ゲーム処理装置100の制御部101は、通信部102を制御して指示情報を通信端末200から受信し、記憶部103に記憶し、受信した指示情報に対応する処理を実行する。制御部101と通信部102と記憶部103が協働して、指示受付手段501として機能する。
パラメータ記憶手段502は、ゲーム処理システム1によって行われる仮想世界のゲームの状態を表す変数、すなわちゲームパラメータを記憶する。ゲームパラメータには、例えば、ユーザキャラクタに対応付けられる仮想通貨の額、所有するアイテムの種類や数、ユーザキャラクタに対応付けられる攻撃値と防御値と体力値、キャラクター名、発生したイベントのログ、などがある。ただし、ゲームパラメータは、これらに限られず、ゲーム処理装置100によって実行されるゲームに応じて適宜定義される。制御部101は、ゲームパラメータを随時更新可能である。制御部101と記憶部103が協働して、パラメータ記憶手段502として機能する。
更新手段503は、メインユーザからの指示情報(コマンド)が受け付けられると、受け付けられたメインユーザからの指示情報に基づいて、仮想世界の状態を表すゲームパラメータを更新する。また、更新手段503は、後述する選択受付手段505によって受け付けられた選択情報に基づいて、仮想世界の状態を表すゲームパラメータを更新する。制御部101と記憶部103が協働して、更新手段503として機能する。
例えば、指示情報の内容が「街Xから街Yへ移動する」の場合、制御部101は、ゲームパラメータのうちユーザキャラクタが現在いるエリアを表すパラメータに、“街Xから街Yへの道の途中”あるいは“街Yの中”を表す値を設定する。指示情報の内容がコマンド「仮想通貨を使ってアイテムを購入する」の場合、制御部101は、ゲームパラメータのうちユーザキャラクタに対応付けられる仮想通貨の総額から所定の額を差し引き、ゲームパラメータのうち所有アイテムを表すパラメータに購入したアイテムの情報を追加する。なお、指示情報の具体的な内容は、本発明によって限定されない。
選択情報は、後述する決定手段504により生成される選択肢の中からサブユーザがいずれか1つを選択した選択結果を示す情報である。
決定手段504は、パラメータ記憶手段502に記憶される仮想世界の状態を表す変数(ゲームパラメータ)に基づいて、この仮想世界に将来生じさせるイベント、このイベントを発生させるイベント発生時刻、この発生時刻より以前の投票開始時刻などを決定する。制御部101が、決定手段504として機能する。
例えば、制御部101は、ユーザキャラクタが存在するエリアを表すパラメータの値を“街Xの中”から“街Xから街Yへの道の途中”に変更すると、このパラメータ値に対応し且つこれから発生させるイベント「モンスターに遭遇する」を現実世界のある時刻に発生させる旨を、決定する。また、制御部101は、発生させるイベントに対応する複数の選択肢を生成し、サブユーザによる投票を受け付ける開始時刻を決定する。サブユーザが投票できる投票期間は、例えば、決定された投票開始時刻から、決定されたイベント発生時刻まで、の間である。ただし、投票期間は、イベント発生時刻と一致していなくてもよく、イベント発生時刻よりも前に終了してもよい。
ここで、制御部101によって決定される事項について詳しく説明する。制御部101は、(1)仮想世界に生じさせるイベントの内容、(2)発生させるイベントに対応する選択肢の内容、(3)イベント発生時刻、(4)投票開始時刻と投票終了時刻とで定義される投票期間を、それぞれ決定する。以下、順に説明する。
(1)イベントの内容の決定
制御部101は、イベントの内容を、受け付けられたコマンドに予め対応付けられた内容に、決定してもよい。受け付けられるコマンドと発生させるイベントとを対応付ける情報が記憶部103に予め記憶されており、制御部101は、この対応付けを参照して、発生させるイベントの内容を決定する。
制御部101は、予め用意された複数のイベントの内容の候補の中から1つの候補を選択し、発生させるイベントの内容としてもよい。例えば、制御部101は、コマンド「前へ進む」が受け付けられると、このコマンドに予め対応付けられているイベント「モンスターに遭遇する」、「宝物を見つける」、「罠にはまってしまう」などの中から、いずれか1つのイベントを選択する。
制御部101は、記憶部103に記憶されているゲームパラメータに基づいてイベントの内容を決定してもよい。記憶部103に記憶されているゲームパラメータは、直前に受け付けられたただ1つのコマンドにのみ基づくのではなく、これまでに受け付けられた複数の様々なコマンドによって形成される総合的な結果を表す。従って、制御部101は、過去のゲームの進行過程を反映させたイベントを発生させることができる。
制御部101は、メインユーザからの入力に基づいてイベントの内容を決定してもよい。例えば、制御部101は、入力されたコマンドに応じて、発生させることができるイベントの内容の候補をメインユーザに提示し、メインユーザが候補の中から1つを選び、選ばれた候補をイベントの内容に決定してもよい。
なお、制御部101は、コマンドが受け付けられる度に、ゲームパラメータが変化し得るイベントを常に発生させなければならないわけではなく、「何も起きない」というイベントを発生させてもよい。
(2)選択肢の内容の決定
制御部101は、選択肢の内容を、発生させるイベントに予め対応付けられた内容に決定してもよい。例えば、決定したイベントが「モンスターに遭遇する」であった場合、制御部101は、「モンスターに遭遇する」というイベントに予め対応付けられた2つの選択肢「(A)モンスターと戦おう」と「(B)モンスターから逃げよう」を用意する。選択肢は3つ以上でもよいし、イベントに対応付けられた3つ以上の選択肢の候補から2つ以上の選択肢がサブユーザに提示されても良い。
制御部101は、選択肢の内容を、受け付けたコマンドに予め対応付けられた内容に決定してもよい。例えば、受け付けたコマンドが「キャラクターを街Xから街Yへ移動させる」であった場合、制御部101は、「キャラクターを街Xから街Yへ移動させる」というコマンドに予め対応付けられた2つの選択肢「(A)遭遇したモンスターと戦う」と「(B)遭遇したモンスターから逃げる」を用意する。選択肢は3つ以上でもよいし、コマンドに対応付けられた3つ以上の選択肢の候補から2つ以上の選択肢がサブユーザに提示されても良い。
制御部101は、選択肢の内容を、ゲームパラメータに基づいて変化させてもよい。例えば、制御部101は、ユーザキャラクタの成長度を表すレベルが所定の基準より小さい(ユーザキャラクタが所定の基準より弱い)場合には2つの選択肢「(A)遭遇したモンスターと戦う」と「(B)遭遇したモンスターから逃げる」を用意し、このレベルが所定の基準以上(ユーザキャラクタが所定の基準以上に強い)の場合には3つの選択肢「(A)遭遇したモンスターと戦う」と「(B)遭遇したモンスターから逃げる」と「(C)遭遇したモンスターを仲間にする」を用意する。メインユーザのゲームのやり込み度が高いと選択肢を多様化させることにより、メインユーザのゲームへの興味が増し、継続的なプレイが期待できる。
なお、制御部101は、レベルが所定の基準より小さい場合には2つの選択肢「(A)遭遇したモンスターと戦う」と「(B)遭遇したモンスターから逃げる」を用意し、このレベルが所定の基準以上の場合には異なる2つの選択肢「(A)遭遇したモンスターと戦う」と「(C)遭遇したモンスターを仲間にする」を用意してもよい。選択肢の数は固定でもよいし、可変でもよい。
(3)イベント発生時刻の決定
制御部101は、イベント発生時刻を、イベントの内容にかかわらず、投票開始時刻から所定時間経過後に設定してもよい。例えば、制御部101は、この所定時間を“3時間”などの固定値に設定する。そして、制御部101は、メインユーザから入力されるコマンドが第1の時刻に確定すると、この第1の時刻を投票開始時刻とし、第1の時刻から所定時間経過した第2の時刻を、イベント発生時刻にする。
制御部101は、イベント発生時刻を、投票開始時刻からイベントごとに異なる長さの時間の経過後の時刻に設定してもよい。例えば、制御部101は、イベントごとに異なった時間長をそれぞれ予め対応付けておく。そして、制御部101は、メインユーザから入力されるコマンドが第1の時刻に確定すると、この第1の時刻を投票開始時刻とし、決定されたイベントに対応付けられた第1の時間長を第1の時刻に加算して得られる第2の時刻を、イベント発生時刻にする。制御部101は、異なるイベントを発生させる場合、コマンドの確定時刻に、この異なるイベントに対応付けられた第2の時間長を加算した第3の時刻を、イベント発生時刻にする。
制御部101は、イベント毎ではなくコマンド毎に異なった時間長をそれぞれ予め対応付けておき、上述と同様に、入力されたコマンドに対応付けられる時間長を投票開始時刻に加算した時刻を、イベント発生時刻に決定しても良い。
制御部101は、イベント発生時刻を、固定時刻に設定してもよい。制御部101は、例えば毎日17時00分00秒にイベントを発生させる、といったように、イベント発生時刻を予め決めておく。そして、制御部101は、メインユーザから入力されるコマンドが第1の時刻に確定すると、この第1の時刻を投票開始時刻とし、第1の時刻より後であって最初に訪れる固定時刻を、イベント発生時刻にする。
メインユーザがイベント発生時刻を決定できるようにしてもよい。すなわち、制御部101は、メインユーザの通信端末200からイベント発生時刻を示す指示情報を受け付け、メインユーザと対応付けてイベント発生時刻を記憶部103に記憶し、設定する。ただし、ユーザが指定できるイベント発生時刻は、コマンドが確定する時刻よりも後である。メインユーザがイベント発生時刻を指定できるようにすれば、投票期間が例えば深夜や早朝あるいは勤務時間帯になってしまってサブユーザが投票できなかったりサブユーザに迷惑をかけたりする可能性が小さくなる。
制御部101は、イベント発生時刻を、過去の他のイベントにおける投票数や過去に投票された時刻などの統計値に基づいて、決定してもよい。すなわち、集計サーバ300は、例えば直近の1ヶ月などのような、ある期間におけるサブユーザによる投票活動の実績の統計を取り、統計データを記憶部103に保存する。統計データは、具体的には、同一メインユーザが行うゲームの他のイベントにおける、最終的な投票総数、時間帯ごとの投票総数、などである。統計を取る統計期間は任意である。また、制御部101は、同一メインユーザだけでなく、ゲーム処理装置100によって行われるすべてのメインユーザのゲームに起きたイベントにおける投票の統計を取ってもよい。
制御部101は、記憶部103に保存した統計データから過去に投票された時間を取得し、1時間毎などの時間帯に分けて投票総数を集計する。1時間毎であれば24個の時間帯毎の投票総数の分布が得られる。そして、制御部101は、最も投票数が多い時間帯に、イベント発生時刻を設定してもよい。このようにすれば、投票期間はサブユーザが投票することが多い傾向にある時間帯に設定されるので、より多くのサブユーザに投票してもらえ、より多くのサブユーザにこのゲームへの関心をもたせることができる。定義される時間帯は1時間毎に限られず、N分毎(Nは1以上の整数)、曜日毎などでもよい。
制御部101は、過去に投票された時間に基づいてイベント毎の投票総数の分布を取得し、発生させるイベントにおける最も投票総数が多い時間帯に、イベント発生時刻を設定してもよい。
制御部101は、コマンドの受信後、所定の条件が満たされた時刻、もしくは所定の条件が満たされた時刻から所定時間が経過した時刻を、イベント発生時刻に決定してもよい。例えば、制御部101は、コマンドをキャンセルできる期間が設けられている場合において、「コマンドのキャンセルが無かったこと」を所定の条件にすることができる。制御部101は、この所定の条件を任意に設定することができる。
(4)投票期間の決定
制御部101は、コマンドが確定した時刻を、投票開始時刻に決定してもよい。受信されたコマンドは、制御部101が管理するFIFO(First In First Out)型の処理キューに登録され、順次実行される。典型的には、この処理キューにコマンドが登録された時刻が、コマンドが確定した時刻である。
制御部101は、投票開始時刻を、固定時刻に設定してもよい。制御部101は、例えば毎日17時00分00秒に投票の受け付けを開始する、といったように、投票開始時刻を予め決めておく。そして、制御部101は、メインユーザから入力されるコマンドが確定した時刻より後であって最初に訪れる固定時刻を、投票開始時刻にする。
投票終了時刻についても同様に、制御部101は、投票終了時刻を、固定時刻に設定してもよい。
制御部101は、メインユーザの通信端末200から投票開始時刻を示す指示情報を受け付け、メインユーザと対応付けて投票開始時刻を記憶部103に記憶し、記憶部103に記憶したこの投票開始時刻を用いてもよい。ただし、ユーザが指定できる投票開始時刻は、コマンドが確定する時刻よりも後であり、且つ、イベント発生時刻よりも前である。
投票終了時刻についても同様に、制御部101は、メインユーザの通信端末200から投票終了時刻を示す指示情報を受け付け、メインユーザと対応付けて投票終了時刻を記憶部103に記憶し、記憶部103に記憶したこの投票終了時刻を用いてもよい。ただし、ユーザが指定できる投票終了時刻は、コマンドが確定する時刻よりも後であり、且つ、イベント発生時刻よりも前であり、且つ、投票開始時刻よりも後である。
制御部101は、コマンドの受信後、所定の条件が満たされた時刻を、投票開始時刻に決定してもよい。例えば、制御部101は、コマンドをキャンセルできる期間が設けられている場合において、「コマンドのキャンセルが無かったこと」を所定の条件にすることができる。制御部101は、この所定の条件を任意に設定することができる。
投票終了時刻についても同様に、制御部101は、所定の条件が満たされた時刻を投票終了時刻に決定してもよい。例えば、制御部101は、投票できる上限の数を設け、「投票総数が上限値に達したこと」を所定の条件にすることができる。制御部101は、この所定の条件を任意に設定することができる。
制御部101は、投票開始時刻及び/又は投票終了時刻を、ランダムな時刻に決定してもよい。
制御部101は、投票期間を、他のイベントにおける投票数や過去に投票された時刻などの統計値に基づいて、決定してもよい。すなわち、上述したように、集計サーバ300は、例えば直近の1ヶ月などのような、ある期間におけるサブユーザによる投票活動の実績の統計を取る。統計を取る統計期間は任意である。同一ユーザだけでなく、ゲーム処理装置100によって行われるすべてのユーザのゲームに起きたイベントにおける投票の統計でもよい。
そして、制御部101は、過去に投票された時間に基づいてイベント毎の投票総数の分布を取得し、設定したイベントに対応する投票総数が少ないほど投票期間を長く設定し、設定したイベントに対応する投票総数が多いほど投票期間を短く設定してもよい。
制御部101は、投票期間中に受け付けた投票数が、設定したイベント発生時刻を含む時間帯における投票総数の統計値以上の場合にはイベント発生時刻に投票期間を終了させ、統計値未満の場合には投票期間を延長してもよい。
また、制御部101は、投票期間を複数に分けて設定してもよい。例えば、制御部101は、1回目の投票期間を時刻T1から時刻T2まで設定し、2回目の投票期間を時刻T2より後の時刻T3から時刻T4まで設定する。
制御部101は、複数の投票期間を設定し、各投票期間中に投票できるサブユーザを限定してもよい。例えば、制御部101は、1回目の投票期間をメインユーザとフレンド登録したサブユーザのみ投票できる期間とし、2回目の投票期間をすべてのサブユーザが投票できる期間とする。
なお、制御部101は、投票開始時刻、投票終了時刻、イベント発生時刻を、現実世界の時刻を用いて決めても良いし、仮想世界に定義される仮想の時刻を用いて決めても良い。
次に、選択受付手段505は、決定手段504によって決定された投票開始時刻から、決定手段504によって決定されたイベント発生時刻までのサブユーザからの選択肢への投票の結果を示す選択情報を受け付ける。受け付けられた選択情報は、パラメータ記憶手段502に記憶される。制御部101と通信部102が協働して、選択受付手段505として機能する。
本実施形態では、サブユーザによる投票の受け付けは、記事サーバ400と集計サーバ300によって行われる。投票を受け付ける旨は記事サーバ400に投稿される記事によって公開される。投票は、集計サーバ300によって集計される。選択受付手段505は、集計された投票結果を表す選択情報を集計サーバ300から受け付ける。
投票終了時刻は、イベント発生時刻より前であってもよい。すなわち、制御部101は、投票終了時刻から所定時間が経過した後にイベントを発生させることとし、イベント発生時刻よりこの所定時間だけ前に投票終了時刻を設定してもよい。
選択受付手段505によって受け付けられた選択情報は、仮想世界の状態を表すゲームパラメータを変化させるために用いられる。すなわち、制御部101は、決定したイベント発生時刻に、決定したイベントを発生させると、受け付けた選択情報に基づいて、仮想世界の状態を表すゲームパラメータを更新する。
例えば、制御部101は、メインユーザからのコマンド「キャラクターを街Xから街Yへ移動させる」が受け付けられると、このコマンドに対応する第1の選択肢「(A)遭遇したモンスターと戦う」と第2の選択肢「(B)遭遇したモンスターから逃げる」を生成する。制御部101は、生成した2つの選択肢を記事サーバ400に送信する。制御部101は、コマンドに対応するイベント「モンスターに遭遇する」を、決定した時刻に発生させる。
一方、記事サーバ400は、コマンドが確定されてからイベントが発生するまでの間、受信した選択肢を、それぞれの選択肢に対応付けたURIと共にウェブページに掲載し、サブユーザからの投票を受け付ける。選択肢の数は、2つ以上の任意の数である。URIは集計サーバ300内のリソースの場所を指しており、集計サーバ300は、各URIへの1回のアクセスを1票として扱う。集計サーバ300は、各URIへのアクセス数を集計し、集計結果をゲーム処理装置100に送信する。
ゲーム処理装置100の制御部101は、設定した選択肢のうち、最も投票数が多かった選択肢に基づいてゲームを進行させ、ゲームパラメータを更新する。
例えば、制御部101は、第1の選択肢「(A)遭遇したモンスターと戦う」への投票数が、第2の選択肢「(B)遭遇したモンスターから逃げる」への投票数よりも多い場合には、決定したイベントを発生させ、ユーザキャラクタをモンスターと戦わせるように制御し、ゲームパラメータを更新する。一方、第1の選択肢「(A)遭遇したモンスターと戦う」への投票数が、第2の選択肢「(B)遭遇したモンスターから逃げる」への投票数よりも少ない場合には、決定したイベントを発生させ、ユーザキャラクタをモンスターと戦わずに逃げるように制御し、ゲームパラメータを更新する。
制御部101は、集計サーバ300から受信した集計結果が所定の条件を満たさない場合、投票期間を延長したり投票をやり直したりしてもよい。例えば、制御部101は、投票結果が有効か無効かの判定ラインとなる最低投票数を設け、すべての選択肢への投票総数が最低投票数に達しない場合、サブユーザが投票できる投票期間を延長してもよい。延長期間は固定値でもよいし可変値でもよい。あるいは、制御部101は、投票総数が最低投票数に達するまで、投票期間を延長してもよい。投票期間を延長した場合には、制御部101は、イベントの発生時刻を、延長された投票期間の満了後に設定すればよい。これにより、ごく少数の投票によってゲームが左右されてしまい面白味に欠けるといった事態を防ぐことができる。
次に、本実施形態のゲーム処理システム1によって行われるゲーム処理の流れについて、図6等を用いて説明する。図6には、ゲーム処理装置100と記事サーバ400と集計サーバ300において行われる処理をまとめて「サーバ側のゲーム処理」と記載している。上述のように、ユーザには、仮想世界のゲームをプレイしコマンドを入力するメインユーザと、入力されたコマンドを受けて提示される選択肢の中から投票できるサブユーザとが存在する。図6には、メインユーザが操作する通信端末200において行われるゲーム処理と、サブユーザが操作する通信端末200において行われるゲーム処理とを分けて記載している。サブユーザは1人だけでなく複数であることが好ましい。1人のサブユーザは1つの通信端末200を操作する。ただし、サブユーザは、上記構成を有する通信端末200の代わりに、ゲーム処理システム1にアクセス可能な通信機能付きの任意の装置を用いていてもよい。
まず、メインユーザの通信端末200の制御部208は、メインユーザからコマンドの入力を受け付ける(ステップS601)。コマンドは、メインユーザの操作対象であるユーザキャラクタに所望の行動を取らせるための指示である。コマンドには、例えば複数のフロアがあるダンジョンを冒険するゲームにおいて、ユーザ、又は、ユーザキャラクタの移動方向や移動位置、動作内容等を指示するコマンド、具体的には、「前へ進む」コマンド、「見ている向きを変える」コマンド、「1階から2階へ上がる」コマンド、「武器を装備する」コマンド、などがある。
通信端末200の制御部208は、受け付けたコマンドをゲーム処理装置100に送信する(ステップS602)。ゲーム処理装置100の制御部101は、通信端末200からコマンドを受信する(ステップS603)。受信されたコマンドはFIFO型の処理キューに登録される。本実施形態では、この処理キューに登録した時刻が、コマンドの確定時刻であり、サブユーザによる投票を受け付ける投票期間の起算時刻となる。
ここで、ゲーム処理装置100は、受信したコマンドの内容を記事サーバ400に通知し、記事サーバ400は、通知されたコマンドの内容をウェブページに掲載してもよい。この場合、ウェブページを閲覧できるすべてのサブユーザは、メインユーザがいつどのようなコマンドを出したのか、あるいはメインユーザのゲームの現在の状況がどうなっているのかを逐次把握できるようになる。
図7に、記事サーバ400によって公開されるウェブページの例を示す。メインユーザが出したコマンドの内容や、発生したイベントなどが、時系列順に並んで掲載されるので、閲覧者は、ゲーム展開を容易に把握することができる。このウェブページは、ゲーム処理装置100によって実行されるゲームに登録しているユーザだけでなく、ゲームに登録していない一般ユーザも閲覧することができる。例えば、記事サーバ400によって公開される記事をフォロー(購読)している任意のユーザは、メインユーザがプレイしているゲームの進捗状況を逐次把握することができる。
また、記事には、ゲームに未登録のサブユーザが簡単にゲームに登録できるように誘導する広告701が含まれる。フォローしているサブユーザであって、未登録のサブユーザが、投稿された記事を閲覧することにより、ゲームに興味を抱きゲームに参加してくれる可能性が増す。
次に、ゲーム処理装置100の制御部101は、受信したコマンドに基づいて、仮想空間において発生させるイベントの内容、そのイベントを発生させる時刻、サブユーザから投票を受け付ける選択肢の内容、投票期間を決定する(ステップS604)。制御部101は、決定したイベント内容とイベント発生時刻と選択肢の内容と投票期間を、記事サーバ400に通知する。なお、制御部101は、少なくとも選択肢の内容を記事サーバ400に通知すればよく、イベント内容とイベント発生時刻と投票期間を通知しなくてもよい。
本実施形態では、制御部101は、上述したように、イベント発生時刻を、コマンドが確定されてからイベントあるいはコマンドに予め対応付けられた時間の経過後の時刻とする。あるいは、制御部101は、イベント発生時刻を、イベントやコマンドの具体的な内容にかかわらず、所定の時間の経過後の時刻としてもよい。さらには、制御部101は、イベントを発生させる時刻を、コマンドが確定された時刻にかかわらず、所定の時刻としてもよい。また、制御部101は、コマンドが確定された時刻を投票開始時刻とし、イベントを発生させる時刻を投票終了時刻とする。この投票開始時刻から投票終了時刻までが、投票期間である。
次に、記事サーバ400は、イベントの内容とイベントの発生時刻と選択肢の内容と投票期間をゲーム処理装置100から受信すると、サブユーザから投票を受け付ける旨、および、投票可能な選択肢を、ウェブページに掲示し、投票の受け付けを開始する(ステップS605)。ゲーム処理システム1は、投票処理を実行する(ステップS606)。
図8に、記事サーバ400によって公開されるウェブページの構成を示す。例えば、メインユーザがコマンド「洞窟に入る」コマンドを入力すると、ウェブページには、メインユーザから出されたコマンドを示す記事801とともに、コマンドを入力したことにより発生するイベント「モンスターに遭遇した!」と、そのイベントにおける選択肢「(a)戦おう」と「(b)逃げよう」が提示される。それぞれの選択肢にはURIが対応付けられており、サブユーザがいずれかの選択肢を選ぶと、選ばれた選択肢に対応付けられているURIに通信端末200がアクセスする。このアクセスが、選択肢への投票となる。本図には、イベント内容と選択肢の内容のみ記載されているが、イベントの発生時刻と投票期間も合わせて明示してもよい。
ここで、サブユーザによる投票の際に行われる投票処理の詳細について、図9を用いて詳しく説明する。
記事サーバ400によって公開されたウェブページを閲覧したサブユーザは、タッチパネル226を操作して、提示された選択肢を示すボタンあるいはリンクの中からいずれか1つを押す。通信端末200の制御部208は、通信端末200の固有の識別情報と共に投票のリクエストを集計サーバ300に送信する(ステップS901)。固有の識別情報は、例えば、MACアドレス、電話番号、筐体に固有の製造番号などである。
あるイベントにおける投票をリクエストすると、投票に使われる通信端末200には、集計サーバ300から固有のセッションIDが付与される。制御部208は、過去に投票を行ったことがある場合には、過去に発行されたセッションIDと共にリクエストを送信する。制御部208は、過去に投票を行ったことがない場合には、セッションIDが付与されていないので、セッションIDを送信しない。
集計サーバ300は、投票のリクエストを受信すると、リクエストを送信した通信端末200に既にセッションIDが発行済みか否かを判別する(ステップS902)。
セッションIDを発行済みの場合(ステップS902;YES)、集計サーバ300はステップS904の処理に移る。セッションIDを発行済みでない場合(ステップS902;NO)、集計サーバ300は、セッションIDを発行し(ステップS903)、通信端末200の識別情報と対応付けてセッションIDを保存する。集計サーバ300は、この保存したセッションIDのリストを検索すれば、通信端末200に対してセッションIDが発行済みか否かを判別することができる。
なお、集計サーバ300は、通信端末200に対し、イベントごとにセッションIDを発行する。集計サーバ300は、異なるイベントにおける投票の際には、異なるセッションIDを通信端末200に発行する。
集計サーバ300は、ステップS903で新たに発行したセッションID、もしくは、ステップS901でリクエストと共に送信されたセッションIDを、通信端末200に送信する(ステップS904)。通信端末200の制御部208は、セッションIDを受信する(ステップS905)。制御部208は、受信したセッションIDをRAM207の不揮発性メモリ領域もしくは外部メモリ225に保存する(ステップS906)。
セッションIDが付与された通信端末200の制御部208は、投票内容、すなわちサブユーザによって選択された選択肢を示す情報を、集計サーバ300へ送信する(ステップS907)。集計サーバ300は、投票内容を通信端末200から受信し(ステップS908)、セッションIDと対応付けて投票内容を記憶部に保存する(ステップS909)。
集計サーバ300もしくは記事サーバ400は、サブユーザによって選択された選択肢を示す情報を通信端末200から受信すると、その応答として、投票を受け付けた旨、及び/又は、ゲームへの参加を促すメッセージや広告を含むデータを通信端末200に送信してもよい。そして、通信端末200の制御部207は、受信したメッセージや広告を含むデータを再生し、サブユーザに提示してもよい。
このように、投票処理では、通信端末200に付与したセッションIDによって投票が管理されるので、同じ通信端末200によって2回以上投票された場合には、セッションIDが同じのため、最後の投票によって投票内容が上書きされる。したがって、同一ユーザが同一端末を使って何度も投票できるといったことはない。
なお、集計サーバ300は、投票のリクエストがあった通信端末200にセッションIDを既に付与しており、付与したセッションIDと対応付けて投票内容を記憶部に既に保存している場合には、投票済みである旨を通信端末200に通知して重複した投票を受け付けないようにしてもよい。これにより、集計サーバ300は、同じ通信端末200によって2回以上投票された場合に、最初の投票のみ有効とし、2回目以降の投票を無効にすることができる。
図6に戻り、集計サーバ300は、決定された投票期間が終わったか否かを判別する(ステップS607)。
投票期間がまだ終わっていない場合(ステップS607;NO)、集計サーバ300は、投票期間が終わるまで、投票を受け付ける。一方、投票期間が終わった場合(ステップS607;YES)、集計サーバ300は、投票の受け付けを終了し、投票を集計する(ステップS608)。集計サーバ300は、各選択肢への投票数を計算し、計算された各投票数を示す選択情報をゲーム処理装置100に送信する。
なお、投票期間が終わると、集計サーバ300は、投票期間が終わった旨を示す記事を掲載するように記事サーバ400に要求してもよい。記事サーバ400は、投票期間が終わった旨をウェブページに掲載してもよい。
ゲーム処理装置100の制御部101は、投票結果を示す選択情報を受信すると、仮想世界にイベントを発生させ(ステップS609)、選択情報に基づいてゲームを進行させ、ゲームパラメータを更新する(ステップS610)。
例えば、制御部101は、ステップS604で決定したとおりに、イベント「モンスターに遭遇する」を発生させる。投票の結果、第1の選択肢「(a)モンスターと戦おう」と第2の選択肢「(b)モンスターから逃げよう」のうち、第1の選択肢への投票数が第2の選択肢への投票数より多い場合、制御部101は、ユーザキャラクタとモンスターを戦わせ、ゲームパラメータを変化させる。一方、第1の選択肢への投票数が第2の選択肢への投票数より少ない場合、制御部101は、ユーザキャラクタとモンスターを戦わせないで、ゲームパラメータを変化させる。ゲームは、投票数が多かった選択肢が示す展開で進むことになる。
なお、いずれの選択肢への投票数も同じであった場合には、制御部101は、いずれかの選択肢をランダムに選択してもよいし、投票期間を延長してステップS606〜S608の処理を行っても良い。
メインユーザが操作する通信端末200からアクセスがあると(ステップS611)、ゲーム処理装置100の制御部101は、ステップS609で発生させたイベントと、投票結果に基づいて実行された処理内容(これらを総称して「イベント結果」という。)を、アクセスのあった通信端末200に送信する(ステップS612)。通信端末200の制御部208は、イベント結果を受信し(ステップS613)、ディスプレイ224に表示する(ステップS614)。
図10に、ゲーム画面の構成例を示す。制御部208は、武器を変更するボタン1001、防具を変更するボタン1002、所持しているアイテムを表示するボタン1003などのソフトウェアボタンのほか、ゲームの進行を表すログ1004を表示する。ログ1004には、発生したイベントの内容やそのイベントの発生時刻などが時系列順に表示される。通信端末200の制御部208は、ゲームへのログイン後、最新のゲームパラメータをゲーム処理装置100から取得して、これらを表示する。
例えば、メインユーザがステップS601においてコマンドを入力した後に一旦ゲームから退出(ログオフ)した後、再びゲームに入り(ログイン)、ログイン時にイベントが既に発生していれば、サブユーザによる投票を反映して進行したゲーム内容が通信端末200に表示される。メインユーザは、ログオフの間、ゲームを“放置”しておき、自動的にゲームを進行させることができる。メインユーザは、一日中ログインしていなくても、お昼休み、休憩時間、帰宅後などのちょっとした短い時間を利用して、ゲームのプレイを継続することができる。
制御部101は、投票したサブユーザにもイベント結果を通知する。すなわち、制御部101は、ゲームパラメータを更新すると、イベント結果をサブユーザの通信端末200に送信する(ステップS612)。サブユーザの通信端末200の制御部208は、イベント結果を受信し(ステップS615)、ディスプレイ224に表示する(ステップS616)。
制御部101は、イベント結果をサブユーザの通信端末200に直接送信する代わりに、イベント結果を記載した記事をウェブページに掲載してもよい。そして、サブユーザの通信端末200が記事サーバ400にアクセスして最新の記事を取得すると、イベント結果を含む記事をディスプレイ224に表示してもよい。
図11に、記事サーバ400によって公開されるウェブページの構成を示す。ウェブページには、投票結果を示す記事1101、投票結果を反映したイベントを示す記事1102、更新されたゲームパラメータを示す記事1103などが含まれる。投票したサブユーザは、ゲームに参加していなくても、自分が投票した後のゲーム進行を逐次閲覧することができる。サブユーザは、メインユーザがプレイするゲームに投票という形で関与できる。
ゲーム処理システム1は、以上のゲーム処理を繰り返し実行し、ゲームを進行させる。メインユーザは、プレイ中に常にゲーム処理装置100にアクセスする必要はなく、コマンドの入力後にログオフしてゲームを“放置”しても自動でゲームが進行するので、少ない時間でより手軽にゲームを楽しむことができる。また、サブユーザは、メインユーザがプレイしているゲームに投票によって影響を及ぼすことができ、自分も一緒にゲームをプレイしているという感覚を楽しむことができる。
(実施形態2)
次に、本発明のその他の実施形態について説明する。上記実施形態では、メインユーザがコマンドの送信後に一旦ログオフしてゲームから離れ、イベントの発生後に再びログインしてゲームに復帰することを想定している。しかし、メインユーザがコマンドの送信後もログオフせずにゲームを続ける可能性もある。本実施形態では、コマンド送信後からイベント発生前までにメインユーザがゲームにアクセスすることを考慮している。
本実施形態では、ゲーム処理装置100の制御部101は、メインユーザによるコマンドの受信後、直ちにイベントの内容とイベントの発生時刻と投票開始時刻とを決定する代わりに、メインユーザによるコマンドの受信後に更に所定の放置指令を受信した場合、もしくは、メインユーザによるコマンドが受信されず所定の放置指令があったとみなした場合に、イベントの内容とイベントの発生時刻と投票開始時刻とを決定する。所定の放置指令とは、典型的には、通信端末200とゲーム処理装置100との間の通信のセッションを切るコマンド(ログオフコマンド)である。
制御部101は、メインユーザからの指示情報が放置指令であれば、メインユーザからの指示情報が所定の閾期間以上受け付けられることはないと判別する。そして、制御部101は、イベントの内容とイベントの発生時刻と投票開始時刻とを決定する。この場合の投票開始時刻は、例えば、放置指令がゲーム処理装置100によって受信された時刻である。
あるいは、制御部101は、最後に指示情報を受信してから所定時間以上新たな指示情報を受信しなかった場合に、放置指令があったとみなし、メインユーザからの指示情報が閾期間以上受け付けられることはないと判別してもよい。すなわち、所定時間以上コマンドが受信されなければ、ユーザがゲームを放置していると推測されてもよい。この場合の投票開始時刻は、放置指令があったとゲーム処理装置100によって見なされた時刻、言い換えれば、最後に指示情報を受信してから所定時間が経過した時点の時刻である。
さらには、制御部101は、最後にゲーム処理装置100にアクセスがあってから所定時間以上通信がなかった場合に、放置指令があったとみなし、メインユーザからの指示情報が閾期間以上受け付けられることはないと判別してもよい。すなわち、ユーザがコマンドを出さなくても、少なくとも「最新の状態に表示を更新する(リロードする)」指示をすれば、放置指令を出したとは見なされないが、所定時間以上リロードもしなければ、セッションタイムアウトし、放置指令を出したと見なされる。
また、制御部101は、放置指令を受信した時刻あるいは放置指令があったとみなした時刻を投票開始時刻とする代わりに、放置指令を受信した時刻あるいは放置指令があったとみなした時刻から所定時間経過後や、放置指令を受信した時刻あるいは放置指令があったとみなした時刻より後であって所定の条件が満たされた時刻等を、投票開始時刻としてもよい。
そして、制御部101は、放置指令を受信するか、もしくは放置指令があったと見なすと、放置指令を受信した時刻、もしくは放置指令があったと見なした時刻から、所定の閾期間が経過するまでは、新たな指示情報を通信端末200から受信しても、その指示情報を無視する。メインユーザは、ゲーム処理装置100により放置指令が受信された時刻(ログオフした時刻)、もしくは、ゲーム処理装置100により放置指令があったと見なされた時刻から、所定の閾期間が経過するまでは、新たなコマンドを出すことはできない。
なお、制御部101は、この閾期間の長さを、投票開始時刻から投票終了時刻までの期間(すなわち投票期間)の長さと一致させてもよい。メインユーザは、投票処理が終了した後に、新たなコマンドを出すことができる。投票終了時刻をイベント発生時刻と一致させる場合には、メインユーザは、投票処理が終了し、且つ、イベントが発生した後に、新たなコマンドを出すことができる。
本実施形態によれば、メインユーザは、ゲーム処理装置100にアクセスし続けてゲームのプレイを続けることもできるし、一旦ゲームから離れて自動でゲームを進行させることもできる。メインユーザがコマンドを出していれば、もしくはメインユーザがゲーム処理装置100にアクセスし続けていれば、自分が思ったとおりにゲームを進めることができるし、ログオフすれば、もしくは長時間放置すれば、サブユーザによる投票によってゲームを進めることができる。
(実施形態3)
次に、本発明のその他の実施形態について説明する。本実施形態では、メインユーザはコマンドを出した後も引き続きゲームをプレイでき、また、サブユーザは出されたコマンドに応じて発生するイベントにおけるいずれかの選択肢への投票を行える。
メインユーザによるコマンドがゲーム処理装置100に送信されると、上述のように、ゲーム処理装置100の制御部101は、受信したコマンドに対応するイベントの内容とそのイベントの発生時刻と投票期間を決定する。しかし、メインユーザがログオフせずに引き続きゲームをプレイすると、決定後に更に受信したコマンドによってゲームが進行していき、イベントを発生させる予定だった頃にはそのイベントを発生させられない可能性がある。
例えば、ゲーム処理装置100は、メインユーザの通信端末200からコマンド「ユーザキャラクタを街Xから街Yへ移動させる」を時刻T1に受信すると、そのコマンドに対応するイベント「街Yで商人Zに出会う」を時刻T2に発生させることを決定する。ゲーム処理装置100は、決定したイベントに対応する3つの選択肢「(a)武器を買う」と「(b)防具を買う」と「(c)何も買わない」を決定して記事サーバ400に通知する。記事サーバ400はこれら3つの選択肢をウェブページに掲載し、時刻T1から時刻T2の間、集計サーバ300はサブユーザによる投票を受け付ける。しかし、メインユーザが時刻T1以降もゲームを続け、異なるコマンド「移動をキャンセルする」を出すと、時刻T2にはユーザキャラクタは街Yにいないことになり、先に決定したイベント「街Yで商人Zに出会う」と矛盾してしまう。
そこで、ゲーム処理装置100の制御部101は、イベントを発生させる旨の先の決定を破棄し、イベントを発生させない。また、制御部101は、集計サーバ300から投票結果を受信すると、受信した投票結果を破棄する。つまり、イベントを発生させる旨が決定されてからイベント発生時刻までの間に、メインユーザからの指示情報が受け付けられ、その指示情報によって仮想世界の状態が更新されると、決定されたイベントは発生せず、受け付けられたサブユーザによる投票結果は無視され、ゲームには反映されない。したがって、ユーザキャラクタが街Yにいないにもかかわらず街Yの商人に出会う、といった矛盾するイベントは起こらない。
なお、制御部101は、イベントの内容とイベントの発生時刻と投票期間を決定後、新たに指示情報を受け付けた場合には、サブユーザによる投票を中止する旨を集計サーバ300に通知し、集計サーバ300は、この通知以降の投票を受け付けないようにしてもよい。
同様に、制御部101は、サブユーザによる投票を中止する旨を記事サーバ400に通知し、記事サーバ400は、投票の受け付けを終了した旨をウェブページに掲載してもよい。記事サーバ400は、各選択肢に対応付けているURIを削除し、URIが指定していた集計サーバ300のリソースにアクセスできないようにすることが望ましい。
本発明は、上述した実施形態に限定されず、種々の変形及び応用が可能である。また、上述した実施形態の各構成要素を自由に組み合わせることも可能である。
上記各実施形態では、ゲーム処理装置100の制御部101は、コマンドが処理キューに登録された時刻を投票開始時刻としているが、実際にコマンドに対応する内部処理を実行した時点としてもよい。
あるいは、ゲーム処理装置100の制御部101は、コマンドに対応する内部処理を実行してから所定の猶予時間が経過した時刻を、投票開始時刻としてもよい。メインユーザが入力したコマンドを後からキャンセルできるゲームの場合には、この猶予時間を設けるとよい。
ゲーム処理装置100の制御部101は、サブユーザによる投票結果をゲームパラメータに反映させる際、投票総数に応じて、ゲームパラメータの変化量を調整してもよい。例えば、制御部101は、サブユーザによる投票総数が多いほど、メインユーザ(もしくはメインユーザに対応付けられるユーザキャラクタ)に付与する報酬を多くしてもよい。報酬には、例えば、メインユーザもしくはユーザキャラクタに対応付けられる仮想通貨やアイテムなどがある。メインユーザは、より多くのサブユーザに投票してもらうためにこのゲームを広めようとするので、より多くのユーザにゲームを周知させることができる。ゲーム処理システム1は、多くのユーザの興味を惹き、ゲームへの参加を促すことができる。
ゲーム処理装置100の制御部101は、サブユーザによる投票総数を、メインユーザに対応付けられるゲームパラメータの一つとし、例えばメインユーザのプロフィール画面に表示してもよい。制御部101は、投票総数の代わりに、Aランク、Bランクなど、投票総数に応じた称号をユーザもしくはユーザキャラクタに付与してもよい。メインユーザは、より高い称号を得るためにこのゲームを広めようとするので、より多くのユーザにゲームを周知させることができる。
ゲーム処理装置100の制御部101は、投票したサブユーザに特典を与えてもよい。例えば、制御部101は、投票したサブユーザが既にゲームに登録したユーザであれば、このゲーム内で自由に使える仮想通貨等のアイテムを配布してもよい。
また、ゲーム処理システム1の運営会社が複数の異なるゲームを含むゲームサイトを運営している場合には、投票したサブユーザがいずれかのゲームに登録したユーザであれば、ゲームサイト内で自由に使える仮想通貨等のアイテムを配布してもよい。
上記各実施形態では、ゲーム処理システム1の中に記事サーバ400を設けているが、記事サーバ400は、ゲーム処理システム1にアクセス可能な既存のSNSサーバであってもよい。具体的には、記事サーバ400に掲載された選択肢を含む記事を見たサブユーザがいずれかの選択肢を選択すると、SNSサーバは、サブユーザの通信端末200をSNSの正規ユーザであることを認証するための認証ページに誘導(リダイレクト)し、サブユーザに認証を受けさせる。SNSサーバは、サブユーザから入力されたユーザ名とパスワードが、予め登録されたユーザ名とパスワードと一致すると、正規のユーザであると判別し、投票を受け付けるページへアクセスするための鍵となるデータ(アクセストークン)を通信端末200に送信する。アクセストークンを受信した通信端末200の制御部208は、投票するためのAPI(Application Programming Interface)を呼び出し、実行する。このようにすれば、ゲームシステム10の運営者は、既存の外部SNSを利用することにより、記事サーバ400を自前で設置しなくて済む。
ゲーム処理装置100、通信端末200、集計サーバ300、記事サーバ400の全部又は一部としてコンピュータを動作させるためのプログラムを、メモリカード、CD−ROM、DVD、MO(Magneto Optical disk)などのコンピュータ読み取り可能な記録媒体に格納して配布し、これを別のコンピュータにインストールし、上述の手段として動作させ、あるいは、上述の工程を実行させてもよい。
さらに、インターネット上のサーバ装置が有するディスク装置等にプログラムを格納しておき、例えば搬送波に重畳させて、コンピュータにダウンロード等するものとしてもよい。
以上説明したように、本発明によれば、より多くのユーザが気軽にゲームに参加できるようにするために好適なゲーム処理装置、ゲーム処理装置の制御方法、ならびに、プログラムを提供することができる。