以下、図面を参照しながら、本発明の実施形態について説明する。また、図面において同一の構成要素は、同じ番号を付し、説明は、適宜省略する。
図1は、ゲームシステムの構成例を示したブロック図である。図1のゲームシステム100は、ゲームサーバ1と、決済サーバ2と、賞品サーバ3と、ネットワーク6と、情報端末7と、情報端末8とを含んでいる。ゲームサーバ1、決済サーバ2、情報端末7と、情報端末8は、ネットワーク6を介して互いに通信可能である。ネットワーク6は、例えば、複数のコンピュータネットワークが相互に接続されたインターネットである。ネットワーク6は、通信媒体として有線、無線または、これらの組み合わせを用いることができる。また、ネットワーク6で使われる通信プロトコルの例としては、TCP/IPがあるが、通信プロトコルの種類については特に問わない。
ゲームサーバ1、決済サーバ2、賞品サーバ3は、いずれも中央演算処理装置(CPU)とメモリとを含むコンピュータ(情報処理装置)である。ゲームサーバ1は、例えば、データセンターに設置されたサーバである。ただし、ゲームサーバ1は、デスクトップPC、ノートPCなどその他の種類のコンピュータであってもよい。また、ゲームサーバ1が設置される場所については、特に問わない。ゲームサーバ1は、例えば、ユーザがゲームで使うキャラクタの管理、ユーザへのゲームの提供、ユーザが保有する参加フィーおよびポイントの管理、ユーザが獲得したポイントと賞品との交換の処理を行う。なお、これらの処理は必ず同一のコンピュータによって実行されなくてもよい。例えば、これらの処理の少なくとも一部が異なるコンピュータによって実行されてもよい。また、上述の処理のそれぞれが異なるコンピュータによって実行されてもよい。
決済サーバ2の例としては、金融機関のシステムサーバ、仮想通貨の管理サーバが挙げられる。ただし、決済サーバ2は、どのような種類のコンピュータであってもよく、決済サーバ2の管理主体については、特に問わない。決済サーバ2は、例えば、ユーザが法定通貨または仮想通貨などで参加フィーを購入した際に、口座の残高を更新し、対価の決済処理を実行する。なお、決済サーバ2は、1台のコンピュータでなくてもよい。例えば、決済サーバ2は、複数台のコンピュータが互いに電気通信回線(ネットワーク)で接続された情報処理システムであってもよい。
賞品サーバ3の例としては、賞品の発送を行う業者のサーバ、賞品の製造販売を行う事業者のサーバ、賞品に相当する経済的な利益(特典)を付与する業界団体のサーバが挙げられる。ただし、賞品サーバ3は、どのような種類のコンピュータであってもよく、賞品サーバ3の管理主体については、特に問わない。賞品サーバ3は、例えば、ゲームサーバ1にユーザへ提供可能な賞品に関する情報を提供する処理、賞品をユーザに発送する処理、ユーザに経済的な利益を付与する処理を実行する。なお、これらの処理は必ず同一のコンピュータによって実行されなくてもよい。例えば、これらの処理の少なくとも一部が異なるコンピュータによって実行されてもよい。また、上述の処理のそれぞれが異なるコンピュータによって実行されてもよい。
図1では、ゲームサーバ1、決済サーバ2、賞品サーバ3がそれぞれ1台ずつ示されている。ただし、各サーバの台数はこれとは異なっていてもよい。また、ゲームサーバ1、決済サーバ2、賞品サーバ3の機能の少なくとも一部は、仮想コンピュータ(VM:Virtual Machine)やコンテナによって実現されていてもよい。また、複数台のコンピュータによってゲームサーバ1、決済サーバ2、賞品サーバ3の機能が実現されていてもよい。図1では、ゲームサーバ1、決済サーバ2、賞品サーバ3がそれぞれ別々のコンピュータとなっているが、この構成は一例にしかすぎない。例えば、ゲームサーバ1の少なくとも一部の機能と、決済サーバ2の少なくとも一部の機能が同一のコンピュータによって実現されていてもよい。
情報端末7は、ラップトップPCである。また、情報端末8は、スマートフォンである。情報端末7、8は、いずれも無線通信(例えば、無線LANまたはモバイル通信)によって、ネットワーク6に接続された他の装置との間でデータの送受信を行うことができる。ラップトップPCやスマートフォンは、情報処理システムで使用可能な情報端末の例にしかすぎない。したがって、ゲーム専用機、デスクトップPC、タブレット、車載機器などその他の種類の情報端末が用いられてもよい。また、ネットワーク6と有線で接続された情報端末を使ってもよい。ユーザは、情報端末をクライアントとして使い、リモート環境でゲームサーバ1を操作することができる。図1には2台の情報端末が示されているが、情報端末の台数はこれより多くてもよい。
図2は、ゲームサーバの構成例を示したブロック図である。以下では、図2を参照しながら、ゲームサーバ1の各構成要素について説明する。ゲームサーバ1は、演算処理部10と、記憶部12と、通信部13と、入力部14と、出力部15とを備えている。また、ゲームサーバ1には、操作装置4と、表示装置5とが接続されている。
操作装置4は、ゲームサーバ1に各種の情報を入力するための装置である。操作装置4は、例えば、キーボード、マウス、タッチパネル、音声認識装置などであるが、これに限られない。表示装置5は、ゲームサーバ1から出力される画像、映像、テキストなどを表示するための装置である。表示装置5の例としては、LCD(液晶ディスプレイ)、有機EL(有機エレクトロルミネッセンス)ディスプレイ、プロジェクタがあるが、これに限られない。管理者は、操作装置4および表示装置5を使い、ゲームサーバ1に各種の操作を行うことができる。なお、管理者によって使用される操作装置4または表示装置5の少なくともいずれかは、ゲームサーバ1に組み込まれたものであってもよい。また、ゲームサーバ1には、必ず操作装置4および表示装置5が接続されていなくてもよい。この場合、管理者またはユーザは、上述の操作装置4および表示装置5に相当した機能を兼ね備えた情報端末を使ってゲームサーバ1を操作することができる。
演算処理部10は、演算を実行し、ゲームサーバ1全体を制御する電子回路である。演算処理部10として、例えば、CPU、マイクロプロセッサ、ASIC、FPGA、PLDまたはこれらの組み合わせを用いることができる。ゲームサーバ1の機能の少なくとも一部は、演算処理部10の電子回路によって実現されてもよい。また、ゲームサーバ1の機能の少なくとも一部は、演算処理部10上で実行されるプログラムによって実現されてもよい。この場合、プログラムは、一時的でない有形のコンピュータ読み取り可能な記憶媒体(例えば、後述の記憶部12)に保存される。
演算処理部10は、内部の構成要素として、ウェブサーバ部11と、ゲーム管理部40と、システム管理部50とを含んでいる。さらに、ゲーム管理部40は、内部の構成要素として、モンスター管理部41と、予選ゲーム管理部42と、本選ゲーム管理部43と、決勝ゲーム管理部44とを含んでいる。また、システム管理部50は、内部の構成要素として、ユーザ管理部51と、参加フィー管理部52と、ポイント管理部53と、賞品選択部54とを含んでいる。ウェブサーバ部11は、ブラウザを使ってアクセス可能なゲームサイトのウェブページを提供する。ユーザは、ウェブサーバ部11によって提供されるゲームサイトにアクセスし、参加フィーの購入、ゲームのプレイ、ポイントと賞品との交換などを行うことができる。ゲームサイトのブラウザ画面は、上述の表示装置5または、各ユーザが使う情報端末のディスプレイに表示される。なお、ユーザに提供されるゲームは、ブラウザ上でプレイされるものに限られない。例えば、ゲームは、情報端末上で実行されるゲームアプリを使ってプレイされるものであってもよい。この場合、演算処理部10は、ゲームアカウント管理、ポイントの付与、トーナメント戦の情報の共有、他ユーザとのチームプレイなどゲームアプリとの連携などの処理を行う。
ゲーム管理部40は、ユーザが参加フィーを使ってプレイできる予選ゲームと、少なくとも予選ゲームをプレイしたことのある、複数のユーザでチームを結成し、チームでプレイできる決勝ゲームとを実行する。なお、ゲーム管理部40は、さらに予選ゲームをプレイしたことのあるユーザがプレイでき、チームを結成しなくてもプレイ可能な本選ゲームを実行してもよい。モンスター管理部41は、各ユーザがゲームプレイ時に使用するキャラクタであるモンスターの情報を管理する。予選ゲーム管理部42は、各ユーザに予選ゲームの機能を提供する。本選ゲーム管理部43は、各ユーザに本選ゲームの機能を提供する。決勝ゲーム管理部44は、各ユーザに決勝ゲームの機能を提供する。なお、ゲームが情報端末上で実行されるゲームアプリを使ってプレイするものである場合、ゲーム管理部40の機能の一部は、当該ゲームアプリ上に実装されていてもよい。
システム管理部50は、ゲームをプレイするユーザの情報を管理し、賞品選択の機能を提供する。ユーザ管理部51は、例えば、ユーザアカウントの登録処理と、複数のユーザが含まれるチームの生成/更新処理とを実行する。参加フィー管理部52は、ユーザに参加フィーを付与し、各ユーザが保有する参加フィーの残高を更新する。参加フィーは無償でユーザに付与されてもよいし、ユーザに有償で付与されてもよい。ポイント管理部53は、決勝ゲームのプレイに応じてユーザまたはチームの少なくともいずれかにポイントを付与する。ポイントは、ユーザに付与される場合もあれば、チームに付与される場合もある。なお、ゲーム管理部40で本選ゲームが実行される場合、ポイント管理部53は、本選ゲームをプレイするユーザにポイントを付与してもよい。ポイント管理部53は、例えば、各ユーザが保有する個人ポイントの残高の更新処理と、各チームが保有するチームポイントの残高の更新処置とを実行する。賞品選択部54は、個人ポイントまたはチームポイントとの交換によって各ユーザが取得する賞品の選択を実現する。さらに、賞品選択部54は、チームポイントとの交換によって各チームが取得する賞品の選択を実現する。賞品選択部54でユーザが選択できる賞品は、商品、役務、経済的な利益の少なくともいずれかを含んでいてもよい。
以降では、ユーザに付与される個人ポイントと、チームに付与されるチームポイントの2種類のポイントが使われている場合を中心に説明する。チームポイントは必ずチームに帰属していなくてもよい。例えば、チームに付与されたチームポイントをチームに所属するユーザに分配してもよい。後述するように、ゲームシステム100で、必ず2種類のポイントを使う必要はない。例えば、決勝ゲームをプレイするチームにチームポイントを付与する代わりに、決勝ゲームをプレイするチームに所属するユーザに個人ポイントを付与してもよい。なお、単にポイントを述べた場合、それは個人ポイントとチームポイントの両方を含むものとする。
記憶部12は、ゲームサーバ1のプログラム、プログラムの実行に必要なデータ、プログラムによって生成されたデータを含む各種のデータを記憶するメモリまたは/およびストレージである。ここで、プログラムは、OSとアプリケーションの両方を含むものとする。メモリまたは/およびストレージは、揮発性メモリ、不揮発性メモリ、またはこれらの組み合わせであってもよい。揮発性メモリの例としては、DRAM、SRAMなどがある。不揮発性メモリの例としては、NANDフラッシュメモリ、NORフラッシュメモリ、ReRAM、MRAMが挙げられる。また、ストレージとして、ハードディスク、光ディスク、磁気テープまたは外部の記憶装置が使われてもよい。
通信部13は、ネットワーク6に接続された各装置とデータとの送受信を行う通信回路である。通信部13、例えば、有線LANのNIC(Network Interface Card)である。ただし、通信部13は、無線LANなど、その他の種類の通信回路であってもよい。
入力部14は、ゲームサーバ1へのデータ入力を実現する回路である。例えば、操作装置4は入力部14を介してゲームサーバ1に接続される。入力部14の例として、USB、PCI−Express、シリアルポートなどのインタフェースがあるが、その他のインタフェースを使ってもよい。出力部15、ゲームサーバ1からのデータ出力を実現する回路である。例えば、上述の表示装置5は出力部15を介してゲームサーバ1に接続される。出力部15の例として、HDMI、DisplayPortなどのインタフェースがあるが、その他の種類のインタフェースを使ってもよい。
図3は、ゲームサーバに保存されるデータの例を示している。以下では、図3を参照しながら、ゲームサーバ1で使われる各データについて説明する。図3の記憶部12には、賞品授与プログラム55と、賞品交換レートデータ56と、ウェブサーバプログラム57と、ゲームプログラム60と、ゲームデータ70と、ユーザデータ80と、チームデータ90とを含んでいる。ゲームプログラム60は、予選ゲームプログラム61と、本選ゲームプログラム62と、決勝ゲームプログラム63とを含んでいる。ゲームデータ70は、モンスターデータ71と、予選ゲームデータ72と、本選ゲームデータ73と、決勝ゲームデータ74とを含んでいる。チームデータ90は、チームポイントデータ91を含んでいる。
演算処理部10で賞品授与プログラム55が実行されることにより、上述の賞品選択部54の機能が実現される。賞品交換レートデータ56は、各種の賞品とポイントとの間の交換レートに関する情報を含む。例えば、賞品選択部54は、賞品交換レートデータ56を参照し、情報端末のディスプレイ上にそれぞれの賞品を得るために必要なポイント数を表示させることができる。演算処理部10でウェブサーバプログラム57が実行されることにより、上述のウェブサーバ部11の機能が実現される。また、演算処理部10でゲームプログラム60が実行されることにより、上述のゲーム管理部40の機能が実現される。予選ゲームプログラム61、本選ゲームプログラム62、決勝ゲームプログラム63は、それぞれ上述の予選ゲーム管理部42、本選ゲーム管理部43、決勝ゲーム管理部44の機能を実現するプログラムに相当する。
ユーザデータ80には、各ユーザアカウントに関連付けられた情報が含まれている。参加フィーデータ81は、各ユーザの保有している参加フィーの残高に関する情報を含む。個人ポイントデータ82は、各ユーザの保有している個人ポイントの残高に関する情報を含む。ユーザモンスターデータ83は、各ユーザがゲームで使っているモンスターに関する情報を含む。ここで、モンスターに関する情報の例としては、ユーザがモンスターにつけた名前、モンスターの経験値、モンスターのレベル、モンスターの能力値、モンスターが参加したイベント数、モンスターの戦績が挙げられる。チームデータ90には、チームに参加しているユーザの一覧を含む、チームに関する情報が含まれている。チームポイントデータ91は、各チームが保有しているチームポイントに関する情報を含む。
図4は、決済サーバの構成例を示したブロック図である。以下では、図4を参照しながら、決済サーバ2の各構成要素について説明する。決済サーバ2は、通信部20と、演算処理部21と、記憶部23とを備えている。また、演算処理部21は、内部の構成要素として決済部22を備えている。決済サーバ2の通信部20は、ネットワーク6に接続された他の装置とデータの送受信を行う通信回路である。通信部20は、例えば、有線LANのNIC(Network Interface Card)である。ただし、通信部20は、無線LANなど、その他の種類の通信回路であってもよい。
決済サーバ2の演算処理部21は、演算を実行し、決済サーバ2全体の制御を行う電子回路である。演算処理部21として、例えば、CPU、マイクロプロセッサ、ASIC、FPGA、PLDまたはこれらの組み合わせを用いることができる。決済サーバ2の機能の少なくとも一部は、演算処理部21の電子回路によって実現されてもよい。また、決済サーバ2の機能の少なくとも一部は、演算処理部21でプログラムを実行することによって実現されてもよい。この場合、プログラムは、一時的でない有形のコンピュータ読み取り可能な記憶媒体(例えば、後述の記憶部23)に保存される。決済部22は、法定通貨または仮想通貨による決済の処理を行う。
決済サーバ2の記憶部23は、決済サーバ2のプログラム、プログラムの実行に必要なデータ、プログラムによって生成されたデータを含む各種のデータを記憶するメモリまたは/およびストレージである。ここで、プログラムは、OSとアプリケーションのいずれも含むものとする。メモリまたは/およびストレージは、揮発性メモリ、不揮発性メモリ、またはこれらの組み合わせであってもよい。揮発性メモリの例としては、DRAM、SRAMなどがある。不揮発性メモリの例としては、NANDフラッシュメモリ、NORフラッシュメモリ、ReRAM、MRAMが挙げられる。また、ストレージとして、ハードディスク、光ディスク、磁気テープまたは外部の記憶装置が使われてもよい。
図4の記憶部23には、残高データ24と、決済プログラム25とが保存されている。残高データ24は、各ユーザの法定通貨または仮想通貨の残高に関する情報を含む。演算処理部21で決済プログラム25が実行されることにより、決済部22の機能が実現される。
図5は、賞品サーバの構成例を示したブロック図である。以下では、図5を参照しながら、賞品サーバ3の各構成要素について説明する。賞品サーバ3は、通信部30と、演算処理部31と、記憶部33とを備えている。また、演算処理部31は、内部の構成要素として賞品管理部32を備えている。賞品サーバ3の通信部30は、ネットワーク6に接続された他の装置とデータの送受信を行う通信回路である。通信部30は、例えば、有線LANのNIC(Network Interface Card)である。ただし、通信部20は、無線LANなど、その他の種類の通信回路であってもよい。
賞品サーバ3の記憶部33は、賞品サーバ3のプログラム、プログラムの実行に必要なデータ、プログラムによって生成されたデータを含む各種のデータを記憶するメモリまたは/およびストレージである。ここで、プログラムは、OSとアプリケーションのいずれも含むものとする。メモリまたは/およびストレージは、揮発性メモリ、不揮発性メモリ、またはこれらの組み合わせであってもよい。揮発性メモリの例としては、DRAM、SRAMなどがある。不揮発性メモリの例としては、NANDフラッシュメモリ、NORフラッシュメモリ、ReRAM、MRAMが挙げられる。また、ストレージとして、ハードディスク、光ディスク、磁気テープまたは外部の記憶装置が使われてもよい。
図5の記憶部33には、賞品在庫データ34と、賞品管理プログラム35とが保存されている。賞品在庫データ34は、例えば、ユーザ/チームに与えることが可能な賞品の種類、各種の賞品の在庫の有無、各種の賞品の在庫数、特典(経済的な利益)を受けられることができる人数に関する情報を含む。演算処理部21で賞品管理プログラム35が実行されることにより、賞品管理部32の機能が実現される。
(ゲームの概要)
図6は、ゲームシステムの構成例を概略的に示したブロック図である。図6に示されているように、ゲームシステムは、例えば、予選ゲームと、本選ゲームと、決勝ゲームとを含む。はじめに、ユーザは購入した参加フィーおよび/または付与された参加フィーを使って予選ゲームをプレイする。そして、予選ゲームをプレイすることにより、ユーザは、本選ゲームへの参加資格を得ることができる。ユーザは、本選ゲームをプレイすることによって得られた個人ポイントを使い、賞品を獲得することができる。本選ゲームをプレイしたユーザは、所定の条件を満たすことにより、決勝ゲームへの参加資格を得ることができる。決勝ゲームでは、複数のユーザがチームを形成し、チームとしてゲームプレイをすることができる。決勝ゲームをプレイしたチームはチームポイントを得ることができる。チームポイントを使うことにより、チームとして賞品を獲得することができる。また、チームポイントの少なくとも一部をチームに所属するユーザ(チームメンバー)に分配し、各ユーザに賞品と獲得させてもよい。
ただし、破線の矢印28で示されているように、少なくとも予選ゲームをプレイしたユーザに決勝ゲームへの参加資格を与えてもよい。すなわち、本選ゲームのプレイを、決勝ゲームに参加するための前提条件にしなくてもよい。なお、図6に示されている遷移パターンは一例にしかすぎない。したがって、本選ゲームまたは決勝ゲームに参加したことのあるユーザが再び予選ゲームをプレイすることを許容してもよい。また、決勝ゲームに参加したことのあるユーザが再び本選ゲームをプレイすることを許容してもよい。
なお、以降では、主に、ゲームシステム100のコンテンツとして、予選ゲーム、本選ゲーム、決勝ゲームが提供される場合(例えば、図6)の場合を想定した説明を行う。ただし、ゲームシステムでは、必ず予選ゲームの後にプレイするコンテンツとして、チームを結成しなくてもプレイ可能な本選ゲームが提供されていなくてもよい。例えば、図7のゲームシステムでは、予選ゲームをプレイしたユーザに決勝ゲームへの参加資格が与えられる(実線の矢印28a)。そして、ユーザは、決勝ゲームにおいて、複数のユーザでチームを結成し、チームで決勝ゲームをプレイする。そして、決勝ゲームをプレイしたチームはチームポイントを得る。そして、チームポイントを使うことにより、チームとして賞品を獲得してもよいし、チームポイントの少なくとも一部をチームに所属するユーザ(チームメンバー)に分配し、各ユーザに賞品と獲得させてもよい。また、チームに所属するユーザに個人ポイントが付与されてもよい。この場合、ユーザは、個人ポイントを使って賞品を獲得することができる。決勝ゲームに参加したことのあるユーザが、再び予選ゲームをプレイすることを許容してもよい(破線の矢印27a)。
以下では、ゲームシステム100で各ユーザがゲーム中のキャラクタとしてモンスターを使う対戦ゲームが提供されている場合を例に、説明を行う。それぞれの対戦(マッチ)では、モンスター間の戦闘(バトル)が行われるものとする。ただし、ゲームで使われるキャラクタは、格闘家、戦士、魔法使い、ロボット、マンガ/アニメーションの登場人物などその他の種類のものであってもよい。また、ゲームの種類および内容を限定するものではない。例えば、ゲームの種類は、アクションゲーム、ロールプレイングゲーム(RPG)、シミュレーションゲーム、パズルゲーム、シューティングゲーム、アドベンチャーゲーム、スポーツゲーム、レースゲーム、音楽ゲーム、ボードゲーム、テーブルゲーム、クイズゲームまたは、これらを組み合わせたもののいずれであってもよい。予選ゲーム、本選ゲーム、決勝ゲームの少なくともいずれかで共通する種類のゲームが採用されていてもよい。また、予選ゲーム、本選ゲーム、決勝ゲームで、異なる種類のゲームが採用されていてもよい。
(ゲームへの参加時)
図8は、ゲームシステムのログイン画面の例を示している。初めて当該ゲームシステムをプレイするユーザは、「アカウントを作る」ボタンをクリックし、ゲームシステムのアカウントを作成する。アカウントの入力画面(図示せず)では、例えば、アカウントのユーザ名、アカウントのパスワード、ユーザの氏名、生年月日、メールアドレス、電話番号、住所などの情報を入力する。アカウントが作成されたら、ユーザはユーザ名およびパスワードを入力し、「ログイン」ボタンをクリックする。なお、新たなアカウントの作成を求めず、ユーザが持っている他のサービス(例えば、ポータルサイト、SNS、動画サイト、ウェブメール)の既存アカウントを使ってゲームにログインできるようにしてもよい。また、ウェブサイトで複数のゲームが提供されている場合、他のゲームと共通のアカウントを使ってログインできるようにしてもよい。
なお、以降ではボタン、タイルなどGUI上の要素に対してクリック操作が行われるものとして説明を行うが、GUI上の要素に対して行われる操作は、クリック操作に限られない。例えば、GUI上の要素に対してタップ、スワイプ、ピンチ、リターンキーの押下、スペースキーの押下などの操作が行われてもよい。また、ユーザのジェスチャ、ユーザが発する音声に基づいて操作が行われてもよい。
図9は、モンスターの選択画面の例を示している。図9の画面には2種類のモンスターのみが表示されているが、画面左側および画面右側にある三角形状ボタンをクリックすることにより、他の種類のモンスターを表示させることも可能である。ユーザは、表示されているいずれかのモンスターの絵をクリックし、モンスターを選択状態にした後、「このモンスターを選ぶ」ボタンをクリックすることによって、ゲーム内で使うモンスターを決定することができる。図9の画面は一例にしかすぎない。したがって、これとは異なる画面上で、ユーザに使うモンスターを決めさせてもよい。
図9の右上には、女性キャラクタが表示されている。この女性キャラクタは、モンスター使いの高校生であり、ゲーム中では、ユーザに各種の助言を行うアドバイザーとしての役割を果たす。アドバイザーがいるため、初心者のユーザも安心してゲームをプレイすることができる。アドバイザーとなるキャラクタは、図9の例と異なっていてもよい。例えば、アドバイザーは男性キャラクタであってもよい。また、アドバイザーは、動物、ロボット、エイリアン、空想上の生き物などその他の種類のキャラクタであってもよい。また、ユーザの希望によってアドバイザーとなるキャラクタを選択できるようにしてもよい。なお、ゲームに必ずアドバイザーとなるキャラクタが存在していなくてもよい。
図10は、モンスターの名前を入力する画面の例を示している。ユーザは、図10の画面のテキストボックスに名前を入力後、「確定」ボタンをクリックすることによって、モンスターの名前を決定することができる。画面に表示されているように、モンスターの名前はゲームにおけるユーザのハンドルネーム(あだ名)にもなる。図10では、モンスターの名前およびユーザのハンドルネームとして、「アントニウス」が入力されている。
図11は、参加フィーの購入画面の例を示している。ユーザは、予選ゲームでモンスターの能力をアップさせるために、参加フィーを用意する必要がある。図11の画面で、ユーザは、参加フィーを購入することができる。ユーザは、法定通貨で参加フィーを購入してもよい。また、ユーザは、電子マネー、プリペイドカード、仮想通貨、各種サービスのポイントなどその他の手段で参加フィーを購入してもよい。なお、ユーザの年齢に応じ、参加フィーの購入に制限を設けてもよい。例えば、16歳未満のユーザが、参加フィーの購入をできないようにしてもよい。また、ユーザの年齢によって、購入できる参加フィーに上限を設けてもよい。例えば、16歳〜19歳のユーザに対し、参加フィーの購入に使える法定通貨の額に上限を設けてもよい。未成年者は、親権者など法定代理人であるユーザの承認が得られないと、参加フィーを購入できないようにしてもよい。なお、参加フィー管理部52は、ユーザ間で参加フィーの譲渡を行うことを許容してもよい。これにより、未成年者自身が参加フィーの購入を行わず、代わりに親権者など法定代理人が未成年者に対し、ゲームプレイに必要な参加フィーを分け与えることができる。
なお、ユーザによる参加フィーの購入をゲームプレイの前提条件としなくてもよい。参加フィー管理部52は、ユーザに無償で参加フィーを付与してもよい。例えば、ゲームのアカウントが作成されたら、特典として一定の参加フィーをユーザに付与してもよい。図11の例では、アカウントを作成したユーザに100Fが無償で与えられている。(Fは、フィーの英語“Fee”の頭文字をとったものである。)また、図11に示されているように、所定のキャンペーンコードを入力したら、ユーザに参加フィーが与えられるようにしてもよい。キャンペーンコードは、例えば、ユーザが各種ウェブサイトにおけるゲームの広告をクリックしたら表示されるものであってもよいし、各種のイベント、販促資料、ゲーム/アニメなどの紹介サイトで告知されるものであってもよい。また、アンケートに回答したユーザをゲームに招待し、無償で参加フィーを付与してもよい。なお、ユーザに無償で与えられる参加フィーの額、参加フィーの購入時におけるレート(例えば、1参加フィーの購入に必要な法定通貨の額)については、特に問わない。
ユーザに参加フィーを無償で付与することにより、予算の制約のあるユーザや、未成年のユーザにゲームの楽しさを体験させることが可能となる。ユーザは、図11の画面下部に表示された「プレイを開始する」ボタンをクリックすることにより、ゲーム(より具体的には、予選ゲーム)のプレイを始めることができる。
図11に示したように、予選ゲームのプレイを開始する前のユーザに、参加フィーの購入をする機会を与えたり、参加フィーを付与したりすることができる。ただし、ユーザが予選ゲームのプレイをしているときに、参加フィーを購入する機会を与えたり、参加フィーを付与したりしてもよい。例えば、予選ゲームの画面中に臨時店舗が出現している期間など、参加フィーの購入ができるタイミングを限定してもよい。さらに、予選ゲーム中に発生するイベントの結果に応じて、ユーザに参加フィーを与えてもよい。
(予選ゲーム)
予選ゲームは、本選ゲームおよび決勝ゲームに参加する前の準備ステージに位置付けられる。以下に述べる予選ゲームは、モンスターの育成プロセスまたは、訓練プロセスをユーザに体感させ、モンスターに対する愛着を持たせる性質を有する。以下の予選ゲームにおいて、ユーザは、モンスターが本選ゲームおよび決勝ゲームで好成績を残せるよう、モンスターの能力値を高めることができる。
図12は、モンスターの能力値表示画面の例を示している。図12には、モンスターの名前、モンスターの種類、モンスターのレベル、HP(ヒットポイント)の現在値、現レベルにおけるHPの最大値、MP(マジックポイント)、現レベルにおけるMPの最大値、攻撃力、防御力、すばやさ、かしこさ、および総経験値が表示されている。図12に表示されている能力値は一例にしかすぎない。したがって、能力値はこれらのすべての項目を含んでいなくてもよいし、能力値はその他の項目を含んでいてもよい。モンスターは、経験値に応じたレベル(例えば、レベル1〜レベル99)となり、レベルが上がるほど各能力値が上昇する。図12に示された、各ユーザのモンスターの能力値は、ユーザモンスターデータ83で管理される。一方、それぞれの種類のモンスターの各レベルにおける能力値は、モンスターデータ71で定義されている。図12の画面では、女性キャラクタが次のレベル(レベル29)になるのには、経験値があと33必要である旨を述べている。予選ゲームにおいて、ユーザは、参加フィーを使い、モンスターを練習試合に参加させたり、修行を積ませたりすることにより、モンスターの有する経験値を増やすことができる。
図13は、予選ゲームにおける画面の例を示している。図13の上側には、道場が表示されている。ユーザは、参加フィーを5F使うことによって、道場でモンスターに練習試合をさせることができる。練習試合を行うと、画面には図14に例示したような他モンスターとの戦闘シーンが表示される。ユーザは、各ターンにおいて「戦う」「守る」「呪文を使う」「道具を使う」などのコマンドを選択することにより、自分のモンスターを他のモンスターと戦わせることができる。他のモンスターとの練習試合は、いずれかのモンスターのHPが0になるまで続く。ユーザは、他のモンスターを倒したら、(すなわち、他のモンスターのHPを0にしたら)自分のモンスターに経験値を獲得させることができる。ユーザは、自分のモンスターのHPが試合中に0になるまで、次々と他のモンスターとの練習試合を行うことができる。できる限り多くのモンスターを倒すほど、ユーザは自分のモンスターに多くの経験値を獲得させることができる。
ここで説明した練習試合の内容は一例にしかすぎない。したがって、練習試合は、必ず(RPGなどで採用される)コマンド選択式の戦闘シーンでなくてもよい。練習試合は、例えば、アクション、パズル、スポーツ、レース、シューティング、クイズなどのミニゲームであってもよい。経験値の付与条件も、上述とは異なっていてもよい。例えば、試合の勝敗に関わらず、モンスターに経験値を与えてもよい。また、道場で、複数の練習試合に参加するための前提条件として、練習試合で勝利することを求めなくてもよい。例えば、一度参加フィーを消費して道場に入った場合、モンスターの勝敗に関わらず、一定数の試合に参加できるようにしてもよい。これにより、ユーザのスキルに大きく左右されることなく、モンスターの能力値を高めることができるようになる。なお、道場で練習試合を行うために必要な参加フィーの額は、図13の例とは異なっていてもよい。
一方、図13の下側には、ダンジョンが表示されている。ユーザは、参加フィーを2F使うことによって、ダンジョンでモンスターを修行させることができる。モンスターの修行は、一定期間経過したら終了し、終了時に当該モンスターに経験値が付与されるものであってよい。ただし、ユーザを何らかの形でモンスターの修行に関与させてもよい。例えば、モンスターが修行している期間中におけるユーザの歩数、走行距離、走行時間、消費したカロリーなどの運動量に応じて、モンスターに経験値を付与してもよい。ユーザの運動量は情報端末に搭載されたセンサによって計測された値であってもよいし、情報端末と無線通信しているセンサによって計測された値であってもよい。また、ユーザがアプリなどを使って入力した値であってもよい。これにより、ユーザが現実に行った運動内容を、モンスターの成長(獲得経験値)に反映させることができる。また、モンスターの修行では、練習試合とは異なる種類のミニゲームが行われてもよい。なお、モンスターを修行させるために必要な参加フィーの額は、図13の例とは異なっていてもよい。
なお、予選ゲームの画面に店や商人を表示させてもよい。ユーザは、モンスターを店や商人に話しかけさせることによって、参加フィーを使ってアイテムおよび/または道具を購入することができる。アイテムには、モンスターをレベルアップさせる効果があるため、アイテムを入手することにより、モンスターの能力値を高めるのに要する時間を短縮することができる。一方、道具は、他のモンスターとの戦闘中にHP、MP、状態の回復に使うことができる。
ユーザは、所定の条件を満たしたら、予選ゲームから本選ゲームに進むことができる。予選ゲームは、一定のハードルを乗り越えない限りは、クリアできない、突破すべきゲームのステージとして構成されていてもよい。また、予選ゲームは、ある制限の下において練習試合および修行を行うことが可能な期間(準備期間)として位置付けられていてもよい。さらに、予選ゲームは、前者と後者の性質を兼ね備えていてもよい。例えば、所定の条件が満たされたら、練習試合および修行を行うことができなくなり(準備期間の終了)、ボスモンスターが出現し、当該ボスモンスターを倒すこと(ハードルを乗り越えることに相当)を予選ゲームのクリア条件としてもよい。
予選ゲーム管理部42は、予選ゲームのプレイ内容に基づき、準備期間の終了判定または予選ゲームのクリア判定を行ってもよい。予選ゲームのプレイ内容は、例えば、修行の回数、修行の行われた合計時間、道場への入場回数、練習試合における対戦数、練習試合の対戦における勝利数、練習試合の対戦における敗戦数、モンスターの経験値の合計、モンスターのレベル、モンスターの能力値の少なくともいずれかを含んでいてもよい。また、予選ゲーム管理部42は、予選ゲームにおける統計情報に基づき、予選ゲームのクリア判定を行ってもよい。予選ゲームのプレイ内容に基づく判定を行うことにより、本選ゲームに参加するモンスターの能力を一定程度、担保することができる。
なお、予選ゲーム管理部42は、予選ゲームのプレイ内容以外の情報に基づいて、準備期間の終了判定または予選ゲームのクリア判定を行ってもよい。予選ゲームのプレイ内容以外の情報の例としては、初回にログインしてから経過した時間、予選ゲームのプレイ時間、ログインして予選ゲームをプレイした回数が挙げられる。予選ゲーム管理部42は、初回にログインしてから経過した時間、予選ゲームのプレイ時間、ログインして予選ゲームをプレイした回数の少なくともいずれかを使って、準備期間の終了判定を行ってもよい。このような判定が行われている場合、予選ゲームをプレイできる、制限された期間内において効率的な準備を行うことが重要となってくる。予選ゲームをプレイできる時間的な制約が厳しくなるほど、ゲーム全体の難易度が高くなる。一方、予選ゲームをプレイできる時間的な制約を緩和すれば、ゲーム全体の難易度を下げることができる。
また、予選ゲーム管理部42は、予選ゲームのプレイ内容に係る情報と、予選ゲームのプレイ内容以外の情報の両方を組み合わせて、準備期間の終了判定または予選ゲームのクリア判定を行ってもよい。
図15は、本選ゲームのエントリ画面の例を示している。図15の例では、女性キャラクタが「予選ゲームをクリアしたよ!」と述べている。ただし、これは予選ゲームの終了条件およびクリア条件を限定することを意図したものではない。ユーザは、「エントリする」ボタンをクリックすると、本選ゲームへのエントリを行うことができる。また、ユーザは、「今はエントリしない」ボタンをクリックすると、本選ゲームへのエントリを保留することができる。
ここまでは、一定の条件が満たされた場合に、本選ゲームへの参加資格が得られる方式について説明した。ただし、予選ゲームをプレイしているユーザに対して、特に条件を設けず本選ゲームへのエントリを許可してもよい。本選ゲームへのエントリに条件をつけない場合、上述の準備期間の終了判定を行ってもよいし、準備期間の終了判定を行わなくてもよい。また、本選ゲームに挑戦する条件を緩和してもよい。例えば、ゲーム管理部40で複数の階級の本選ゲームを用意し、階級ごとに異なるエントリ条件を設定してもよい。この場合、上述の予選ゲームのプレイ内容に係る情報と、上述の予選ゲームのプレイ内容以外の情報の少なくともいずれかに基づいて、エントリ可能な本選ゲームの階級を決めることができる。
予選ゲームでは、例えば、ダンジョンにおける修行、道場における練習試合の結果に応じ、ユーザに参加フィー、アイテムまたは道具を付与してもよい。例えば、ユーザのモンスターが修行または練習試合で奥義を取得したり、ユーザのモンスターが練習試合で連勝したり、ユーザのモンスターが練習試合イベントでボスレベルのモンスターに勝利した場合、ユーザに参加フィー、アイテムまたは道具を付与してもよい。また、予選ゲーム中に、ユーザに参加フィー、アイテムまたは道具が付与される臨時イベントを発生させてもよい。さらに、特定の日時または時間帯に、ゲーム内で参加フィーの購入ができたり、参加フィーをレアなアイテムまたは道具と交換できたりする臨時店舗を開設してもよい。これにより、予選ゲームが過度に単調となるのを回避し、多忙なユーザが予選ゲームをプレイするきっかけをつくることができる。ウェブサイト上の表示または電子メールなどで臨時イベントの日時または、臨時店舗の開設される時間帯を予告してもよい。
なお、ここで説明した予選ゲームの内容は一例にしかすぎない。したがって、予選ゲームの内容は、上述とは異なっていてもよい。例えば、予選ゲームで、コンピュータによって操作される他のモンスターとの対戦を行い、対戦結果に応じて、ユーザのモンスターに経験値を付与してもよい。予選ゲームにおいても、後述する本選ゲームと同様のトーナメント戦が行われてもよい。この場合、予選ゲームは、「予選トーナメント」の位置付けとなり、予選ゲーム管理部42は、予選トーナメントの結果に応じて、本選ゲームに進めるか否かの判定を行うことができる。また、予選ゲームは、必ずモンスター間の対戦を含むものでなくてもよい。例えば、予選ゲームは、アクション、シューティング、パズル、クイズなどのミニゲームまたはミニゲームの組み合わせの形で提供されるものであってもよい。
ここでは、キャラクタの能力値を高めることができる予選ゲームの例について説明した。ただし、予選ゲームは、必ず獲得した経験値に応じてキャラクタの能力値が高まるものでなくてもよい。例えば、予選ゲーム中におけるアイテムの獲得に応じて、キャラクタの能力値が高まる方式を採用してもよい。さらに、予選ゲームは、ゲーム中のキャラクタの能力値を高める要素を含むものでなくてもよい。したがって、必ず予選ゲームでキャラクタに経験値を付与しなくてもよく、予選ゲームは専ら一定のクリア条件の突破を目的にプレイされるものであってもよい。
(本選ゲーム)
ゲームシステム100において、本選ゲームは、予選ゲームの後にプレイできるコンテンツとして提供される。ポイント管理部53は、本選ゲームをプレイするユーザに賞品と交換可能なポイント(個人ポイント)を付与することができる。本選ゲームは、複数のマッチまたは複数のステージを含むものであってもよい。本選ゲームのマッチまたはステージは、異なるユーザ間の対戦を含むものであってもよいし、異なるユーザ間の対戦を含まないものであってもよい。例えば、本選ゲームの少なくとも一部に、コンピュータが操作するキャラクタとの対戦マッチや、本選ゲーム管理部43が提供するステージをクリアする内容が含まれていてもよい。
以下では、本選ゲームで複数のマッチ(具体的には、モンスター間の対戦)を含むトーナメント戦が行われる場合を例に説明をする。ただし、本選ゲームは必ずトーナメント戦の形式で行われるものでなくてもよいし、複数のマッチまたは複数のステージを含むものでなくてもよい。例えば、本選ゲームは、RPGやシミュレーションゲームであってもよく、本選ゲームで採用されるゲームの種類については特に問わない。本選ゲームの種類および内容は、予選ゲームと共通していてもよいし、異なっていてもよい。
トーナメント戦のそれぞれのマッチは、例えば、コマンド選択式の対戦(上述の図14で示した、戦闘シーン)の形式で行われてもよい。また、それぞれのマッチは、アクションゲーム(例えば、対戦型格闘ゲーム)、パズルゲーム、シューティングゲーム、アドベンチャーゲーム、スポーツゲーム、レースゲーム、音楽ゲーム、ボードゲーム、テーブルゲーム、クイズゲームなどその他の形式で行われるものであってもよい。すなわち、トーナメント戦のマッチで採用されるゲームの種類は、何らかの形で相手方との対戦が可能なのであれば、どのようなものであってもよい。ここで、対戦とは、先に相手方のHPを0にした方を勝者とする戦闘に限らず、得点および/またはタイムによって勝者を判定するものも含むものとする。
ユーザは、獲得した個人ポイントを賞品に交換することができる。トーナメント戦には複数の形式がありうる。例えば、本選ゲームは、ユーザのモンスターがマッチに連勝し続ける限り、プレイを継続できる勝ち残り式トーナメント(勝ち抜き戦)の形式であってもよい。勝ち抜き戦の場合、一度のマッチの勝敗が結果を大きく左右することになる。勝ち抜き戦のゲームにスリルを感じ、やりがいを感じるユーザが一定数存在するのは事実である。その一方で、勝ち抜き戦が過酷であり、気軽にプレイするのには、ゲームの難易度が高く設定されすぎていると感じるユーザもいるであろう。
そこで、本選ゲームは、勝ち抜き戦以外の形式で行われるものであってもよい。例えば、本選ゲームは、ユーザのモンスターのマッチにおける勝敗を問わず、プレイを継続できるものであってもよい。本選ゲームは、エントリしたすべてのモンスター間の総当たり戦であってもよい。また、本選ゲームは、各ユーザが一定数の対戦を行うスイス式トーナメントであってもよい。例えば、トーナメント戦は、勝ち抜き戦、スイス式トーナメント、総当たり戦の少なくともいずれかであってもよい。ただし、本選ゲームで採用されるトーナメント戦の形式については、特に問わない。
上述のように、本選ゲームのトーナメント戦は、異なる条件によってエントリすることができる複数の階級を有していてもよい。また、本選ゲームにおいて、エントリするトーナメントの形式を選択可能にしてもよい。例えば、勝ち残り式トーナメントと、勝ち抜き戦ではないトーナメントを選択できるようにしてもよい。ユーザがエントリする本選ゲームの階級によって、異なる形式のトーナメント戦が用意されていてもよい。例えば、初心者レベルの本選ゲームでは、勝ち抜き戦ではないトーナメントを採用し、上級者レベルの本選ゲームでは、勝ち残り式トーナメントを採用してもよい。
本選ゲームでは、実際に他のユーザが育成したモンスターとの対戦を行うことができるよう、トーナメント戦の開催にあたり、日時の指定を行ったり、本選ゲームにエントリしたユーザ数などの基準を設けたりすることができる。ただし、本選ゲームにおいて対戦相手となるモンスターのすべてが他のユーザによって操作されるモンスターでなくてもよい。例えば、本選ゲームにエントリしたユーザ数がトーナメント戦の開催に必要な数に満たない場合、コンピュータが操作するモンスターを補充的にトーナメント戦にエントリさせてもよい。これにより、ユーザは、希望するタイミングに本選ゲームをプレイすることができるようになる。
予選ゲームでは、道場での練習試合およびダンジョンでの修行を行うのに当たり、ユーザに参加フィーの支払いを求めていた。本選ゲームについては、ユーザが参加フィーを消費しなくても、エントリできるようにしてもよい。なお、任意的に、ユーザが参加フィーを消費して、本選ゲームにエントリした場合には、ユーザが参加フィーを消費しないで本選ゲームにエントリした場合と比べ、難易度が緩和された本選ゲームを提供してもよい。
本選ゲームは、同じモンスターが一度しかプレイできないものであってもよいし、同じモンスターが複数回プレイできるものであってもよい。上述のように階級別で異なるエントリ条件のトーナメントを用意する場合、階級ごとにエントリ回数の制限を設けてもよい。また、特にエントリ回数を制限しなくてもよい。1回、本選ゲームのプレイを行ったモンスターについては、再び予選ゲームに戻すことができる(図6、矢印26の遷移)。この場合、モンスターに、再び道場での練習試合およびダンジョンでの修行を行わせてもよい。また、初めて予選ゲームをプレイしたときと比べ、予選ゲーム内で行うことができる内容を制限してもよい。
同じモンスターが複数回本選ゲームをプレイすることを許容する場合、本選ゲームの結果に応じて、ユーザにアイテムまたは道具を与えてもよい。また、本選ゲームに参加したモンスターに経験値を与えてもよい。なお、本選ゲームを初めてプレイするモンスターを対象とする階級と、本選ゲームをプレイしたことがあるモンスターを対象とする階級とを分けてもよい。これにより、本選ゲームに、経験値の大きく異なるモンスターが混在し、能力値の不均衡が発生することを防ぐことができる。
同じモンスターが本選ゲームを一度しかプレイできない方式を採用する場合、同一ユーザが再度本選ゲームにエントリするためには、改めて予選ゲームで別のモンスターを育成する必要がある。ただし、この方式が採用される場合であっても、既に一度本選ゲームをプレイしたモンスターに、決勝ゲームへの参加資格を与えることは妨げるものではない。
ポイント管理部53は、本選ゲームをプレイするユーザに、個人ポイントを付与することができる。ユーザがそれぞれのマッチをプレイしている途中に個人ポイントを付与してもよい。また、ユーザがそれぞれのマッチをプレイし終わったタイミングで個人ポイントを付与してもよい。ユーザに付与する個人ポイント数は、例えば、各マッチの内容または結果に応じて決定することができる。また、ユーザが本選ゲームのプレイを終了したタイミングで個人ポイントを付与してもよい。
ポイント管理部53は、本選ゲームのトーナメント戦でユーザが獲得した勝ち点に基づいて、ユーザに個人ポイントを付与してもよい。例えば、トーナメント戦において、各マッチの結果に応じてモンスターに勝ち点を付与し、トーナメント戦の終了後に勝ち点に基づいた各モンスターの順位を算出することができる。この場合、各ユーザには、トーナメント戦の終了時に、モンスターの順位に応じた個人ポイントを付与することができる。また、トーナメント戦の終了時において、モンスターの勝ち点に比例した個人ポイントを各ユーザに与えてもよい。勝ち点については、例えば、マッチの勝利時に2点、マッチの敗戦時に1点、モンスターに付与することができる。ただし、各条件において与えられる勝ち点は、これとは異なっていてもよい。なお、個人ポイントは複数のタイミングで与えられてもよい。例えば、マッチのプレイ中、マッチの終了後と、トーナメント戦の終了時の少なくともいずれかのタイミングでユーザに個人ポイントを与えてもよい。
次に、ユーザへ個人ポイントを付与する条件について説明する。ユーザに個人ポイントに付与する条件(ポリシー)によって、本選ゲームの難易度と性質を調整することができる。
例えば、ポイント管理部53は、本選ゲームのトーナメント戦のマッチでユーザが連勝した場合に、ユーザに個人ポイントを付与してもよい(第1のポリシー)。本選ゲームが勝ち抜き戦であるか否かに関わらず、本ポリシーを採用することが可能である。本ポリシーが採用された場合、ユーザは、マッチで連勝するほど、多くの個人ポイントを獲得することができる。ユーザがトーナメント戦で敗戦を喫した場合における、個人ポイントの扱いについては、いくつかのパターンが考えられる。例えば、ポイント管理部53は、本選ゲームのトーナメント戦のマッチでユーザが連勝後、マッチに敗戦した場合、本選ゲームでユーザが獲得した個人ポイントを0にリセットしてもよい(第1のパターン)。また、ポイント管理部53は、本選ゲームのトーナメント戦のマッチでユーザが連勝後、マッチに敗戦した場合、本選ゲームでユーザが獲得した個人ポイントを減らしてもよい(第2のパターン)。さらに、ポイント管理部53は、マッチにおけるユーザの勝敗に関わらず、個人ポイントをそのまま維持してもよい(第3のパターン)。
第1のパターンを採用した場合、ユーザは、本選ゲームをプレイする際にスリルを感じることができる一方、ゲーム自体の難易度が上昇する。第1のパターンでは、ユーザのスキルによって獲得できる個人ポイント数が大きく左右される。このため、本選ゲームで第1のパターンが採用されている場合、ユーザにトーナメント戦を棄権するか否かを選択する権利を与えてもよい。例えば、モンスターが複数のマッチで連勝中であるとき、ユーザにペナルティとして一部の個人ポイントを放棄することを条件に、トーナメント戦の残りマッチを棄権する権利を与えてもよい。この場合、ユーザに一定比率(例えば、1/2)の個人ポイントを放棄させてもよいし、一定値(例えば、10ポイント)の個人ポイントを放棄させてもよい。また、残りマッチを棄権する際に課される、個人ポイントに対するペナルティはこれとは異なっていてもよい。すなわち、ポイント管理部53は、ユーザが本選ゲームのトーナメント戦の残りマッチを棄権した場合、本選ゲームでユーザが獲得した個人ポイントを減らしてもよい。
一方、第3のパターンが採用される場合、プレイ中にかかるプレッシャーを軽減することができるため、ユーザは勝ち負けにこだわらずゲームプレイを楽しむことができる。第2のパターンを採用した場合、ゲームの性質は、第1のパターンと第3のパターンの中間的なものになろう。
また、ポイント管理部53は、本選ゲームのトーナメント戦のマッチでユーザが勝利したことを条件に、ユーザに個人ポイントを付与してもよい(第2のポリシー)。この場合、ユーザは、できる限り多くのマッチで勝利することによって、個人ポイントを増やすことができる。また、ポイント管理部53は、本選ゲームのトーナメント戦のマッチの勝敗に関わらず、ユーザに個人ポイントを付与してもよい(第3のポリシー)。これにより、初心者ユーザにも、参加賞として各ユーザに賞品と交換可能な個人ポイントを付与することができ、ユーザのゲームに対するモチベーションを高めることができる。さらに、ポイント管理部53は、マッチで対戦した相手に応じて、異なる個人ポイント数を付与してもよい(第4のポリシー)。例えば、相手のモンスターのレベルや種類に基づいて、付与される個人ポイント数を決めてもよい。ポイント管理部53は、トーナメント戦のマッチの種類(1回戦、2回戦、準決勝、決勝など)に応じて、異なる個人ポイント数を付与してもよい(第5のポリシー)。ポイント管理部53は、ユーザが獲得した得点、ユーザのタイム、ユーザが相手に与えたダメージ(相手HPの減少量)など本選ゲーム内における数値情報に応じて、ユーザに付与する個人ポイント数を決定してもよい(第6のポリシー)。これにより、勝敗だけでなく、プレイ内容の充実度を基準にユーザへ個人ポイントを付与することができる。
上述のポリシーおよびパターンはいずれも例にしかすぎない。したがって、その他のポリシーまたはパターンに基づいて、ユーザに個人ポイントを付与してもよい。また、ポイント管理部53は、本選ゲームで、上述のポリシーおよび/またはパターンを組み合わせて適用してもよい。例えば、トーナメント戦でモンスターがマッチに勝利するたびに、ユーザに個人ポイントを付与し(第2のポリシー)、複数のマッチに連続して勝利している場合には、さらにボーナスで個人ポイントを付与し(第1のポリシー)てもよい。これに加え、勝敗に関わらず、マッチごとにユーザに個人ポイントを付与してもよい(第3のポリシー)。なお、ポイント管理部53は、本選ゲームのトーナメント戦の階級ごとに異なる条件(例えば、上述の第1〜第6のポリシー、第1〜第3のパターンまたはこれらの組み合わせ)で個人ポイントを付与してもよい。
図16は、本選ゲームのマッチ後に表示される画面の例を示している。図16の画面を参照すると、ユーザがマッチに3連勝しており、マッチ後に個人ポイントが8PP与えられていることがわかる。なお、PPは個人ポイントの略であり、個人ポイントの英訳である“Personal Point”の頭文字をとったものである。また、図16の画面では、女性キャラクタが3連勝したユーザに「すごい!」というコメントをしている。ユーザのモンスターが相手モンスターとのマッチに負けてしまった場合には、「くやしいけど、善戦したね。」「今回は残念だったけど、次は勝てると思うよ。」など、ユーザを激励するメッセージが出されてもよい。
本選ゲームの終了条件は、トーナメント戦の形式によって異なる。例えば、勝ち抜き戦が行われる場合、ユーザは連勝し続ける限り本選ゲームのプレイを続けることができ、マッチで敗戦した時点で本選ゲームのプレイが終了する。また、勝ち抜き戦以外の形式でトーナメント戦が行われる場合、ユーザのモンスターがすべてのマッチを終えた場合、本選ゲームを終了させることができる。また、ユーザがトーナメント戦の途中で棄権した場合にも、本選ゲームを終了させてもよい。本選ゲームの内容および採用されているゲームの種類に応じて、異なる終了条件を設定することが可能である。このため、本選ゲームの終了条件については、限定しない。
図17は、本選ゲームのプレイ終了後に表示される画面の例を示している。図17の画面上のメッセージで表示されているように、ユーザがトーナメント戦の終了時点で保有する個人ポイントは、賞品に交換することが可能である。個人ポイントと賞品との交換に係る処理の詳細については、後述する。
なお、ユーザは、本選ゲームの終了後、ただちに個人ポイントを賞品に交換しなくてもよい。例えば、ユーザアカウントに個人ポイントを貯蓄し、任意のタイミングで個人ポイントを賞品に交換してもよい。また、ユーザが獲得した個人ポイントの用途は、賞品との交換に限定されない。例えば、個人ポイントをその他の種類のポイント(例えば、各種サービスのポイント)に交換してもよい。
(決勝ゲーム)
ゲームシステム100では、予選ゲーム、本選ゲームの他に、決勝ゲームを提供することができる。図6の例のように、本選ゲームの後にプレイできるコンテンツとして、決勝ゲームを提供してもよい。また、少なくとも予選ゲームをプレイしたことがあることがあるユーザに、決勝ゲームへの参加資格を与えてもよい。また、決勝ゲームへの参加資格を得るのにあたり、さらにその他の要件を満たしていることを求めてもよい。例えば、ゲーム管理部40は、本選ゲームで獲得した勝ち点、本選ゲームで獲得した個人ポイント数、本選ゲーム内における得点、本選ゲーム内におけるタイム、ユーザが相手に与えたダメージ(相手HPの減少量)、本選ゲームにおける勝利数、本選ゲームにおける勝率、本選ゲームにおける連勝数など、本選ゲームにおける成績および/または数値情報に基づき、決勝ゲームへのエントリ可否を判定してもよい。
また、ゲームシステム100において、予選ゲームの後にプレイできるコンテンツとして、本選ゲームまたは決勝ゲームを選択できるようにしてもよい。すなわち、ゲーム管理部40は、ユーザが予選ゲームをプレイしたことがあるのであれば、過去におけるユーザの本選ゲームへのエントリ履歴、ユーザの本選ゲームにおける成績および/または数値情報に関わらず、ユーザの決勝ゲームへのエントリを許可してもよい。例えば、ユーザが予選ゲームをプレイし、本選ゲームへのエントリ条件を満たした場合、ゲーム管理部40は、同時に決勝ゲームへのエントリ資格を与えてもよい(図6の矢印28の遷移)。また、ゲーム管理部40は、予選ゲームをプレイしているユーザに特に制限を設けず、決勝ゲームへのエントリ資格を与えてもよい。また、ゲーム管理部40は、ユーザが予選ゲームにおいて所定の条件を満たした場合に、決勝ゲームへのエントリ資格を与えてもよい。ゲーム管理部40は、複数の階級の決勝ゲームを用意し、決勝ゲームの階級別に、異なる条件でエントリ資格を設定してもよい。予選ゲームから決勝ゲームへのエントリを許容する場合、ゲーム管理部40は、決勝ゲームのプレイを終えたモンスターを予選ゲームに戻してもよい(図6の矢印27の遷移)。また、決勝ゲームは、一度のみエントリできるものであってもよいし、複数回エントリできるものであってもよい。
予選ゲームでは、道場での練習試合およびダンジョンでの修行を行うのに当たり、ユーザに参加フィーの支払いを求めていた。決勝ゲームについては、ユーザが参加フィーを消費しなくても、エントリできるようにしてもよい。なお、任意的に、チームのユーザが参加フィーを消費して、決勝ゲームにエントリした場合には、チームのユーザが参加フィーを消費しないで決勝ゲームにエントリした場合と比べ、難易度が緩和された決勝ゲームを提供してもよい。この場合、チームの全ユーザが参加フィーを消費することを求めず、チーム全体として一定の参加フィーを消費した場合に、決勝ゲームの難易度を緩和してもよい。
図18は、決勝ゲームのエントリ画面の例を示している。図18の画面には、ユーザに決勝ゲームへの招待状が届いている旨が通知されている。ユーザは、「エントリする」ボタンをクリックすると、図19に表示されているチームメンバーの確認画面に進むことができる。また、ユーザは、「今はしない」ボタンをクリックすると、決勝ゲームへのエントリを保留することができる。図18で女性キャラクタが述べているように、決勝ゲームはチームを作ってみんなで楽しく遊べることが特徴となっている。すなわち、決勝ゲームの開始時に、複数のユーザのモンスターを含むチーム(RPGにおける「パーティ」に相当する)が結成される。そして、決勝ゲームでは、チーム間で対戦を行い、各チームでポイント(チームポイントとよぶ)を獲得することができる。
図19は、チームメンバーの確認画面の例を示している。図19の画面では、ハンドルネーム「アントニウス」のユーザに対し、ハンドルネーム「カサンドラ」のユーザと、ハンドルネーム「ネストル」のユーザとチームを組み、決勝ゲームにエントリするか否かの意思確認が求められている。図19の画面が表示された時点までに、ハンドルネーム「カサンドラ」のユーザと、ハンドルネーム「ネストル」のユーザは、ハンドルネーム「アントニウス」のユーザとチームを組むことを承諾しているものとする。ハンドルネーム「アントニウス」のユーザは、「このメンバーでプレイする」ボタンをクリックすると、図19の画面に表示されたチームメンバーで、決勝ゲームにエントリすることができる。すなわち、「このメンバーでプレイする」ボタンがクリックされた時点で、決勝ゲームにおけるチームメンバーが確定する。
図19の画面では、チームメンバーの候補として3名のユーザが示されている。ただし、決勝ゲームのチームに所属するユーザ数は、必ず3名でなくてもよく、これとは異なる人数であってもよい。決勝ゲームにエントリ可能なチームに所属するユーザ数は、決まった人数ではなく、一定の範囲内の人数であってもよい。また、決勝ゲームにエントリ可能なチームに所属するユーザ数に関する制限がなくてもよい。図19では、決勝ゲームの開始時にチームメンバーが確定する方式が採用されているが、これとは異なるタイミングでチームメンバーが確定してもよい。例えば、決勝ゲームのプレイ中にチームが結成されてもよい。また、決勝ゲームのプレイ開始後に、チームメンバーの変更が行われてもよい。例えば、新たに勧誘したユーザをチームに追加してもよいし、他のチームとの間でユーザの入れ替えが行われてもよい。決勝ゲームでチームの解散と、別のチームの結成の両方が行われてもよい。また、決勝ゲームのプレイ開始後に、一部のユーザをチームから脱退させてもよい。
図19を参照すると、ハンドルネーム「カサンドラ」のユーザと、ハンドルネーム「ネストル」のユーザから送られたメッセージが表示されている。ハンドルネーム「アントニウス」のユーザも、テキストボックス29にテキストを入力後、「送信する」ボタンをクリックすることにより、ハンドルネーム「カサンドラ」のユーザと、ハンドルネーム「ネストル」のユーザの操作画面にメッセージを表示させることができる。このように、ゲームシステム100では、ユーザ間でメッセージの送受信(チャット)を行えるインタフェースが提供されていてもよい。インタフェースの形式は、図19とは異なっていてもよい。また、メッセージの送受信は、図19の画面のようにチームメンバーの確定前に行われてもよいし、チームメンバーの確定後に行われてもよい。
図20は、チーム名を入力する画面の例を示している。図20の画面では、決勝ゲームへのエントリを感謝し、チーム名の入力を依頼するメッセージが表示されている。ユーザは、テキストボックス36にチーム名を入力後、「確定する」ボタンをクリックすることによって、チーム名を決めることができる。図20の画面では、チーム名として、「チームカエサル」が入力されている。ここでは、チームメンバーの確定後にチーム名が決められている。ただし、図19の画面に、チーム名を入力可能なテキストボックスを追加し、チームメンバーとチーム名が同時に確定するようにしてもよい。また、決勝ゲームのプレイ中にチーム名を変更できるようにしてもよい。
図19の画面では、ユーザにチームメンバーの候補が提示されていた。チームメンバーの候補は、ユーザが自発的に決めるものであってもよいし、ゲームシステム100側によって提示されるものであってもよく、チームメンバーの決め方については、特に問わない。例えば、ユーザが、家族や友人などの仲間に招待状を送付し、招待状を受け取った者をチームメンバーの候補とし、招待を承諾した者を正式なチームメンバーとしてもよい。招待状は、ゲームシステム100の提供するメッセージ機能によって送付されてもよいし、電子メールまたはSNSによって送付されてもよい。ゲーム内のどのユーザが、家族や友人などであるかは、公表しているハンドルネームと、各ユーザがゲームシステム100内での開示を許可したプロフィール情報を参照することによって判断することが可能である。
また、ゲームシステム100側が、アカウント作成時に入力されたユーザの情報または、SNSなど他サービスから提供されたアカウントのプロフィール情報に基づいて、チームメンバーの候補を提案してもよい。例えば、ファーストネームおよび住所から同じ家族のメンバーである可能性が高いと推定されるユーザをチームメンバーの候補として提示してもよい。また、ユーザ側で、チームメンバーの候補としたい他ユーザの属性(例えば、住所、年代、性別、趣味、学校など)を指定し、ゲームシステム100側で、ユーザの希望する属性に近い他ユーザをチームメンバーの候補として提示してもよい。また、ユーザ側でチームメンバーの候補としたい他ユーザの属性の希望が指定されていない場合でも、ユーザの属性に近い他ユーザをチームメンバーの候補として提示してもよい。例えば、各種の機械学習手法を使い、属性の類似性の判定を行うことができる。
ユーザ側に招待状を送付させ、チームメンバーを自発的に決めさせることにより、ユーザは希望するメンバーでチームを結成し、チームプレイを行うことができる。知り合いどうしでチームを結成することにより、仲間との親睦・交流をさらに深めることができる。一方、ゲームシステム100側が提案したチームメンバー候補でチームを結成することにより、新たに他のユーザと知り合いになれるチャンスが生まれる。
図19の画面(チームメンバーの確認画面)で、ハンドルネーム「アントニウス」のユーザが、「いいえ」ボタンをクリックした場合の動作には、複数バリエーションがありうる。例えば、ゲームシステム100側で、図19とは異なるユーザの組み合わせをチームメンバーの候補として提示してもよい。また、ユーザが「いいえ」ボタンをクリックした後、他のユーザに招待状を送信できる画面に遷移してもよい。
決勝ゲームでは、複数のマッチを含むトーナメント戦が行われてもよい。以下では、決勝ゲームでそれぞれ複数のユーザが所属しているチーム間のトーナメント戦が行われる場合を例に説明を行う。トーナメント戦は、チーム間の対戦(複数モンスター対複数モンスターの戦闘)が複数回行われる。なお、トーナメント戦を行うのに必要な数のチームが決勝ゲームにエントリしていない場合には、決勝ゲーム管理部44でコンピュータ操作のモンスターが所属するチームを用意し、不足分のチームを補ってもよい。また、ユーザが所属するチームに、コンピュータが操作するモンスターを加入させてもよい。これにより、決勝ゲーム開催時におけるプレイヤ不足の問題を解決することができる。これらの対策を行わず、それぞれチームメンバー数の要件を満たしている、一定数のチームが決勝ゲームにエントリしたことを条件に、決勝ゲームを開催してもよい。
ただし、決勝ゲームの内容および種類については、特に限定しない。決勝ゲームの内容は、チームに所属するユーザでプレイできるものであれば、どのようなものであってもよい。決勝ゲームは、常にチームに属する複数ユーザの同時プレイが求められるものであってもよい。また、決勝ゲームは、内容の一部でチームに属する複数ユーザの同時プレイが求められるものであってもよい。また、決勝ゲームは、チームに属する複数ユーザによる同時プレイが求められない内容のものであってもよい。例えば、決勝ゲームの一部でチームに属する複数ユーザの同時プレイが行われ、決勝ゲームの他の部分でチームに属するユーザの単独プレイまたは役割分担が行われてもよい。
また、決勝ゲームの種類は、例えば、アクションゲーム、ロールプレイングゲーム(RPG)、シミュレーションゲーム、パズルゲーム、シューティングゲーム、アドベンチャーゲーム、スポーツゲーム、レースゲーム、音楽ゲーム、ボードゲーム、テーブルゲーム、クイズゲームまたは、これらを組み合わせたもののいずれであってもよい。また、決勝ゲームは、複数のマッチまたは複数のステージを含むものであってもよいし、明確に複数のマッチまたは複数のステージに分けられていないものであってもよい。また、決勝ゲームは、必ずチーム間の対戦を含むトーナメント戦でなくてもよい。例えば、決勝ゲームは、チーム単位でプレイするRPG、アドベンチャーゲームなどであってもよいし、チームメンバーでコンピュータ操作の敵と戦うゲームであってもよい。ここで、対戦とは、先に相手方のHPを0にした方を勝者とする戦闘に限らず、得点および/またはタイムによって勝者を判定するものも含むものとする。決勝ゲームの内容および種類に関わらず、決勝ゲームをプレイしたチームには、所定の条件に基づきチームポイントが与えられるものとする。
図21は、決勝ゲームにおける画面の例を示している。図21は、ハンドルネーム「アントニウス」のユーザの画面に表示される戦闘シーンである。上述の図14と同様、コマンド選択式のバトルが行われている。ハンドルネーム「アントニウス」のユーザの属する、「チームカエサル」の対戦相手は、「チームブルータス」となっている。「チームブルータス」には、3体のモンスターが含まれている。図21の画面を参照すると、ユーザは自分のモンスターのみを操作できるようになっていることがわかる。したがって、ハンドルネーム「カサンドラ」のユーザと、ハンドルネーム「ネストル」のユーザは、それぞれ自分のモンスターがゲーム中で行うアクション(戦う/守る/呪文を使う/道具を使う)を選択し、戦闘に参加する。図21の画面が表示された時点で、「チームカエサル」はチームポイントを178TP獲得していることがわかる。なお、TPはチームポイントの略であり、英語“Team Point”の頭文字となっている。
また、図21の下部には、テキストボックス37が用意されている。ハンドルネーム「アントニウス」のユーザは、テキストボックス37にテキストを入力後、「メッセージを送る」ボタンをクリックすると、他のチームメンバー(ハンドルネーム「カサンドラ」のユーザおよびハンドルネーム「ネストル」のユーザ)にメッセージを送ることができる。これにより、マッチ中にも、他のユーザとコミュニケーションをとり、情報共有を行ったり、連携的なプレイを行ったりすることが可能となる。なお、チームメンバー間のコミュニケーションは、音声通話など、その他の機能によって行われてもよい。
決勝ゲームでは、図21に示したようなマッチがトーナメント戦の形で複数回行われてもよい。ただし、マッチの形式は、コマンド選択式のバトルに限られない。マッチは、例えば、アクションゲーム、パズルゲーム、シューティングゲーム、アドベンチャーゲーム、スポーツゲーム、レースゲーム、音楽ゲーム、ボードゲーム、テーブルゲーム、クイズゲームなどその他の形式で行われるものであってもよい。トーナメント戦のマッチは、何らかの形で相手方チームとの対戦が可能なのであれば、どのような種類のものであってもよい。
決勝ゲームで採用されるトーナメント戦の形式が限定されないのは、本選ゲームの場合と同様である。したがって、トーナメント戦は、勝ち抜き戦、スイス式トーナメント、総当たり戦の少なくともいずれかであってもよい。また、チームポイントを付与するタイミングについても、特に問わない。例えば、各マッチが行われているときにチームポイントが付与されてもよいし、各マッチの終了後にチームポイントが付与されてもよい。また、トーナメント戦(決勝ゲーム)の終了時にチームポイントが付与されてもよい。また、複数のタイミングでチームポイントが付与されてもよい。
ポイント管理部53、決勝ゲームをプレイするチームに、ポイント(チームポイント)を付与する。決勝ゲームで、チームポイントが付与される条件についても、特に問わない。ポイント管理部53は、決勝ゲームのトーナメント戦でチームが獲得した勝ち点に基づいて、チームポイントを付与してもよい。例えば、トーナメント戦の各マッチの結果に応じて、チームに勝ち点を付与し、トーナメント戦の終了後に勝ち点に基づき、各チームの順位を計算する。そして、チームの順位に応じて、各チームにチームポイントを与えてもよい。また、直接勝ち点に基づいて、各チームにチームポイントを付与してもよい。例えば、勝ち点に比例したチームポイントを各チームに与えることができる。例えば、勝ち点をマッチの勝利時に2点、マッチの敗戦時に1点、チームに付与することができる。ただし、各条件において与えられる勝ち点は、これとは異なっていてもよい。
ユーザをチームに、個人ポイントをチームポイントにそれぞれ置き換えれば、本選ゲームの説明で述べた第1〜第6のポリシーおよび第1〜第3のパターンは、決勝ゲームにもそのまま適用することが可能である。すなわち、ポイント管理部53は、決勝ゲームのトーナメント戦のマッチでチームが連勝した場合に、チームポイントを付与してもよい(第1のポリシー)。ポイント管理部53は、決勝ゲームのトーナメント戦のマッチでチームが連勝後、マッチに敗戦した場合、決勝ゲームで獲得されたチームポイントを0にリセットしてもよい(第1のパターン)。ポイント管理部53は、決勝ゲームのトーナメント戦のマッチでチームが連勝後、マッチに敗戦した場合、決勝ゲームで獲得されたポイントを減らしてもよい(第2のパターン)。また、ポイント管理部53は、マッチにおけるチームの勝敗に関わらず、チームポイントをそのまま維持してもよい(第3のパターン)。また、本選ゲームと同様、獲得したチームポイントの一部を放棄することを条件に、チームがトーナメント戦の残りマッチを棄権することを認めてもよい。すなわち、ポイント管理部53は、チームが決勝ゲームのトーナメント戦の残りマッチを棄権した場合、決勝ゲームで獲得されたチームポイントを減らしてもよい。
さらに、ポイント管理部53は、決勝ゲームのトーナメント戦のマッチでチームが勝利したことを条件に、チームポイントを付与してもよい(第2のポリシー)。また、ポイント管理部53は、決勝ゲームのトーナメント戦のマッチの勝敗に関わらず、チームポイントを付与してもよい(第3のポリシー)。さらに、ポイント管理部53は、マッチで対戦する相手に応じて、チームに異なるチームポイント数を付与してもよい(第4のポリシー)。ポイント管理部53は、トーナメント戦のマッチの種類(1回戦、2回戦、準決勝、決勝など)に応じて、チームに異なるチームポイント数を付与してもよい(第5のポリシー)。ポイント管理部53は、チームが獲得した得点、チームのタイム、チームが相手に与えたダメージ(相手HPの減少量)など決勝ゲーム内における数値情報に応じて、チームに付与するチームポイント数を決定してもよい(第6のポリシー)。各ポリシーおよび各パターンを採用することによって得られる効果は、本選ゲームの説明で述べた通りである。
ポイント管理部53は、決勝ゲームで、複数のポリシーおよび/またはパターンを組み合わせて適用してもよい。例えば、初心者向け階級の決勝ゲーム、中級者向け階級の決勝ゲーム、上級者向け階級の決勝ゲームのそれぞれで、トーナメント戦の形式と、採用されるポリシー/パターンが異なっていてもよい。上級者向け階級の決勝ゲームでは、勝ち残り式トーナメントを行い、第1のポリシーと、第1〜第3のいずれかのパターンを採用してもよい。一方、初心者向け階級の決勝ゲームでは、スイス式トーナメントまたは総当たり戦を行い、第2〜第6のポリシーを採用してもよい。中級者向け階級の決勝ゲームでは、勝ち点に基づいたチームポイントの付与を行ってもよい。すなわち、決戦ゲームのトーナメント戦は、異なる条件によってエントリすることができる複数の階級を有していてもよい。ポイント管理部53は、決戦ゲームのトーナメント戦の階級ごとに異なる条件でチームポイントを付与してもよい。
決勝ゲームでは、チーム間でバトルが行われるため、チーム内での連携の良し悪しによって、ゲームの結果が左右される。例えば、打撃技を中心として行うモンスター、呪文または道具を使ってHPの著しく減少したモンスターの回復を行うモンスター、攻撃呪文を使うモンスターのように、チーム内におけるモンスターの役割分担を行うことができる。決勝ゲームでは、複数ユーザを含むチームでプレイが行われるため、プレイの結果が極端に個々のユーザのスキルに依存しなくなる。このため、初心者ユーザが含まれるチームであっても賞品と交換可能なチームポイント数を獲得することが可能である。
決勝ゲームで勝ち残り式トーナメントが行われる場合、ユーザのモンスターの所属するチームは連勝し続ける限り、決勝ゲームを継続することができる。このため、ユーザのモンスターの所属するチームがバトルに負けた時点で決勝ゲームが終了する。また、チームがトーナメント戦の途中で棄権した場合にも、決勝ゲームを終了させてもよい。決勝ゲームで勝ち抜き戦以外の形式でトーナメント戦が行われる場合、チームが参戦するすべてのマッチが終了したら決勝ゲームを終了させてもよい。決勝ゲームの内容および採用されているゲームの種類に応じて、異なる終了条件を設定することが可能である。このため、決勝ゲームの終了条件については、特に限定しない。
決勝ゲームのプレイが終了後、決勝ゲームで結成されたチームを解散してもよい。また、決勝ゲームのプレイ終了後も、結成されたチームをそのまま維持してもよい。この場合、以前と同じチームメンバーで再び決勝ゲームにエントリすることを許容してもよい。なお、上述のように、一度決勝ゲームをプレイしたユーザを予選ゲームに戻すことができる(図6の矢印27)。したがって、決勝ゲームの内容または結果に応じて、ユーザにアイテム、道具、経験値の少なくともいずれかを付与してもよい。
(賞品との交換)
ゲームシステム100において、チームポイントと個人ポイントは、異なる種類のポイントとして管理される。このため、チームポイントの残高と、個人ポイントの残高は別々に計算される。また、個人ポイントとチームポイントは、帰属する主体が異なっている。個人ポイントは、個々のユーザに帰属している一方、チームポイントは、各チームに帰属している。個人ポイントの場合、各ユーザが希望する賞品を選び、各ユーザが賞品を取得することができる。
賞品選択部54では、チームが保有するポイント(チームポイント)と交換される賞品を選択することができる。チームポイントと賞品との交換は、複数の方式によって行うことが想定される。例えば、チーム内で代表者のユーザが設定され、代表者のユーザがシステム上で希望する賞品の選択操作を行い、代表者のユーザが賞品の受け取りを行う方式(第1の方式)が考えられる。第1の方式を採用すると、チームとして、多くのチームポイントが必要な賞品を獲得できる利点がある。例えば、チームメンバー全員で楽しめる、キャンピング用品、バーベキュー用品、ファミリー用品、スポーツ用品、特大サイズの食料品などの賞品を入手できる可能性がある。これらの賞品を入手することを目標にし、チームメンバーのゲームに対するモチベーションを高めることができる。
ただし、代表者の選定、賞品の選択、賞品の管理者、賞品の所有権など、チームメンバー内で同意をとる必要がある事項が多い。各チームメンバーは、これらの相談を、ゲームシステム100の提供するメッセージ機能によって行うことができる。チームメンバーが同じ家族に属する場合、賞品は、当然家族全員の共同所有物となるかもしれない。ただし、賞品の選択、管理者、所有権についてチームメンバー間で意見の相違が発生する可能性も皆無ではない。このため、賞品選択部54は、チームメンバー間で複雑な意見調整を行うことが不要な方式を採用してもよい。
例えば、チームメンバーの全員が同じ賞品を得られるようにしてもよい(第2の方式)。第2の方式では、チーム内で代表者のユーザが設定され、代表者のユーザがシステム上でチームメンバーのそれぞれに与えられる賞品を選択する。選択される賞品は、ひとつの賞品であってもよいし、複数の賞品の組み合わせであってもよい。すなわち、賞品選択部54は、チームに所属するすべてのユーザが獲得する賞品として、同じ賞品を選択してもよい。第2の方式では、チームメンバーのそれぞれが平等に同じ賞品を獲得できるため、管理者の選定や所有権に関する問題が起こらなくなる。ただし、第2の方式でも、希望する賞品がチームメンバー間で異なっている場合には、意見調整が難航してしまう可能性がある。
そこで、それぞれのチームメンバーが希望する賞品を選択できるよう、チームポイントをチーム内のユーザで分配してもよい(第3の方式)。すなわち、ポイント管理部53は、チームが保有するポイント(チームポイント)をチームに所属するユーザに分配し、賞品選択部54では、ユーザに分配されたポイント(チームポイント)と交換する賞品が選択されてもよい。例えば、決勝ゲームの終了後、チームに属する各ユーザにチームポイントを平等に振り分けてもよい。チームポイント数をチームに属するユーザ数で除算し、ユーザ1名あたりに割り当てられるチームポイントを計算する場合、小数点下の端数が発生する場合がある。この場合、小数点下の端数は切り捨てられてもよいし、整数に切り上げられてもよい。なお、必ずユーザ数の頭割りでチームポイントが分配されなくてもよい。例えば、各ユーザの決勝ゲームにおける寄与度に応じて、ポイントを振り分けてもよい。決勝ゲームにおける寄与度は、例えば、対戦で相手モンスターに与えたダメージ(HPの減少)に基づいて計算されてもよい。また、対戦中における同一チームの味方モンスターへの支援内容(例えば、HPの回復量)に基づいて定められてもよく、計算方法については、特に問わない。
さらに、上述の第1〜第3の方式が組み合わされて適用されてもよい。例えば、チームポイントの一部を各チームメンバーに分配し、各ユーザが賞品を選択できるようにし(第3の方式)、残りのポイントは分配せず、チームメンバー全員で楽しめる賞品を選択してもよい(第1の方式)。また、分配されないポイントを使って、各チームメンバーに生活必需品を与えてもよい(第2の方式)。なお、賞品選択部54は、チームポイントについて適用される方式(例えば、上述の第1〜第3の方式または、これらの方式の組み合わせ)を選択できるように構成されてもよい。チームポイントについて適用される方式の選択権は、チームの代表者が有していてもよい。また、賞品選択部54は、チームに所属するメンバーの多数決で、チームポイントについて適用される方式を選択してもよい。
ここでは、個人ポイントとチームポイントのいずれを使っても、賞品の交換ができる場合を例に説明している。ただし、賞品選択部54では、個人ポイントまたはチームポイントのいずれかを使わないと、賞品との交換ができないように設定されていてもよい。この場合、ポイント管理部53では、チームポイントを個人ポイントと交換する処理または、個人ポイントをチームポイントと交換する処理の少なくともいずれかを行う必要がある。これらの場合における、ポイント間の交換レートについては、特に問わない。
なお、個人ポイントとチームポイントのいずれを使っても、賞品との交換ができる場合においても、ポイント管理部53は、個人ポイントとチームポイントの交換を行ってもよい。例えば、決勝ゲームの開始後、ポイント管理部53は、チームに所属するユーザの個人ポイントのうち、少なくとも一部をチームポイントに交換してもよい。この場合、交換後のチームポイントは、ユーザ個人ではなく、ユーザの所属するチームに帰属する。これにより、決勝ゲームでチームが獲得できたチームポイント数が充分でない場合でも、チームメンバーの有する個人ポイントを使ってチームポイントを補充することにより、チームとして賞品を獲得することが可能となる。
図22は、決勝ゲームのプレイ終了後に表示される画面の例を示している。図22の画面では、女性キャラクタがチームポイントのうち、ハンドルネーム「アントニウス」のユーザに分配された分を賞品と交換できる旨を通知している。ハンドルネーム「アントニウス」のユーザには、チームポイントが80TP分配されている。これより、図22の例では、少なくとも上述の第3の方式が採用されていることがわかる。ハンドルネーム「アントニウス」のユーザは、「交換する」ボタンをクリックすることによって、図23の賞品の選択画面に進むことができる。また、ハンドルネーム「アントニウス」のユーザは、「後で」ボタンをクリックすることによって、分配されたチームポイントを貯蓄することができる。ユーザが貯蓄したチームポイントは、任意のタイミングでチームポイントを賞品に交換してもよい。また、チームポイントの用途は、賞品との交換に限定されない。例えば、ユーザは、チームポイントをその他の種類のポイント(例えば、各種サービスのポイント)に交換してもよい。
図23は、賞品の選択画面の例を示している。図23の画面の上部には、ハンドルネーム「アントニウス」のユーザが保有している個人ポイント数およびチームポイント数が表示されている。また、図23の画面には、タイル45〜48が表示されている。それぞれのタイル上には、選択可能な賞品が表示されている。タイル45には、消しゴムが表示されている。タイル46には、レトルトカレーが表示されている。タイル47には、清涼飲料水が表示されている。タイル48には、ノートが表示されている。タイル45〜48の上下にそれぞれ配置されている、三角形状のボタンをクリックすると、その他の種類の賞品を含むタイルが画面上に表示される。ハンドルネーム「アントニウス」のユーザは、タイル46をクリックしたため、タイル46の周囲が太線に変わっている。また、図23の画面の下部には、賞品「レトルトカレー」を得るのに35PP(個人ポイント)または、20TP(チームポイント)が必要である旨が表示されている。
この状態でハンドルネーム「アントニウス」のユーザが「選択」ボタンをクリックすると、賞品「レトルトカレー」を選択状態にすることができる。図23には表示されていないものの、画面中にユーザが選択状態にした賞品の一覧を表示してもよい。また、ユーザの保有する個人ポイントまたはチームポイントで交換可能なのであれば、図23の画面で複数の賞品を選択できるようにしてもよい。ここで、複数の賞品の選択は、同じ種類の賞品(同じタイル上に表示されている賞品)を複数点選択する場合、2以上の種類の賞品(別のタイル上に表示されている賞品)を選択する場合、前者と後者のいずれに該当する場合を含むものとする。
なお、ユーザの年齢に応じて、一部の賞品をタイルに表示させないようにしたり、一部の賞品を選択できないようにしたりすることが可能である。例えば、ユーザが20歳未満である場合には、一部の賞品をタイルに表示せず、これらの賞品を選択できないようにしてもよい。
図23の画面で、ハンドルネーム「アントニウス」のユーザは、「戻る」ボタンをクリックすると、賞品の選択を中止することができる。この場合、ハンドルネーム「アントニウス」のユーザが保有する個人ポイントおよびチームポイントは、そのまま貯められる。また、図23の画面で、ハンドルネーム「アントニウス」のユーザが「進む」ボタンをクリックすると、図24の賞品の送付先の入力画面に進むことができる。なお、図24の賞品の送付先の入力画面に進む前に、ユーザが選択した賞品の一覧を含む画面が表示されてもよい。これにより、ユーザは、自分の希望する賞品を正しく選択したのか確認することができる。
図24は、賞品の送付先を入力する画面の例を示している。図24の画面には、賞品の送付先の氏名、電話番号、メールアドレス、郵便番号、都道府県、市町村(区)、町名および番地、部屋番号、配達希望時間帯を入力することが可能なテキストボックスが表示されている。なお、都道府県、配達希望時間帯は、ドロップダウンボックスによって複数の選択肢から入力内容が選択できるようになっていてもよい。図24の画面では、各テキストボックス/ドロップダウンボックスが空欄となっている。ただし、図24の画面に遷移した時点で、あらかじめユーザがアカウント作成時に設定した情報が各テキストボックス/ドロップダウンボックスに入力されていてもよい。これにより、ユーザが自宅に賞品の送付されることを希望する場合、改めて自宅の住所などの情報を入力する手間を省くことができる。
なお、ユーザは、図24の画面において、賞品の送付先として、友人、知人など他人の氏名および住所を入力してもよい。すなわち、ユーザが獲得した賞品の受取人は、当該ユーザ以外の者であってもよい。例えば、ユーザは、ゲームシステム100で獲得した賞品を他人にプレゼントしてもよい。ここまでは、ユーザが獲得した賞品が、ユーザの指定した宛先に送付される場合を例に、説明を行った。なお、ユーザが獲得した賞品の受け取りは、必ず指定住所への送付によって行われなくてもよく、賞品の受け取り方法については特に問わない。
図25は、情報端末に表示された賞品引換券の例を示している。例えば、ユーザは、図23の画面で希望する賞品を選択した後、指定住所への配達ではなく、店舗での受け取りを指定する。ユーザが、店舗での受け取りを指定した場合、ユーザの情報端末(例えば、フィーチャフォン、スマートフォン、タブレット)のディスプレイ上に賞品引換券を表示させることができる。ユーザは、所定の店舗で情報端末8のディスプレイ64上に表示された賞品引換券を提示すると、店舗で対象となる賞品を受け取ることができる。賞品引換券には、二次元コード65が表示されている。レジの読み取り器に二次元コード65を読み込ませることにより、店舗での賞品引き渡しに係る事務処理を簡略化することができる。なお、賞品引換券には、二次元コードの代わりにバーコードが表示されていてもよい。また、賞品引換券に二次元コード、バーコードなどが表示されていなくてもよい。賞品引換券は、ウェブサイトのページであってもよいし、ダウンロード可能なファイル(例えば、PDF)であってもよい。また、賞品引換券は、ユーザのメールアドレス宛に送信される電子メールであってもよい。なお、ユーザは、プリンタを使って印刷した賞品引換券の紙を店舗で提示してもよい。賞品引換券によって引換可能な賞品はひとつの賞品であってもよいし、複数の賞品であってもよい。
ゲームシステム100をプレイすることによって獲得することができる賞品の種類については、特に問わない。賞品は、各種の商品(モノ)であってもよいし、各種の役務(サービス)であってもよい。また、賞品は、割引券、各種サービスのポイントなど、ユーザに何らかの経済的な利益をもたらすものであってもよいし、これらの組み合わせであってもよい。
(決勝ゲームのプレイに向けた動機づけ)
一部のユーザは、決勝ゲームで他ユーザとチームを結成する必要がある点を煩わしく感じたり、決勝ゲームと比べてシステムがシンプルな本選ゲームの方が好ましいと感じたりするかもしれない。したがって、一部のユーザは、決勝ゲームへの参加資格を有しているのにも関わらず、決勝ゲームに参加せず、チームの結成が不要な本選ゲームのプレイを繰り返す可能性がある。また、一部のユーザは、決勝ゲームに参加をしても、本選ゲームと比べてプレイする頻度や、プレイ時間が少なくなる可能性もある。そこで、より多くのユーザが決勝ゲームのプレイに関心を持つよう、各種の動機づけを行うことができる。
第1の方法として、決勝ゲームと本選ゲームとで異なるポイントの付与基準を用いる方法について説明する。例えば、ポイント管理部53で、決勝ゲームでユーザ1名当たりに付与されるチームポイントの平均値を、本選ゲームでユーザに付与される個人ポイントの平均値より大きく設定してもよい。すなわち、決勝ゲームにおけるポイント(チームポイント)の付与基準を、本選ゲームにおけるポイント(個人ポイント)の付与基準より緩やかに設定してもよい。
図26のテーブルは、本選ゲームで各ユーザに付与される個人ポイント数と、決勝ゲームで1ユーザ当たりに付与されるチームポイント数の例を示している。列C1は、本選ゲームをプレイするユーザに、付与される個人ポイント数を条件別に示している。列C2は、決勝ゲームで1ユーザ当たりに付与されるチームポイント数を条件別に示している。例えば、決勝ゲームにおいて各チームのチームメンバー数が3名である場合、実際にチームに付与されるチームポイントは、列C2に示した値の3倍となる。列C1と列C2とを比較すると、後者の方では、1回の対戦ごとに、結果を問わず、参加賞として2ポイント付与されるのに対し、前者では、対戦に勝利しないとポイントの付与は行われない。また、同一条件に該当する場合、後者の方が前者より多くのポイントがもらえるようになっている。
図26のテーブルに示したようなポイントの付与基準を用いることにより、ユーザは、同じ時間だけゲームをプレイする場合、決勝ゲームをプレイした方が、本選ゲームをプレイするより多くポイントを得られる確率が高くなる。なお、図26に示したポイントの付与基準は一例にしかすぎない。したがって、これとは異なる基準に基づいてポイントの付与を行ってもよい。
ポイント管理部53では、チームポイントの付与条件の少なくとも一部において、決勝ゲームで付与されるチームポイントの数を、本選ゲームで付与される個人ポイントの数より多く設定していてもよい。例えば、ポイント管理部53は、決勝ゲームでチームポイントが付与される条件数を、本選ゲームで個人ポイントが付与される条件数より多く設定してもよい。ゲームシステム100の稼働中に、ポイントの付与条件を変更してもよいし、各条件において付与されるポイント数を変更してもよい。
第2の方法として、個人ポイントとチームポイントにおいて、賞品を得るために必要なポイント数として異なる値を設定する方法について説明する。
図27のテーブルは、各賞品を得るために必要な個人ポイント数と各賞品を得るために必要なチームポイント数とを示している。列C3は、各賞品を得るために必要な個人ポイント数を示している。列C4は、各賞品を得るために必要なチームポイント数を示している。列C3と列C4とを比較すると、個人ポイント数より少ないチームポイント数で賞品が獲得できることがわかる。すなわち、チームポイントの方が、個人ポイントより有利に賞品との交換基準が設定されている。なお、必ずすべての賞品について、チームポイントの方が、個人ポイントより有利に賞品との交換基準が設定されていなくてもよい。ゲームシステム100の稼働中に、各賞品の獲得に必要な個人ポイント数またはチームポイント数を変更してもよい。
第3の方法として、ある数のチームポイントを個人ポイントに交換した場合、交換前のチームポイント数より交換後の個人ポイント数が多くなるよう、チームポイントと個人ポイントとの間の交換レートを設定する方法が挙げられる。例えば、1チームポイントを2以上の整数値の個人ポイント(ポイント数として小数値が許容される場合には、1チームポイントを1より大きい数の個人ポイント)として交換を行うことができる。この方法は、チームポイントではなく、個人ポイントを使って賞品との交換を行うことが求められている場合に、好適である。この方法でも、ユーザに、決勝ゲームをプレイした方が、本選ゲームをプレイするよりポイントを獲得しやすい、という動機づけを行うことができる。
第4の方法として、ポイント管理部53は、決勝ゲームでチームが結成されたこと、チームにユーザが加入すること、勧誘を受けたユーザがチームに加入することを承諾することの少なくともいずれかを条件に、個人ポイントまたはチームポイントを付与することができる。例えば、決勝ゲームでチームメンバーが確定したときに、チームに属するユーザ全員に個人ポイントまたはチームポイントを与えてもよいし、チームにチームポイントを付与してもよい。また、ユーザが他ユーザにチームへの参加を勧誘する招待状を送付し、他ユーザが承諾し、正式なチームメンバーとなったら、勧誘を行ったユーザに個人ポイントまたはチームポイントを与えてもよい。また。勧誘を承諾した側のユーザにも個人ポイントまたはチームポイントを付与してもよい。決勝ゲームでチームメンバーの数が増えたら、チームに属する少なくとも一部のユーザに個人ポイントを与えてもよいし、チームにチームポイントを付与してもよい。
ユーザに、決勝ゲームをプレイするインセンティブを与えるために、上述の第1〜第4の方法のいずれかを適用してもよい。また、上述の第1〜第4の方法のうち、2以上の方法を組み合わせて適用してもよい。また、上述の第1〜第4の方法の少なくともいずれかの方法とその他の方法を組み合わせて適用してもよい。上述の方法の少なくともいずれかを適用することにより、シングルプレイヤーゲームを好むユーザにも、チーム間のバトルの楽しさを気づかせることができる。また、ユーザ間のコミュニケーションを促進し、ユーザが孤立してしまうことを防ぐことができる。
(決勝ゲームにおける個人ポイントの付与)
ここまで、本選ゲームで、ユーザ個人にポイント(個人ポイント)が付与され、決勝ゲームでは、チームにポイント(チームポイント)が付与される場合を主に説明した。チームポイントは、チームメンバーであるユーザに分配されない限り、ユーザ個人ではなく、チームに帰属していた。ただし、本選ゲームと決勝ゲームでユーザに同じ種類のポイントを付与してもよい。すなわち、ポイント管理部53は、決勝ゲームをプレイするチームに所属するユーザに、ポイント(個人ポイント)を付与してもよい。
例えば、本選ゲームだけでなく、決勝ゲームにおいても、ユーザに個人ポイントを与えてもよい。決勝ゲームにおいて、参戦しているチームにチームポイントを与える代わりにチームメンバーであるユーザに直接個人ポイントを付与してもよい。また、決勝ゲームにおいて、参戦しているチームにチームポイントを付与し、さらにチームメンバーであるユーザに個人ポイントを与えてもよい。
決勝ゲームに係る説明では、チームポイントが付与されうる複数の条件を示した。例えば、上述のチームポイントが付与されうるタイミングにおいて、代わりにチームメンバーであるユーザに直接個人ポイントを付与してもよい。ポイント管理部53は、決勝ゲームのトーナメント戦でチームが獲得した勝ち点に基づいて、当該チームに所属するユーザに付与する個人ポイントを決めてもよい。また、ポイント管理部53は、トーナメント戦の勝ち点によって算出されたチームの順位に基づき、当該チームに所属するユーザに付与する個人ポイントを決めてもよい。
決勝ゲームで、チームに所属するユーザに個人ポイントを付与する場合にも、上述の第1〜第6のポリシーおよび第1〜第3のパターンを適用することが可能である。ポイント管理部53は、決勝ゲームのトーナメント戦のマッチでチームが連勝した場合に、当該チームに所属するユーザに個人ポイントを付与してもよい(第1のポリシー)。ポイント管理部53は、決勝ゲームのトーナメント戦のマッチでチームが連勝後、マッチに敗戦した場合、チームに所属するユーザが決勝ゲームで獲得した個人ポイントを0にリセットしてもよい(第1のパターン)。ポイント管理部53は、決勝ゲームのトーナメント戦のマッチでチームが連勝後、マッチに敗戦した場合、チームに所属するユーザが決勝ゲームで獲得した個人ポイントを減らしてもよい(第2のパターン)。また、ポイント管理部53は、チームの勝敗に関わらず、ユーザが獲得した個人ポイントをそのまま維持してもよい(第3のパターン)。チームに属する各ユーザが、決勝ゲームで獲得した個人ポイントの一部を放棄することを条件に、チームにトーナメント戦の残りマッチを棄権することを認めてもよい。すなわち、ポイント管理部53は、チームが決勝ゲームのトーナメント戦の残りマッチを棄権した場合、チームに所属するユーザが決勝ゲームで獲得した個人ポイントを減らしてもよい。
さらに、ポイント管理部53は、決勝ゲームのトーナメント戦のマッチでチームが勝利したことを条件に、当該チームに所属するユーザに個人ポイントを付与してもよい(第2のポリシー)。また、ポイント管理部53は、決勝ゲームのトーナメント戦のマッチの勝敗に関わらず、チームに所属するユーザにチームポイントを付与してもよい(第3のポリシー)。さらに、ポイント管理部53は、マッチでチームが対戦した相手に応じて、当該チームに所属するユーザに異なる個人ポイント数を付与してもよい(第4のポリシー)。ポイント管理部53は、トーナメント戦のマッチの種類(1回戦、2回戦、準決勝、決勝など)に応じて、チームに所属するユーザに異なる個人ポイント数を付与してもよい(第5のポリシー)。ポイント管理部53は、チームが獲得した得点、チームのタイム、チームが相手に与えたダメージ(相手HPの減少量)など決勝ゲーム内における数値情報に応じて、当該チームに所属するユーザに付与する個人ポイント数を決定してもよい(第6のポリシー)。各ポリシーおよび各パターンを採用することによって得られる効果は、チームにチームポイントが付与される場合と同様である。また、ポイント管理部53は、これらの複数のポリシーおよび/またはパターンを組み合わせて適用してもよい。なお、ポイント管理部53は、決戦ゲームのトーナメント戦の階級ごとに異なる条件でチームに属するユーザに個人ポイントを付与してもよい。
また、上述とは異なる条件で、チームに所属するユーザに個人ポイントを与えてもよい。例えば、ポイント管理部53が、チームの成績に関わらず、各ユーザのプレイ内容に応じて個人ポイントを付与することを妨げるものではない。決勝ゲームにおいて、各ユーザに個人ポイントが付与されるタイミングについては、特に問わない。例えば、各マッチが行われているときに個人ポイントが付与されてもよいし、各マッチの終了後に個人ポイントが付与されてもよい。また、決勝ゲームまたはトーナメント戦の終了時に個人ポイントが付与されてもよい。また、複数のタイミングでユーザに個人ポイントが与えられてもよい。
決勝ゲームで、チームに所属するユーザに個人ポイントを与える場合にも、ユーザが決勝ゲームをプレイする意欲を高めるため、動機づけを行うことができる。例えば、ポイント管理部53で、決勝ゲームでチームに所属するユーザに付与される個人ポイントの平均値を、本選ゲームでユーザに付与される個人ポイントの平均値より大きく設定してもよい。すなわち、決勝ゲームにおける個人ポイントの付与基準を、本選ゲームにおける個人ポイントの付与基準より緩やかに設定してもよい。
上述の図26のテーブルを、本選ゲームで各ユーザに付与される個人ポイント数と、決勝ゲームでチームに所属する各ユーザに付与される個人ポイント数を示したテーブルとして使うことができる。列C1は、本選ゲームをプレイするユーザに、付与される個人ポイント数を条件別に示している。また、列C2は、決勝ゲームで各ユーザに付与される個人ポイント数を条件別に示す。列C1と列C2とを比較すると、後者では、1回の対戦ごとに、結果を問わず、参加賞として2PP付与されるのに対し、前者では、対戦に勝利しないと個人ポイントの付与は行われない。また、同一条件の場合、後者の方が前者より多くのポイントがもらえるようになっている。
図26に示したポイントの付与基準は一例にしかすぎない。したがって、これとは異なる基準に基づいてポイントの付与を行ってもよい。例えば、ポイント管理部53では、個人ポイントの付与条件の少なくとも一部において、決勝ゲームで付与される個人ポイントの数を、本選ゲームで付与される個人ポイントの数より多く設定していてもよい。ポイント管理部53は、決勝ゲームで個人ポイントが付与される条件数を、本選ゲームで個人ポイントが付与される条件数より多く設定してもよい。ゲームシステム100の稼働中に、個人ポイントの付与条件を変更してもよいし、各条件において付与される個人ポイント数を変更してもよい。なお、上述の第4の方法で述べたように、ポイント管理部53は、決勝ゲームでチームが結成されたこと、チームにユーザが加入すること、勧誘を受けたユーザがチームに加入することを承諾することの少なくともいずれかを条件に、ユーザへ個人ポイントを付与してもよい。
図28〜図30は、ゲームシステム100において実行される処理の例を示すフローチャートである。以下では、図28〜図30のフローチャートを参照しながら、処理を説明する。
まず、ユーザは、情報端末を介し、ゲームサーバ1にアクセスし、ゲームシステム100のアカウントを作成する(ステップS101)。ユーザの情報端末は、汎用的なスマートフォン、タブレット、デジタルテレビ、パソコンなどであってもよいし、ゲーム専用機であってもよい。ユーザは、アカウントの作成時に、氏名、生年月日、メールアドレス、電話番号、住所などの情報を入力する。ユーザが他のサービスのアカウントを使ってゲームをプレイする場合、ステップS101を省略してもよい。次に、ユーザは、ゲームで使用するキャラクタを選択する(ステップS102)。上述のように、ユーザは、さらにゲーム中のハンドルネーム(あだ名)およびキャラクタの名前を決定してもよい。ユーザがゲーム中で使うキャラクタは、モンスターであっても、それ以外のものであってもよい。
そして、ユーザは、参加フィーを購入する(ステップS103)。例えば、参加フィー管理部52は、法定通貨、電子マネー、プリペイドカード、仮想通貨の少なくともいずれかを支払ったユーザに参加フィーを付与することができる。ただし、ユーザは必ずステップS103で参加フィーを購入しなくてもよい。例えば、ゲームシステム100はユーザに参加フィーを付与してもよい。ユーザは他のユーザから参加フィーの少なくとも一部を譲り受けてもよい。なお、予選ゲーム内で参加フィーの購入をできるようにしてもよいし、予選ゲームをプレイしているユーザに参加フィーを付与してもよい。
ユーザは、参加フィーを使い、予選ゲームでキャラクタの能力値を高める(ステップS104)。予選ゲームの内容および方式については、特に問わない。次に、予選ゲーム管理部42は、予選ゲームのクリア条件および/または終了条件が満たされているか否かを判定する(ステップS105)。予選ゲームのクリア条件または終了条件の少なくともいずれかが満たされている場合(ステップS105のYES)、ユーザは、本選ゲームにエントリすることができる(ステップS106)。なお、予選ゲームのクリア条件が満たされていない場合(ステップS105のNO)、ユーザは、参加フィーを使い、予選ゲームのプレイを継続する(ステップS104)。
次に、ユーザは本選ゲームをプレイし、個人ポイントを獲得する(ステップS107)。本選ゲームでは、例えば、複数マッチのあるトーナメント戦を行うことができるが、本選ゲームの内容および方式については、特に問わない。ポイント管理部53は、ユーザが本選ゲームをプレイしているとき、ユーザが保有する個人ポイント数を更新する。そして、本選ゲーム管理部43は、本選ゲームの終了条件が満たされているか否かの判定を行う(ステップS108)。本選ゲームの終了条件が満たされている場合(ステップS108のYES)、賞品選択部54は、ユーザに個人ポイントを賞品と交換する機会を与える(ステップS109)。ここで、ユーザは、各種の商品、役務、経済的な利益の少なくともいずれかを賞品として選ぶことができる。賞品の受け取り方法は、指定住所への配達であってもよいし、店頭での受け取りであってもよく、方法については、特に問わない。また、賞品の受取人は、ユーザ本人、ユーザ以外の者のいずれでもよい。ユーザは、必ずステップS109ですべての個人ポイントを賞品と交換しなくてもよい。例えば、ユーザは、少なくとも一部の個人ポイントを貯蓄してもよいし、別のタイミングで個人ポイントを賞品と交換してもよい。本選ゲームの終了条件が満たされていない場合(ステップS108のNO)、ユーザは本選ゲームのプレイを継続する(ステップS107)。
次に、所定の条件が満たされたら、ユーザは、他ユーザとともにチームを結成し、決勝ゲームにエントリする(ステップS110)。ここで、所定の条件とは、決勝ゲームのエントリ資格が満たされていること、他ユーザが共同でチームに参加できる人数だけ存在していること、他のユーザによるチーム参加の承諾が得られていることが挙げられる。そして、ユーザは、チームで決勝ゲームをプレイし、チームポイントを獲得する(ステップS111)。決勝ゲームでは、例えば、チーム対抗のトーナメント戦を行うことができるが、チームメンバーでプレイできるのであれば、決勝ゲームの内容および方式については、特に問わない。ポイント管理部53は、チームが本選ゲームをプレイしているとき、当該チームが保有するチームポイント数を更新する。なお、上述のように、ステップS111で、チームに所属している各ユーザに個人ポイントを与えてもよい。チームに付与されるチームポイントの代わりに、各ユーザに個人ポイントが付与されてもよい。また、チームにチームポイントを付与し、さらに各ユーザに個人ポイントを付与してもよい。
次に、決勝ゲーム管理部44は、決勝ゲームの終了条件が満たされているか否かを判定する(ステップS112)。決勝ゲームの終了条件が満たされている場合(ステップS112のYES)、ポイント管理部53は、チームポイントをチームに属する各ユーザに分配する(ステップS113)。決勝ゲームの終了条件が満たされていない場合(ステップS112のNO)、チームは決勝ゲームのプレイを継続する(ステップS111)。なお、ステップS113で、必ずチームポイントをチームに属する各ユーザに分配しなくてもよい。例えば、ステップS113で、賞品選択部54は、チームの代表者となるユーザに、チームポイントを賞品と交換する機会を与えてもよい。また、ステップS113で、チームポイントの一部をチームに属する各ユーザに分配し、その残りをチーム全体で獲得する賞品との交換用に使ってもよい。
最後に、賞品選択部54は、ユーザにチームポイントを賞品と交換する機会を与える(ステップS114)。ここで、ユーザは、各種の商品、役務または経済的な利益を賞品として選ぶことができる。賞品選択部54でユーザが選択した賞品は、指定住所への配達または店舗での賞品引換券の提示によって受け取りが可能であってもよい。ただし、賞品の受取方法については、特に問わない。また、賞品の受取人は、ユーザ本人、ユーザ以外の者のいずれでもよい。ユーザは、必ずステップS114ですべてのチームポイントを賞品と交換しなくてもよい。例えば、ユーザは、少なくとも一部のチームポイントを貯蓄してもよいし、別のタイミングでチームポイントを賞品と交換してもよい。なお、ユーザにチームポイントを個人ポイントに交換する機会を与え、個人ポイントを賞品と交換させてもよい。また、上述のステップS113で、チームポイントを個人ポイントとして、チームに所属するユーザに分配してもよい。この場合、ステップS114で、ユーザは個人ポイントを希望する賞品と交換することができる。
図28〜図30のフローチャートの説明は、以上である。なお、図28〜図30のフローチャートでは、予選ゲーム、本選ゲーム、決勝ゲームの順にプレイが行われる場合を示しているが、本選ゲームおよび決勝ゲームのプレイが行われる順序および回数はこれとは異なっていてもよい。なお、ゲームシステムで本選ゲームが提供されない場合には、図28〜図30のフローチャートにおけるステップS105〜ステップS109が省略される。
ゲームシステム100を使うことにより、ユーザは、気軽にプレイを楽しみながらささやかな賞品を獲得でき、ユーザの心に潤いを与えることができる。ゲームシステム100では、プレイをするのにあたり課金を行うことが必須ではないため、未成年者や、ゲームに使うことができる予算が限られているユーザも安心してプレイすることができる。また、ゲームプレイの結果に関わらずユーザにポイントを付与することも可能であるため、ユーザは、ゲームのプレイ経験や勝ち負けにこだわらず、ゲーム内容を楽しむことができる。一方、ポイントを付与する条件(ポリシー)の設定次第では、ゲームにスリリングな要素を加味し、スキルに自信のある上級者ユーザを十分に満足させることも可能である。
また、ゲームシステム100では、ゲームをプレイすることにより、賞品を獲得することができるため、多忙なユーザも、ゲームをプレイするモチベーションを維持することができる。さらに、他のユーザとチームを組み、他のユーザと一緒にゲームをプレイすることも可能である。単独プレイでは獲得することが難しい賞品の獲得という共通の目標を設定し、他のユーザと協力しながらプレイすることもできる。また、特に欲しい賞品を特定せず、チームメンバー全員でより多くのポイントを稼ぐことを目指してもよい。ゲームをプレイする過程で、必然的に他のユーザとのコミュニケーションが必要となるため、他のユーザとの親睦を深めることができる。
このように、ゲームシステム100は、ユーザの多様なニーズに応え、より多くのユーザがゲームの楽しさを体感できるものであり、ゲームから遠ざかってしまっているユーザを呼び戻すポテンシャルを有するものであるといえる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示したものであり、発明の範囲の限定することは意図していない、これらの実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。