JP2014064638A - ゲーム処理装置、ゲーム処理装置の制御方法、ならびに、プログラム - Google Patents

Abstract

【課題】より多くのユーザが気軽にゲームに参加できるようにする。
【解決手段】指示受付手段５０１は、メインユーザからの指示情報を受け付ける。更新手段５０３は、メインユーザからの指示情報が受け付けられると、受け付けられたメインユーザからの指示情報に基づいて、仮想世界の状態を更新する。決定手段５０４は、仮想世界の状態から、仮想世界に将来生ずるイベントと、イベントが発生する発生時刻と、発生時刻より以前の開始時刻とを決定する。選択受付手段５０５は、決定された開始時刻から、決定された発生時刻まで、１人以上のサブユーザからの選択情報を受け付ける。そして、決定された発生時刻に決定されたイベントが発生すれば、更新手段５０３は、受け付けられた選択情報に基づいて、仮想世界の状態を更新する。
【選択図】図５

Description

本発明は、より多くのユーザが気軽にゲームに参加できるようにするために好適なゲーム処理装置、ゲーム処理装置の制御方法、ならびに、プログラムに関する。

多機能型携帯電話機や通信機能付きのポータブルゲーム機が普及するに連れ、これらの通信端末を使ってユーザが気軽に楽しむことができる、いわゆるソーシャルゲームが普及している。ソーシャルゲームには、他のユーザとのコミュニケーションを楽しみつつ、例えば、カードを集めたり農場やキャラクターなどを育成したりするものがある。

一方で、同じゲームをプレイしているユーザ達の投票によって進行が変わるゲームが、例えば特許文献１に提案されている。

特開２０１１−１５６３９６号公報

しかしながら、従来技術によれば、投票ができるユーザはゲームに既に参加しているユーザに限定されているため、未だそのゲームにプレイヤとしては参加していないユーザにとっては、敷居が高い仕様となっていた。また、未参加のユーザに、そのゲームの存在を知得させるとともに、未参加のユーザがゲームの進行に影響を与えられるようにし、未参加ユーザの興味を惹き、ゲームへの参加を促したいという要望があった。

本発明はこのような課題を解決するものであり、より多くのユーザが気軽にゲームに参加できるようにするために好適なゲーム処理装置、ゲーム処理装置の制御方法、ならびに、プログラムを提供することを目的とする。

以上の目的を達成するため、本発明の原理にしたがって、下記の発明を開示する。

本発明の第１の観点に係るゲーム処理装置は、指示受付手段、更新手段、決定手段、選択受付手段を備える。
指示受付手段は、メインユーザからの指示情報を受け付ける。
更新手段は、メインユーザからの指示情報が受け付けられると、当該受け付けられたメインユーザからの指示情報に基づいて、仮想世界の状態を更新する。
決定手段は、仮想世界の状態に基づいて、仮想世界に将来生ずるイベントと、当該イベントが発生する発生時刻と、当該発生時刻より以前の開始時刻と、を、決定する。
選択受付手段は、決定された開始時刻から、決定された発生時刻まで、１人以上のサブユーザからの選択情報を受け付ける。
そして、決定された発生時刻に、仮想世界において決定されたイベントが発生すれば、更新手段は、受け付けられた１人以上のサブユーザからの選択情報に基づいて、仮想世界の状態を更新する。

ゲーム処理装置においては、例えば、仮想世界に配置されるユーザキャラクタにメインユーザがコマンドを与えて行動させるゲームが行われる。メインユーザからのコマンドが受け付けられると、受け付けられたコマンドに基づいて、ユーザキャラクタに対応付けられるゲームパラメータが更新される。

コマンドが受け付けられると、受け付けられたコマンドに応じて、将来発生するイベントの内容と、そのイベントの発生時刻と、メインユーザ以外の他のユーザ（サブユーザ）からの投票を受け付ける投票開始時間とが決定される。また、決定されたイベントに応じて、そのイベント時にどのように仮想世界を進行させるかを示す複数の選択肢が用意される。これらの選択肢は、未だこの仮想世界に参加していないサブユーザにも提示される。サブユーザは、いずれかの選択肢を選んで投票することができる。サブユーザは、投票開始時刻からイベント発生時刻までの間、自由に投票できる。

決定されたイベント発生時刻になると、決定されたイベントが仮想世界に発生する。そして、サブユーザによる投票結果に基づいて、仮想世界が進行する。メインユーザは、コマンドを出してから投票結果が決まるまでの間、ゲームを離れていていてもよく、ゲームが自動的に進行する。また、仮想世界に未だ登録していないサブユーザは、メインユーザがプレイしているゲームに、登録しなくても、投票という形で関与することができる。本発明によれば、メインユーザがゲームをプレイできるだけでなく、サブユーザもゲームに影響を及ぼすことができ、メインユーザとサブユーザが一緒にプレイしているかのようにゲームを楽しむことができる。また、未参加のユーザの興味を惹き、ゲームへの参加を促すことができる。そして、より多くのユーザが気軽にゲームに参加できるようになる。

決定手段は、メインユーザからの指示情報が閾期間以上受け付けられることはない、と判別すると、イベントと、発生時刻と、開始時刻と、を決定してもよい。

つまり、メインユーザがコマンドを閾期間以上出さないと推定される場合に、イベントの内容と、そのイベントの発生時刻と、サブユーザによる投票が受け付けられる開始時刻が決定されてもよい。本発明によれば、コマンドが受け付けられた後に直ちにイベント内容等が決定されるのではなく、メインユーザがゲームから暫く離れると推定される場合にイベント内容等が決定されるので、イベント内容の決定のやり直しが発生しづらくなり、ゲーム処理装置による処理が効率良くなる。

メインユーザからの指示情報が所定の放置指令であれば、決定手段は、メインユーザからの指示情報が閾期間以上受け付けられることはない、と判別してもよい。

つまり、メインユーザが暫くの間コマンドを出さない旨の放置指示を出した場合に、イベントの内容と、そのイベントの発生時刻と、サブユーザによる投票が受け付けられる開始時刻が決定されてもよい。本発明によれば、コマンドが受け付けられた後に直ちにイベント内容等が決定されるのではなく、メインユーザがゲームから暫く離れる場合にイベント内容等が決定されるので、イベント内容の決定のやり直しが発生しづらくなり、ゲーム処理装置による処理が効率良くなる。

所定の放置指令が受け付けられて以後、閾時間が経過するまでは、更新手段は、受け付けられたメインユーザからの指示情報を無視してもよい。

つまり、コマンドを出してから閾時間が経過するまでは、メインユーザは新たなコマンドを出すことはできない。本発明によれば、イベント内容の決定のやり直しが発生しづらくなり、ゲーム処理装置による処理が効率良くなる。

決定手段による決定から決定された発生時刻までの間にメインユーザからの指示情報が受け付けられ、仮想世界の状態が更新されることによって、決定された発生時刻に、仮想世界において決定されたイベントが発生しなければ、更新手段は、受け付けられた１人以上のサブユーザからの選択情報を無視してもよい。

つまり、メインユーザがコマンドを出したことによりイベント内容が決定された後、さらに別のコマンドが出されることによって、現在のゲーム進行と先に決定したイベントとの間に矛盾が生じる場合には、先に決定したイベントを発生させないこととし、サブユーザによる投票結果も破棄される。本発明によれば、メインユーザは、コマンドを出し続けて仮想世界を進行させることもできるし、暫くゲームから離れてサブユーザによる投票によって自動的に仮想世界を進行させることもできる。

決定された開始時刻に、１人以上のサブユーザが選択可能な複数の選択肢と、当該複数の選択肢のそれぞれを識別する情報を含むＵＲＩ(Universal Resource Identifier)と、が指定された記事が、記事サーバに投稿され、１人以上のサブユーザの各サブユーザがＵＲＩに示される集計サーバにアクセスすると、当該各サブユーザにより選択された選択肢が当該ＵＲＩに含まれる情報から識別されてもよい。

つまり、サブユーザにはＵＲＩが対応付けられた選択肢が提示され、サブユーザの指示によりいずれかのＵＲＩにアクセスがあると、そのアクセスが選択肢への投票となる。本発明によれば、サブユーザによる投票が簡素化される。

記事サーバと、集計サーバと、の、いずれか一方もしくは双方は、ゲーム処理装置と通信可能な外部の情報処理装置により実現されてもよい。

本発明によれば、仮想世界の進行と、選択肢の提示と、選択結果の集計とがそれぞれ別の装置によって行われるので、処理の分散化が図られる。

記事サーバと、集計サーバと、の、いずれか一方もしくは双方は、ゲーム処理装置により実現されてもよい。

本発明によれば、仮想世界の進行と、選択肢の提示と、選択結果の集計とが１つの装置によって行われるので、仮想世界の全体の管理が容易くなる。

決定手段は、イベントが発生する発生時刻を、ゲーム処理装置において過去にサブユーザから受け付けた選択情報の統計に基づいて、決定してもよい。

本発明によれば、イベントの発生時刻は、いつも決まった時刻になるのではなく、過去の投票活動の実績に基づいて決まるので、仮想世界の進行が多様化される。また、サブユーザによる投票が多すぎたり少なすぎたりしないように調整することができる。

決定手段は、選択受付手段が受け付けた選択情報の数が所定の最低投票数に満たない場合には、投票期間を延長してもよい。

本発明によれば、投票期間は固定ではなく可変になり、少人数の意見にのみ展開が左右されることはない。

本発明のその他の観点に係るゲーム処理装置の制御方法は、指示受付手段、更新手段、決定手段、選択受付手段を有するゲーム処理装置において実行される制御方法であって、指示受付ステップと更新ステップと決定ステップと選択受付ステップとを備える。
指示受付ステップでは、指示受付手段が、メインユーザからの指示情報を受け付ける。
更新ステップでは、更新手段が、メインユーザからの指示情報が受け付けられると、当該受け付けられたメインユーザからの指示情報に基づいて、仮想世界の状態を更新する。
決定ステップでは、決定手段が、仮想世界の状態に基づいて、仮想世界に将来生ずるイベントと、当該イベントが発生する発生時刻と、当該発生時刻より以前の開始時刻と、を、決定する。
選択受付ステップでは、選択受付手段が、決定された開始時刻から、決定された発生時刻まで、１人以上のサブユーザからの選択情報を受け付ける。
そして、決定された発生時刻に、仮想世界において前記決定されたイベントが発生すれば、更新ステップでは、更新手段が、受け付けられた前記１人以上のサブユーザからの選択情報に基づいて、仮想世界の状態を更新する。

本発明によれば、より多くのユーザがゲームに参加できるようになる。

本発明のその他の観点に係るプログラムは、コンピュータを、指示受付手段、更新手段、決定手段、選択受付手段として機能させる。
指示受付手段は、メインユーザからの指示情報を受け付ける。
更新手段は、メインユーザからの指示情報が受け付けられると、当該受け付けられたメインユーザからの指示情報に基づいて、仮想世界の状態を更新する。
決定手段は、仮想世界の状態に基づいて、仮想世界に将来生ずるイベントと、当該イベントが発生する発生時刻と、当該発生時刻より以前の開始時刻と、を、決定する。
選択受付手段は、決定された開始時刻から、決定された発生時刻まで、１人以上のサブユーザからの選択情報を受け付ける。
そして、決定された発生時刻に、仮想世界において決定されたイベントが発生すれば、更新手段は、受け付けられた１人以上のサブユーザからの選択情報に基づいて、仮想世界の状態を更新する。

本発明によれば、コンピュータを上述のゲーム処理装置として機能させることができる。

本発明のプログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、半導体メモリ等のコンピュータ読取可能な情報記憶媒体に記録することができる。
上記プログラムは、プログラムが実行されるコンピュータとは独立して、コンピュータ通信網を介して配布・販売することができる。また、上記情報記憶媒体は、コンピュータとは独立して配布・販売することができる。

本発明によれば、より多くのユーザが気軽にゲームに参加できるようにするために好適なゲーム処理装置、ゲーム処理装置の制御方法、ならびに、プログラムを提供することができる。

ゲーム処理システムの概要を示す図である。 ゲーム処理装置のハードウェア構成を示す図である。 通信端末のハードウェア構成を示す図である。 通信端末の外観を示す図である。 ゲーム処理装置の機能的な構成を示す図である。 ゲーム処理の流れを説明するための図である。 記事サーバによって公開されるウェブページの構成例を示す図である。 記事サーバによって公開されるウェブページの構成例を示す図である。 投票処理の流れを説明するための図である。 ゲーム画面の構成例を示す図である。 記事サーバによって公開されるウェブページの構成例を示す図である。

（実施形態１）
以下に本発明の実施形態を説明する。実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。

まず、本実施形態のゲーム処理システム１の全体の概要について説明する。図１に示すように、ゲーム処理システム１は、ゲーム処理装置１００と、ユーザが使用する通信端末２００（本図中では２００Ａ，２００Ｂ，２００Ｃなどと記載）と、後述する投票を受け付けて集計する集計サーバ３００と、記事の投稿を受け付けて記事を公開する記事サーバ４００とを備え、これらは通信ネットワーク５０によって繋がれている。通信ネットワーク５０は、典型的にはインターネットである。

本実施形態のゲーム処理装置１００は、複数のユーザがそれぞれ通信端末２００を使ってアクセス可能な仮想空間内におけるゲームを実行する。本実施形態において行われるゲームは、ユーザからの指示に基づいてユーザキャラクタが仮想空間内のダンジョンなどを冒険する、いわゆるRPG(ロールプレイングゲーム)を題材としたソーシャルゲームである。ゲーム内では、ユーザキャラクタが他のキャラクターに遭遇したりアイテムを取得したりする様々なイベントが発生する。ゲーム処理装置１００はゲームの進行を制御する。ゲーム処理装置１００は、通信端末２００から受信した指示に基づいてユーザキャラクタを行動させ、イベントを発生させて各ユーザキャラクタに対応付けられるゲームパラメータを変化させる。ゲームパラメータには、例えば、ユーザキャラクタが所有する仮想通貨やアイテム数を示すパラメータやユーザキャラクタの攻撃力、防御力を示すパラメータなどがある。

通信端末２００はユーザによって操作される。本実施形態では、通信端末２００は多機能型携帯電話機である。通信端末２００は、通信機能を有するポータブルゲーム装置や、タブレット型の端末、パーソナルコンピューターなどでも良い。ユーザは、通信端末２００を操作して、ゲーム処理装置１００において実行されるゲームへの指示を入力する。ユーザは、自分のユーザキャラクタへのコマンドを入力する。

ユーザは、メインユーザとサブユーザに分けられる。メインユーザは、通信端末２００を操作してゲーム処理装置１００にアクセスし、ゲーム処理装置１００によって制御されているゲームをプレイするユーザである。サブユーザは、ゲーム処理装置１００によって制御されるゲームをプレイしているか否かにかかわらず、記事サーバ４００と集計サーバ３００にアクセスできるユーザである。Ｎ人（Ｎは２以上の整数）がゲームに参加しているとき、第１の通信端末２００を操作する第１のユーザから見て、自分自身がメインユーザであり、他のＮ−１人がサブユーザである。また、未だゲームに参加していないものの、記事サーバ４００と集計サーバ３００にアクセス可能であって、後述する投票に参加するユーザも、サブユーザである。

なお、メインユーザが通信ネットワーク５０内の予め利用登録したＳＮＳ（Social Networking Service）サーバを記事サーバ４００とし、この記事サーバ４００においてメインユーザが自身の友達に登録したユーザをサブユーザとしてもよい。

メインユーザは、ユーザ名とパスワードの設定を含むゲームへの参加登録を予め行っている。メインユーザは、予め設定したユーザ名（もしくは電子メールアドレスなどのＩＤ）とパスワードを入力して認証を受け、ゲーム処理装置１００に接続（ログイン）し、ユーザキャラクタに対するコマンドを入力する。メインユーザがコマンドを入力すると、コマンドが確定されてから所定時間経過後に、ゲーム内イベントが発生する。コマンドが確定されてから所定時間が経過するまで（イベントが発生するまで）、メインユーザは、コマンドを入力しなくてもよく、放置していてよい。放置している間、メインユーザは、ゲームにログインしたままでもよいし、ログアウトしてもよい。

本実施形態では、コマンドが確定するタイミングは、コマンドがゲーム処理装置１００によって受信され、ゲーム処理装置１００によって行われる処理のキューに登録された時点である。ただし、後述するように、コマンドが確定するタイミングはこれだけに限られない。

サブユーザには、コマンドが確定されてから所定時間が経過するまでの間、メインユーザのゲームに反映させることができる、今後のゲーム展開に影響を与えるいくつかの選択肢が提示される。集計サーバ３００は、コマンドが確定されてから所定時間経過するまでの間、各選択肢に対するサブユーザからの投票を受け付ける。

例えば、ゲームに参加登録しているメインユーザが「ユーザキャラクタを街Ｘから街Ｙへ移動させる」コマンドを入力すると、ゲーム処理装置１００は、「ユーザキャラクタを街Ｘから街Ｙへ移動させる」旨のコマンドに対するいくつかの選択肢を設定し、記事サーバ４００に通知する。選択肢は、例えば、「（Ａ）遭遇したモンスターと戦う」「（Ｂ）遭遇したモンスターから逃げる」などである。サブユーザは、ゲームに登録していても登録していなくても、メインユーザがプレイしているゲームに、投票という形で関与できるわけである。

記事サーバ４００は、各選択肢の内容をインターネット上のウェブページに掲載する。掲載される記事は、ゲームに参加しているユーザだけでなく、ゲームに参加していないユーザも閲覧可能である。各選択肢にはＵＲＩ（Universal Resource Identifier）によるリンクが張られている。ＵＲＩは、集計サーバ３００内のリソースの場所を指す。例えば、第１の選択肢「（Ａ）遭遇したモンスターと戦う」に対応する第１のＵＲＩと、第２の選択肢「（Ｂ）遭遇したモンスターから逃げる」に対応する第２のＵＲＩがウェブページに掲載される。サブユーザが通信端末２００を操作して第１の選択肢を選択すると、通信端末２００は第１のＵＲＩにアクセスする。同様に、サブユーザが通信端末２００を操作して第２の選択肢を選択すると、通信端末２００は第２のＵＲＩにアクセスする。

集計サーバ３００は、投票期間中、サブユーザによる記事サーバ４００を経由したアクセスを受け付ける。記事サーバ４００に掲示されたＵＲＩへの１回のアクセスが１票となる。集計サーバ３００は、投票期間が終了すると、各選択肢へのアクセス数（投票数）を集計し、集計結果をゲーム処理装置１００に通知する。

ゲーム処理装置１００は、コマンドが確定されてから所定時間経過した後のイベント発生時刻に、ゲーム内イベントを発生させる。例えば、ゲーム処理装置１００は、「ユーザキャラクタを街Ｘから街Ｙへ移動させる」コマンドに対応するイベント「モンスターに遭遇する」を発生させる。そして、ゲーム処理装置１００は、発生させたイベントに従って、メインユーザのユーザキャラクタに対応付けられるゲームパラメータを変化させる。このとき、ゲーム処理装置１００は、集計サーバ３００から通知された集計結果、すなわちサブユーザによる投票結果を、メインユーザがプレイしているゲームに反映させる。

例えば、第１の選択肢への投票数が第２の投票数より多ければ、第１の選択肢「（Ａ）遭遇したモンスターと戦う」をゲームに反映させる。つまり、ゲーム処理装置１００は、「モンスターに遭遇する」イベントが発生すると、ユーザキャラクタとモンスターを戦闘させ、ゲームパラメータを変化させる。一方、第１の選択肢への投票数が第２の投票数より少なければ、第２の選択肢「（Ｂ）遭遇したモンスターから逃げる」をゲームに反映させる。つまり、ゲーム処理装置１００は、「モンスターに遭遇する」イベントが発生すると、ユーザキャラクタとモンスターを戦闘させずにゲームを進行させ、ゲームパラメータを変化させる。

発生したイベントによって変化されたゲームパラメータは、メインユーザの通信端末２００に通知される。例えば、メインユーザが「ユーザキャラクタを街Ｘから街Ｙへ移動させる」コマンドを入力した後に一旦ログアウトし、イベントの発生後に再びゲームにログインすると、イベント内容とイベント結果が通信端末２００に通知され、表示される。メインユーザは、表示されたイベント内容とイベント結果を見て、次のコマンドを入力する。ユーザは、コマンドを入力後、しばらく放置しておいてゲームの進行を待ち、次のログイン時もしくは所定時間の経過後に、ゲームの経過を見て楽しむわけである。なお、メインユーザがあるコマンドを入力後も引き続き他のコマンドを入力できてもよい。

また、サブユーザは、提示された選択肢への投票を行うことで、メインユーザがプレイするゲームに影響を与えることができる。特に、未だゲームに参加していないサブユーザには、投票できることを案内し、まずは投票することによってゲームを知ってもらい、ゲームへの関心をもってもらえるという宣伝効果が期待される。記事サーバ４００に投稿される記事は、既にゲームに参加しているメインユーザに限らず、未だゲームに参加していないユーザや、このゲームを知らないユーザにも公開されるので、より多くのユーザにゲームに関心をもってもらい、より多くのユーザに参加してもらえるように導くことができる。

なお、提示された選択肢への投票は、サブユーザだけでなく、メインユーザ自身が行うことができてもよい。また、本実施形態では、１つの通信端末２００からは、１つのイベントにつき１票のみ投じることができるものとし、同一の通信端末２００から複数回の投票が行われた場合には、最後の投票のみ有効となる。なお、同一の通信端末２００から複数回の投票が行われた場合に、最初の１回目の投票のみを有効とし、２回目以降の投票を無効とすることもできる。

本実施形態では、ゲーム処理システム１には、ゲーム処理装置１００と集計サーバ３００と記事サーバ４００が別々に設けられているが、これらが行う処理を１つあるいは２つの装置にまとめて処理させてもよい。

次に、ゲーム処理装置１００のハードウェア構成について説明する。図２に示すように、ゲーム処理装置１００は、制御部１０１、通信部１０２、記憶部１０３を備える。ゲーム処理装置１００は、メインフレームやワークステーションなどといった情報処理装置から構成される。

制御部１０１は、ＣＰＵ（Central Processing Unit）などから構成され、記憶部１０３に記憶されるオペレーティングシステム（ＯＳ）やプログラム等に従ってゲーム処理装置１００の各部を制御する。例えば、制御部１０１は、通信部１０２を制御して、ゲームの進行状態や結果などの情報を通信端末２００に送信する。

通信部１０２は、ＮＩＣ（Network Interface Card）やルータ、モデム、などといった所定の通信装置から構成される。通信部１０２は、制御部１０１の制御により、通信ネットワーク５０に接続された通信端末２００、集計サーバ３００、記事サーバ４００などと通信する。

記憶部１０３は、ワークエリアとなるＲＡＭ（Random Access Memory）などの記憶装置、ハードディスク装置やＲＯＭ（Read Only Memory）などといった記憶装置から構成される。例えば、記憶部１０３は、ゲーム処理装置１００全体を制御するためのプログラムやＯＳのほか、仮想空間内におけるゲームのパラメータなどを記憶する。

集計サーバ３００と記事サーバ４００のハードウェア構成は、ゲーム処理装置１００のハードウェア構成と同じであるので、詳しい説明は省略する。

次に、通信端末２００のハードウェア構成について説明する。図３に示すように、通信端末１００は、通信部２０１、音声処理部２０２、出力部２０３、外部インターフェース（Ｉ／Ｆ）２０４、入力受付部２０５、ＲＯＭ２０６、ＲＡＭ２０７、制御部２０８、電源部２０９を備える。

通信部２０１は、マイクロフォン２２３に入力され音声処理部２０２が備えるＡ／Ｄ（Analog/Digital）コンバータ（図示せず）により変換された音声信号を変調し、通信部２０１が備えるアンテナ２２１を用いて音声信号を通信相手に送信する。また、通信部２０１は、アンテナ２２１を用いて音声信号を受信して復調し、音声処理部２０２に入力する。音声信号は音声処理部２０２が備えるＤ／Ａ（Digital/Analog）コンバータ（図示せず）を用いて音声に変換され、スピーカー２２２から音声として出力される。通信部２０１は、通信端末２００のユーザから入力される様々な指示情報をゲーム処理装置１００に送信し、また、ゲーム処理装置１００から送信されるゲームパラメータや画像データ、音声データ等を受信する。

音声処理部２０２は、ユーザの発声音等をマイクロフォン２２３によって集音し、音声処理部２０２が備えるＡ／Ｄコンバータにより音声信号に変換して通信部２０１に入力する。また、音声処理部２０２は、音声処理部２０２が備えるＤ／Ａコンバータにより復調された通話音をスピーカー２２２から出力する。また、音声処理部２０２は、ゲーム処理装置１００にアクセスしてプレイするゲームの音声、効果音、音楽等を再生してスピーカー２２２から出力する。

出力部２０３は、制御部２０８や出力部２０３が備える画像演算プロセッサ（図示せず）によって画像データを加工処理した後、フレームバッファに記録する。フレームバッファに記録された画像情報は、垂直同期などの所定の同期タイミングで画像信号に変換され、例えばＬＣＤ（Liquid Crystal Display）のようなディスプレイ２２４に出力される。ディスプレイ２２４の表面には、ユーザによる接触の有無や位置を検知する複数のタッチセンサを備えたタッチパネル２２６が重畳して配置されている。なお、以下の説明において、ディスプレイ２２４とタッチパネル２２６を合わせて「タッチスクリーン」と言う。

外部Ｉ／Ｆ２０４は、着脱可能なＩＣカードやフラッシュメモリカード等の外部メモリ２２５と接続し、データの入出力を行う。例えば外部Ｉ／Ｆ２０４に接続される外部メモリ２２５には、通信端末２００の固有の情報（例えば、加入者番号、ネットワーク識別子など）などが記憶される。なお、これらの情報は、ＲＡＭ２０７のフラッシュメモリ領域など他の書き換え可能な記憶領域に記憶されてもよい。また、外部Ｉ／Ｆ２０４は、通信部２０１と制御部２０８の制御により、ＵＳＢ（Universal Serial Bus）接続によって通信端末２００と外部機器とを接続して、外部機器との間でデータの入出力を行うことができるインターフェースを備える。なお、外部Ｉ／Ｆ２０４は、その他の外部機器との接続を可能にするインターフェースを更に備えていてもよい。

入力受付部２０５は、タッチパネル２２６からの操作信号を受け付けて、操作信号に対応するキーコード信号を制御部２０８に入力する。制御部２０８は、入力されたキーコード信号に基づいて操作内容を決定する。ユーザは、タッチパネル２２６を用いて任意の文字データを入力したり所定の操作コマンドを入力したりすることができる。操作コマンドには、例えば、アプリケーションソフトウェア（以下「アプリケーション」という。）の起動や終了、電子ファイルの作成や保存、ゲームのアプリケーションにおけるユーザからのコマンドなどがある。

ＲＯＭ２０６は、通信端末２００の全体の制御に必要なオペレーティングシステム（ＯＳ）やプログラム等を予め記憶する不揮発性メモリである。

ＲＡＭ２０７は、制御部２０８が行う処理に必要なデータやプログラム等を一時的に記憶する。また、ＲＡＭ２０７の記憶領域の一部はフラッシュメモリから構成され、電話やメールに使用するアドレス帳、通話の履歴、ダウンロードしたデータ、各種機能の設定値等を記憶する。

制御部２０８は、ＲＯＭ２０６等に記憶されたＯＳや制御プログラムに従って、通信端末２００の全体の制御を行う。制御部２０８は、各部に制御信号およびデータを送信、または、各部から応答信号およびデータを受信する。また、制御部２０８は、通信端末２００の現在の時刻を計時する。なお、制御部２０８が実行する様々な処理の詳細は後述する。

電源部２０９は、通信端末２００を駆動させるためのバッテリーを備える。

本実施形態の通信端末２００は、図４に示すような多機能型携帯電話機である。タッチスクリーン２５０には、ユーザからの指示を受け付けるためのソフトウェアボタンなどが表示される。タッチスクリーン２５０のうちソフトウェアボタンの画像が表示された位置にユーザが指を接触させることを、簡単に「ボタンを選択する」「ボタンをタッチする」などと表現する。

通信端末２００は、タッチパネル２２６を用いた指示の入力をユーザから受け付けるほか、音声による指示入力をユーザから受け付けてもよい。制御部２０８は、マイクロフォン２２３により集音した音声データに音声認識処理を施し、音声認識結果からユーザによる指示入力を判別し、判別した指示入力に対応する処理を実行してもよい。

通信端末２００は、傾きを検出するジャイロセンサや、通信端末２００にかかる加速度を検出する加速度センサを更に備えてもよい。制御部２０８は、ジャイロセンサや加速度センサによる検出結果を解析し、解析結果からユーザによる指示入力を判別し、判別した指示入力に対応する処理を実行してもよい。

通信端末２００は、ハードウェアボタンを更に備え、タッチスクリーン２５０に表示されるソフトウェアボタンへのユーザ操作だけでなく、ハードウェアボタンへのユーザ操作を検出してもよい。制御部２０８は、押されたハードウェアボタンに予め対応付けられる処理を実行してもよい。

次に、本実施形態のゲーム処理装置１００の機能的な構成について説明する。図５に示すように、ゲーム処理装置１００は、指示受付手段５０１、パラメータ記憶手段５０２、更新手段５０３、決定手段５０４、選択受付手段５０５を備える。

指示受付手段５０１は、ユーザキャラクタへの指示を表す指示情報をメインユーザの通信端末２００から受け付ける。メインユーザは、自身の操作対象であるユーザキャラクタに、例えば「街Ｘから街Ｙへ移動する」「アイテム○○を購入する」など、様々な指示情報（コマンド）を、通信端末２００の入力受付部２０５を操作することにより入力する。通信端末２００の入力受付部２０５がユーザからコマンド入力を受け付けると、制御部２０８は、通信部２０１を制御して、受け付けた指示情報をゲーム処理装置１００に送信する。ゲーム処理装置１００の制御部１０１は、通信部１０２を制御して指示情報を通信端末２００から受信し、記憶部１０３に記憶し、受信した指示情報に対応する処理を実行する。制御部１０１と通信部１０２と記憶部１０３が協働して、指示受付手段５０１として機能する。

パラメータ記憶手段５０２は、ゲーム処理システム１によって行われる仮想世界のゲームの状態を表す変数、すなわちゲームパラメータを記憶する。ゲームパラメータには、例えば、ユーザキャラクタに対応付けられる仮想通貨の額、所有するアイテムの種類や数、ユーザキャラクタに対応付けられる攻撃値と防御値と体力値、キャラクター名、発生したイベントのログ、などがある。ただし、ゲームパラメータは、これらに限られず、ゲーム処理装置１００によって実行されるゲームに応じて適宜定義される。制御部１０１は、ゲームパラメータを随時更新可能である。制御部１０１と記憶部１０３が協働して、パラメータ記憶手段５０２として機能する。

更新手段５０３は、メインユーザからの指示情報（コマンド）が受け付けられると、受け付けられたメインユーザからの指示情報に基づいて、仮想世界の状態を表すゲームパラメータを更新する。また、更新手段５０３は、後述する選択受付手段５０５によって受け付けられた選択情報に基づいて、仮想世界の状態を表すゲームパラメータを更新する。制御部１０１と記憶部１０３が協働して、更新手段５０３として機能する。

例えば、指示情報の内容が「街Ｘから街Ｙへ移動する」の場合、制御部１０１は、ゲームパラメータのうちユーザキャラクタが現在いるエリアを表すパラメータに、“街Ｘから街Ｙへの道の途中”あるいは“街Ｙの中”を表す値を設定する。指示情報の内容がコマンド「仮想通貨を使ってアイテムを購入する」の場合、制御部１０１は、ゲームパラメータのうちユーザキャラクタに対応付けられる仮想通貨の総額から所定の額を差し引き、ゲームパラメータのうち所有アイテムを表すパラメータに購入したアイテムの情報を追加する。なお、指示情報の具体的な内容は、本発明によって限定されない。

選択情報は、後述する決定手段５０４により生成される選択肢の中からサブユーザがいずれか１つを選択した選択結果を示す情報である。

決定手段５０４は、パラメータ記憶手段５０２に記憶される仮想世界の状態を表す変数（ゲームパラメータ）に基づいて、この仮想世界に将来生じさせるイベント、このイベントを発生させるイベント発生時刻、この発生時刻より以前の投票開始時刻などを決定する。制御部１０１が、決定手段５０４として機能する。

例えば、制御部１０１は、ユーザキャラクタが存在するエリアを表すパラメータの値を“街Ｘの中”から“街Ｘから街Ｙへの道の途中”に変更すると、このパラメータ値に対応し且つこれから発生させるイベント「モンスターに遭遇する」を現実世界のある時刻に発生させる旨を、決定する。また、制御部１０１は、発生させるイベントに対応する複数の選択肢を生成し、サブユーザによる投票を受け付ける開始時刻を決定する。サブユーザが投票できる投票期間は、例えば、決定された投票開始時刻から、決定されたイベント発生時刻まで、の間である。ただし、投票期間は、イベント発生時刻と一致していなくてもよく、イベント発生時刻よりも前に終了してもよい。

ここで、制御部１０１によって決定される事項について詳しく説明する。制御部１０１は、（１）仮想世界に生じさせるイベントの内容、（２）発生させるイベントに対応する選択肢の内容、（３）イベント発生時刻、（４）投票開始時刻と投票終了時刻とで定義される投票期間を、それぞれ決定する。以下、順に説明する。

（１）イベントの内容の決定
制御部１０１は、イベントの内容を、受け付けられたコマンドに予め対応付けられた内容に、決定してもよい。受け付けられるコマンドと発生させるイベントとを対応付ける情報が記憶部１０３に予め記憶されており、制御部１０１は、この対応付けを参照して、発生させるイベントの内容を決定する。

制御部１０１は、予め用意された複数のイベントの内容の候補の中から１つの候補を選択し、発生させるイベントの内容としてもよい。例えば、制御部１０１は、コマンド「前へ進む」が受け付けられると、このコマンドに予め対応付けられているイベント「モンスターに遭遇する」、「宝物を見つける」、「罠にはまってしまう」などの中から、いずれか１つのイベントを選択する。

制御部１０１は、記憶部１０３に記憶されているゲームパラメータに基づいてイベントの内容を決定してもよい。記憶部１０３に記憶されているゲームパラメータは、直前に受け付けられたただ１つのコマンドにのみ基づくのではなく、これまでに受け付けられた複数の様々なコマンドによって形成される総合的な結果を表す。従って、制御部１０１は、過去のゲームの進行過程を反映させたイベントを発生させることができる。

制御部１０１は、メインユーザからの入力に基づいてイベントの内容を決定してもよい。例えば、制御部１０１は、入力されたコマンドに応じて、発生させることができるイベントの内容の候補をメインユーザに提示し、メインユーザが候補の中から１つを選び、選ばれた候補をイベントの内容に決定してもよい。

なお、制御部１０１は、コマンドが受け付けられる度に、ゲームパラメータが変化し得るイベントを常に発生させなければならないわけではなく、「何も起きない」というイベントを発生させてもよい。

（２）選択肢の内容の決定
制御部１０１は、選択肢の内容を、発生させるイベントに予め対応付けられた内容に決定してもよい。例えば、決定したイベントが「モンスターに遭遇する」であった場合、制御部１０１は、「モンスターに遭遇する」というイベントに予め対応付けられた２つの選択肢「（Ａ）モンスターと戦おう」と「（Ｂ）モンスターから逃げよう」を用意する。選択肢は３つ以上でもよいし、イベントに対応付けられた３つ以上の選択肢の候補から２つ以上の選択肢がサブユーザに提示されても良い。

制御部１０１は、選択肢の内容を、受け付けたコマンドに予め対応付けられた内容に決定してもよい。例えば、受け付けたコマンドが「キャラクターを街Ｘから街Ｙへ移動させる」であった場合、制御部１０１は、「キャラクターを街Ｘから街Ｙへ移動させる」というコマンドに予め対応付けられた２つの選択肢「（Ａ）遭遇したモンスターと戦う」と「（Ｂ）遭遇したモンスターから逃げる」を用意する。選択肢は３つ以上でもよいし、コマンドに対応付けられた３つ以上の選択肢の候補から２つ以上の選択肢がサブユーザに提示されても良い。

制御部１０１は、選択肢の内容を、ゲームパラメータに基づいて変化させてもよい。例えば、制御部１０１は、ユーザキャラクタの成長度を表すレベルが所定の基準より小さい（ユーザキャラクタが所定の基準より弱い）場合には２つの選択肢「（Ａ）遭遇したモンスターと戦う」と「（Ｂ）遭遇したモンスターから逃げる」を用意し、このレベルが所定の基準以上（ユーザキャラクタが所定の基準以上に強い）の場合には３つの選択肢「（Ａ）遭遇したモンスターと戦う」と「（Ｂ）遭遇したモンスターから逃げる」と「（Ｃ）遭遇したモンスターを仲間にする」を用意する。メインユーザのゲームのやり込み度が高いと選択肢を多様化させることにより、メインユーザのゲームへの興味が増し、継続的なプレイが期待できる。

なお、制御部１０１は、レベルが所定の基準より小さい場合には２つの選択肢「（Ａ）遭遇したモンスターと戦う」と「（Ｂ）遭遇したモンスターから逃げる」を用意し、このレベルが所定の基準以上の場合には異なる２つの選択肢「（Ａ）遭遇したモンスターと戦う」と「（Ｃ）遭遇したモンスターを仲間にする」を用意してもよい。選択肢の数は固定でもよいし、可変でもよい。

（３）イベント発生時刻の決定
制御部１０１は、イベント発生時刻を、イベントの内容にかかわらず、投票開始時刻から所定時間経過後に設定してもよい。例えば、制御部１０１は、この所定時間を“３時間”などの固定値に設定する。そして、制御部１０１は、メインユーザから入力されるコマンドが第１の時刻に確定すると、この第１の時刻を投票開始時刻とし、第１の時刻から所定時間経過した第２の時刻を、イベント発生時刻にする。

制御部１０１は、イベント発生時刻を、投票開始時刻からイベントごとに異なる長さの時間の経過後の時刻に設定してもよい。例えば、制御部１０１は、イベントごとに異なった時間長をそれぞれ予め対応付けておく。そして、制御部１０１は、メインユーザから入力されるコマンドが第１の時刻に確定すると、この第１の時刻を投票開始時刻とし、決定されたイベントに対応付けられた第１の時間長を第１の時刻に加算して得られる第２の時刻を、イベント発生時刻にする。制御部１０１は、異なるイベントを発生させる場合、コマンドの確定時刻に、この異なるイベントに対応付けられた第２の時間長を加算した第３の時刻を、イベント発生時刻にする。

制御部１０１は、イベント毎ではなくコマンド毎に異なった時間長をそれぞれ予め対応付けておき、上述と同様に、入力されたコマンドに対応付けられる時間長を投票開始時刻に加算した時刻を、イベント発生時刻に決定しても良い。

制御部１０１は、イベント発生時刻を、固定時刻に設定してもよい。制御部１０１は、例えば毎日１７時００分００秒にイベントを発生させる、といったように、イベント発生時刻を予め決めておく。そして、制御部１０１は、メインユーザから入力されるコマンドが第１の時刻に確定すると、この第１の時刻を投票開始時刻とし、第１の時刻より後であって最初に訪れる固定時刻を、イベント発生時刻にする。

メインユーザがイベント発生時刻を決定できるようにしてもよい。すなわち、制御部１０１は、メインユーザの通信端末２００からイベント発生時刻を示す指示情報を受け付け、メインユーザと対応付けてイベント発生時刻を記憶部１０３に記憶し、設定する。ただし、ユーザが指定できるイベント発生時刻は、コマンドが確定する時刻よりも後である。メインユーザがイベント発生時刻を指定できるようにすれば、投票期間が例えば深夜や早朝あるいは勤務時間帯になってしまってサブユーザが投票できなかったりサブユーザに迷惑をかけたりする可能性が小さくなる。

制御部１０１は、イベント発生時刻を、過去の他のイベントにおける投票数や過去に投票された時刻などの統計値に基づいて、決定してもよい。すなわち、集計サーバ３００は、例えば直近の１ヶ月などのような、ある期間におけるサブユーザによる投票活動の実績の統計を取り、統計データを記憶部１０３に保存する。統計データは、具体的には、同一メインユーザが行うゲームの他のイベントにおける、最終的な投票総数、時間帯ごとの投票総数、などである。統計を取る統計期間は任意である。また、制御部１０１は、同一メインユーザだけでなく、ゲーム処理装置１００によって行われるすべてのメインユーザのゲームに起きたイベントにおける投票の統計を取ってもよい。

制御部１０１は、記憶部１０３に保存した統計データから過去に投票された時間を取得し、１時間毎などの時間帯に分けて投票総数を集計する。１時間毎であれば２４個の時間帯毎の投票総数の分布が得られる。そして、制御部１０１は、最も投票数が多い時間帯に、イベント発生時刻を設定してもよい。このようにすれば、投票期間はサブユーザが投票することが多い傾向にある時間帯に設定されるので、より多くのサブユーザに投票してもらえ、より多くのサブユーザにこのゲームへの関心をもたせることができる。定義される時間帯は１時間毎に限られず、Ｎ分毎（Ｎは１以上の整数）、曜日毎などでもよい。

制御部１０１は、過去に投票された時間に基づいてイベント毎の投票総数の分布を取得し、発生させるイベントにおける最も投票総数が多い時間帯に、イベント発生時刻を設定してもよい。

制御部１０１は、コマンドの受信後、所定の条件が満たされた時刻、もしくは所定の条件が満たされた時刻から所定時間が経過した時刻を、イベント発生時刻に決定してもよい。例えば、制御部１０１は、コマンドをキャンセルできる期間が設けられている場合において、「コマンドのキャンセルが無かったこと」を所定の条件にすることができる。制御部１０１は、この所定の条件を任意に設定することができる。

（４）投票期間の決定
制御部１０１は、コマンドが確定した時刻を、投票開始時刻に決定してもよい。受信されたコマンドは、制御部１０１が管理するＦＩＦＯ（First In First Out）型の処理キューに登録され、順次実行される。典型的には、この処理キューにコマンドが登録された時刻が、コマンドが確定した時刻である。

制御部１０１は、投票開始時刻を、固定時刻に設定してもよい。制御部１０１は、例えば毎日１７時００分００秒に投票の受け付けを開始する、といったように、投票開始時刻を予め決めておく。そして、制御部１０１は、メインユーザから入力されるコマンドが確定した時刻より後であって最初に訪れる固定時刻を、投票開始時刻にする。

投票終了時刻についても同様に、制御部１０１は、投票終了時刻を、固定時刻に設定してもよい。

制御部１０１は、メインユーザの通信端末２００から投票開始時刻を示す指示情報を受け付け、メインユーザと対応付けて投票開始時刻を記憶部１０３に記憶し、記憶部１０３に記憶したこの投票開始時刻を用いてもよい。ただし、ユーザが指定できる投票開始時刻は、コマンドが確定する時刻よりも後であり、且つ、イベント発生時刻よりも前である。

投票終了時刻についても同様に、制御部１０１は、メインユーザの通信端末２００から投票終了時刻を示す指示情報を受け付け、メインユーザと対応付けて投票終了時刻を記憶部１０３に記憶し、記憶部１０３に記憶したこの投票終了時刻を用いてもよい。ただし、ユーザが指定できる投票終了時刻は、コマンドが確定する時刻よりも後であり、且つ、イベント発生時刻よりも前であり、且つ、投票開始時刻よりも後である。

制御部１０１は、コマンドの受信後、所定の条件が満たされた時刻を、投票開始時刻に決定してもよい。例えば、制御部１０１は、コマンドをキャンセルできる期間が設けられている場合において、「コマンドのキャンセルが無かったこと」を所定の条件にすることができる。制御部１０１は、この所定の条件を任意に設定することができる。

投票終了時刻についても同様に、制御部１０１は、所定の条件が満たされた時刻を投票終了時刻に決定してもよい。例えば、制御部１０１は、投票できる上限の数を設け、「投票総数が上限値に達したこと」を所定の条件にすることができる。制御部１０１は、この所定の条件を任意に設定することができる。

制御部１０１は、投票開始時刻及び／又は投票終了時刻を、ランダムな時刻に決定してもよい。

制御部１０１は、投票期間を、他のイベントにおける投票数や過去に投票された時刻などの統計値に基づいて、決定してもよい。すなわち、上述したように、集計サーバ３００は、例えば直近の１ヶ月などのような、ある期間におけるサブユーザによる投票活動の実績の統計を取る。統計を取る統計期間は任意である。同一ユーザだけでなく、ゲーム処理装置１００によって行われるすべてのユーザのゲームに起きたイベントにおける投票の統計でもよい。

そして、制御部１０１は、過去に投票された時間に基づいてイベント毎の投票総数の分布を取得し、設定したイベントに対応する投票総数が少ないほど投票期間を長く設定し、設定したイベントに対応する投票総数が多いほど投票期間を短く設定してもよい。

制御部１０１は、投票期間中に受け付けた投票数が、設定したイベント発生時刻を含む時間帯における投票総数の統計値以上の場合にはイベント発生時刻に投票期間を終了させ、統計値未満の場合には投票期間を延長してもよい。

また、制御部１０１は、投票期間を複数に分けて設定してもよい。例えば、制御部１０１は、１回目の投票期間を時刻Ｔ１から時刻Ｔ２まで設定し、２回目の投票期間を時刻Ｔ２より後の時刻Ｔ３から時刻Ｔ４まで設定する。

制御部１０１は、複数の投票期間を設定し、各投票期間中に投票できるサブユーザを限定してもよい。例えば、制御部１０１は、１回目の投票期間をメインユーザとフレンド登録したサブユーザのみ投票できる期間とし、２回目の投票期間をすべてのサブユーザが投票できる期間とする。

なお、制御部１０１は、投票開始時刻、投票終了時刻、イベント発生時刻を、現実世界の時刻を用いて決めても良いし、仮想世界に定義される仮想の時刻を用いて決めても良い。

次に、選択受付手段５０５は、決定手段５０４によって決定された投票開始時刻から、決定手段５０４によって決定されたイベント発生時刻までのサブユーザからの選択肢への投票の結果を示す選択情報を受け付ける。受け付けられた選択情報は、パラメータ記憶手段５０２に記憶される。制御部１０１と通信部１０２が協働して、選択受付手段５０５として機能する。

本実施形態では、サブユーザによる投票の受け付けは、記事サーバ４００と集計サーバ３００によって行われる。投票を受け付ける旨は記事サーバ４００に投稿される記事によって公開される。投票は、集計サーバ３００によって集計される。選択受付手段５０５は、集計された投票結果を表す選択情報を集計サーバ３００から受け付ける。

投票終了時刻は、イベント発生時刻より前であってもよい。すなわち、制御部１０１は、投票終了時刻から所定時間が経過した後にイベントを発生させることとし、イベント発生時刻よりこの所定時間だけ前に投票終了時刻を設定してもよい。

選択受付手段５０５によって受け付けられた選択情報は、仮想世界の状態を表すゲームパラメータを変化させるために用いられる。すなわち、制御部１０１は、決定したイベント発生時刻に、決定したイベントを発生させると、受け付けた選択情報に基づいて、仮想世界の状態を表すゲームパラメータを更新する。

例えば、制御部１０１は、メインユーザからのコマンド「キャラクターを街Ｘから街Ｙへ移動させる」が受け付けられると、このコマンドに対応する第１の選択肢「（Ａ）遭遇したモンスターと戦う」と第２の選択肢「（Ｂ）遭遇したモンスターから逃げる」を生成する。制御部１０１は、生成した２つの選択肢を記事サーバ４００に送信する。制御部１０１は、コマンドに対応するイベント「モンスターに遭遇する」を、決定した時刻に発生させる。

一方、記事サーバ４００は、コマンドが確定されてからイベントが発生するまでの間、受信した選択肢を、それぞれの選択肢に対応付けたＵＲＩと共にウェブページに掲載し、サブユーザからの投票を受け付ける。選択肢の数は、２つ以上の任意の数である。ＵＲＩは集計サーバ３００内のリソースの場所を指しており、集計サーバ３００は、各ＵＲＩへの１回のアクセスを１票として扱う。集計サーバ３００は、各ＵＲＩへのアクセス数を集計し、集計結果をゲーム処理装置１００に送信する。

ゲーム処理装置１００の制御部１０１は、設定した選択肢のうち、最も投票数が多かった選択肢に基づいてゲームを進行させ、ゲームパラメータを更新する。

例えば、制御部１０１は、第１の選択肢「（Ａ）遭遇したモンスターと戦う」への投票数が、第２の選択肢「（Ｂ）遭遇したモンスターから逃げる」への投票数よりも多い場合には、決定したイベントを発生させ、ユーザキャラクタをモンスターと戦わせるように制御し、ゲームパラメータを更新する。一方、第１の選択肢「（Ａ）遭遇したモンスターと戦う」への投票数が、第２の選択肢「（Ｂ）遭遇したモンスターから逃げる」への投票数よりも少ない場合には、決定したイベントを発生させ、ユーザキャラクタをモンスターと戦わずに逃げるように制御し、ゲームパラメータを更新する。

制御部１０１は、集計サーバ３００から受信した集計結果が所定の条件を満たさない場合、投票期間を延長したり投票をやり直したりしてもよい。例えば、制御部１０１は、投票結果が有効か無効かの判定ラインとなる最低投票数を設け、すべての選択肢への投票総数が最低投票数に達しない場合、サブユーザが投票できる投票期間を延長してもよい。延長期間は固定値でもよいし可変値でもよい。あるいは、制御部１０１は、投票総数が最低投票数に達するまで、投票期間を延長してもよい。投票期間を延長した場合には、制御部１０１は、イベントの発生時刻を、延長された投票期間の満了後に設定すればよい。これにより、ごく少数の投票によってゲームが左右されてしまい面白味に欠けるといった事態を防ぐことができる。

次に、本実施形態のゲーム処理システム１によって行われるゲーム処理の流れについて、図６等を用いて説明する。図６には、ゲーム処理装置１００と記事サーバ４００と集計サーバ３００において行われる処理をまとめて「サーバ側のゲーム処理」と記載している。上述のように、ユーザには、仮想世界のゲームをプレイしコマンドを入力するメインユーザと、入力されたコマンドを受けて提示される選択肢の中から投票できるサブユーザとが存在する。図６には、メインユーザが操作する通信端末２００において行われるゲーム処理と、サブユーザが操作する通信端末２００において行われるゲーム処理とを分けて記載している。サブユーザは１人だけでなく複数であることが好ましい。１人のサブユーザは１つの通信端末２００を操作する。ただし、サブユーザは、上記構成を有する通信端末２００の代わりに、ゲーム処理システム１にアクセス可能な通信機能付きの任意の装置を用いていてもよい。

まず、メインユーザの通信端末２００の制御部２０８は、メインユーザからコマンドの入力を受け付ける（ステップＳ６０１）。コマンドは、メインユーザの操作対象であるユーザキャラクタに所望の行動を取らせるための指示である。コマンドには、例えば複数のフロアがあるダンジョンを冒険するゲームにおいて、ユーザ、又は、ユーザキャラクタの移動方向や移動位置、動作内容等を指示するコマンド、具体的には、「前へ進む」コマンド、「見ている向きを変える」コマンド、「１階から２階へ上がる」コマンド、「武器を装備する」コマンド、などがある。

通信端末２００の制御部２０８は、受け付けたコマンドをゲーム処理装置１００に送信する（ステップＳ６０２）。ゲーム処理装置１００の制御部１０１は、通信端末２００からコマンドを受信する（ステップＳ６０３）。受信されたコマンドはＦＩＦＯ型の処理キューに登録される。本実施形態では、この処理キューに登録した時刻が、コマンドの確定時刻であり、サブユーザによる投票を受け付ける投票期間の起算時刻となる。

ここで、ゲーム処理装置１００は、受信したコマンドの内容を記事サーバ４００に通知し、記事サーバ４００は、通知されたコマンドの内容をウェブページに掲載してもよい。この場合、ウェブページを閲覧できるすべてのサブユーザは、メインユーザがいつどのようなコマンドを出したのか、あるいはメインユーザのゲームの現在の状況がどうなっているのかを逐次把握できるようになる。

図７に、記事サーバ４００によって公開されるウェブページの例を示す。メインユーザが出したコマンドの内容や、発生したイベントなどが、時系列順に並んで掲載されるので、閲覧者は、ゲーム展開を容易に把握することができる。このウェブページは、ゲーム処理装置１００によって実行されるゲームに登録しているユーザだけでなく、ゲームに登録していない一般ユーザも閲覧することができる。例えば、記事サーバ４００によって公開される記事をフォロー（購読）している任意のユーザは、メインユーザがプレイしているゲームの進捗状況を逐次把握することができる。

また、記事には、ゲームに未登録のサブユーザが簡単にゲームに登録できるように誘導する広告７０１が含まれる。フォローしているサブユーザであって、未登録のサブユーザが、投稿された記事を閲覧することにより、ゲームに興味を抱きゲームに参加してくれる可能性が増す。

次に、ゲーム処理装置１００の制御部１０１は、受信したコマンドに基づいて、仮想空間において発生させるイベントの内容、そのイベントを発生させる時刻、サブユーザから投票を受け付ける選択肢の内容、投票期間を決定する（ステップＳ６０４）。制御部１０１は、決定したイベント内容とイベント発生時刻と選択肢の内容と投票期間を、記事サーバ４００に通知する。なお、制御部１０１は、少なくとも選択肢の内容を記事サーバ４００に通知すればよく、イベント内容とイベント発生時刻と投票期間を通知しなくてもよい。

本実施形態では、制御部１０１は、上述したように、イベント発生時刻を、コマンドが確定されてからイベントあるいはコマンドに予め対応付けられた時間の経過後の時刻とする。あるいは、制御部１０１は、イベント発生時刻を、イベントやコマンドの具体的な内容にかかわらず、所定の時間の経過後の時刻としてもよい。さらには、制御部１０１は、イベントを発生させる時刻を、コマンドが確定された時刻にかかわらず、所定の時刻としてもよい。また、制御部１０１は、コマンドが確定された時刻を投票開始時刻とし、イベントを発生させる時刻を投票終了時刻とする。この投票開始時刻から投票終了時刻までが、投票期間である。

次に、記事サーバ４００は、イベントの内容とイベントの発生時刻と選択肢の内容と投票期間をゲーム処理装置１００から受信すると、サブユーザから投票を受け付ける旨、および、投票可能な選択肢を、ウェブページに掲示し、投票の受け付けを開始する（ステップＳ６０５）。ゲーム処理システム１は、投票処理を実行する（ステップＳ６０６）。

図８に、記事サーバ４００によって公開されるウェブページの構成を示す。例えば、メインユーザがコマンド「洞窟に入る」コマンドを入力すると、ウェブページには、メインユーザから出されたコマンドを示す記事８０１とともに、コマンドを入力したことにより発生するイベント「モンスターに遭遇した！」と、そのイベントにおける選択肢「（ａ）戦おう」と「（ｂ）逃げよう」が提示される。それぞれの選択肢にはＵＲＩが対応付けられており、サブユーザがいずれかの選択肢を選ぶと、選ばれた選択肢に対応付けられているＵＲＩに通信端末２００がアクセスする。このアクセスが、選択肢への投票となる。本図には、イベント内容と選択肢の内容のみ記載されているが、イベントの発生時刻と投票期間も合わせて明示してもよい。

ここで、サブユーザによる投票の際に行われる投票処理の詳細について、図９を用いて詳しく説明する。

記事サーバ４００によって公開されたウェブページを閲覧したサブユーザは、タッチパネル２２６を操作して、提示された選択肢を示すボタンあるいはリンクの中からいずれか１つを押す。通信端末２００の制御部２０８は、通信端末２００の固有の識別情報と共に投票のリクエストを集計サーバ３００に送信する（ステップＳ９０１）。固有の識別情報は、例えば、ＭＡＣアドレス、電話番号、筐体に固有の製造番号などである。

あるイベントにおける投票をリクエストすると、投票に使われる通信端末２００には、集計サーバ３００から固有のセッションＩＤが付与される。制御部２０８は、過去に投票を行ったことがある場合には、過去に発行されたセッションＩＤと共にリクエストを送信する。制御部２０８は、過去に投票を行ったことがない場合には、セッションＩＤが付与されていないので、セッションＩＤを送信しない。

集計サーバ３００は、投票のリクエストを受信すると、リクエストを送信した通信端末２００に既にセッションＩＤが発行済みか否かを判別する（ステップＳ９０２）。

セッションＩＤを発行済みの場合（ステップＳ９０２；ＹＥＳ）、集計サーバ３００はステップＳ９０４の処理に移る。セッションＩＤを発行済みでない場合（ステップＳ９０２；ＮＯ）、集計サーバ３００は、セッションＩＤを発行し（ステップＳ９０３）、通信端末２００の識別情報と対応付けてセッションＩＤを保存する。集計サーバ３００は、この保存したセッションＩＤのリストを検索すれば、通信端末２００に対してセッションＩＤが発行済みか否かを判別することができる。

なお、集計サーバ３００は、通信端末２００に対し、イベントごとにセッションＩＤを発行する。集計サーバ３００は、異なるイベントにおける投票の際には、異なるセッションＩＤを通信端末２００に発行する。

集計サーバ３００は、ステップＳ９０３で新たに発行したセッションＩＤ、もしくは、ステップＳ９０１でリクエストと共に送信されたセッションＩＤを、通信端末２００に送信する（ステップＳ９０４）。通信端末２００の制御部２０８は、セッションＩＤを受信する（ステップＳ９０５）。制御部２０８は、受信したセッションＩＤをＲＡＭ２０７の不揮発性メモリ領域もしくは外部メモリ２２５に保存する（ステップＳ９０６）。

セッションＩＤが付与された通信端末２００の制御部２０８は、投票内容、すなわちサブユーザによって選択された選択肢を示す情報を、集計サーバ３００へ送信する（ステップＳ９０７）。集計サーバ３００は、投票内容を通信端末２００から受信し（ステップＳ９０８）、セッションＩＤと対応付けて投票内容を記憶部に保存する（ステップＳ９０９）。

集計サーバ３００もしくは記事サーバ４００は、サブユーザによって選択された選択肢を示す情報を通信端末２００から受信すると、その応答として、投票を受け付けた旨、及び／又は、ゲームへの参加を促すメッセージや広告を含むデータを通信端末２００に送信してもよい。そして、通信端末２００の制御部２０７は、受信したメッセージや広告を含むデータを再生し、サブユーザに提示してもよい。

このように、投票処理では、通信端末２００に付与したセッションＩＤによって投票が管理されるので、同じ通信端末２００によって２回以上投票された場合には、セッションＩＤが同じのため、最後の投票によって投票内容が上書きされる。したがって、同一ユーザが同一端末を使って何度も投票できるといったことはない。

なお、集計サーバ３００は、投票のリクエストがあった通信端末２００にセッションＩＤを既に付与しており、付与したセッションＩＤと対応付けて投票内容を記憶部に既に保存している場合には、投票済みである旨を通信端末２００に通知して重複した投票を受け付けないようにしてもよい。これにより、集計サーバ３００は、同じ通信端末２００によって２回以上投票された場合に、最初の投票のみ有効とし、２回目以降の投票を無効にすることができる。

図６に戻り、集計サーバ３００は、決定された投票期間が終わったか否かを判別する（ステップＳ６０７）。

投票期間がまだ終わっていない場合（ステップＳ６０７；ＮＯ）、集計サーバ３００は、投票期間が終わるまで、投票を受け付ける。一方、投票期間が終わった場合（ステップＳ６０７；ＹＥＳ）、集計サーバ３００は、投票の受け付けを終了し、投票を集計する（ステップＳ６０８）。集計サーバ３００は、各選択肢への投票数を計算し、計算された各投票数を示す選択情報をゲーム処理装置１００に送信する。

なお、投票期間が終わると、集計サーバ３００は、投票期間が終わった旨を示す記事を掲載するように記事サーバ４００に要求してもよい。記事サーバ４００は、投票期間が終わった旨をウェブページに掲載してもよい。

ゲーム処理装置１００の制御部１０１は、投票結果を示す選択情報を受信すると、仮想世界にイベントを発生させ（ステップＳ６０９）、選択情報に基づいてゲームを進行させ、ゲームパラメータを更新する（ステップＳ６１０）。

例えば、制御部１０１は、ステップＳ６０４で決定したとおりに、イベント「モンスターに遭遇する」を発生させる。投票の結果、第１の選択肢「（ａ）モンスターと戦おう」と第２の選択肢「（ｂ）モンスターから逃げよう」のうち、第１の選択肢への投票数が第２の選択肢への投票数より多い場合、制御部１０１は、ユーザキャラクタとモンスターを戦わせ、ゲームパラメータを変化させる。一方、第１の選択肢への投票数が第２の選択肢への投票数より少ない場合、制御部１０１は、ユーザキャラクタとモンスターを戦わせないで、ゲームパラメータを変化させる。ゲームは、投票数が多かった選択肢が示す展開で進むことになる。

なお、いずれの選択肢への投票数も同じであった場合には、制御部１０１は、いずれかの選択肢をランダムに選択してもよいし、投票期間を延長してステップＳ６０６〜Ｓ６０８の処理を行っても良い。

メインユーザが操作する通信端末２００からアクセスがあると（ステップＳ６１１）、ゲーム処理装置１００の制御部１０１は、ステップＳ６０９で発生させたイベントと、投票結果に基づいて実行された処理内容（これらを総称して「イベント結果」という。）を、アクセスのあった通信端末２００に送信する（ステップＳ６１２）。通信端末２００の制御部２０８は、イベント結果を受信し（ステップＳ６１３）、ディスプレイ２２４に表示する（ステップＳ６１４）。

図１０に、ゲーム画面の構成例を示す。制御部２０８は、武器を変更するボタン１００１、防具を変更するボタン１００２、所持しているアイテムを表示するボタン１００３などのソフトウェアボタンのほか、ゲームの進行を表すログ１００４を表示する。ログ１００４には、発生したイベントの内容やそのイベントの発生時刻などが時系列順に表示される。通信端末２００の制御部２０８は、ゲームへのログイン後、最新のゲームパラメータをゲーム処理装置１００から取得して、これらを表示する。

例えば、メインユーザがステップＳ６０１においてコマンドを入力した後に一旦ゲームから退出（ログオフ）した後、再びゲームに入り（ログイン）、ログイン時にイベントが既に発生していれば、サブユーザによる投票を反映して進行したゲーム内容が通信端末２００に表示される。メインユーザは、ログオフの間、ゲームを“放置”しておき、自動的にゲームを進行させることができる。メインユーザは、一日中ログインしていなくても、お昼休み、休憩時間、帰宅後などのちょっとした短い時間を利用して、ゲームのプレイを継続することができる。

制御部１０１は、投票したサブユーザにもイベント結果を通知する。すなわち、制御部１０１は、ゲームパラメータを更新すると、イベント結果をサブユーザの通信端末２００に送信する（ステップＳ６１２）。サブユーザの通信端末２００の制御部２０８は、イベント結果を受信し（ステップＳ６１５）、ディスプレイ２２４に表示する（ステップＳ６１６）。

制御部１０１は、イベント結果をサブユーザの通信端末２００に直接送信する代わりに、イベント結果を記載した記事をウェブページに掲載してもよい。そして、サブユーザの通信端末２００が記事サーバ４００にアクセスして最新の記事を取得すると、イベント結果を含む記事をディスプレイ２２４に表示してもよい。

図１１に、記事サーバ４００によって公開されるウェブページの構成を示す。ウェブページには、投票結果を示す記事１１０１、投票結果を反映したイベントを示す記事１１０２、更新されたゲームパラメータを示す記事１１０３などが含まれる。投票したサブユーザは、ゲームに参加していなくても、自分が投票した後のゲーム進行を逐次閲覧することができる。サブユーザは、メインユーザがプレイするゲームに投票という形で関与できる。

ゲーム処理システム１は、以上のゲーム処理を繰り返し実行し、ゲームを進行させる。メインユーザは、プレイ中に常にゲーム処理装置１００にアクセスする必要はなく、コマンドの入力後にログオフしてゲームを“放置”しても自動でゲームが進行するので、少ない時間でより手軽にゲームを楽しむことができる。また、サブユーザは、メインユーザがプレイしているゲームに投票によって影響を及ぼすことができ、自分も一緒にゲームをプレイしているという感覚を楽しむことができる。

（実施形態２）
次に、本発明のその他の実施形態について説明する。上記実施形態では、メインユーザがコマンドの送信後に一旦ログオフしてゲームから離れ、イベントの発生後に再びログインしてゲームに復帰することを想定している。しかし、メインユーザがコマンドの送信後もログオフせずにゲームを続ける可能性もある。本実施形態では、コマンド送信後からイベント発生前までにメインユーザがゲームにアクセスすることを考慮している。

本実施形態では、ゲーム処理装置１００の制御部１０１は、メインユーザによるコマンドの受信後、直ちにイベントの内容とイベントの発生時刻と投票開始時刻とを決定する代わりに、メインユーザによるコマンドの受信後に更に所定の放置指令を受信した場合、もしくは、メインユーザによるコマンドが受信されず所定の放置指令があったとみなした場合に、イベントの内容とイベントの発生時刻と投票開始時刻とを決定する。所定の放置指令とは、典型的には、通信端末２００とゲーム処理装置１００との間の通信のセッションを切るコマンド（ログオフコマンド）である。

制御部１０１は、メインユーザからの指示情報が放置指令であれば、メインユーザからの指示情報が所定の閾期間以上受け付けられることはないと判別する。そして、制御部１０１は、イベントの内容とイベントの発生時刻と投票開始時刻とを決定する。この場合の投票開始時刻は、例えば、放置指令がゲーム処理装置１００によって受信された時刻である。

あるいは、制御部１０１は、最後に指示情報を受信してから所定時間以上新たな指示情報を受信しなかった場合に、放置指令があったとみなし、メインユーザからの指示情報が閾期間以上受け付けられることはないと判別してもよい。すなわち、所定時間以上コマンドが受信されなければ、ユーザがゲームを放置していると推測されてもよい。この場合の投票開始時刻は、放置指令があったとゲーム処理装置１００によって見なされた時刻、言い換えれば、最後に指示情報を受信してから所定時間が経過した時点の時刻である。

さらには、制御部１０１は、最後にゲーム処理装置１００にアクセスがあってから所定時間以上通信がなかった場合に、放置指令があったとみなし、メインユーザからの指示情報が閾期間以上受け付けられることはないと判別してもよい。すなわち、ユーザがコマンドを出さなくても、少なくとも「最新の状態に表示を更新する（リロードする）」指示をすれば、放置指令を出したとは見なされないが、所定時間以上リロードもしなければ、セッションタイムアウトし、放置指令を出したと見なされる。

また、制御部１０１は、放置指令を受信した時刻あるいは放置指令があったとみなした時刻を投票開始時刻とする代わりに、放置指令を受信した時刻あるいは放置指令があったとみなした時刻から所定時間経過後や、放置指令を受信した時刻あるいは放置指令があったとみなした時刻より後であって所定の条件が満たされた時刻等を、投票開始時刻としてもよい。

そして、制御部１０１は、放置指令を受信するか、もしくは放置指令があったと見なすと、放置指令を受信した時刻、もしくは放置指令があったと見なした時刻から、所定の閾期間が経過するまでは、新たな指示情報を通信端末２００から受信しても、その指示情報を無視する。メインユーザは、ゲーム処理装置１００により放置指令が受信された時刻（ログオフした時刻）、もしくは、ゲーム処理装置１００により放置指令があったと見なされた時刻から、所定の閾期間が経過するまでは、新たなコマンドを出すことはできない。

なお、制御部１０１は、この閾期間の長さを、投票開始時刻から投票終了時刻までの期間（すなわち投票期間）の長さと一致させてもよい。メインユーザは、投票処理が終了した後に、新たなコマンドを出すことができる。投票終了時刻をイベント発生時刻と一致させる場合には、メインユーザは、投票処理が終了し、且つ、イベントが発生した後に、新たなコマンドを出すことができる。

本実施形態によれば、メインユーザは、ゲーム処理装置１００にアクセスし続けてゲームのプレイを続けることもできるし、一旦ゲームから離れて自動でゲームを進行させることもできる。メインユーザがコマンドを出していれば、もしくはメインユーザがゲーム処理装置１００にアクセスし続けていれば、自分が思ったとおりにゲームを進めることができるし、ログオフすれば、もしくは長時間放置すれば、サブユーザによる投票によってゲームを進めることができる。

（実施形態３）
次に、本発明のその他の実施形態について説明する。本実施形態では、メインユーザはコマンドを出した後も引き続きゲームをプレイでき、また、サブユーザは出されたコマンドに応じて発生するイベントにおけるいずれかの選択肢への投票を行える。

メインユーザによるコマンドがゲーム処理装置１００に送信されると、上述のように、ゲーム処理装置１００の制御部１０１は、受信したコマンドに対応するイベントの内容とそのイベントの発生時刻と投票期間を決定する。しかし、メインユーザがログオフせずに引き続きゲームをプレイすると、決定後に更に受信したコマンドによってゲームが進行していき、イベントを発生させる予定だった頃にはそのイベントを発生させられない可能性がある。

例えば、ゲーム処理装置１００は、メインユーザの通信端末２００からコマンド「ユーザキャラクタを街Ｘから街Ｙへ移動させる」を時刻Ｔ１に受信すると、そのコマンドに対応するイベント「街Ｙで商人Ｚに出会う」を時刻Ｔ２に発生させることを決定する。ゲーム処理装置１００は、決定したイベントに対応する３つの選択肢「（ａ）武器を買う」と「（ｂ）防具を買う」と「（ｃ）何も買わない」を決定して記事サーバ４００に通知する。記事サーバ４００はこれら３つの選択肢をウェブページに掲載し、時刻Ｔ１から時刻Ｔ２の間、集計サーバ３００はサブユーザによる投票を受け付ける。しかし、メインユーザが時刻Ｔ１以降もゲームを続け、異なるコマンド「移動をキャンセルする」を出すと、時刻Ｔ２にはユーザキャラクタは街Ｙにいないことになり、先に決定したイベント「街Ｙで商人Ｚに出会う」と矛盾してしまう。

そこで、ゲーム処理装置１００の制御部１０１は、イベントを発生させる旨の先の決定を破棄し、イベントを発生させない。また、制御部１０１は、集計サーバ３００から投票結果を受信すると、受信した投票結果を破棄する。つまり、イベントを発生させる旨が決定されてからイベント発生時刻までの間に、メインユーザからの指示情報が受け付けられ、その指示情報によって仮想世界の状態が更新されると、決定されたイベントは発生せず、受け付けられたサブユーザによる投票結果は無視され、ゲームには反映されない。したがって、ユーザキャラクタが街Ｙにいないにもかかわらず街Ｙの商人に出会う、といった矛盾するイベントは起こらない。

なお、制御部１０１は、イベントの内容とイベントの発生時刻と投票期間を決定後、新たに指示情報を受け付けた場合には、サブユーザによる投票を中止する旨を集計サーバ３００に通知し、集計サーバ３００は、この通知以降の投票を受け付けないようにしてもよい。

同様に、制御部１０１は、サブユーザによる投票を中止する旨を記事サーバ４００に通知し、記事サーバ４００は、投票の受け付けを終了した旨をウェブページに掲載してもよい。記事サーバ４００は、各選択肢に対応付けているＵＲＩを削除し、ＵＲＩが指定していた集計サーバ３００のリソースにアクセスできないようにすることが望ましい。

本発明は、上述した実施形態に限定されず、種々の変形及び応用が可能である。また、上述した実施形態の各構成要素を自由に組み合わせることも可能である。

上記各実施形態では、ゲーム処理装置１００の制御部１０１は、コマンドが処理キューに登録された時刻を投票開始時刻としているが、実際にコマンドに対応する内部処理を実行した時点としてもよい。

あるいは、ゲーム処理装置１００の制御部１０１は、コマンドに対応する内部処理を実行してから所定の猶予時間が経過した時刻を、投票開始時刻としてもよい。メインユーザが入力したコマンドを後からキャンセルできるゲームの場合には、この猶予時間を設けるとよい。

ゲーム処理装置１００の制御部１０１は、サブユーザによる投票結果をゲームパラメータに反映させる際、投票総数に応じて、ゲームパラメータの変化量を調整してもよい。例えば、制御部１０１は、サブユーザによる投票総数が多いほど、メインユーザ（もしくはメインユーザに対応付けられるユーザキャラクタ）に付与する報酬を多くしてもよい。報酬には、例えば、メインユーザもしくはユーザキャラクタに対応付けられる仮想通貨やアイテムなどがある。メインユーザは、より多くのサブユーザに投票してもらうためにこのゲームを広めようとするので、より多くのユーザにゲームを周知させることができる。ゲーム処理システム１は、多くのユーザの興味を惹き、ゲームへの参加を促すことができる。

ゲーム処理装置１００の制御部１０１は、サブユーザによる投票総数を、メインユーザに対応付けられるゲームパラメータの一つとし、例えばメインユーザのプロフィール画面に表示してもよい。制御部１０１は、投票総数の代わりに、Ａランク、Ｂランクなど、投票総数に応じた称号をユーザもしくはユーザキャラクタに付与してもよい。メインユーザは、より高い称号を得るためにこのゲームを広めようとするので、より多くのユーザにゲームを周知させることができる。

ゲーム処理装置１００の制御部１０１は、投票したサブユーザに特典を与えてもよい。例えば、制御部１０１は、投票したサブユーザが既にゲームに登録したユーザであれば、このゲーム内で自由に使える仮想通貨等のアイテムを配布してもよい。

また、ゲーム処理システム１の運営会社が複数の異なるゲームを含むゲームサイトを運営している場合には、投票したサブユーザがいずれかのゲームに登録したユーザであれば、ゲームサイト内で自由に使える仮想通貨等のアイテムを配布してもよい。

上記各実施形態では、ゲーム処理システム１の中に記事サーバ４００を設けているが、記事サーバ４００は、ゲーム処理システム１にアクセス可能な既存のＳＮＳサーバであってもよい。具体的には、記事サーバ４００に掲載された選択肢を含む記事を見たサブユーザがいずれかの選択肢を選択すると、ＳＮＳサーバは、サブユーザの通信端末２００をＳＮＳの正規ユーザであることを認証するための認証ページに誘導（リダイレクト）し、サブユーザに認証を受けさせる。ＳＮＳサーバは、サブユーザから入力されたユーザ名とパスワードが、予め登録されたユーザ名とパスワードと一致すると、正規のユーザであると判別し、投票を受け付けるページへアクセスするための鍵となるデータ（アクセストークン）を通信端末２００に送信する。アクセストークンを受信した通信端末２００の制御部２０８は、投票するためのＡＰＩ（Application Programming Interface）を呼び出し、実行する。このようにすれば、ゲームシステム１０の運営者は、既存の外部ＳＮＳを利用することにより、記事サーバ４００を自前で設置しなくて済む。

ゲーム処理装置１００、通信端末２００、集計サーバ３００、記事サーバ４００の全部又は一部としてコンピュータを動作させるためのプログラムを、メモリカード、ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ（Magneto Optical disk）などのコンピュータ読み取り可能な記録媒体に格納して配布し、これを別のコンピュータにインストールし、上述の手段として動作させ、あるいは、上述の工程を実行させてもよい。

さらに、インターネット上のサーバ装置が有するディスク装置等にプログラムを格納しておき、例えば搬送波に重畳させて、コンピュータにダウンロード等するものとしてもよい。

以上説明したように、本発明によれば、より多くのユーザが気軽にゲームに参加できるようにするために好適なゲーム処理装置、ゲーム処理装置の制御方法、ならびに、プログラムを提供することができる。

１ ゲーム処理システム
５０ 通信ネットワーク
１００ ゲーム処理装置
１０１ 制御部
１０２ 通信部
１０３ 記憶部
２００，２００Ａ，２００Ｂ，２００Ｃ 通信端末
２０１ 通信部
２０２ 音声処理部
２０３ 出力部
２０４ 外部Ｉ／Ｆ
２０５ 入力受付部
２０６ ＲＯＭ
２０７ ＲＡＭ
２０８ 制御部
２０９ 電源部
２２１ アンテナ
２２２ スピーカー
２２３ マイクロフォン
２２４ ディスプレイ
２２５ 外部メモリ
２２６ タッチパネル
２５０ タッチスクリーン
３００ 集計サーバ
４００ 記事サーバ
５０１ 指示受付手段
５０２ パラメータ記憶手段
５０３ 更新手段
５０４ 決定手段
５０５ 選択受付手段
７０１ 広告
８０１，８０２ 記事
１００１，１００２，１００３ ボタン
１００４ ログ
１１０１，１１０２，１１０３ 記事

Claims (12)

1. メインユーザからの指示情報を受け付ける指示受付手段と、
   前記メインユーザからの指示情報が受け付けられると、当該受け付けられた前記メインユーザからの指示情報に基づいて、仮想世界の状態を更新する更新手段と、
   前記仮想世界の状態に基づいて、前記仮想世界に将来生ずるイベントと、当該イベントが発生する発生時刻と、当該発生時刻より以前の開始時刻と、を、決定する決定手段と、
   前記決定された開始時刻から、前記決定された発生時刻まで、１人以上のサブユーザからの選択情報を受け付ける選択受付手段と、
   を備え、
   前記決定された発生時刻に、前記仮想世界において前記決定されたイベントが発生すれば、前記更新手段は、前記受け付けられた前記１人以上のサブユーザからの選択情報に基づいて、前記仮想世界の状態を更新する、
   ことを特徴とするゲーム処理装置。
2. 請求項１に記載のゲーム処理装置であって、
   前記決定手段は、前記メインユーザからの指示情報が閾期間以上受け付けられることはない、と判別すると、前記イベントと、前記発生時刻と、前記開始時刻と、を決定する、
   ことを特徴とするゲーム処理装置。
3. 請求項２に記載のゲーム処理装置であって、
   前記メインユーザからの指示情報が所定の放置指令であれば、前記決定手段は、前記メインユーザからの指示情報が閾期間以上受け付けられることはない、と判別する、
   ことを特徴とするゲーム処理装置。
4. 請求項３に記載のゲーム処理装置であって、
   前記所定の放置指令が受け付けられて以後、前記閾時間が経過するまでは、前記更新手段は、前記受け付けられた前記メインユーザからの指示情報を無視する、
   ことを特徴とするゲーム処理装置。
5. 請求項１に記載のゲーム処理装置であって、
   前記決定手段による決定から前記決定された発生時刻までの間に前記メインユーザからの指示情報が受け付けられ、前記仮想世界の状態が更新されることによって、前記決定された発生時刻に、前記仮想世界において前記決定されたイベントが発生しなければ、前記更新手段は、前記受け付けられた前記１人以上のサブユーザからの選択情報を無視する、
   ことを特徴とするゲーム処理装置。
6. 請求項１から５のいずれか１項に記載のゲーム処理装置であって、
   前記決定された開始時刻に、前記１人以上のサブユーザが選択可能な複数の選択肢と、当該複数の選択肢のそれぞれを識別する情報を含むＵＲＩ(Universal Resource Identifier)と、が指定された記事が、記事サーバに投稿され、前記１人以上のサブユーザの各サブユーザが前記ＵＲＩに示される集計サーバにアクセスすると、当該各サブユーザにより選択された選択肢が当該ＵＲＩに含まれる情報から識別される、
   ことを特徴とするゲーム処理装置。
7. 請求項６に記載のゲーム処理装置であって、
   前記記事サーバと、前記集計サーバと、の、いずれか一方もしくは双方は、前記ゲーム処理装置と通信可能な外部の情報処理装置により実現される、
   ことを特徴とするゲーム処理装置。
8. 請求項６に記載のゲーム処理装置であって、
   前記記事サーバと、前記集計サーバと、の、いずれか一方もしくは双方は、前記ゲーム処理装置により実現される、
   ことを特徴とするゲーム処理装置。
9. 請求項１から８のいずれか１項に記載のゲーム処理装置であって、
   前記決定手段は、前記イベントが発生する発生時刻を、前記ゲーム処理装置において過去に前記サブユーザから受け付けた選択情報の統計に基づいて、決定する、
   ことを特徴とするゲーム処理装置。
10. 請求項１から９のいずれか１項に記載のゲーム処理装置であって、
    前記決定手段は、前記選択受付手段が受け付けた選択情報の数が所定の最低投票数に満たない場合には、投票期間を延長する、
    ことを特徴とするゲーム処理装置。
11. 指示受付手段、更新手段、決定手段、選択受付手段を有するゲーム処理装置において実行される制御方法であって、
    前記指示受付手段が、メインユーザからの指示情報を受け付ける指示受付ステップと、
    前記更新手段が、前記メインユーザからの指示情報が受け付けられると、当該受け付けられた前記メインユーザからの指示情報に基づいて、仮想世界の状態を更新する更新ステップと、
    前記決定手段が、前記仮想世界の状態に基づいて、前記仮想世界に将来生ずるイベントと、当該イベントが発生する発生時刻と、当該発生時刻より以前の開始時刻と、を、決定する決定ステップと、
    前記選択受付手段が、前記決定された開始時刻から、前記決定された発生時刻まで、１人以上のサブユーザからの選択情報を受け付ける選択受付ステップと、
    を備え、
    前記決定された発生時刻に、前記仮想世界において前記決定されたイベントが発生すれば、前記更新ステップでは、前記更新手段が、前記受け付けられた前記１人以上のサブユーザからの選択情報に基づいて、前記仮想世界の状態を更新する、
    ことを特徴とするゲーム処理装置の制御方法。
12. コンピュータを、
    メインユーザからの指示情報を受け付ける指示受付手段、
    前記メインユーザからの指示情報が受け付けられると、当該受け付けられた前記メインユーザからの指示情報に基づいて、仮想世界の状態を更新する更新手段、
    前記仮想世界の状態に基づいて、前記仮想世界に将来生ずるイベントと、当該イベントが発生する発生時刻と、当該発生時刻より以前の開始時刻と、を、決定する決定手段、
    前記決定された開始時刻から、前記決定された発生時刻まで、１人以上のサブユーザからの選択情報を受け付ける選択受付手段、
    として機能させ、
    前記決定された発生時刻に、前記仮想世界において前記決定されたイベントが発生すれば、前記更新手段は、前記受け付けられた前記１人以上のサブユーザからの選択情報に基づいて、前記仮想世界の状態を更新する、
    ことを特徴とするプログラム。

Images