以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
1.サーバシステムの説明
図1は、本実施形態のサーバシステム(ネットワークシステム、ゲームシステム)を示す。本実施形態のサーバシステムは、複数の端末10とサーバ20とによって構成される。つまり、図1に示すように、本実施形態のサーバシステムは、サービスを提供するサーバ20と、端末10とが、ネットワークに接続可能に構成される。
また、本実施形態のサーバ20は、端末10からの要求に応じて、オンラインゲームサービス(ゲーム)を提供する。本実施形態では、端末10においてゲームプログラムが実行され、サーバ20では、ユーザ(プレーヤ)の情報やゲームに関する情報等が管理される。
端末10は、携帯端末(スマートフォン、タブレット型端末、携帯電話、PHS端末、PDA、携帯型ゲーム機等)、パーソナルコンピュータ(PC)、ゲーム機、画像生成装置などの情報処理装置であり、インターネット(WAN)、LANなどのネットワークを介してサーバ20に接続可能な装置である。なお、端末10とサーバ20との通信回線は、有線でもよいし無線でもよい。
なお、サーバ20は、複数のユーザ(プレーヤ)間でコミュニケーションを提供することが可能なサービスを提供する情報処理装置であり、本実施形態ではSNS(ソーシャル
・ネットワーキング・サービス)と呼ばれるコミュニティ型のサービスを提供するサーバであってもよい。つまり、サーバ20は、ユーザの情報(ユーザ名、日記、掲示情報、ゲームの進捗状況など)をログインしたユーザだけでなく、当該ユーザとフレンド関係にある他のユーザにも送信し、ユーザ間でコミュニティを図るようにし、会員登録を行ったユーザに限定してサービスを提供するようにしてもよい。かかる場合、サーバ20は、1又は複数のサーバ(認証サーバ、ゲーム処理サーバ、通信サーバ、課金サーバ、データベースサーバ等)により構成することができる。
2.サーバの構成
図2に本実施形態のサーバ20の機能ブロック図の一例を示す。なお本実施形態のサーバ20は図2の構成要素(各部)の一部を省略した構成としてもよい。
記憶部170は、処理部100や通信部196などのワーク領域となるもので、その機能はRAM、ハードディスクなどにより実現できる。記憶部170は、ワーク領域として使用される主記憶部172と、格納部160(例えばデータベース)とを含む。
格納部160は、本実施形態のネットワークシステムに参加する複数のユーザそれぞれのユーザ情報161、及び、ゲーム情報162を格納(記憶)する。
ユーザ情報161は、各ユーザの課金情報(課金額)、仮想通貨(ゲーム内通貨)、ユーザが使用可能なゲーム媒体の情報、ユーザがゲームで使用するゲーム媒体の情報(ユーザキャラクタに着用する服・靴アイテムや仮想カフェに配置する家具、料理等のアイテム)を記憶する。
本実施形態では、ユーザが所定の料金を支払うことによって、仮想通貨やゲーム媒体(アイテム等)をユーザに付与する課金システムを採用する。
つまり、サーバ20は、課金処理を行うサーバとして機能してもよいし、サーバ20は、他の課金サーバとネットワークを介して接続され、当該課金サーバによって課金処理を行うようにしてもよい。
つまり、サーバ20(課金サーバ)は、ユーザの端末から仮想通貨やゲーム媒体の代価を徴収する課金処理を行う。例えば、サーバ20(課金サーバ)は、ユーザへの料金請求及びユーザの銀行口座等からの引き落とし等を管理する処理、クレジット会社や、ユーザの端末10の通信サービス会社に応じた種々の課金処理を行う。例えば、ユーザU1が100円の料金の支払いを行うと、ユーザU1の仮想通貨に100円分の価値を加算する処理を行う。
ゲーム情報162は、ゲームを進行するために必要な情報であり、アイテムやゲーム進行、イベント進行に関する情報を記憶する。
情報記憶媒体180(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)などにより実現できる。処理部100は、情報記憶媒体180に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。情報記憶媒体180には、本実施形態の処理部100の各部としてコンピュータを機能させるためのプログラムを記憶することができる。
通信部196は端末10や他のサーバとの間で通信を行うための各種制御を行うもので
あり、その機能は、各種プロセッサ又は通信用ASICなどのハードウェアや、プログラムなどにより実現できる。
処理部100(プロセッサ)は、端末10から送信され通信部196を介して受信したデータ(入力情報等)、プログラムなどに基づいて、ユーザ情報161、ゲーム情報162の管理、ログイン/ログアウトに関する処理、画像生成処理などの各種処理を行う。処理部100は主記憶部172をワーク領域として各種処理を行う。処理部100の機能は各種プロセッサ(CPU、DSP等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。処理部100は、通信制御部110、イベント管理部111、選択処理部121、報知処理部122、特典処理部126を含む。
通信制御部110は、端末や他のサーバとネットワークを介してデータを送受信する処理を行う。
イベント管理部111は、第1のユーザに対応するゲームパラメータが所与のイベント実行値以上であることを条件に実行される当該第1のユーザによるイベント(以下、「第1のユーザ主催イベント」という。)のイベント実行情報を、第1のユーザの端末から受信した場合に、当該ゲームパラメータからイベント実行値を減算する。
また、イベント管理部111は、第2のユーザの端末からイベント参加情報を受信した場合に、第1のユーザ主催イベントに参加するために必要なイベント参加値を、第2のユーザに対応するゲームパラメータから減算する。
また、イベント管理部111は、第1のユーザの端末およびイベント参加が決定した第2のユーザの端末に、第1のユーザ主催イベントの実行に必要なイベント情報を送信する。
また、イベント管理部111は、イベント情報を受信した端末で実行される第1ユーザ主催イベントにおいて、第1のユーザの使用可能なゲーム媒体の中からゲームで使用するゲーム媒体として選択されたゲーム媒体、及び、前記第2のユーザの使用可能なゲーム媒体の中からゲームで使用するゲーム媒体として選択されたゲーム媒体に関する情報を受信する。
また、イベント管理部111は、端末から受信したゲーム媒体に関する情報を他のユーザの端末に送信する。
また、イベント管理部111は、第1のユーザ及び第2のユーザに選択されたゲーム媒体と、イベント実行値とに基づいて判定されるイベント達成度を記憶部に記憶する。
イベント管理部111は、イベント実行部120、イベント参加部124を含む。
例えば、イベント実行部120は、第1のユーザに対応するゲームパラメータが所与のイベント実行値以上であることを条件に実行される当該第1のユーザによるイベント(以下、「第1のユーザ主催イベント」という。)のイベント実行情報を受信した場合に、前記第1のユーザに対応するゲームパラメータからイベント実行値を減算して、当該第1のユーザ主催イベントを実行する。
また、イベント実行部120は、第1のユーザ主催イベントにおいて、第1のユーザの使用可能なゲーム媒体の中からゲームで使用するゲーム媒体として選択されたゲーム媒体、前記第2のユーザの使用可能なゲーム媒体の中からゲームで使用するゲーム媒体として
選択されたゲーム媒体、及び、前記イベント実行値に基づいて、イベント達成度を判定する。
また、イベント実行部120は、第1のユーザ及び前記第2のユーザの少なくとも一方が使用可能なアイテムを消費した場合には、消費したアイテムに基づいてイベント達成度を判定するようにしてもよい。
また、イベント実行部120は、第1のユーザがゲームで使用するゲーム媒体を選択してからの経過時間、第2のユーザがゲームで使用するゲーム媒体を選択してからの経過時間、第1のユーザがゲームで使用するゲーム媒体の希少度、第2のユーザがゲームで使用するゲーム媒体の希少度、の少なくとも一つに基づいて、イベント達成度を判定するようにしてもよい。
イベント参加部124は、第2のユーザの端末からイベント参加情報を受信した場合に、当該第2のユーザを第1のユーザ主催イベントに参加させることを決定する処理を行う。また、イベント参加部124は、第2のユーザに対応するゲームパラメータからイベント参加値を減算する。
また、イベント参加部124は、第2のユーザの端末から、当該イベント参加情報と、第2のユーザの使用可能なゲーム媒体の中からイベント達成度に対して有利に作用するゲーム媒体をゲームで使用するゲーム媒体として選択したことを示す情報と、を受信するようにしてもよい。
選択処理部121は、第1のユーザの端末から、第1のユーザ以外のユーザの中から第1のユーザ主催イベントに招待する第2のユーザを選択する情報を受信する。
また、選択処理部121は、第1のユーザの端末から、第1のユーザ主催イベントに招待する第2のユーザの使用可能なゲーム媒体の参照を希望する参照情報を受信した場合に、第2のユーザの使用可能なゲーム媒体の情報を、前記第1のユーザの端末に送信してもよい。例えば、選択処理部121は、第1のユーザの端末から参照情報を受信した場合に、第1のユーザがゲームで使用するゲーム媒体に基づき決められる第1のユーザ主催イベントのテーマに基づいて、第2のユーザの使用可能なゲーム媒体の中から一部のゲーム媒体を抽出し、抽出されたゲーム媒体の情報を、第1のユーザの端末に送信するようにしてもよい。
また、選択処理部121は、第1のユーザの端末から、第2のユーザの使用可能なゲーム媒体の中から、イベント達成度に対して有利に作用するゲーム媒体を指示する指示情報を受信してもよい。
報知処理部122は、第1のユーザの端末から、第1のユーザ以外のユーザの中から前記イベントに招待する第2のユーザを選択する情報を受信した場合に、第2のユーザの端末に第1のユーザ主催イベントへの参加を促す報知情報を送信する。
また、報知処理部122は、第2のユーザの端末に対して、イベント達成度に対して有利に作用するゲーム媒体に関する指示情報を含む報知情報を送信してもよい。
また、報知処理部122は、第2のユーザの端末に対して、第1のユーザの端末から受信した指示情報を含む報知情報を送信するようにしてもよい。
特典処理部126は、イベント達成度に基づいて、第1のユーザに特典を付与する。
また、特典処理部126は、イベント達成度に基づいて、第2のユーザに特典を付与してもよい。また、特典処理部126は、第1のユーザと第2のユーザとにおいて、異なる特典を付与するようにしてもよい。
なお、本実施形態において、端末10がサーバ20から受信した情報に基づいて端末10の表示部290に表示する画像データ(画面データ)を生成しているが、端末10から受信した情報に基づきサーバ20が画像データを生成してもよい。
3.端末の構成
図3に本実施形態の端末10の機能ブロック図の一例を示す。なお本実施形態の端末10は図3の構成要素(各部)の一部を省略した構成としてもよい。
入力部260は、ユーザからの入力情報を入力するための機器であり、ユーザの入力情報(操作入力)を処理部200に出力する。入力部260の機能は、タッチパネル(タッチパネル型ディスプレイ)、タッチパッド、マウス、方向キーやボタン、キーボード等の入力機器により実現することができる。本実施形態では、表示部としても機能するタッチパネルによるタッチ入力(接触操作入力)によりユーザの入力を検出している。
記憶部270は、処理部200や通信部296などのワーク領域となるもので、その機能はRAMなどにより実現できる。記憶部270は、ワーク領域として使用される主記憶部272を含む。
情報記憶媒体280(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)などにより実現できる。処理部200は、情報記憶媒体280に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。情報記憶媒体280には、本実施形態の処理部200の各部としてコンピュータを機能させるためのプログラムを記憶することができる。
表示部290は、処理部200で生成されたゲーム画像を出力するものであり、その機能は、LCD、CRT、或いはタッチパネルなどのディスプレイにより実現できる。
音出力部292は、処理部200で生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
通信部296はサーバ20との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ASICなどのハードウェアや、プログラムなどにより実現できる。
処理部200(プロセッサ)は、入力部260からの入力情報、プログラム、通信部296を介してサーバ20から受信したデータなどに基づいて、ゲーム処理、画像生成処理、音生成処理、などの処理を行う。処理部200は主記憶部272をワーク領域として各種処理を行う。処理部200の機能は各種プロセッサ(CPU、DSP等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。処理部200は、ゲーム進行制御部210、画像生成部220、音生成部230を含む。
ゲーム進行制御部210は、入力部260からの入力情報や、サーバ20から受信したデータなどに基づいて、ゲームを進行させる処理(ゲームを開始させる処理、ゲーム空間
にキャラクタ等を配置する処理、各種ゲームパラメータを算出する処理、ゲームを終了させる処理)を行う。
例えば、ゲーム進行制御部210は、第1のユーザ主催イベントに参加する場合において、イベント参加情報と、第1のユーザ主催イベントにおいて使用するゲーム媒体の選択とを同時に入力を受け付ける処理を行うようにしてもよい。
画像生成部220は、各種ゲーム画面を生成し、表示部290に出力する。例えば、サーバ20から受信した画像情報に基づいて画像データ(画面データ)を生成し、表示部290に出力する。
また、画像生成部220は、サーバにおいて生成された画像データを受信し、受信した画像データを表示部290に出力してもよい。例えば、サーバにおいて画像情報に基づいて生成された画像データを、表示部290に出力するようにしてもよい。
なお、画像生成部220は、オブジェクト空間内において仮想カメラ(所与の視点)から見える画像(いわゆる3次元画像)を生成してもよい。
音生成部230は、処理部200で行われる種々の処理の結果に基づいて音処理を行い、BGM、効果音、又は音声などのゲーム音を生成し、音出力部292に出力する。
また、通信制御部240は、ゲームを開始した場合には、ゲームを開始したことを通知するための情報をサーバ20に送信する。また、通信制御部240は、サーバからユーザ情報や特典情報を受信する処理を行う。また、通信制御部240は、ゲームが終了した場合には、ゲームが終了したことを通知するための情報をサーバ20に送信してもよい。
また、通信制御部240は、種々の情報をサーバ20に送受信する。
例えば、通信制御部240は、第1のユーザ主催イベントにおいて、ユーザの使用可能なゲーム媒体の中からゲームで使用するゲーム媒体として選択されたゲーム媒体に関する情報をサーバに送信する。
特に、第1のユーザ主催イベントに招待された第2のユーザの端末の通信制御部240は、イベント参加情報と、第1のユーザ主催イベントにおいて使用するゲーム媒体の選択とを同時に入力を受け付け可能であるので、通信制御部240は、当該イベント参加情報と、第1のユーザ主催イベントにおいて使用するゲーム媒体に関する情報とを、サーバに同時に送信してもよい。かかる場合、第2のユーザに選択されるゲーム媒体は、第2のユーザの使用可能なゲーム媒体の中からイベント達成度に対して有利に作用するゲーム媒体であってもよい。つまり、第2のユーザの端末の通信制御部240は、イベント参加情報と、第2のユーザの使用可能なゲーム媒体の中からイベント達成度に対して有利に作用するゲーム媒体をゲームで使用するゲーム媒体として選択したことを示す情報と、をサーバに送信するようにしてもよい。
また、イベントを主催する第1のユーザの端末の通信制御部240は、第1ユーザ主催イベントの実行に必要なイベント情報をサーバから受信する。
また、第2のユーザの端末の通信制御部240も、第1ユーザ主催イベントの実行に必要なイベント情報をサーバから受信する。
また、第1のユーザの端末の通信制御部240は、第1のユーザ以外のユーザの中から
第1のユーザ主催イベントに招待する第2のユーザを選択する情報をサーバに送信する。
また、第1のユーザの端末の通信制御部240は、第1のユーザ主催イベントに招待する第2のユーザの使用可能なゲーム媒体の参照を希望する参照情報をサーバに送信し、第2のユーザの使用可能なゲーム媒体の情報をサーバから受信するようにしてもよい。かかる場合、第1のユーザの端末の通信制御部240は、第2のユーザの使用可能なゲーム媒体の中から、イベント達成度に対して有利に作用するゲーム媒体を指示する指示情報を、サーバに送信するようにしてもよい。
また、第2のユーザの端末の通信制御部240は、第1のユーザ主催イベントへの参加を促す報知情報を受信する処理を行う。また、第2のユーザの端末の通信制御部240は、イベント達成度に対して有利に作用するゲーム媒体に関する指示情報を含む報知情報を受信するようにしてもよいし、ユーザが第1のユーザ主催イベントを実行する第1のユーザが指示した指示情報を含む報知情報を受信するようにしてもよい。
4.本実施形態の処理の手法
<概要>
本実施形態では、ユーザをキャラクタ化したユーザキャラクタを仮想空間内(2次元仮想空間内又は3次元仮想空間内)に配置し、ユーザキャラクタの服や家具等のアイテム(ゲーム媒体の一例)を取得し、ユーザが仮想空間を楽しむゲームに関するものである。例えば、ユーザは、ユーザキャラクタが仮想カフェのオーナーとなりパーティを開いて他のユーザを招待し交流を図れるようゲームをプレイすることができる。
<イベントの実行>
本実施形態のサーバは、ユーザの端末からのゲーム開始要求に基づきゲームを実行し、ゲーム中に端末からイベント実行情報を受信すると、仮想空間上のカフェ内でパーティを開催するイベントを実行する。例えば、端末は、ユーザU1の操作入力によりイベントの実行を受け付け、サーバにイベントの実行情報を送信する処理を行う。サーバは、ユーザU1の端末からイベントの実行情報を受信すると、ユーザU1の操作対象のユーザキャラクタCA1のパーティを開催するイベントを実行する処理を行う。
サーバは、図4に示すように、T1時点でユーザU1からのイベントの実行情報を受信すると、当該T1時点においてユーザU1のイベントを実行する。そして、T1時点から所定期間K1(例えば、1分)経過した時点T2に、イベントを開始するように制御する。つまり、所定期間K1は、イベントを開始するための準備期間となる。なお、所定期間K1は必ずしも必要とは限らず、イベント実行時T1にイベントを開始してもよい。また、イベントの実行期間は、実行時T1からイベント終了時T4までの期間である。
また、サーバは、各ユーザIDに対応づけてゲームパラメータを管理している。このゲームパラメータはゲーム進行に応じて変動する。例えば、ユーザの課金や時間経過に応じてゲームパラメータを増加させ、ユーザの入力により所定値を減算する情報を受信した場合に、ゲームパラメータを減算する処理を行う。
例えば、仮想通貨をゲームパラメータとする場合について説明すると、ユーザU1がイベントを実行する際には、当該イベントに応じて定められたイベント実行値をユーザU1に対応する仮想通貨から消費(減算)する。例えば、ユーザU1に対応する仮想通貨が「1000」に設定されている場合に、ユーザU1の端末からイベントの実行情報を受信してユーザキャラクタCA1がパーティを開催するイベントを実行すると、当該ユーザU1に対応する仮想通貨「1000」からパーティ開催に伴うイベント実行値「400」を減算する処理を行う。
本実施形態では、イベント実行値を所定の値に予め定めても良いし、図5に示すように、ユーザU1が任意にイベント実行値を決められるように制御してもよい。つまり、図5に示すように、ユーザU1の端末においてイベント実行値の入力フォーム51とイベントを実行する決定の指示体52を表示する。例えば、ユーザU1の端末は、イベント実行値を受け付け、イベント実行を受け付けると、当該イベント実行値をサーバに送信するように制御する。サーバはユーザU1の端末からイベント実行値を受信すると、ユーザU1に対応する仮想通貨からイベント実行値を減算する処理を行う。
本実施形態では、ユーザがイベント実行値を高く設定すればする程(ユーザが所持する仮想通貨を消費すればする程)、ユーザに有利になるような特典処理を行う。例えば、パーティに特別キャラクタが登場する可能性を高くする、或いは、希少度の高いレアアイテムをユーザに付与する等の制御を行う。
また、サーバは、イベントを実行するユーザが、イベント実行時T1から終了時T4においてアイテムを消費(減算)した場合には、当該ユーザに有利になるような特典処理を行うようにしてもよい。例えば、図6に示すように、ユーザU1の端末において、イベントで使用可能なアイテム(「ハーブ」のアイテム)を表示し、アイテムの消費量を入力するための入力フォーム61と決定の指示体62を表示する。例えば、ユーザU1の端末は、アイテムの消費量を受け付けると、当該アイテムの消費量をサーバに送信する。サーバは、ユーザU1に対応するアイテムの所持数から受信した消費量を減算する処理を行う。本実施形態では、ユーザがイベントで用いるアイテムを消費すればするほど、ユーザに有利になるような特典処理を行う。
<イベントの招待>
本実施形態では、イベントを実行したユーザU1は、他のユーザを招待することができる。サーバは、ユーザU1のフレンド関係にあるユーザの情報を招待候補ユーザとして、ユーザU1の端末に送信し、ユーザU1の端末は、図7に示すように、受信したユーザの情報を表示部に表示する。
また、招待候補ユーザは、イベントを実行したユーザU1とフレンド関係にないユーザであってもよい。また、サーバは、ユーザU1とフレンド関係にあるユーザの中から、所定条件を満たすユーザを招待候補ユーザとして選ぶようにしてもよい。例えば、ユーザU1と所定期間(例えば、30日間)フレンド関係を維持していることを条件に、招待候補ユーザを決定してもよい。また、ユーザU1のフレンド数が100人等多数の場合は、フレンド関係の維持期間が長いユーザから順に所定数のユーザ(例えば5人)を招待候補ユーザとして選んでもよい。
ユーザU1の端末は、図7に示すように、サーバから受信したユーザ情報(例えば、ユーザU2、U3、U4、U5、U6)を表示する。例えば、ユーザ毎に、ユーザキャラクタの画像(例えば、ユーザキャラクタの顔画像)71、ユーザ名72、ユーザの詳細内容を示す指示体73、招待の選択を受け付けるための指示体74を表示する。
そして、ユーザU1の端末は、イベントに招待するユーザを招待候補ユーザの中から選択する。イベントに招待するユーザの数は複数人でもよいし一人でもよい。ユーザU1の端末は、例えば、ユーザU1の操作入力によりユーザU2をイベントに招待するユーザとしての選択を受け付けた場合には、ユーザU2を選択したことを示す情報をサーバに送信する。
なお、本実施形態において、ユーザU1が他のユーザを招待する期間は、図4に示すよ
うにイベントを実行した時点T1からイベント開始時点T2までの期間K1としてもよいし、イベントを実行した時点T1からイベントの達成度の判定時点T3の期間K2としてもよい。
<イベントの参加を促す報知情報>
サーバは、ユーザU1の端末から招待する他のユーザの選択を受け付けると、ユーザU1のイベントの参加を促す報知情報を当該他のユーザの端末に送信する。
例えば、サーバは、ユーザU1の端末からユーザU2をイベントに招待するユーザとしての選択した情報を受信した場合には、ユーザU2の端末に報知情報を送信する。例えば、サーバは、ユーザU2の端末に、報知情報に含まれるメッセージ(例えば、ユーザU1のイベントの参加を促すメッセージ)を送信する。そして、ユーザU2の端末は、図8に示すように、画面W8において報知情報に含まれるユーザU1のイベントの参加を促すメッセージ80とイベント参加可否入力の指示体81、82を表示し、イベント参加可否を受け付ける処理を行う。
<イベントの参加>
図8に示すように、ユーザU2の端末は、例えば、参加の指示体81の入力により、ユーザU1のイベントに参加する入力を受け付けた場合には、イベント参加情報をサーバに送信する。また、不参加の指示体82の入力により、ユーザU1のイベントに参加しない入力を受け付けた場合には、イベント不参加情報をサーバに送信する。
そして、サーバ、ユーザU2の端末からイベント参加情報を受信した場合に、ユーザU2をイベントに参加させることを決定する処理を行う。
また、本実施形態において、サーバは、ユーザU2の端末からイベント参加を受け付ける期間は、図4に示すようにイベントを実行した時点T1からイベントの達成度の判定時点T3の期間K2としている。つまり、パーティを開始した時点T2以後も、他のユーザのイベント参加を受け付ける処理を行っている。つまり、イベントの達成度の判定時点T3は、イベントの参加受付終了時点となる。
また、本実施形態では、他のユーザがイベントに参加する際には、当該イベントに応じて定められたイベント参加値を他のユーザに対応する仮想通貨から消費(減算)する。例えば、ユーザU2がユーザU1のイベントに参加することを決定した場合には、ユーザU2に対応する仮想通貨からイベント参加値を減算する。例えば、ユーザU2に対応する仮想通貨が「2000」に設定されている場合に、ユーザU2の端末からイベントの参加情報を受信すると、当該ユーザU2に対応する仮想通貨「2000」からパーティ開催に伴うイベント参加値「200」を減算する処理を行う。
このイベント参加値は、イベント実行値よりも低い値に設定されており(イベント参加値<イベント実行値)、イベントに参加するユーザは、イベントを実行するユーザよりも負担を軽くし、簡易にイベントに参加できるようにしている。
本実施形態では、イベント参加値を所定の値に予め定めても良いし、図9に示すように、ユーザU2が任意にイベント参加値を決められるように制御してもよい。つまり、図9に示すように、ユーザU2の端末においてイベント参加値の入力フォーム91とイベントに参加する決定の指示体92を表示する。例えば、ユーザU2の端末は、イベント参加値を受け付け、イベント参加を受け付けると、当該イベント参加値をサーバに送信するように制御する。サーバはユーザU2の端末からイベント参加値を受信すると、ユーザU2に対応する仮想通貨からイベント参加値を減算する処理を行う。
本実施形態では、ユーザがイベント参加値を高く設定すればする程(ユーザが所持する仮想通貨を消費すればする程)、ユーザに有利になるような特典処理を行う。例えば、パーティに特別キャラクタが登場する可能性を高くする、或いは、レアアイテムをユーザに付与する等の制御を行う。
また、サーバは、イベントに参加するユーザが、イベント実行時T1から終了時T4においてアイテムを消費(減算)した場合には、イベントを実行したユーザ及びイベントに参加したユーザに有利になるような特典処理を行うようにしてもよい。つまり、ユーザU1の端末と同じように、ユーザU2の端末においても、例えば、図6に示すように、イベントで使用可能なアイテム(「ハーブ」のアイテム)を表示し、アイテムの消費量を入力するための入力フォーム61と決定の指示体62を表示する。例えば、ユーザU2の端末は、アイテムの消費量を受け付けると、当該アイテムの消費量をサーバに送信する。サーバは、ユーザU2に対応するアイテムの所持数から受信した消費量を減算する処理を行う。本実施形態では、ユーザがイベントで用いるアイテムを消費するほど、イベントを実行したユーザ及びイベントに参加したユーザに有利になるような特典処理を行う。
なお、本実施形態では、イベント開始時点T2前において、イベント参加のキャンセルができるように制御してもよい。例えば、サーバは、イベント開始時点T2前において、ユーザU2の端末から、ユーザU1が実行したイベントへの参加をキャンセルする情報を受信した場合には、ユーザU1が実行したイベントに対してユーザU2の不参加になるように制御する。また、キャンセルした場合には、ユーザU2に対応する仮想通貨に、イベント参加値の減算分を加算し元に戻すように制御する。
<イベントのレベル>
本実施形態では、一のイベントについてレベルLを設定する。このレベルLはイベント毎に設定され、初期値に0を設定している。そして、所定条件下でレベルLが増大するように制御される。レベルLはイベントの達成度(イベント達成度)を判別するために用いられ、例えば、図10に示すように、レベルLの値が高いほど、イベントの達成度が高いことを示す。
具体的に、ユーザU1が実行するイベントのレベルLの制御について説明する。まず、レベルLに、初期値0が設定される(L=0に設定される)。そして、ユーザU1がイベントを実行すると、イベント実行値をレベルに加算する。例えば、サーバが、ユーザU1の端末からイベント実行情報を受信すると、レベルLにイベント実行値を加算する処理を行う。例えば、イベント実行値が400の場合には、レベルL=400に更新される。
そして、他のユーザの端末からイベント参加情報を受信するとレベルLにイベント参加値を加算する処理を行う。例えば、サーバは、ユーザU2の端末からイベント参加情報を受信し、イベント参加値が200である場合には、レベルL=600に更新される。
また、サーバは、別のユーザU3からイベント参加情報を受信すると、更に、レベルLにユーザU3のイベント参加値を加算する処理を行う。例えば、ユーザU3のイベント参加値が100である場合には、レベルL=700に更新される。
本実施形態では、図4に示すように、イベントを実行した時点T1から他のユーザからのイベントの達成度の判定時点T3までの期間K2において、レベルLを制御する。
そして、図10に示すように、イベントの達成度の判定時点T3のレベルLに基づいて、達成度を判定する。
例えば、レベルLが0以上250未満(0≦L<250)の場合は、イベントの達成度が「0」であると判定する。
また、レベルLが250以上500未満(250≦L<500)の場合は、イベントの達成度が「1」であると判定する。
また、レベルLが500以上750未満(500≦L<750)の場合は、イベントの達成度が「2」であると判定する。
また、レベルLが750以上1000未満(750≦L<1000)の場合は、イベントの達成度が「3」であると判定する。
また、レベルLが1000以上(1000≦L)の場合は、イベントの達成度が「4」であると判定する。
<ゲームで使用するゲーム媒体の選択>
本実施形態のサーバは、ユーザ毎に、ユーザ(ユーザID)に対応づけて当該ユーザが使用可能な種々のゲーム媒体(靴、服、家具等のアイテム)を管理している。そして、サーバは、ユーザ毎に、ユーザの使用可能な複数のゲーム媒体の中から、ゲームで使用するゲーム媒体の選択を受け付ける処理を行う。つまり、ゲームで使用するゲーム媒体の選択とは、ゲーム中のユーザキャラクタに設定するゲーム媒体(靴、服などのアイテム)の選択であり、応用例としてゲーム中のデッキに設定するゲーム媒体(カード、キャラクタ)の選択等を含む。
例えば、ゲームで使用するゲーム媒体の個数は種類毎に制限を設けてもよい。例えば、靴、服はそれぞれ1つのみゲームで使用するように制限し、家具については無制限でゲームで使用できるようにする。
本実施形態では、イベントを実行したユーザ及びイベントに参加したユーザそれぞれにおいて、使用可能なゲーム媒体の中からゲームで使用するゲーム媒体の選択を受け付ける。そして、本実施形態では、選択されたゲーム媒体に基づいてイベントを実行する処理を行う。
例えば、イベントを実行するユーザU1の端末は、ゲームで使用するユーザキャラクタCA1に着用する服と靴のアイテム、及び、パーティで用いる家具の選択を受け付ける。そして、ユーザU1の端末は選択された服、靴、家具のアイテムをサーバに送信する。
サーバは、ユーザU1の端末から受信した情報に基づき、ユーザU1に対応づけてゲームで使用するゲーム媒体を記憶する。
また、イベントに参加するユーザU2の端末は、ゲームで使用するユーザキャラクタCA2に着用する服と靴のアイテムの選択を受け付ける。そして、ユーザU2の端末は選択された服、靴のアイテムをサーバに送信する。
サーバは、ユーザU2の端末から受信した情報に基づき、ユーザU2に対応づけてゲームで使用するゲーム媒体を記憶する。
<ゲーム媒体を選択してからの経過時間に基づくレベルの制御>
本実施形態では、サーバは、イベントを実行したユーザ、イベントに参加したユーザそ
れぞれについて、ゲームで使用する各ゲーム媒体(服、靴、家具、料理など)を選択してからの経過時間を管理する。そして、イベントを実行したユーザ、イベントに参加したユーザそれぞれについて、ゲーム媒体を選択してからの経過時間に基づいて、レベルLを変動させるように制御してもよい。例えば、ゲーム媒体を選択してからの経過時間が短いほどレベルLを増加させるように制御してもよい。
例えば、イベントを実行するユーザが、ゲームで使用するゲーム媒体を選択してからの経過時間が10分以内である場合には、ゲーム媒体1個につき20をレベルLに加点する。
また、例えば、イベントを実行するユーザが、ゲームで使用するゲーム媒体を選択してからの経過時間が60分以内である場合には、ゲーム媒体1個につき10をレベルLに加点する。
また、例えば、イベントに参加するユーザが、ゲームで使用するゲーム媒体を選択してからの経過時間が10分以内である場合には、ゲーム媒体1個につき5をレベルLに加点する。
このようにすれば、イベントのためにゲーム媒体を選択することがユーザにとって有利となり、ユーザにゲームで使用するゲーム媒体の選択操作を促すことができる。
<ゲーム媒体の希少度に基づくレベルの制御>
本実施形態では、サーバは、イベントを実行したユーザ、イベントに参加したユーザそれぞれについて、ゲームで使用する各ゲーム媒体(服、靴、家具、料理など)の希少度に基づき、レベルLを変動させるように制御してもよい。例えば、選択されたゲーム媒体の希少度が高いほどレベルLを増加させるように制御してもよい。
例えば、ゲーム媒体である靴、服、家具などのゲーム媒体それぞれに希少度を設定する。例えば、希少度は1〜100の値域とする。
そして、イベントを実行するユーザが選択したゲーム媒体の希少度をレベルLに加点する。例えば、ユーザU1の靴の希少度が10、服の希少度が20、家具の希少度が50である場合には、80をレベルLに加点する。
同じように、イベントに参加するユーザそれぞれについて、ユーザが選択したゲーム媒体の希少度をレベルLに加点する。
このようにすれば、イベントのために希少度の高いゲーム媒体を選択することがユーザにとって有利となり、ユーザに希少度の高いゲーム媒体の選択操作を促すことができる。
<イベントの開始>
本実施形態では、図4に示すように、T2時点でイベントが開始されると、イベントを実行するユーザの端末、イベントに参加するユーザの各端末において、共通の仮想空間上に各ユーザのキャラクタを配置したゲーム画像を表示する制御を行う。
つまり、サーバはイベント開始時点が到来すると、イベントを実行するユーザU1の端末やイベントに参加するユーザU2、U3、U4の端末に、開始情報を送信し、イベントが終了するまで画像情報を送信する。各端末は、サーバから開始情報を受信すると、サーバから受信した画像情報に基づき画像データを生成し表示部に表示する制御を行う。
図11は、ユーザU1の表示部に表示されるゲーム画面W11の一例である。例えば、ユーザU1のイベントに、ユーザU2、U3、U4が参加している場合には、仮想空間において、ユーザU1のユーザキャラクタCA1がカフェのオーナーとなり、飲み物、ケーキなどの提供を行い、ユーザU2、U3、U4の各ユーザキャラクタCA2、CA3、CA4がパーティ会場を探索し、飲み物、ケーキなどの飲食を楽しむことができる。本実施形態では、ユーザU1、U2、U3、U4のユーザ毎に、各ユーザの操作対象のキャラクタに基づいて画像を生成する。
また、図11に示すように、ユーザU1の端末において、レベルLの値をゲージとして表示するようにしてもよい。例えば、図11の例ではレベルLが700であることを示している。
<イベントにおける特典処理の例(特別キャラクタの登場)>
本実施形態では、イベントの達成度に基づいて、イベントを実行するユーザやイベントに参加したユーザに特典処理を行っている。
例えば、本実施形態では、イベントの達成度に応じて、仮想空間に特別キャラクタを登場させるか否かを制御している。例えば、イベントの達成度が0の場合には特別キャラクタを登場させず、イベントの達成度が1以上の場合に特別キャラクタを登場させる制御を行う。つまり、本実施形態では、イベントの達成度が1以上の場合に、特別キャラクタを登場させる特典処理を行っている。
図12は、特別キャラクタの一例を示す。例えば、サーバは、予め、達成度に対応する特別キャラクタを用意する。例えば、達成度が「1」に対応する特別キャラクタ400、達成度「2」に対応する特別キャラクタ401、達成度「3」に対応する特別キャラクタ402、達成度「4」に対応する特別キャラクタ403、のように、サーバは予め特別キャラクタを用意する。なお、達成度が高くなるにつれて希少度の高い特別キャラクタになるように設定している。
そして、図4に示すように、イベントの達成度の判定時点T3で、イベントの達成度が決定され、イベントの達成度が1以上の場合には、達成度に対応する特別キャラクタを仮想空間に配置する制御を行う。
図13はユーザU1のゲーム画面W12の一例である。例えば、ユーザU1のイベントの達成度が「2」である場合には、達成度「2」に対応する特別キャラクタ401を仮想空間に配置し、特別キャラクタが配置された仮想空間の画像を各端末の表示部に表示する制御を行う。
本実施形態では、イベントの達成度の判定時点T3からイベント終了時点T4の期間K3において、特別キャラクタ401が仮想空間に配置されるように制御を行っている。
このように、イベントの達成度が高ければ高いほど、希少度の高い特別キャラクタが登場することになるので、イベントを実行するユーザには多くのイベント実行値やアイテムを消費させる動機を与えることができる。また、また、イベント参加ユーザには多くのイベント参加値やアイテムを消費させるきっかけを与えることができる。また、参加ユーザが多ければ多いほどイベントの達成度が高くなり、希少度の高い特別キャラクタが登場するので、より多くのユーザがイベントに参加するように促すことができる。
<イベントにおける特典処理の例(ゲーム媒体の特典付与)>
また、本実施形態では、イベントの達成度に応じて、イベントを実行したユーザ及び参
加したユーザにゲーム媒体を付与する特典処理を行う。なお、本実施形態では、達成度が0であってもイベントを実行したユーザ及び参加したユーザにゲーム媒体を付与する特典処理を行う。
具体的には、イベントの達成度に基づいて、各ユーザに服、靴、家具などのアイテムを付与する処理を行う。
図14(A)(B)(C)は、特典として付与するアイテムの一例を示す。例えば、サーバは、予め、達成度に対応するアイテムを用意する。
例えば、図14(A)に示すように、靴のアイテムの場合に、達成度「0」に対応する靴300、達成度「1」に対応する靴301、達成度「2」に対応する靴302、達成度「3」に対応する靴303、達成度「4」に対応する靴304、のように、サーバは予め靴のアイテムを用意する。
また、例えば、図14(B)に示すように、服のアイテムの場合に、達成度「0」に対応する服310、達成度「1」に対応する服311、達成度「2」に対応する服312、達成度「3」に対応する服313、達成度「4」に対応する服314、のように、サーバは予め服のアイテムを用意する。
また、例えば、図14(c)に示すように、家具のアイテムの場合に、達成度「0」に対応する家具320、達成度「1」に対応する家具321、達成度「2」に対応する家具322、達成度「3」に対応する家具323、達成度「4」に対応する家具324、のように、サーバは予め家具のアイテムを用意する。
なお、靴、服、家具いずれも、達成度が高くなるにつれて希少度の高いアイテムになるように設定している。
そして、図4に示すように、イベントの達成度の判定時点T3で、イベントの達成度が決定され、イベントの達成度に対応するアイテムを、イベント実行ユーザ及び参加ユーザに付与する制御を行う。
例えば、ユーザU1が実行したイベントに、ユーザU2、U3、U4が参加した場合において、イベントの達成度が「2」である場合には、ユーザU1に対しては達成度「2」に対応する靴のアイテム302を付与する、参加ユーザU2、U3、U4に対しては(達成度−2)に対応する靴のアイテムを付与する。つまり、イベントの達成度が「2」である場合には、達成度0に対応する靴のアイテムを参加ユーザU2、U3、U4に付与する。なお、(達成度−2)が0よりも小さい値の場合にも達成度0に対応するアイテムを付与する。
つまり、ユーザU1が消費するイベント実行値はユーザU2、U3、U4が消費するイベント参加値よりも高く、ユーザU1の方がより仮想通貨を消費しているので、ユーザU1には、ユーザU2、U3、U4よりも希少度の高いアイテムを付与した方がユーザU1に満足感を与えることができ、継続してゲームプレイをさせることができるからである。
なお、靴よりも服の方が、希少度が高く、服よりも家具の方が、希少度が高いようにアイテムの設定をしている場合には、イベント実行ユーザに達成度に対応する家具又は服のアイテムを付与し、イベント参加ユーザに達成度に対応する靴のアイテムを付与するように制御してもよい(或いは、イベント実行ユーザに達成度に対応する家具のアイテムを付与し、イベント参加ユーザに達成度に対応する服又は靴のアイテムを付与するように制御
するように制御してもよい)。つまり、本実施形態では、イベント実行ユーザに、イベント参加ユーザよりも希少度の高いアイテムを付与するように制御する。
なお、サーバは、イベントの達成度を判定後、イベント終了時T4までに、各ユーザに特典として付与するアイテムを決定する。そして、サーバは、イベント終了時T4に、各ユーザの端末に特典付与のアイテムを送信する。そして、各端末は、サーバから受信したアイテムを使用可能なアイテムとして記憶する。なお、ユーザがイベント中にログアウトした際や何らかの通信障害が発生した場合に、サーバは、当該ユーザIDに対応付けて、特典付与のアイテムを記憶部に記憶する。そして、サーバは、端末のログイン時に特典付与のアイテムを送信する処理を行う。
<イベントのテーマに基づく制御>
本実施形態では、イベントにおいて、あるテーマに対応する服、靴、家具などのアイテムが多く揃うとユーザにとって有利な特典処理を行う。つまり、イベントを実行するユーザがゲームで使用するアイテムとして選択した服、靴、家具、イベントに参加するユーザがゲームで使用するアイテムとして選択した服、靴が同じテーマで揃うと、ユーザにとって有利になるような特典が得られることになり、ゲームの面白みを増大させることができる。
図15は、テーマとアイテムとの関係を示す図である。例えば、テーマ「A」では、「靴300」、「服310」、「家具320」等が対応付けられている。また、テーマ「B」では、「靴301」、「服311」、「家具321」等が対応付けられている。
本実施形態では、テーマに沿ったアイテムが増えるほど、レベルLを増加させるように制御する。レベルLの増大によってイベントの達成度が高まり、希少度の高い特別キャラクタが登場することになり、また、希少度の高いアイテムが付与される可能性を高くするように制御する。
<イベントを実行するユーザが指定するテーマ>
例えば、ユーザU1が、テーマ「A」のイベントを行いたい場合には、ユーザU1が、仮想空間のカフェをテーマAに応じた家具320を配置し、ユーザU1のユーザキャラクタCA1に靴300、服310をゲームで使用するアイテムとして選択する。
本実施形態では、ユーザU1の端末は、イベント実行時にユーザU1がゲームで使用するアイテム(例えば、服)を参照して、当該アイテムのテーマを、指定されたテーマとしてサーバに送信する。つまり、ユーザU1のキャラクタCA1に着用(選択)されている服のアイテムが服310である場合にはテーマ「A」と判別されるので、テーマ「A」を指定されたテーマとしてサーバに送信する。なお、ユーザU1の端末は、ユーザU1の入力によって直接、指定するテーマをサーバに送信するように制御してもよい。
<テーマを指定して他のユーザを招待する手法の説明>
本実施形態では、イベントを実行するユーザU1の端末がサーバを介して他のユーザU2にテーマを指定して招待できるように制御してもよい。
まず、ユーザU1の端末は、他のユーザをイベントに招待するユーザとしての選択を受け付けた場合に、他のユーザを選択した情報と、テーマ情報とを送信する。
そして、サーバは、ユーザU1の端末からテーマ「A」の指定を受け付け、招待する他のユーザとしてユーザU2の選択情報を受け付けた場合に、当該他のユーザU2の端末に、指定されたテーマAとユーザU1のイベントの招待を知らせる報知情報を送信する。
図16は、ユーザU2の端末に表示される画面の一例である。例えば、図16に示すように、画面W81において報知情報に含まれるユーザU1のイベントの参加を促すメッセージ80と、指定されたテーマAの情報83とを表示し、イベント参加可否を受け付ける処理を行う。
図16に示すように、ユーザU2の端末は、例えば、設定の指示体84の入力により、ユーザU2の操作対象のユーザキャラクタCA2に着用する服、靴の選択画面に移行する。
図17は、ユーザU2の操作対象のユーザキャラクタCA2に着用する服、靴の選択画面W82の一例である。例えば、図17に示すように、ユーザU2の端末は、テーマAの服のアイテム310、及び、テーマAの靴のアイテム300の選択をし、決定の指示体370の入力により、テーマAの服のアイテム310、及び、テーマAの靴のアイテム300の選択を受け付ける。
そして、図16に示すように、ユーザU2の端末は、ユーザU1のイベントに参加する入力を受け付けた場合には、イベント参加情報、テーマAの服のアイテム310、及び、テーマAの靴のアイテム300の情報をサーバに送信する。
そして、サーバは、ユーザU2の端末からイベント参加情報を受信した場合に、ユーザU2をイベントに参加させることを決定する処理を行い、ユーザU2の端末から受信したテーマAの服のアイテム310、及び、テーマAの靴のアイテム300の情報に基づいて、ユーザU2がテーマAの服のアイテム310、及び、テーマAの靴のアイテム300をゲームで使用するアイテムとして選択設定する処理を行う。
また、本実施形態では、ユーザU2がテーマに沿ったアイテムを設定入力する手間と、イベント参加入力の手間を減らすために、アイテムの設定入力とイベント参加の入力とを同時に行えるように制御してもよい。
例えば、サーバは、ユーザU1の端末からテーマ「A」の指定を受け付け、招待する他のユーザとしてユーザU2の選択情報を受け付けた場合に、ユーザU2の使用可能なアイテムの中からテーマ「A」に対応するアイテムを抽出する。例えば、服のアイテムについて1つ、靴のアイテムについて1つ抽出する。そして、サーバは、ユーザU2の端末に、抽出したアイテムとユーザU1のイベントの招待を知らせる報知情報を送信する。
図18は、ユーザU2の端末に表示される画面の一例である。例えば、図18に示すように、画面W83において報知情報に含まれるユーザU1のイベントの参加を促すメッセージ80と、指定されたテーマAに対応する服310と靴300の情報を含むイベント参加の指示体85、イベント不参加の指示体82とを表示してもよい。
例えば、図18に示すように、ユーザU2の端末は、例えば、参加の指示体85の入力を受け付けた場合には、イベント参加情報、テーマAの服のアイテム310、及び、テーマAの靴のアイテム300の情報をサーバに送信する。これにより、ユーザU2は参加の指示体85の入力だけで、指定されたテーマに沿ったアイテムを選択してイベントに参加することができる。
そして、サーバは、ユーザU2の端末からイベント参加情報を受信した場合に、ユーザU2をイベントに参加させることを決定する処理を行い、テーマAの服のアイテム310、及び、テーマAの靴のアイテム300の情報に基づいて、ユーザU2がテーマAの服の
アイテム310、及び、テーマAの靴のアイテム300をゲームで使用するアイテムとして選択設定する処理を行う。
なお、サーバは、イベントに招待するための候補となるユーザが、テーマに対応するアイテムを所有するユーザか否かを判断し、テーマに対応するアイテムを所有すると判断した場合に、当該ユーザを招待候補のユーザとして決定してもよい。
例えば、サーバがユーザU1の端末にテーマAのイベントを招待する候補のユーザの情報を送信する場合には、テーマAのアイテムを所有するユーザU2、U3、U4、U5、U6の情報を、ユーザU1の端末に送信するように制御する。つまり、図7に示すように、ユーザU1の端末は、テーマ「A」のイベントを指定した際に、テーマ「A」のアイテムを所有する他のユーザ一覧を表示させ、ユーザU1が、当該他のユーザの中からイベントの招待ユーザを決められるように制御する。
<テーマに対応するアイテムを指定して他のユーザを招待する手法の説明>
また、本実施形態では、イベントを実行するユーザU1が、他のユーザU2にテーマに対応する靴や服のアイテムを直接指定できるように制御してもよい。
例えば、図7に示すように、ユーザU1の端末10は、詳細内容を示す指示体73の入力を受け付けると、他のユーザの所有アイテム参照画面を表示する。ユーザの所有アイテムとは、当該ユーザが使用可能なアイテムを意味する。
例えば、ユーザU1がテーマ「A」を指定した場合において、詳細内容の入力を受け付けた場合には、ユーザU1の端末はサーバにテーマ「A」に対応する所有アイテムの参照要求情報を送信し、サーバは、テーマ「A」に対応するユーザU2の所持アイテムを抽出し、ユーザU1の端末に送信する。
例えば、図19は、ユーザU1の端末において、ユーザU2の所有アイテムを表示した参照画面W71の一例を示す。
例えば、図19に示すように、ユーザU1は、ユーザU2がテーマAの服のアイテム310、及び、テーマAの靴のアイテム300、305を所有していることを確認できる。ユーザU1の端末は、例えば、テーマAの服のアイテム310、及び、テーマAの靴のアイテム300の選択を受け付ける。そして、ユーザU1の端末は、例えば、指示体319の入力によりユーザU2をイベントに招待するユーザとしての選択を受け付けた場合には、ユーザU2を選択したことを示す情報、及び、指定したテーマAの服のアイテム310、及び、テーマAの靴のアイテム300の情報をサーバに送信する。
サーバは、ユーザU1の端末からユーザU2を招待するユーザとしての選択を受信すると、ユーザU1のイベントの参加を促す情報と、指定したテーマAの服のアイテム310、及び、テーマAの靴のアイテム300の情報を含む報知情報を当該ユーザU2の端末に送信する。
例えば、図18に示すように、ユーザU2の端末は、例えば、参加の指示体85の入力を受け付けた場合には、イベント参加情報、テーマAの服のアイテム310、及び、テーマAの靴のアイテム300の情報をサーバに送信する。
そして、サーバは、ユーザU2の端末からイベント参加情報を受信した場合に、ユーザU2をイベントに参加させることを決定する処理を行い、テーマAの服のアイテム310、及び、テーマAの靴のアイテム300の情報に基づいて、ユーザU2がテーマAの服の
アイテム310、及び、テーマAの靴のアイテム300をゲームで使用するアイテムとして選択設定する処理を行う。
<テーマに応じた複数種類のアイテムについて>
本実施形態において、イベント実行したユーザU1が例えば「白雪姫」など物語性のテーマでイベントを行いたい場合、白雪姫の衣装と7人の小人の衣装とを揃えることが望ましい。例えば、ユーザU1のユーザキャラクタCA1が白雪姫の服と靴を着用(ゲームで使用するアイテムとして選択)している場合、7人の参加ユーザに7人の小人それぞれの服・靴を着用させることが望ましい。つまり、イベント時に、参加ユーザの服・靴で、7人の小人が示す7種類の服・靴が揃うようにすることが望ましい。
そこで、サーバは、ユーザU1の服や靴を参照し「白雪姫」のテーマであると判定した場合には、ユーザU1のユーザキャラクタCA1が着用している服・靴以外である小人の服・靴を所有している7人の招待候補ユーザとして抽出する。この7人の招待候補ユーザはそれぞれ異なる服・靴であり、各7人の招待候補ユーザが参加することを決定すれば、7人の小人が示す7種類の服・靴が揃うことになる。
ユーザU1の端末は、例えば、「白雪姫」のテーマでバリエーションが揃うように抽出した上記7人の招待候補ユーザ及び指定の服・靴のアイテムの選択を受け付けると各7人の招待候補ユーザを選択したことを示す情報、指定の服・靴のアイテムの情報をサーバに送信する。
サーバは、ユーザU1の端末から7人の招待候補ユーザとしての選択を受信すると、各招待候補ユーザの端末に、ユーザU1のイベントの参加を促す情報と、指定した服・靴の情報を含む報知情報を送信する。
各招待候補ユーザの端末は、例えば、参加の入力を受け付けた場合には、イベント参加情報、指定された服・靴のアイテムをゲームで使用するアイテムとして選択したことをサーバに送信する。
そして、サーバは、各招待候補ユーザの端末からイベント参加情報を受信した場合に、各招待候補ユーザは参加ユーザとして決定する処理を行う。また、サーバは、各参加ユーザがゲームで使用するアイテムとして、指定された服・靴のアイテムを設定する。
<アイテム合成の指示>
本実施形態では、複数のアイテムを合成して、1つの別のアイテムを生成することができるように制御している。例えば、イベント実行ユーザU1がシンデレラのテーマでイベントを行うことを意図している場合において、他のユーザにシンデレラの靴で参加することを切望する場合がある。また、端末では、花のアイテムと靴300のアイテムとを合成すると、シンデレラの靴を生成することができる。
かかる場合、ユーザU1の端末は、例えば、招待候補のユーザU2が、花のアイテムと靴300のアイテムを所有している場合には、当該花のアイテムと靴300のアイテムとを合成することを指示する情報と、招待するユーザとして選択したことを示す情報をサーバに送信する。そして、サーバは、ユーザU2の端末に、花のアイテムと靴300のアイテムを合成することを指示する情報を含む報知情報を送信する。
そして、ユーザU2の端末は、ユーザU1のイベントに参加する入力を受け付けた場合には、続いて、ユーザU2のユーザキャラクタCA2に着用する服・靴のアイテムの入力を受け付ける。例えば、ユーザU2の端末は、花のアイテムと靴300のアイテムの合成
指示入力を受け付けると、花のアイテムと靴300のアイテムとを合成し、シンデレラの靴を生成する。そして、ユーザU2のユーザキャラクタCA2に当該生成された靴を着用する入力を受け付けると、ユーザU2の操作対象のユーザキャラクタCA2に着用する。
なお、ユーザU2の端末は、ユーザU1のイベントに参加する入力を受け付けた場合に、自動的に、花のアイテムと靴300のアイテムを合成してシンデレラの靴を生成し、生成された靴をユーザU2の操作対象のユーザキャラクタCA2に着用する制御をしてもよい。
そして、ユーザU2の端末は、イベント参加情報、生成されたシンデレラの靴やテーマに応じた服のアイテム情報をサーバに送信する。
そして、サーバは、ユーザU2の端末からイベント参加情報を受信した場合に、ユーザU2をイベントに参加させることを決定する処理を行い、ユーザU2の端末から受信した服・靴の情報に基づいて、ユーザU2が靴をゲームで使用するアイテムとして選択設定する処理を行う。
<アイテム購入の指示>
本実施形態では、ユーザが課金することによって所定のアイテムを購入することができる。
例えば、イベント実行ユーザU1がシンデレラのテーマでイベントを行うことを意図している場合において、他のユーザにシンデレラの靴で参加することを切望する場合がある。
かかる場合、ユーザU1の端末は、例えば、招待候補のユーザU3が、シンデレラの靴を所有していない場合に、シンデレラの靴を購入して着用することを指示する情報と、招待するユーザとして選択したことを示す情報をサーバに送信する。そして、サーバは、ユーザU3の端末に、シンデレラの靴を購入して着用することを指示する情報を含む報知情報を送信する。
そして、ユーザU3の端末は、ユーザU1のイベントに参加する入力を受け付けた場合には、続いて、ユーザU3のユーザキャラクタCA3に着用する服・靴のアイテムの入力を受け付ける。例えば、ユーザU3の端末は、シンデレラの靴アイテムを購入する入力を受け付けると、シンデレラの靴を使用可能なアイテムとして取得する。そして、ユーザU3のユーザキャラクタCA3に当該購入した靴を着用する入力を受け付けると、ユーザU3の操作対象のユーザキャラクタCA3に着用する。
なお、ユーザU3の端末は、ユーザU1のイベントに参加する入力を受け付けた場合に、自動的に、シンデレラの靴を購入し、購入した靴をユーザU3の操作対象のユーザキャラクタCA3に着用する制御をしてもよい。
そして、ユーザU3の端末は、イベント参加情報、購入したシンデレラの靴やテーマに応じた服のアイテム情報をサーバに送信する。
そして、サーバは、ユーザU3の端末からイベント参加情報を受信した場合に、ユーザU3をイベントに参加させることを決定する処理を行い、ユーザU3の端末から受信した服・靴の情報に基づいて、ユーザU3が靴をゲームで使用するアイテムとして選択設定する処理を行う。
<一人のユーザが複数のイベントに参加する例>
本実施形態では、一人のユーザが複数のイベントに参加するように制御してもよい。
例えば、ユーザU1のイベントにユーザU2が参加することを決定し、当該イベント終了前に、ユーザU7のイベントにユーザU2が参加することを決定してもよい。
また、本実施形態では、ユーザU2が、異なるイベントに参加する場合には、着用する服・靴をイベント毎に異ならせて参加するように制御する。また、イベントそれぞれにおいて、イベント参加値をユーザU2の仮想通貨から減算するように制御する。
<自動的にイベントに参加する例>
本実施形態では、ユーザが予め参加するイベントを登録しておき、ユーザの入力によらずに自動的にイベントに参加するように制御してもよい。
例えば、ユーザU2がユーザU1のイベントに参加することを切望する場合において、ユーザU1のイベント実行前に、事前参加を行えるように制御する。つまり、ユーザU2の端末は、ユーザU1がイベントを実行した場合参加すること示す事前参加情報を、サーバに送信する。
サーバは、ユーザU2の端末から事前参加情報を受信すると、当該事前参加情報を記憶部に記憶する。そして、サーバは、ユーザU1の端末からイベント実行情報を受信し、ユーザU1のイベントを実行した際に、自動的にユーザU2をユーザU1のイベントに参加させることを決定する処理を行う。つまり、ユーザU2の端末からイベント参加情報を受信することなく、ユーザU2に対応するイベント参加値をユーザU2の仮想通貨から減算し、ユーザU2をユーザU1のイベントに参加させることを決定する処理を行う。
事前参加情報には、ユーザU2の入力指示に基づきイベントに着用する服・靴を含むようにしてもよいし、ユーザU1のおまかせ(ユーザU1が指定した服・靴をイベントに着用することを指示した情報)を含むようにしてもよい。
そして、サーバは、事前参加情報に、イベントに着用する服・靴が指示されている場合には、ユーザU2のイベントで使用するアイテムとして選択する設定を行う。また、サーバは、事前参加情報に、ユーザU1のおまかせ情報が指示されている場合には、ユーザU1の端末からの指示情報に基づく服・靴をゲームで使用するアイテムとして選択する設定を行う。
<テーマに基づくレベルの制御>
上述したように、本実施形態では、一のイベントについてレベルLを設定しているが、テーマに沿ったアイテムが揃う度に所定値をレベルLに加算するように制御してもよい。
例えば、イベントを実行するユーザが、テーマに対応する靴アイテムをゲームで使用するアイテムとして選択している場合には、10をレベルLに加点する。
例えば、イベントを実行するユーザが、テーマに対応する服アイテムをゲームで使用するアイテムとして選択している場合には、20をレベルLに加点する。ゲームで使用するアイテムが複数個存在する場合には、1つのアイテムあたり20を加点する。
また、例えば、イベントを実行するユーザが、テーマに対応する家具アイテムをゲームで使用するアイテムとして選択している場合には、1個当たり50をレベルLに加点する。
また、イベントに参加する他のユーザが、テーマに対応する靴アイテムをゲームで使用するアイテムとして選択している場合には、10をレベルLに加点する。
また、イベントに参加する他のユーザが、テーマに対応する服アイテムをゲームで使用するアイテムとして選択している場合には、20をレベルLに加点する。ゲームで使用するアイテムが複数個存在する場合には、1つのアイテムあたり20を加点する。
このように、イベントを実行するユーザやイベントに参加するユーザがゲーム中に選択するアイテムが、テーマに対応するアイテムであると、レベルLが増加するので、ユーザにとって有利な特典処理が得られやすくなる。
なお、本実施形態では、「白雪姫」など物語性のテーマの場合は、イベントの実行ユーザと参加ユーザのアイテムのうち、テーマに対応するアイテムの種類の数を算出し、テーマに対応するアイテムの種類数に応じて、更にレベルLを増大させるようにしてもよい。例えば、ユーザU1のユーザキャラクタCA1が白雪姫の服アイテムを着用し、ユーザU2のユーザキャラクタCA2が第1の小人のアイテムを着用し、ユーザU3のユーザキャラクタCA3が第2の小人のアイテムを着用している場合には、テーマに対応するアイテムの種類数が3種類であるので、レベルLを3倍にするように制御してもよい。
<フローチャート>
図20A、図20B、図20Cを用いて本実施形態の処理の流れについて説明する。なお、説明の便宜上、ユーザU1がイベントを実行するユーザ、ユーザU2が当該イベントに参加するユーザとして説明する。
まず、ユーザU1の端末は、ユーザU1の入力によりイベントの実行を受け付けると(ステップS1)、イベント実行情報をサーバに送信する(ステップS2)。
そして、サーバは、イベント実行情報をユーザU1の端末から受信すると(ステップS11)、ユーザU1の仮想通貨からイベント実行値を減算する処理を行う(ステップS12)。そして、イベントに招待するユーザ候補をユーザU1の端末に送信する処理を行う(ステップS13)。
ユーザU1の端末は、ユーザ候補をサーバから受信すると、ユーザ候補の中からイベントに招待するユーザ(ユーザU2)を選択する処理を行う(ステップS3)。そして、選択したユーザ(ユーザU2)が所有するアイテムの参照情報をサーバに送信する(ステップS4)。
サーバは、参照情報をユーザU1の端末から受信すると(ステップS14)、選択されたユーザ(ユーザU2)の所有アイテムの中から、テーマに対応するアイテムを抽出し、抽出したアイテムの情報を、ユーザU1の端末に送信する(ステップS15)。
ユーザU1の端末は、アイテムの情報を受信する(ステップS5)。そして、ユーザU1の端末は、ユーザU2を選択した情報と、アイテムの指示情報をサーバに送信する(ステップS6)。
サーバは、ユーザU2を選択した情報とアイテムの指示情報を受信する(ステップS16)。そして、サーバは、アイテムの指示情報を含む報知情報をユーザU2の端末に送信する処理を行う(ステップS17)。
ユーザU2の端末は、サーバから報知情報を受信する(ステップS31)。そして、ユーザU2の端末は、ユーザU2の入力に基づきイベントに参加するか否かを判定し(ステップS32)、参加する場合には、イベント参加情報をサーバに送信する(ステップS33)。一方、イベントに参加しない場合には、ユーザU2の端末の処理を終了する。
サーバは、イベント参加情報を受信すると(ステップS18)、ユーザU2の仮想通貨からイベント参加値を減算する処理を行う(ステップS19)。
そして、サーバはイベントを開始するか否かを判断し(ステップS20)、イベントを開始すると(ステップS20のY)、達成度の判定時期が到来したか否かを判断する(ステップS21)。そして、達成度の判定時期が到来すると(ステップS21のY)、達成度が0より大きい値(達成度>0)か否かを判断する(ステップS22)。達成度が0より大きい値(達成度>0)である場合には(ステップS22のY)、達成度に基づき特別キャラクタの登場制御を行う(ステップS23)。
そして、サーバは、イベントを終了するか否かを判断する(ステップS24)。イベントを終了すると(ステップS24のY)、達成度に基づきユーザU1に付与するアイテムを決定し、当該アイテムをユーザU1の端末に送信する処理を行う(ステップS25)。
ユーザU1の端末は、サーバからアイテムを受信し(ステップS7)、処理を終了する。
また、サーバは、達成度に基づきユーザU2に付与するアイテムを決定し、当該アイテムをユーザU2の端末に送信する処理を行う(ステップS26)。そして、サーバの処理を終了する。
ユーザU2の端末は、サーバからアイテムを受信し(ステップS34)、処理を終了する。
<その他>
本明細書において説明したサーバの一部又は全部の機能は、端末や他のサーバにおいて機能するようにしてもよい。
例えば、図2に示すサーバの処理部100の処理の一部又は全部を、端末側で実行するようにしてもよい。例えば、サーバは、サーバの処理部100の処理の一部又は全部の処理プログラムをアプリ(アプリケーションプログラム)として端末に送信し、端末が当該アプリを実行するようにしてもよい。
より具体的に説明すると、端末は、第1のユーザ及び第2のユーザに選択されたゲーム媒体と、イベント実行値とに基づいて判定されるイベント達成度を判定してもよい。かかる場合、端末は当該イベント達成度をサーバに送信してもよい。
また、端末は、第1のユーザ及び第2のユーザの少なくとも一方が使用可能なアイテムを消費した場合には、消費したアイテムに基づいてイベント達成度を判定するようにしてもよい。
また、端末は、第1のユーザがゲームで使用するゲーム媒体を選択してからの経過時間、第2のユーザがゲームで使用するゲーム媒体を選択してからの経過時間、第1のユーザがゲームで使用するゲーム媒体の希少度、第2のユーザがゲームで使用するゲーム媒体の希少度、の少なくとも一つに基づいて、イベント達成度を判定するようにしてもよい。
また、端末は、イベント達成度に基づいて、ユーザに特典を付与する制御を行うようにしてもよい。
また、本実施形態では、複数の端末間でデータの送受信を行いながらゲームを実行するピア・ツー・ピア(いわゆるP2P)方式とするゲームシステムを実現してもよい。
<応用例>
本実施形態では、ユーザキャラクタと敵キャラクタとが対戦(バトル)するゲームに応用してもよい。例えば、ゲーム中のバトルにおいて、通常の敵キャラクタよりも強力なボスキャラクタに対して複数のユーザが協力して挑むイベントが発生することがある。このようなボスキャラクタ(レイドボスとも呼ぶ)とバトルを行うイベント場合に応用してもよい。
例えば、ユーザU1がイベントを実行した場合には、時間経過に応じて増大する行動パラメータ或いは仮想通貨等のゲームパラメータからイベント実行値を減算する。また、ユーザU2が当該イベントに参加する場合には、ゲームパラメータからイベント実行値、イベント参加値を減算する。
そして、上述したように、イベント実行値やイベント参加値に基づきイベントのレベルLを加算する。なお、イベントに使用するアイテム、イベントで消費するアイテムや、アイテムの希少度、経過時間等に基づき、イベントのレベルLを増大させる。
例えば、上述したように、ユーザU1やユーザU2のデッキ(バトルで使用するカード)に設定されたカードの希少度が高いほど、レベルLが増大するように制御する。また、ユーザU1やユーザU2のデッキに設定されたカードの経過時間が短いほど、レベルLが増大するように制御する。
そして、サーバは、イベントの達成度が高いほど強いボスキャラクタが登場するようにイベントの達成度とボスキャラクタとを対応付けて記憶部に記憶し、イベント開始してから終了するまでの間に、レベルLに基づきイベントの達成度を判定し、判定後、イベントの達成度に対応する当該ボスキャラクタを登場させてユーザと対戦できるように制御する。