図1は、本発明の実施の形態に係るゲーム装置の第1実施例を示すブロック図である。実施例は携帯電話システムを構成しており、第1携帯電話2、第2携帯電話4、第3携帯電話6、および第4携帯電話8を含む。これらは、基本的には同一の構成である。なお、図1では簡単のために4つの携帯電話のみ図示しているが、本発明の実施例は多数の携帯電話を前提としたシステムであり、例えば近距離通信圏内にある同一の構成の100台程度の携帯電話によるシステムを想定している。
第1携帯電話2は、携帯電話全体を制御するコンピュータからなる第1制御部10を有し、第1操作部12の操作に応じて、第1電話機能部14などを制御する。この第1制御部14の機能は記憶部16に格納されたソフトウエアによって実行される。記憶部16は、また第1携帯電話2全体の制御に必要な種々のデータを一時的に格納する。また、第1制御部10は、第1表示部18を制御し、第1操作部12の操作と連携するGUI表示を行うとともに制御結果の表示を行う。
GPS部20は、GPSシステムに基づいて衛星または最寄の放送局より第1携帯電話2の絶対位置情報である緯度、経度、および高度の情報を得て第1制御部10に送る。この絶対位置情報は、第1制御部10の制御により地図とともに第1表示部に表示され、ナビゲーション情報として提供される。 第1ゲーム記億部22は、第1携帯電話2で可能なゲームに関するデータを記憶する。これらゲームに関するデータは標準化されており、IDにより識別可能である。第1ゲーム記億部22に記憶されるゲームは、以下で詳述するように第1携帯電話2単独で楽しむゲームばかりではなく、第2携帯電話4等の他の多数の携帯電話と連携して行うゲームのためのデータを記憶している。なお、第1ゲーム記億部22は、単に娯楽のためのゲームだけではなく、以下で詳述するような世論調査や情報交換等を行うためのデータも記憶している。このような世論調査や情報交換についても、以下の説明では「ゲーム」と総称し、必要に応じ、狭義の「ゲーム」、「世論調査」、「情報交換」等に分けて説明する。従って、特に区別する旨を断わらない限り、「ゲーム」という用語は、は狭義の「ゲーム」だけでなく、広義に「世論調査」、「情報交換」等を含み、その説明はこれらに共通する機能を指すものとする。
第1携帯電話2は、第1電話機能部14および第1電話通信部24により通常の通話を含む電話回線を介した無線通信を行うことができる。第1携帯電話2には、これと別に無線LANなどによる第1近距離通信部26が備えられており、近距離通信圏内に存在する他の携帯電話との無線通信が可能となっている。 この第1近距離通信部26は法規制上問題のない規格に基づくものであって、通信圏は限られるが電話回線などのように料金が発生しないものである。
第1近距離通信部26は、後述するゲームのためのデータの交信の他、上記のGPS部20において取得した絶対位置情報を他の携帯電話に送信すると共に、他の携帯電がそのGPS部で取得した絶対位置情報を受信することができる。これにより、第1表示部18において自分の位置だけでなく他の携帯電話を持つ人の位置についても同一の地図上で表示することが可能となり、両者の相対関係を地図上で確認できる。その詳細については、同一出願人による特許願2007−28393などに記載されている。 また、第1携帯電話2は、カメラ部28を有し、撮影した画像を記憶部16に記憶することが可能であるとともに、第1電話通信部24によって画像を他の携帯電話に送信することができる。
第2携帯電話4、第3携帯電話6、および第4携帯電話8は、既に述べたように第1携帯電話2と同様の構成を持つものであり、図1においては、重複を避けるため必要のない限り符号は付さず説明も省略する。また、図1において、第2携帯電話4、第3携帯電話6、および第4携帯電話8におけるGPS部、記憶部、カメラ部について図示を省略している。 次に、第1携帯電話2と他の携帯電話の間の連携について説明する。説明は第1携帯電話を中心にして行うが、第2携帯電話4等の他の携帯電話も同様にして機能の中心となることができる。
第2携帯電話4、第3携帯電話6、および第4携帯電話8は、既に述べたように第1携帯電話2と同様の構成を持つものであり、重複を避けるため、図1において必要のない限り符号は付さず説明も省略する。 図1において、第1携帯電話2は、例として第2携帯電話4と通常の電話交信状態にあり、第1電話通信部24と第2電話通信部30との間で無線通信が行われている。なお、図1では両者が直接通信を行っているごとく図示しているが、周知のように携帯電話は通信回線によるインフラストラクチャー通信によるものであり、実際には第1電話通信部24と第2電話通信部30とは、基地局を介した電話回線によって通信している。 一方、図1において、第1携帯電話2は、例として第3携帯電話6および第4携帯電話8とアドホック通信を行っており、それぞれ第1近距離通信部26と第3近距離通信部32との間、および第1近距離通信部26と第4近距離通信部34との間で直接通信を行っている。なお、既に述べたように、第1近距離通信部26はさらに他の携帯電話の近距離通信部との直接通信が可能であり、例えば、第1携帯電話2のからの近距離通信圏内にある多数の携帯電話に同じ情報を送信可能である。一方、受信については、先着優先または時間帯割り当てによって個々の携帯電話から個別に情報を受信可能である。
なお、当然ながら、第1携帯電話2の第1電話通信部24は、第3携帯電話6または第4携帯電話に電話をかけることによって第3電話通信部または第4電話通信部との間で無線電話接続が可能である。一方、第1近距離通信部26は、第3携帯電話6および第4携帯電話8の近距離通信部への送信と同時に第2携帯電話4の第2近距離通信部への情報送信が可能であり、第2近距離通信部からの情報の個別受診も行うことができる。 以上、第一携帯電話2の機能を例として他の携帯電話との関係を説明したが、第2携帯電話4、第3携帯電話6および第4携帯電話のそれぞれについても同様の機能があることはいうまでもない。 以上の機能によって、第1携帯電話2、第2携帯電話4、第3携帯電話6、および第4携帯電話8は、電話通信部によってそれぞれの間の通常どおりの二者間電話が可能であるとともに、近距離通信部によって多数の携帯電話の連携によるグループゲームを楽しむことができる。さらには、多数の携帯電話の連携で世論調査などを行うことができる。
図2は、折り畳み式となっている第1携帯電話2を開いた状態における外観正面図であり、その主要な構成とともに、LCDからなる第1表示部18に表示されるゲームの例を示したものである。第1携帯電話2は、電源キー52、通話キー54、マイク56およびイヤホン58によって通常の電話が可能であるとともに、カメラ部28で自分の顔を映すことによってテレビ電話も可能となっている。 第1操作部12は、主にテンキー60および十字キー62によって第1表示部18の表示を操作することでGUIを行う。また、メニューキー64は、GUIのためにメニューを出す際に操作する。
図2の第1表示部18には、例えば100人によってそれぞれの携帯電話で連携して行うアンケートゲームが表示されており、設問エリア64には一連の設問のうちの第三問である「あなたは、犬派?猫派?」という設問が表示されている。そしてこの設問に対し、第1携帯電話2の持ち主自身は、第1操作部12の操作により「犬派」のチェックボックスにチェックを入れている。このような設問は、ゲームに参加している100台の携帯電話のいずれからも近距離通信部によって他の携帯電話全てに送信可能であるが、ここでは、第1携帯電話2から送信されたものとして説明を進める。なお、以下の説明では、このようにして近距離通信部からゲームを他の携帯電話に送信することをゲームの「提唱」と称し、これに応えてゲームに加わることを「参加」と称する。また、ゲームの送信者を「提唱者」と称する。さらに、このように多数の参加を前提とするゲームを、以下代表として「100人ゲーム」と称する。 第1携帯電話2からの提唱に応え、参加者からはそれぞれ個別に近距離通信部によって第1携帯電話2に回答が送信される。第1表示部18の集計エリア66には、全参加者の回答の集計が表示されている。この集計結果の情報は全参加者にも送信される。したがって、全参加者は第1表示部18に表示されているのと同じ情報をそれぞれの携帯電話の表示部で表示するができる。
なお、集計エリア66のデータの表示は「リアルタイム表示」モードと「条件表示」モードで切り換えることができる。「リアルタイム表示」モードとは、各参加者からの集まってくる回答を途中段階において刻々リアルタイムで集計し、リアルタイムで各参加者に送信するモードである。これによって、参加者は他の参加者の動きを刻々知ることができ、これを参考にして自分の回答を決定することができる。これは設問が人気投票である場合などに適する。 一方、「条件表示」モードは、一定の条件が満たされたとき(例えば、全回答数が全参加者の半分に達したとき、または例えば「犬派」と「猫派」の一方が他方の倍となったとき、または一定の時間が経過する毎、など)に集計を行って結果を送信するが、条件が満たされない限り途中経過は伏せておくモードである。これは、限られた情報から他の参加者の動きを読んで自分の回答を決定する場合などに適する。この「条件表示」モードに設定した場合、集計エリア66の「犬派」、「猫派」の集計グラフは条件が満たされない限り更新されず、前回に条件が満たされたときになされた表示がそのまま継続される。または、これに代えて、「条件表示」モードに設定した場合、集計エリア66の「犬派」、「猫派」の集計グラフは条件が満たされときに所定時間だけ表示するようにし、他の時間帯では回答数の合計のみを表示するようにしてもよい。
以上の表示モードは、設問が単なるアンケート調査の場合では、いずれに設定するかにさしたる意義はない。しかしながら、最終集計の少数派が勝ち残って次の設問に移れるというトーナメント形式のゲームルールであった場合、他の参加者の動きをリアルタイムで見るか、または節目、節目の情報から他の参加者の動きを読むかの選択はゲームの興を増加させる。さらに締め切りまでは他の参加者の動きを見て回答を何度でも変更できるようなルールであれば、表示モードの設定はゲームの興に大きく影響する。 例えば、中間集計で「猫派」が少数派であったとき、ゲームに勝ちたければ「犬派」から「猫派」に鞍替えすればよいが、他の参加者も同じことを考えるので、次回集計では「猫派」が多数派に逆転してしまう可能性もある。このような他者の動きをどう読むかは株価を読むのに似ており、リアルタイムで他の参加者の動きを見ることができるか、または節目、節目以外の途中経過が伏せられていてこれを読むしかないかでゲームの興が変わってくる。 なお、上記の両モードの中間的なものとして、「リアルタイム表示」モードにおいて集計表示に所定の遅延をかける設定をし、故意に情報を遅らせるようなゲームの演出をすることもできる。
なお、ゲームは、プレイヤーとして回答に参加する場合だけでなく、集計結果を傍からモニタするだけの「モニタ参加」も可能である。この場合は、モニタとしての興に従い、「リアルタイム表示」モードと「条件表示」モードを任意に切換えることができる。一方、「プレイヤー参加」をした場合は、他の参加者の動きの把握の程度が回答変更の動きに影響するので、条件をそろえるため、いずれのモードとするかは全プレイヤーで共通とする。
図3は、本発明の第2実施例の第1表示部18に表示される他のゲームの例(仮に「ご当地ゲーム」と称する)を示したものである。第2実施例では、図1における携帯電話の1つ(例えば第4携帯電話8)の構成が観光地などに固設されている。このような第2実施例の場合、第4携帯電話8はその観光地に関する情報交換を近距離通信圏内に入った来訪者全員に提唱し、そのうちの参加者からの情報を受信するとともに、集計データ等を提供することを主機能としている。 第4携帯電話8はご当地の管理者によって手動操作されてもよいが、自動的に情報交換を常時提唱するとともに、参加者との情報交換も自動化することが可能であり、その場合は、携帯電話としての第4操作部、第4表示部およびカメラ部などを省略してもよく、外形も通常の携帯電話の形状でなくてよい。さらに、固設されているのでGPS部なども省略してよい。
図3は、以上のような第2実施において、第1携帯電話2の所有者がご当地を来訪した場合の第位置表示部18の表示を示しており、設問エリア72には、来訪者の属性入力欄74が設けられている。来訪者はプライバシー上問題ないと思えば、十字キー62などを操作して、住所区域別、男女別、年代別にそれぞれ設けられた属性入力欄74のチェックボックスの一つにチェックを入れる。これらの来訪者属性データは主に観光地の経営上の参考とされるものである。設問エリア72には、さらに人気スポット投票欄76が設けられており、観光地の地図上で割り当てられた観光スポット番号のうち、一番気に入った観光スポットの番号をテンキー60などによって入力する。 第位置表示部18の情報提供エリア78には、その観光地の地図80が表示されており、地図80上で観光スポット番号82が割り当てられている。上記の人気スポット投票欄76への番号入力はこのような地図80と観光スポット番号82のいずれかに基づいて行う。図3の例では、「1」から「4」までの観光スポット番号から「3」が選択され、人気スポット投票欄76に入力されている。
各参加者が送信した人気スポット番号は、第4携帯電話で集計され、その結果は、得票数に応じた人気スポット番号82の数字のサイズで表される。図3の例では、「2」の人気スポットの得票数が一番多いのでサイズが一番大きく表示され、「3」の人気スポットの得票数が一番少ないのでサイズが一番小さく表示されている。 情報提供エリア78にはさらに、設問エリア情報入力提供者のIPアドレスと対応させて参加者に発行された参加者番号の下三桁を対象に抽選を行った結果の当選番号84が表示されている。参加者は、自分の参加者番号が当選番号84の表示に該当すればクーポン発行要求ボタン86を操作することにより、その観光地で使用できる電子クーポンを受取ることができる。 なお、図3では図示していないが、参加者に関心があれば、設問エリア72で入力した来訪者属性データの集計結果を受信することもできる。以上の第2実施例は、ご当地側で必要とする情報収集および協力へのインセンティブとしての観光情報の提供などがゲームコンテンツとなっている単純な例であるが、ご当地クイズや出身地別対戦などコンテンツの工夫により、さらにゲーム性を高めることも可能である。
図4は、本発明の第3実施例の第1表示部18に表示される他のゲームの例を示したものである。第1実施例および第2実施例では、近距離通信部の通信圏内にある携帯電話の間に限られていたが、第3実施例ではこれに広域サーバが関与し、近距離通信部による交信ルールを統一して支配するとともにその集計結果を電話通信部を通じたインターネットによって集結し、これをさらに集計することによって、近距離通信圏を越えた広域の調査などを可能とするものである。(のように広域サーバが関与するゲームを仮に「広域型ゲーム」と称する。) 図4は、このような第3実施例において、支持政党の街頭サンプル調査を行う場合を例示している。なお、第3実施例では、例として、広域サーバの支配下にある第1携帯電話2が提唱者となり、広域調査の提唱を近距離通信圏内に送信する。具体的には、第1携帯電話2の所有者は支持政党調査員であり、街頭調査のために例えば公園や駅前に出向き、付近の人々に街頭調査への協力を呼びかける「ゲーム提唱」を行う。 図4の第1表示部18は、提唱者となっている第1携帯電話での表示であるが、同一の表示が第2携帯電話等の参加者の携帯電話の表示部に表示される。表示部の設問エリア92には、支持政党チェックボックス92、および調査参加者の属性入力欄96が設けられている。調査参加者は、十字キー62などを操作して支持政党チェックボックス92の1つにチェックを入れるとともに、プライバシー上問題ないと思えば、男女別、年代別にそれぞれ設けられた属性入力欄96のチェックボックスの一つにチェックを入れる。
参加者が入力したデータは、第1携帯電話2の第1近距離通信部26に送信され、第1携帯制御部10で集計された後、第1電話機能部14から広域サーバに送信される。広域サーバは各調査員を統括しており、各街頭に出張している調査員から同様の近距離圏集計結果を携帯電話回線にて受信する。調査員の出張地は同一市内や同一都道府県内に限っても良いし、全国に散らばった調査員にサンプル調査を依頼してもよい。このような調査員は広域サーバ管理者と固定的に契約している者に限らず、調査の都度、現地で募集してもよい。 広域サーバは各調査員からのデータを集計し、広域統計データを作成する。この広域統計データは広域サーバ自身で分析されるとともに、各調査員に携帯電話回線で配信される。これを受取った各調査員は、付近の参加者に近距離通信部により広域統計データを転送する。以上によって、各調査員はもとより各参加者のすべてが広域統計データを共有でき、自分の参加した調査結果を知ることができる。
図4の第1表示部18における広域統計データ欄98には、広域調査の参加者が年代別別、男女別に合計されて母数100として表示されている。また、統計結果として男女別の支持政党分布グラフ102および年代別支持政党分布グラフ104が表示される。 以上のように本発明の特徴によれば、支持政党調査や内閣支持率などの調査において、電話による個別調査よりも効率よくサンプリング調査が可能となるとともに、近距離通信圏の選択と配置により、フレキシブルで信頼性の高い世論調査が可能となる。なお、このような広域型においても、コンテンツの工夫次第でより単なる調査にとどまらないゲーム性の高いプログラムを用意することができる。
図5以下は、図1の第1携帯電話2における第1携帯制御部10の動作を示すフローチャートであるが、第2携帯電話4以下の他の携帯電話にも共通に適用されるものである。また、図5以下のフローチャートは上記の第1実施例から第3実施例のいずれにも対応できるよう構成されたものであるが、基本的には第1実施例に即して説明し、適宜、第2実施例および第3実施例における機能についてもコメントする。 図5は、ゲームに入るためのゲームメニューフローであり、図2のメニューキー64の操作などによってフローがスタートする。フローがスタートすると、まず、ステップS2において、近距離通信圏内に他の携帯電話を持っている人がいるかどうかがチェックされる。そして、一人でも近距離通信圏内者がいればステップS4に進み、可能な全ての近距離圏内者のモニタを行う。このモニタは先着順優先など所定の交通整理プロセスに従い、個々の通信圏内者の携帯電話との間で所定時間だけ個別の情報交換を試みるプロセスである。
ステップS4でのモニタ時間が経過するとステップS6に進み、検出できた圏内者数が所定数(例えば50人)以上かどうかをチェックする。そして所定数以上の圏内者がいればステップS8に進み、検出した圏内者数を蓄積してステップS10に進む。ステップS10では、圏内者数の蓄積を開始してから所定時間が経過したかどうかをチェックし、経過していなければステップS2に戻る。以下、ステップS2で近距離圏内者が検出されなくなるか、またはステップS6で所定数以上の圏内者が検出されなくなるかしない限り、所定時間の経過までステップS2からステップS10を繰り返す。この間、ステップS8に至る毎に圏内者数の蓄積が行われる。 ステップS10で所定時間が経過したことが検出されるとステップS12に進み、蓄積された圏内者数の平均が所定以上かどうかチェックする。そしてこの平均値が所定以上であれば、安定して所定数以上の通信圏内者が周囲にいることになるので、多数を前提としたゲームや調査が可能であると見なし、ステップS14に進んで「100人ゲーム」に分類されるゲームをメニューに表示する。この表示は通常のゲームメニューに混在するよう追加することもできるし、「100人ゲーム」だけを分類してメニュー表示するようにしてもよい。
次いで、ステップS16で実施中の「100人ゲーム」があるかどうかチェックし、あればステップS18に進んで実施中の「100人ゲーム」の一覧をメニュー表示する。この表示は、具体的にはステップS14でリストアップされたゲームの内、実施中のものの色を変えるかマークをつけるかの表示となる。これは、色が異なるかまたはマークがついているゲームについて近辺で誰かが既に提唱を行い、これに参加することが可能であることを示す。このメニューが表示されるとゲームを指定してこれに参加するための操作が可能となり、ステップS20でその操作が行われたかどうかチェックされる。 所定時間内にこのような参加選択操作が行われたことの検出がなければステップS22に進む。一方、ステップS16で実施中の「100人ゲーム」があることが検出されなかったときは、直接ステップS22に進む。ステップS22では、ステップS14で表示された「100人ゲーム」メニューの中から現在提唱されていないゲームを新たに提唱する操作があったかどうかをチェックする。操作の検出ができなければステップS24に進み、ゲームメニューの表示を終了させる操作があったかどうかをチェックする。
ステップS24でゲームメニュー終了操作が検出されなかったときはステップS2に戻り、以下、所定の条件とならない限り、ステップS2からステップS24を繰り返す。なお、所定の条件とは、ステップS2で近距離圏内者が検出されないこと、ステップS6で所定数以上の圏内者が検出されないこと、ステップS12で蓄積された圏内者数の平均が所定以上であることが検出されないこと、ステップS20で実施中ゲームの参加選択操作が検出されること、ステップS22でゲーム開始提唱操作が検出されること、およびステップS24でゲームメニュー終了操作が検出されることのいずれかである。 一方、ステップS24でゲームメニュー終了操作が検出されるとステップS26に進み、ゲームデータ更新処理を行った上でフローを終了する。ステップS26のゲームデータ更新処理の詳細については後述する。 また、ステップS20で実施中ゲームの参加選択操作が検出されると、ステップS28に進み、ゲーム参加処理に進む。ステップS28のゲーム参加処理の詳細については後述する。 さらに、ステップS22でゲーム開始提唱操作が検出されると、ステップS30に進み、ゲーム提唱処理に進む。ステップS30のゲーム提唱処理の詳細については後述する。
なお、ステップS2で近距離圏内者が検出されない場合、またはステップS6で所定数以上の圏内者が検出されない場合、またはステップS12で蓄積された圏内者数の平均が所定以上であることが検出されない場合はいずれもステップS32に進み、ゲームメニュー表示において「100人ゲーム」メニューを非表示とする。これによって、「100人ゲーム」の選択が不可能となるとともに、実施不可能なゲームメニューを表示することによる使用者の混乱を防止する。 次いで、ステップSでは、ステップS32で表示された通常ゲームの1つを選択する操作が行われたかどうかをチェックする。操作が検出されればステップS36の通常ゲーム処理に進む。この通常ゲーム処理では、従来どおりの通常ゲームが実施される。 一方、ステップS34でゲーム選択操作が検出されなかったときは、ステップS24に以降し、ゲームメニュー終了操作が検出されなければステップS2に戻る。この場合、ステップS2で近距離圏内者が検出されないか、ステップS6で所定数以上の圏内者が検出されないか、ステップS12で蓄積された圏内者数の平均が所定以上であることが検出されないと、再びステップS32に至り、以下、これらのいずれかを経由してステップS32からステップS34を繰り返す。 なお、上記のようにしてステップS34からステップS24に移行することが可能なよう構成することにより、ステップS2に戻って近距離圏内者が検出された場合、条件によってはステップS14に進んで「100人ゲーム」のメニュー表示のループに入ることも可能である。 以上のように、図5のフローは、そのループの繰返中における条件変化に応じ、ステップS14の「100人ゲーム」メニュー表示とステップS32の「100人ゲーム」メニュー非表示の間で表示が自動的に切換る。
なお、図3の第2実施例における「ご当地ゲーム」の場合、ご当地に固設されている携帯電話の構成からは近距離通信圏内者の有無や数に係らず、常にご当地ゲームの提唱が自動発信されている。これに対応するためには、図5のフローのステップS2において検出される近距離通信圏内者がご当地固設携帯電話であると特定できたときに直接ステップS18に移行するよう構成する。これによって、ご当地固設携帯電話との近距離通信が可能な圏内に入った場合は、それが自分一人だけのときでも「ご当地ゲーム」が実施中であることが表示され、これに参加することが可能となる。
図6は、図5のステップS28におけるゲーム参加処理の詳細を示すフローチャートである。フローがスタートすると、まずステップS42において、ゲームの残り時間が表示される。これによって参加しようとしているゲームの進捗状況がわかる。 次いでステップS44でゲーム開始後所定時間が経過したかどうかチェックされる。所定時間が経過していなければステップS46に移行し、プレイヤー参加する旨の操作が所定時間内になされたかどうかチェックされる。この操作が所定時間内に検出されないときは、ステップS48に進み、選択したゲームへのモニタ参加が確定される。 次いでステップS50で「条件表示」を選択する操作が所定時間内にあったかどうかチェックする。この操作が所定時間内に検出されなければステップS52に進んで「リアルタイム表示」モードを確定し、ステップS53の百人ゲーム処理に移行する。100人ゲーム処理の詳細は後述する。このようにステップS46に進んだ後、所定時間経過するまで何も操作しなければ自動的にステップS52に至り、「リアルタイム表示」モードでの「モニタ参加」が確定する。一方、ステップS50で「条件表示」を選択する操作が所定時間内にあったことが検出されるとステップS54に進み、「条件表示」モードを確定してステップS53の百人ゲーム処理に移行する。
これに対し、ステップS46でプレイヤー参加する旨の操作が所定時間内になされたことが検出されたときはステップS56に進み、参考データを表示させる旨の操作が所定時間内に行われたかどうかをチェックする。そしてこの操作が検出されるとステップS58に進み、現在の参加者数を表示する。さらにステップS60では、参加者の属性を統計処理したデータを表示し、ステップS62に移行する。 ステップS58およびステップS60で表示される上記の参考データはゲームへの関心度に影響するものであり、参加を最終決定する前に特にこれらを知りたいときは、データ表示操作を行えばこれがステップS56で検出され、上記のように参考データが表示される。一方、プレイヤー賛歌操作を行ってから所定時間何も操作しなければステップS56から直接ステップS62に至り、参考データは表示されない。このように、特に関心がない場合は煩雑な参考データ表示は自動的に省略される。
ステップS62では、実施中の表示処理に同意する旨の操作所定時間内に行ったかどうかがチェックされる。既に述べたように、「プレイヤー参加」をした場合は、他の参加者の動きの把握の程度が回答変更の動きに影響するので、「リアルタイム表示」モードまたは「条件表示」のいずれのモードとするかは全プレイヤーで共通で共通にしてゲームが実施される。そして、後から参加する者も、これと異なる表示モードで参加することはできない。従って、ステップS62で同意操作があったことが検出されるとステップS64に進み、表示モードを実施中のものに強制設定する。 次いで、ステップS66では、実施中のゲームに、男女、年齢などの属性データを参加者が提供する必要のあるものかどうかがチェックされる。そして、属性データの提供が必要であればステップS68に進んで所定時間内に属性データ提供に同意する旨の操作があったかどうかチェックする。この操作は、具体的には、属性データをチェックボックスなどにより入力することに相当する。この入力が所定時間内にあればステップS70に進み、入力された属性データを提唱者に送信する。以上をもってステップS72でプレイヤー参加を確定し、ステップS53の百人ゲーム処理に移行する。 なお、ステップS66で実施中のゲームが属性データの提供を要求しない種類のものであったときはステップS66から直接ステップS72に移行し、プレイヤー参加を確定してステップS53の百人ゲーム処理に移行する。
一方、ステップS44でゲーム開始後所定時間が既に経過していたときはステップS74に進み、プレイヤー参加が既に締め切られていて、モニタ参加しか出来ない旨を表示する。これを見て関心を失った参加希望者は参加中止操作を行うことができる。そしてステップS74での表示後所定時間内に参加中止操作があったときはステップS78に進み、ゲームへの参加選択をキャンセルしてフローを終了する。 なお、所定時間何に参加中止操作をしなかった場合はステップS46に進む。そして、この場合はステップS46でのプレイヤー参加操作は不可とされ、自動的に即座にステップS48に進んでモニタ参加を確定する。このように、プレイヤー参加が不可能な場合は、所定時間経過するまで何も操作しなければ自動的にモニタ参加が決定される。
また、ステップS62において実施中表示処理同意操作を所定時間内におこなったことが検出されない場合はステップS78に進んでゲームへの参加選択をキャンセルする。このように、実施中の「リアルタイム表示」モードまたは「条件表示」モードでは興が沸かず、ゲームに参加する関心を失ったときは、プレイヤー参加する旨の操作を行ったまま所定時間経過するまで何も操作しなければ、ゲームへの参加が自動的にキャンセルされる。 さらに、ステップS68において属性データ提供同意操作を所定時間内におこなったことが検出されない場合もステップS78に進んでゲームへの参加選択をキャンセルする。このように、プライバシー上、実施中のゲームで要求される属性データを提供したくないときは、プレイヤー参加する旨の操作を行ったまま所定時間経過するまで何も操作しなければゲームへの参加が自動的にキャンセルされる。
図7は、図5のステップS30におけるゲーム提唱処理の詳細を示すフローチャートである。フローがスタートすると、まずステップS82において、提唱可能ゲームの一般メニューを表示する。次いで、ステップS84において、そのうち「広域型ゲーム」のみのメニューの表示を選択する操作を所定時間内に行ったかどうかがチェックされる。このような「広域型ゲーム」のデータは広域サーバ側で企画され次第、そのルールとともに電話回線を通じて各携帯電話の電話通信部に配信され、ゲーム記億部に記憶される。 ステップS84で広域型ゲームメニュー選択操作があったことが検出されるとステップS86に進み、ゲームメニューがそれぞれのルール概要とともに表示される。フローはこの表示を継続したままステップS88に進む。一方、ステップS84で広域型ゲームメニュー選択操作があったことが検出されない場合は、直接ステップS88に進む。 ステップS88では、ステップS82またはステップS6で表示されたゲームメニューの1つを選択する操作がメニュー表示から所定時間内に検出できたかどうかチェックする。そして選択が行われたことを検出するとステップS90に進む。一方ステップS88で所定時間内にメニュー選択操作が検出されなかったときは、メニュー内の既存ゲームでは満足できないものと判断し、ステップS92のオリジナルゲーム提唱処理に進み、その終了をもってステップS90に進む。なお、ステップS92のオリジナルゲーム提唱処理の詳細は後述する。
図ステップS90では、選択されたゲームのIDを近距離通信部から発信することでゲームを提唱する。なお、ステップS92のオリジナルゲーム提唱処理からステップS90に至った場合はゲームIDとともにゲーム内容のデータも送信する。さらにステップS94でゲームへの参加期限を送信し、ステップS96にて参加者応答の有無をチェックする。この場合、図5のステップS4と同様、複数参加者からの応答が重ならないよう先着順優先など所定の交通整理プロセスを講じて参加者を個別にチェックする。 ステップS96にて参加者の応答が個別に検出できればステップS98に進む。ステップS98で応答者がゲームに必要な属性を満たしているかチェックした上、その属性OKの者のIPアドレスを記憶し、人数の累積が所定数以上となっているかどうかチェックする。そして属性OKの参加者が所定数以上あればステップS100に進んでゲームの成立および開始の旨を近距離通信部から参加者に送信する。そしてステップS102で、ゲームオーバに向かってのカウントダウンを開始し、ステップS103の百人ゲーム処理に移行する。
一方、ステップS96で参加者応答が検出できないか、またはステップS98において属性OK参加者累計が所定数に達していなかった場合はステップS104に進み、ゲームの提唱を中止する操作がなされているかどうかチェックする。そしてこの操作が検出されないときはステップS105に進み、ステップS94で設定した参加期限が満了しているかどうかチェックする。期限満了でなければステップS96に戻り、以下ステップS98で属性OK参加者が所定数以上となるか、またはステップS104で提唱中止操作が検出されるか、またはステップS105で参加期限満了が検出されるかしない限り、ステップS96、ステップS98、ステップS104、ステップS105を繰り返す。 なお、ステップS104で提唱中止操作が検出されるか、またはステップS105で参加期限満了が検出されるかしたときは、ステップS106に進みゲーム不成立の旨を近距離通信部から周囲に送信してフローを終了する。
図8は、図6のステップS53および図7のステップS103における100人ゲーム処理の詳細を示すフローチャートである。フローがスタートすると、ステップS107で交信時間割当処理を行う。この処理は提唱者と各参加者との交信が行われる際に複数の参加者からの送信が重複しないよう時分割し、これらをそれぞれの参加者に割当てる処理である。既に述べたように、図5のステップS4や図7のステップS96におけるように相手が不特定多数の場合は先着順優先など所定の交通整理プロセスを講じて応答が重なる場合に対処するが、100人ゲーム処理に入って参加者が個別に特定できたときはステップS107におけるように不特定多数が相手の場合とは異なる応答重なり防止策を講じる。 以上の後、ステップS108に進み、確定されたゲームが広域型ゲームかどうかチェックする。そして広域型ゲームであればステップS109の広域型ゲーム処理に移行する。その詳細は後述する。ステップS108で広域型ゲームでなければ近距離通信圏内だけでローカルに実施されるゲームなのでステップS110に移行し、「条件表示」モードに設定されているかどうかチェックする。そして条件表示設定であればステップS111の条件表示ゲーム処理に移行する。その詳細は後述する。一方ステップS110で条件表示設定でなければステップS112のリアルタイム表示ゲーム処理に移行する。その詳細は後述する。
図9は、図8のステップS112におけるリアルタイム表示ゲーム処理の詳細を示すフローチャートである。フローがスタートすると、ステップS113においてフローが図7のゲーム提唱処理経由で開始されたかのどうかをチェックする。これは、自身がゲームの提唱者であるか否かのチェックに相当する。提唱処理経由であれば自分の携帯電話からゲームを開始しなければならないのでステップS114以下に進み、ゲームの初期情報を参加者全員に送信する。これは例えば、図2の設問エリア64におけるような1つの設問を参加者全員に送信することに該当する。 次いでステップS116において、ステップS107で割当てられた時間帯における個別応答の着信の有無をチェックする。チェック時間帯の全てが経過していずれかの参加者から着信があればステップS118に進み、新着の個別応答の内容を記憶する。そしてステップS120において新着の個別応答を既着記憶済みの応答と統合し統計処理を行う。
次いで、ステップS121では、統計結果の表示を故意に遅らせる演出を行うための遅延モードにてゲームが行われているかどうかをチェックする。そして、遅延モードであればステップS122において統計結果が出てもその表示および送信の実行を所定時間遅延させる処置を行い、ステップS123に移行する。具体的には表示実行を所定時間だけ自動的に遅らせるコードを統計結果データに付加する。一方、遅延モードでなければステップS121から直接ステップS123に移行する。 ステップS123では、自身の携帯電話における統計結果の表示を指示する。この際、ステップS122の所定時間遅延処置において遅延コードが付加されていれば、表示の実行は自動的に所定時間後となる。次いでステップS124において他の参加者全員に統計結果を送信する。この場合もステップS122の所定時間遅延処置において遅延コードが付加されていれば、他の参加者の携帯電話における統計結果の表示は自動的に統計結果を受信してから所定時間後となる。
次いで、ステップS126では、応答締切り時刻が到来しているかどうかがチェックされ、まだ締切り時刻でなければステップS128に移行してゲームオーバ条件となっているかどうかをチェックする。そして、ゲームオーバでなければステップS116に戻り、以下、ステップS126で応答締切り時刻が検出されるか、ステップS128でゲームオーバが検出されるかしない限り、ステップS116からステップS128を繰返す。これによって、応答とその統計結果に基づいてゲームが進行する。 一方、ステップS126で応答締切り時刻が検出されるか、ステップS128でゲームオーバが検出されるかすると、フローはステップS130に移行して自身の携帯電話において最終結果の表示を行う。同時にステップS132について最終結果を参加者全員に送信してフローを終了する。なお、この最終結果については、表示の遅延コードは付加されないので、最終結果のデータがあればその表示が速やかに行われる。
なお、以上では、簡単のため、1つの設問に関してその設問の送信から応答の統計を行って結果を表示するまでの一連の処理が終了するとフローが終了するよう説明したが、複数の設問からなるゲームであれば、それぞれの設問毎に図9のステップS114からステップS132までを繰り返す。この場合、ステップS128のゲームオーバはゲーム全体の終結ではなく、1つの設問に関する一連の処理の終結を意味する。同様に、ステップS130およびステップS132における「最終結果」についてもゲーム全体の最終結果ではなく、あくまで1つの設問についての最終結果を意味する。
以上で、自身がゲームの提唱者であった場合のフローについての説明を終わり、以下、他者が提唱したゲームに参加する場合のフローについて説明する。これは、フローが提唱処理経由でなく図6のゲーム参加処理経由でステップS113に至った場合に該当する。 この場合はステップS134に進み、提唱者からの初期情報を受信する。この初期情報は例えば図2の設問エリア64におけるような1つの設問を受信することに該当する。次いでステップS136でプレイヤー参加しているかどうかをチェックする。そしてプレイヤー参加であればステップS138に進み、ステップS134で受信した初期情報に対する応答操作を行ったかどうかをチェックする。そして操作を検出すればステップS140において操作結果が示す応答を近距離通信で提唱者に送信し、ステップS142に進む。 一方、ステップS136でプレイヤー参加である旨の検出がなかった場合、またはステップS138で応答操作が検出されなかった場合は直接ステップS142に進む。
ステップS142では、統計結果を受信したかどうかチェックし、受信があればステップS144で統計結果の表示を指示してステップS146に移行する。なお、ステップS144における表示では、統計結果に遅延コードが付加されている場合、表示の実行は統計データ受信から自動的に所定時間遅延させられる。ステップS142で統計結果の受信がなければ直接ステップS146に進む。 ステップS146では、ゲームの最終結果を受信したかどうかをチェックする。そして、受信があればステップS148でこれを表示してフローを終了する。なお、上記のように最終結果の表示には遅延がないので、ステップS144で表示が指示されたデータの表示実行が遅延させられている場合、その表示の実行よりもステップS148における最終結果の表示が先行する場合もある。このとき、ステップS144で指示された途中経過の統計結果の表示指示は既に意味がないので自動的にキャンセルされる。
一方、ステップS146で最終結果の受信が検出されなかったときはステップS136に戻り、以下、最終結果の受信が検出されるまで、ステップS136からステップS146を繰り返す。これによって、プレイヤー参加しているゲーム参加者はステップS144の表示の進展を見ながら応答操作を行いゲームに参加することができる。そしてその応答は統計結果に反映されていく。 一方、プレイヤー参加でなければ、ステップS138で応答操作が検出されることはないので、表示の変化のみを受身的に楽しむことになる。
なお、以上のゲーム参加の場合のフローにおいても、簡単のため、1つの設問に関してその設問の受信と応答から統計結果の受信表示までの一連の処理が終了するとフローが終了するよう説明した。しかしながら、提唱者の場合におけるステップS113からステップS132の繰返しにおいて説明したのと同様、ゲーム参加の場合においても、複数の設問からなるゲームであれば、それぞれの設問毎に図9のステップS134からステップS148までを繰り返す。この場合、ステップS146およびステップS148における「最終結果」はゲーム全体の最終結果ではなく、あくまで1つの設問についての最終結果を意味する。
図10は、図8のステップS111における条件表示ゲーム処理の詳細を示すフローチャートである。このフローは、図9のリアルタイム表示処理と共通するところが多いので、同一のステップには同一のステップ番号を付し、その説明は省略する。 これに対し、図10の条件表示ゲーム処理において図9と異なるステップは太線で図示するとともに異なるステップ番号を付しているので、これらのステップを中心に要点を説明する。図10のフローでは、ステップS114において、ゲームの初期情報、例えば、図2の設問エリア64におけるような1つの設問を参加者全員に送信するとともに、ステップS152に進み、参加者全員に「応答許可」の旨の信号を送信する。各参加者に対してはこの「応答許可」信号および後述する「応答不可」信号が適宜送信され、参加者は「応答許可」信号を受信してから「応答不可」信号を受信するまでの間において応答許可状態となる。なお提唱者自身もゲームに同一条件でゲームに参加できるので、参加者が応答許可状態にあるときのみ提唱者自身も設問に対する応答が可能となっている。 また、後に説明するように、参加者が応答許可状態にある限り、提唱者および参加者のいずれにおいても統計結果の表示が更新されず、統計結果の進展がゲームの興のため意図的に伏せられる。
上記のように、ステップS152において「応答許可」信号の送信が伴う点を除き、フローは図9と同様にしてステップS114からステップS120まで進むが、ステップS120の後にステップS154が設けられ、統計結果を発表すべき条件が整っているかどうかがチェックされる。そして、統計結果の発表条件がOKであれば、ステップS156で、「応答不可」信号を参加者全員に送信すると共に、ステップS123で提唱者自身について統計結果の表示を行い、ステップS124に移行する。なお、図10の場合、図9のステップS121およびステップS122における遅延に関する処置はない。一方、ステップS154において、統計結果発表条件がOKである旨の検出ができなければ、直接ステップS124に移行する。ステップS124では、図9と同様にして他の参加者全員に統計結果を送信し、ステップS126に移行する。 以上のようにして、提唱者自身についてはステップS154で発表条件OKが検出されなければステップS123における統計結果の表示は行われないが、他の参加者については発表条件OKの如何に係らずステップS124において統計結果自体の送信は行われる。但し、ステップS154で発表条件OKが検出されなければステップS156における「応答不可」信号の送信は行われない。
以下、ステップS126、ステップS128は、図9と同様にフローが推移し、ステップS128でゲームオーバが検出されなければステップS152に戻る。ステップS152では「応答許可」信号が送信されるが、ステップS156で「応答不可」信号が送信されていた場合は、これによって参加者は応答許可状態に戻される。 なお、ステップS156を経由せずにステップS152に戻った場合は、参加者は元々応答許可状態にあり、ステップS152で「応答許可」信号を送る意味はない。しかしながら、ステップS152を経由するときは、提唱者側からは参加者の状態を判断することなく常に「応答許可」信号を送信する。そして、参加者側では応答許可状態において「応答許可」信号を受信したときは何も反応せず単に応答許可状態を継続する。なお、このようなフローとせず、参加者が応答許可状態にあるか否かの履歴を判別し、応答許可状態であればてステップS152で無用の「応答許可」信号を送らないよう構成してもよいことはいうまでもない。
図10のステップS128でゲームオーバが検出されたときは、ステップS158に進み、「応答不可」信号を送信してステップS130に移行する。 なお、この場合も、ステップS156を経由してステップS158に至ったときは、参加者はすでに応答不可状態にあり、ステップS158でさらに「応答不可」信号を送る意味はない。しかしながら、ステップS158を経由するときは、提唱者側からは参加者の状態を判断することなく常に「応答不可」信号を送信する。そして、参加者側では応答不可状態において「応答不可」信号を受信したときは何も反応せず単に応答不可状態を継続する。なお、このようなフローとせず、参加者が応答許可状態にあるか否かの履歴を判別し、応答不可状態であればてステップS158で無用の「応答不可」信号を送らないよう構成してもよいことはいうまでもない。
次に、以上のような提唱者側からの「応答許可」信号および「応答不可」信号の送信に基づき参加者側のフローがどう反応するかについて説明する。図10において、フローが提唱処理経由でなく図6のゲーム参加処理経由でステップS113に至った場合、フローがステップS134に進み、提唱者からの初期情報を受信する点は図9と同じである。 図10では、ステップS136でプレイヤー参加であった場合、ステップS160に進み、参加者の携帯電話が応答許可状態にあるかどうかチェックする。そして、応答許可状態であるときのみ、ステップS138およびステップS140に進んで、ステップS162に移行する。一方、ステップS160で応答許可状態であることが検出できなければ直接ステップS162に移行する。このように、参加者は応答許可状態になければ応答操作を行うことができない。
ステップS162では、再び参加者の携帯電話は応答許可状態にあるかどうかのチェックが行われる。但し、その目的は、受信した統計結果の表示を行うかどうかを決定することにある。つまり、ステップS162において応答許可状態であることが検出されるとフローはステップS136に戻り、以下、ステップS162で応答許可状態でないことが検出されるまでステップS136からステップS162が繰り返される。従って、最新の統計結果を受取っていても、その表示は伏せられ、参加者は統計結果を知ることができない。 これに対し、ステップS162で応答不可状態であることが検出されるとステップS142に進むことが可能となり、ステップS142で最新の統計結果の受信が検出されればステップS144でこれが表示される。また、ステップS146で最終結果が受信されていればステップS148に進んでこれが表示される。 なお、ステップS146で最終結果が受信されていなければゲームが継続中であるので、フローはステップS144における最新統計結果の表示の後、ステップS136に戻る。しかしながら、ゲーム継続中であれば、このとき既に参加者の携帯電話は応答許可状態に戻されている。これは、提唱者側のフローにおいてステップS156での「応答不可」信号送信の直後にステップS152に戻って「応答許可」信号が送信されるからである。従って、参加者のフローはステップS136に戻ったあと、次ぎの段階の発表条件OK検出によって「応答不可」信号が提唱者側から送信されない限り、ステップS136からステップS162を繰り返すことになってステップS144に至ることはできず、最新の統計結果は再び伏せられることになる。
なお、図10のフローでは、設問への応答可否と統計結果の表示可否を逆の関係で対応付けている。これは、応答不可となる期間が比較的短く、実質的にゲームの進行を止めることにはならないとともに、節目、節目の統計結果の発表にあたってはその時点で一旦応答を締めることも統計処理上妥当であるからである。 しかしながら、本発明の実施はこのような構成に限るものではなく、発表条件OKの検出と統計結果の表示可否のみを対応付け、応答についてはこれらから独立にいつでも可能となるよう構成してもよい。
図11は、図7のステップS92におけるオリジナルゲーム提唱処理の詳細を示すフローチャートである。フローがスタートすると、ステップS172で、オリジナルゲームメニューが表示される。このオリジナルメニュー表示では、ルールと内容入力のためのテンプレートが用意されている半オリジナルのテンプレートゲームの選択と、完全に自由にオリジナルゲームを作成するためのメニューの選択ができる。 ステップS174ではテンプレートゲームメニューを選択する操作が行われたかどうかがチェックされ、この操作が検出されたときにはステップS176においてテンプレートゲームの内容を詳細に示したメニューが表示される。そしてステップS178においてテンプレートゲームの1つを選択する操作を検出するとステップS179に移行し、そのゲームの完成に必要なテンプレートの1つを表示する。 例えば、図2のようなアンケートゲームの場合、設問エリア64における設問および選択肢を入力するためのテンプレートが表示される。テンプレートは1つのゲームについてその運営に必要なテンプレートが通常は複数用意されており、例えば上記の設問及び選択肢テンプレートの他に、集計エリア66における集計方法の選択および表示レイアウトなどの選択や設定を行うことができる。さらに、ゲームの参加資格属性や、「リアルタイム表示」または「条件表示」の別の設定、および条件表示の際の条件の設定などを行うためのテンプレートも用意される。ステップS179ではこれらのテンプレートの1つが所定の順序でひとつづつ表示される。 このようなテンプレートゲームは、アンケートなど、ゲームの形式は汎用性があるがその内容について自由に設定したい場合に有用であり、その形式やルールの設定など基本的な部分に時間を割くことなく自分に関心のある内容をゲームとして容易に提唱することができる。
次にステップS180では、テンプレートの入力方法に関するアドバイスが表示され、ステップS182ではテンプレートへの入力操作の有無がチェックされる。所定時間入力がないか、または入力方法が適切でない場合は入力操作がないものと見なされステップS180に戻るとともに、必要に応じステップS180で入力アドバイスがより状況にあったものに変更される。 ステップS182で適切な入力操作があったことが検出されたときは、ステップS184に進み、入力内容のチェックが行われる。入力内容に不備があったときはステップS186に進んで訂正が必要である旨の表示がなされた上でステップS182に戻り、以下ステップS184で入力チェックがOKの旨の判断がなされるまでステップS180からステップS186が繰り返される。
ステップS184で入力チェックがOKの旨の判断がなされるとステップS188に進み、入力完了操作が行われたかどうかがチェックされる。そしてこの操作があった旨の検出がない場合はステップS179に戻り、次のテンプレートが表示される。 以下、ステップS188で入力完了操作が検出されるまでステップS179からステップS188が繰り返される。一方、ステップS188で入力完了操作が検出されたときは、ステップS190に進み、ゲームIDの確定とテンプレート入力内容のコード化を行ってフローを終了する。ゲームのIDはテンプレート提供時に仮付与され、ステップS190でこれを確定する。なお、用意されている全てのテンプレートへの入力を完了したときは、ステップS188で特に入力完了操作をしなくても入力が完了したものと見なされてステップS190に移行する。
ステップS174でテンプレートゲームメニューを表示すべき選択する操作しなかった場合、またはステップS178で表示されたテンプレートゲームの1つを選択する操作をしなかった場合は、ステップS192の純オリジナル提唱処理に進む。この処理では、第1操作部12の操作と第1表示部18によるGUIによって完全に自由にオリジナルゲームを作成することができる。そして、ゲームが完成するとステップS194に進み、ゲーム内容を標準化するコード化を行ってフローを終了する。
図12は、図5のステップS36における通常ゲーム処理の詳細を示すフローチャートであり、基本的には従来どおりの携帯電話単独で行うゲームに関するものであるが、これに加えて通常ゲーム中においても「100人ゲーム」が可能になったときにはこれを通知する機能を含むものである。 フローがスタートすると、ステップS202で、ゲームが開始されたかどうかをチェックする。そしてゲームが開始されていなければステップS204で近距離通信圏内に他の携帯電話を持っている人がいるかどうかがチェックされる。これは図5のステップS2と同様のステップであるが、図5のステップS2において近距離通信圏内者がおらずに通常ゲーム処理に入った場合において、その後状況が変化して近距離通信圏内者が現れたかどうかを確認する意義がある。 以下、図12のステップS206からステップS214は、図5のステップS4からステップS12と同趣旨のものであり、安定して所定数以上の通信圏内者が周囲にいることを検出する機能を持つ。そして、この確認ができればステップS216に進み、通常ゲーム処理中ではあるが、「100人ゲーム」が可能となったことを表示してステップS218に移行する。ステップS202からステップS216に至ったときは、まだゲームが開始されていないので、この表示を見た使用者は「100人ゲーム」に移行する操作をすることができる。
これに対し、ステップS202からステップS204に至って近距離圏内者が検出されない場合、またはステップS208で所定数以上の圏内者が検出されない場合、または、ステップS212で蓄積開始後所定時間が経過していない場合、またはステップS214で蓄積された圏内者数の平均が所定以上であることが検出されない場合は、いずれもステップS216の表示を行わずに直接ステップS218に移行する。 ステップS218ではゲーム終了操作を行ったかどうかをチェックし、操作が検出されなければステップS220に進んでゲーム途上かどうかをチェックする。ゲーム途上でなければステップS204に戻り、以下、ステップS218でゲーム終了操作が検出されるか、ステップS220でゲーム途上であるかが検出されない限り、ステップS204からステップS220を繰り返して「100人ゲーム」が可能となる状態の検出を続ける。なお、この繰返しの中でいつでも通常ゲームの開始操作をすることが可能であり、この操作が行われればステップS220でゲーム途上と判断される。
ステップS220でゲーム途上と判断されるとステップS222に進み、所定のゲームフローに従ってゲームのユニットを実行する。そしてそのユニットの実行が終わるとステップS224に移行し、ゲームオーバかどうかをチェックする。そしてゲームオーバが検出されるとステップS204に戻り、以下、ステップS204からステップS220を繰り返して「100人ゲーム」が可能となる状態の検出を続ける。ゲームオーバとなったあとは、新たなゲームを開始する操作がなされない限り、ステップS220ではゲーム途上でないと判断される。 一方、ステップS224でゲームオーバでなければステップS224に進み、ステップS222でゲームユニットの実行が終わった段階でゲームの節目が到来していないかどうかをチェックする。この節目とは、例えばゲームの次の段階に進むための時間制限のない選択操作がユーザに求められているようなゲーム休止状態を指す。そしてこのようなゲームの節目が着ていればステップS204に戻り、以下、ステップS204からステップS220を繰り返して「100人ゲーム」が可能となる状態の検出を続ける。ゲームの節目が到来してゲームが休止状態となったときも、ゲーム再開の操作がない限り、ステップS220ではゲーム途上でないと判断される。
なお、ステップS226でゲームの節目が到来していることが検出されないときは、ステップS222に戻って次のゲームユニットの実行が継続される。 また、ステップS202においてゲームの開始が検出されたときは、ステップS222に進み、ゲームユニットの実行を開始する。 以上のようにして、本発明の実施例では、通常ゲーム処理にあってもゲームの進行に支障がない限り「100人ゲーム」が可能となる状態の検出が続けられる。
図13は、図8のステップS109における広域型ゲーム処理の詳細を示すフローチャートである。このフローも、図9のリアルタイム表示処理と共通するところが多いので、同一のステップには同一のステップ番号を付し、その説明は省略する。 これに対し、図13の広域型ゲーム処理において図9と異なるステップは太線で図示するとともに異なるステップ番号を付しているので、これらのステップを中心に要点を説明する。さらに、図13のフローでは、処理としては図9と同一であるが取扱われるデータが近距離通信圏内のものではなく広域統計データである場合がある。これらのステップには図9と共通のステップ番号を付すが、ステップを太線で図示する。 図13のフローでは、ステップS114において、ゲームの初期情報、例えば、図2の設問エリア64におけるような1つの設問を参加者全員に送信するとともに、ステップS232に進み、参加者全員にそのゲームが「広域型ゲーム」であることを通知する。これによって、参加者は自分の応答が近距離通信圏内に留まらず、電話回線を通じたインターネットによって広域サーバに終結されて広域に広がるものであることを確認できる。
図13のフローは、ステップS120において、図9と同様にして近距離通信圏内の参加者からの応答を統計処理するが、次にステップS234において電話回線からのインターネットにより広域サーバと交信し、統計処理したデータを広域サーバにアップロードするとともに広域サーバが統計処理した広域統計データをダウンロードする。従って、次のステップS123における統計結果の表示およびステップS124における統計結果の参加者全員への送信は、処理としては図9と同一であるが、取扱われる内容は、近距離通信圏内の統計データではなく、ダウンロードされた広域統計データである。
なお、図13では、ステップS120においてまず近距離通信部で受信した応答の統計処理を行い、その結果をステップS234で広域サーバにアップロードしているが、これに代えてステップS120をスキップするよう構成し、ステップS118において記憶された個別応答の生データをステップS234で直接に広域サーバにアップロードするよう構成してもよい。さらに、これに代えて、ステップS120で統計処理したデータをアップロードするとともにステップS118における個別の生データを参考情報として共にアップロードするよう構成してもよい。
以上が、ゲームの途中経過の広域サーバとの交信であるが、図13のフローでは、ステップS128でゲームオーバとなった場合においても、ステップS236に進んで電話回線からのインターネットにより広域サーバと交信し、統計処理した最終結果を広域サーバにアップロードするとともに広域サーバが統計処理した広域統計データとしての最終結果をダウンロードする。従って、次のステップS130における最終結果の表示およびステップS132における最終結果の参加者全員への送信は、処理としては図9と同一であるが、取扱われる内容は、近距離通信圏内の統計データではなく、ダウンロードされた広域統計データである。図4の広域統計データ欄98の内容はこのような経過を経た情報である。
上記のステップS236おいても、統計処理の結果を広域サーバにアップロードするのに代え、記憶された個別応答の生データをステップS236で直接に広域サーバにアップロードするよう構成してもよい。また、これに代えて、統計処理したデータとともに個別の生データを参考情報としてアップロードするよう構成してもよい。これらについては、ステップS234と同様である。
図13の参加者のフローは、処理としては、図9と共通であるが、取扱われる内容が異なる。まず、ステップS134で受信される初期情報には、ステップS232で送信された「広域型ゲーム」である旨の通知が含まれている。また、ステップS142で受信され、ステップS144で表示される統計結果および、ステップS146で受信され、ステップS148で表示される最終結果、近距離通信圏内の統計データではなく、ダウンロードされた広域統計データである。
図14は、図5のステップS26におけるゲームデータ更新処理の詳細を示すフローチャートである。フローがスタートすると、ステップS242において、自機が記憶している全ゲームのIDを第1近距離通信部26から外部に送信する。ついで、ステップS244においてIDを指定したゲームデータの他機からの要求が第1近距離通信部26で受信されているかどうかがチェックされる。そして要求が受信されていれば、要求されたゲームデータを第1近距離通信部26から要求のあった他機に送信してステップS248に至る。一方、ステップS244でこのような要求が検出されなければ直接ステップS248に至る。以上が、自機の記憶しているゲームデータを第1近距離通信部1から他機に移植するための処理である。 一方、ステップS248以降は、外部より自機にゲームデータを取り込むための処理である。まず、ステップS248では、第1近距離通信部26にて他機からゲームIDを受信したかどうかをチェックする。そして受信があればステップS250に進み、ゲームデータ受信登録処理を実行してステップS252に至る。一方、ステップS248においてゲームID受信が検出されなければ直接ステップS252に至る。
ステップS252では、第1電話通信部24からインターネットへアクセスアクセスする。そしてステップS254において、ゲームデータを保持している外部サーバよりゲームIDをダウンロードし、ステップS256のゲームデータ受信登録処理を行う。そしてステップS254でゲームデータ受信登録処理を実行してフローを終了する。 以上のように、外部からのゲームデータの取り込みは、第1近距離通信部26を介した他機からの取り込みの場合と第1電話通信部24からインターネットを介した外部サーバからのダウンロードの場合がある。ステップS250およびステップS256におけるゲームデータ受信登録処理の詳細については次図で説明する。
図15は、図14のステップS250およびステップS256におけるゲームデータ受信登録処理の詳細を示すフローチャートである。フローがスタートすると、ステップS262で、自機にまだ登録のないゲームIDが新着しているかどうかチェックする。そして新ゲームIDがあればステップS264でこれを記憶してステップS266に進む。一方、ステップS262で新着のゲームIDが検出されない場合は直接ステップS266に進む。 なお、ステップS264では、新着IDが近距離通信で他機から受信したものであるかインターネット経由で外部サーバからダウンロードしたものであるかを区別するコードをつけて記憶する。これは、以下の他の新着IDについても同様である。
ステップS266では、登録済みのゲームに関する新バージョンのIDが新着しているかどうかチェックする。そして新バージョンIDがあればステップS268でこれを記憶してステップS270に進む。一方、ステップS266で新着のバージョンIDが検出されない場合は直接ステップS270に進む。 ステップS270では、登録済みのゲームに関する新テンプレートIDが新着しているかどうかチェックする。そして新テンプレートIDがあればステップS272でこれを記憶してステップS274に進む。一方、ステップS270で新着のバージョンIDが検出されない場合は直接ステップS274に進む。 ステップS274では、ゲームの実行一般に関する新処理ソフトのIDが新着しているかどうかチェックする。そして新処理ソフトIDがあればステップS276でこれを記憶してステップS278に進む。一方、ステップS274で新着のバージョンIDが検出されない場合は直接ステップS278に進む。
ステップS278では、ステップS264、ステップS268、ステップS272およびステップS276で記憶したIDがあった場合、そのIDの中に第1近距離通信部26で他機から通信受信したものがあるかどうかチェックする。そして他機から受信した記憶IDがあればステップS280に進み、記憶IDに対応するデータを近距離通信にて他機に要求し、これを受信してステップS282に移行する。一方、ステップS278で、記憶ID中に他機より受信したものがあることが検出できなければ直接ステップS282に移行する。 ステップS282では、ステップS264、ステップS268、ステップS272およびステップS276で記憶したID中、外部サーバよりダウンロードしたものがあるかどうかチェックする。そして外部サーバからダウンロードした記憶IDがあればステップS284に進み、記憶IDに対応するデータを第1電話通信部24からのインターネット経由でダウンロードしてステップS286に移行する。一方、ステップS282で、記憶ID中に外部サーバよりダウンロードしたしたものがあることが検出できなければ直接ステップS286に移行する。
ステップS286では、ステップS280における受信またはステップS284におけるダウンロードによって取得したデータを第1ゲーム記億部に登録する。 以上のように、本発明の実施例では、第1近距離通信部26を利用して楽しむゲーム関連データを第1電話通信部24からのインターネット経由で外部サーバより入手する。この場合、周囲の他機が既にゲーム関連データをダウンロードして入手している可能性があるので、まず、第1近距離通信部26によって他機からのゲーム関連データの取得を試みる。そして他機にゲーム関連データがなければ自身で外部サーバにインターネット経由でアクセスし、これらのゲーム関連データをダウンロードする。なお、自身が入手したゲーム関連データは、第1近距離通信部26から周囲の他機への移植を試みる。 これら、ゲーム関連データの取得と共有による更新の詳細は図14および15図のフローチャートによって行われるが、図5のステップS26に明らかなように、ゲーム終了の際に必ずこれらのゲームデータ更新処理が行われるよう構成し、ゲーム関連データの取得と共有を促進する。
図16は、図9、図10および図12それぞれにおいて共通のステップS120における統計処理の詳細を示すフローチャートである。着信した個別応答の記憶がステップS118で行われてステップS120に至るとフローがスタートし、ステップ292でテンプレートゲームに関する応答であるかどうかがチェックされる。テンプレートゲーム応答である場合はステップS294に進み、応答に対応するゲームのIDを確認する。そして確認されたIDに基づき、ステップS296で対応するテンプレートゲームに共通のアプリケーションソフトが起動される。この共通ソフトは、テンプレートに入力された設問や選択肢などの内容に係らず共通のものである。 ソフトが起動されると、ステップS298に進み、記憶されている応答の中から一つの応答選択肢を抽出する。そして、抽出した選択肢に対応する設問のIDをステップS300で確認する。さらに、ステップS302で、抽出した選択肢自体のIDを確認する。以上によって、設問とこれに対してなされたIDが確定するので、ステップS304に進み、確定したIDを元に設問別かつ選択肢別に分類し、対応する累積カウントに加える。
カウントが終了すると、ステップS306で未集計の選択肢が残っていないかどうかチェックし、未集計選択肢があればステップS298に戻って、次の選択肢を抽出する。なお、このとき抽出されたものが異なる設問に対する選択肢であったときは、ステップS300でそのことが検出され、ステップS304における累積カウントの分類は異なった設問に対するものとされる。 以下、ステップS306において未集計の選択肢がもう存在しないことが確認されるまで、ステップS298からステップS306のループが繰り返される。なお、このループは設問や選択肢の内容にかかわらず、共通ソフトによって形式的に処理される。
以上のようにして、記憶されている応答選択肢が全て分類カウントされるとステップS306において未集計の選択肢がないと判断されるので、ステップS308に進み、設問テンプレートに入力された設問内容が読取られる。さらに、ステップS310では、各選択肢テンプレートに入力された選択肢内容が読取られる。そしてステップS312では選択肢毎に累積された最終カウント値が読取られる。ステップS314では、これらの読取り内容に基づき、集計結果の表示に適用すべき集計レイアウトを決定する。具体的には、対応ゲームについて予め用意されている共通の複数のレイアウトの中から、ステップS308からステップS312での読取り内容の表示に最適のものを決定し、決定されたレイアウトをそのIDにて指定する。ゲームの参加者は、すでに各設問とその選択肢の内容に関する情報およびレイアウトデータを持っているので、統計結果として各参加者に送信するのは、ステップS312で読取った設問別選択肢別最終カウント値とステップS314で指定される集計レイアウトIDだけでよい。これによって参加者は、予め持っているデータと統計結果として受信したデータとに基づいて、図2から図4のいずれかに示すようなレイアウトの統計結果を自分の携帯電話で表示することができる。
以上のように、テンプレートゲームでは、テンプレートに入力した内容に係らず、共通のソフトウエアによってゲーム進行の処理が行われるとともに、その結果の表示についても共通のレイアウトが適用される。これによって、ユーザは最も関心のある設問と選択肢の工夫の集中できるので、ゲームの運用にかかる部分に労力を割く必要がなく、ゲームの提案が容易となる。さらに、ゲームの運用にかかるソフトウエアはゲーム参加者で共有しているので、ゲーム参加者間で交換するデータは、共有しているデータを指定するIDと最低限の情報内容だけで済むことになる。 なお、ステップS292において応答がテンプレートゲームに対するものでなかったときはステップS316に進み、それぞれのゲームに特有の統計処理を行う。
図17は、図9、図10および図12それぞれにおいて共通のステップS114における初期情報の参加者全員への送信の詳細を示すフローチャートである。ステップS113においてフローが図7のゲーム提唱処理経由で開始されたことが確認されてステップS114に至り、図17のフローがスタートすると、ステップS322で参加者に送信すべき初期情報がテンプレートゲームに関するものかどうかがチェックされる。テンプレートゲームであれば、ステップS324でゲームのIDを送信する。これは、受信者側においてもすでに各種のテンプレートゲームを処理するための複数のソフトが共有されており、ゲームIDの指定だけで受信者側における指定されたゲームの処理が可能となることによる。 次いで、ステップS326で、参加者への設問に付与されたIDを送付するとともにステップS328でそのIDに対応する設問の内容を送信する。さらにステップS330で、この設問に対応する応答の選択肢の一つに付与されたIDを送付するとともにステップS332でそのIDに対応する選択肢の内容を送信する。そして、ステップS334で未送信の選択肢があるかどうかチェックする。未送信選択肢があれば、フローはステップS330に戻り、設問に対する次の選択肢のIDを送信する。以下、未送信選択試がなくなるまでステップS330からステップS334を繰り返す。
ステップS334で未送信選択肢がなくなったことが検出されるとステップS336に移行し、応答締切に関する情報を送信する。さらにステップS338では、図8のステップS107で割当てられた交信時間を送信する。この交信割当時間は参加者毎に異なるので、各参加者を特定してそれぞれ個別に送信するかまたは、全参加者の割当表を一括して送信する。 以上で図17のフローを終了するが、ステップS332でテンプレートゲームの送信ではないことが検出された場合は、直接ステップS340に進み、そのゲーム特有の情報を送信する処理をしてフローを終了する。
図18は、図9、図10および図12それぞれにおいて共通のステップS144における参加者側の統計結果表示処理の詳細を示すフローチャートである。ステップS142において統計結果受が検出されてステップS144に至り、図18のフローがスタートすると、ステップS342でテンプレートゲームの統計結果が受信されたかどうかチェックする。 テンプレートゲームの統計結果であれば、ステップS344で受信情報の中からゲーム関連IDを読取る。ゲーム関連IDには、ゲームID、設問ID、および選択肢IDなどが含まれる。次いでステップS346に進み、読取られたIDで指定される設問テンプレートに入力された設問内容が読取られる。これらの設問内容および選択肢内容は、既に、図17のフローにおいて初期情報として受信済みである。さらに、ステップS348では、読取られたIDで指定される各選択肢テンプレートに入力された選択肢内容がそれぞれ読取られる。そしてステップS350では選択肢毎に累積された最終カウント値が読取られる。
次に、以上のようにして得られた統計結果表示用情報を表示する。まず、ステップS352では、受信情報の中で集計表示に適用すべきレイアウトが指定されているかどうかチェックする。具体的には、ステップS344で読取られたゲーム関連IDの中に適用すべき集計レイアウトを指定するIDが含まれているかどうかチェックする。適用集計レイアウトを指定するIDがあればステップS354に進み、このIDを読取ってステップS356に移行する。一方、ステップS352でレイアウト指定がなかったときはステップS358で所定のレイアウトを適用してステップS356に移行する。 以上で統計表示の情報内容およびこれを表示するための情報が揃うので、ステップS356ではこれらの情報に基づき表示画面データを作成する。そして、ステップS360で統計結果の表示を実行し、フローを終了する。 一方、ステップS342でテンプレートゲームの統計結果を受信したのではない場合は、ステップS362に移行しゲーム特有の表示処理を行ってフローを終了する。
なお、上記における図18のフローは、参加者側の統計結果表示処理の詳細を示すフローチャートであるとして説明したが、図9、図10および図12それぞれにおいて共通のステップS123における提案者側での統計結果表示処理の詳細を示すフローチャートも基本的に同様の構成を持つ。但し、ステップS342は、受信された統計結果ではなく、ステップS120で自身が処理した統計結果について判断を行う。 さらに、図18のフローは、統計処理の途中経過の表示だけでなく、図9、図10および図12それぞれにおいて共通のステップS130またはステップS148における最終結果の表示においても同様に使用される。