以下、本発明の好適な実施形態について図面を用いて詳細に説明する。なお、以下に説明する実施の形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また以下で説明される構成の全てが本発明の必須構成要件であるとは限らない。
1.ネットワークシステム
1−1.ネットワークシステムの概要
図1は、本実施形態のネットワークシステムを示す。本実施形態では、複数の端末10(10A、10B、10C、・・・)とサーバ20とによって構成される。つまり、図1に示すように、本実施形態のネットワークシステムは、サービスを提供するサーバ20と、端末10(10A、10B、10C、・・・)とが、ネットワーク30に接続可能に構成される。
サーバ20は、複数のユーザ間で所与のゲームに付随するサービスを提供する情報処理装置である。サーバ20は、会員登録を行ったユーザに限定してサービスを提供するようにしてもよい。例えば、SNS(ソーシャル・ネットワーキング・サービス)と呼ばれるコミュニティ型のサービスを提供するサーバであってもよい。
また、複数台の情報処理装置(サーバ)がネットワークを介して接続され分散処理を行うシステムも本発明のサーバの範囲内である。
本実施形態のサーバ20は、Web(World Wide Web)サーバ機能や、メール配送が可能なメールサーバ機能を備える。また、端末10がWebページ(HTML(HyperText Markup Language)形式のデータ)を閲覧可能なウェブブラウザを備えていている。つまり、端末10は、サーバ20のサービス提供用のURLにアクセスし、サーバ20は当該ユーザのWebページを端末10に送信する。そして、端末10は、受信した当該ユーザのWebページを表示部190(図4)に表示させる。
端末10は、例えば、携帯電話、PHS端末、スマートフォン、PDA(Personal Digital Assistant)、携帯型ゲーム機等の携帯端末、パーソナルコンピュータ(PC)、電子ブック、ゲーム機等の情報処理装置であり、インターネット(WAN)、LAN、携帯電話回線網、パケット回線網、有線電話回線網などのネットワーク30を介してサーバ20に接続可能な装置である。なお、端末10とサーバ20との通信回線は、有線でもよいし無線でもよい。
ゲーム装置40(40A、40B、40C、・・・)は、所与のゲームを提供する情報処理装置であり、非携帯型のゲーム機(例えば業務用ゲーム機)、携帯型のゲーム機、ゲームプログラムがダウンロードされた情報処理端末等である。
本実施形態のネットワークシステムでは、ユーザがゲーム装置40でプレイしたゲームの結果(ゲーム結果情報)を端末10に入力し、ゲーム結果情報を端末10からサーバ20に送信する。そして、サーバ20は、ユーザ識別情報と対応づけてゲーム結果情報を登録する。例えば、端末10がサーバ20にゲーム結果情報とともにユーザ識別情報を送信するようにしてもよいし、サーバ20がユーザ識別情報に対応づけて端末10の端末識別情報を登録しておき、ゲーム結果情報を送信した端末10の端末識別情報からユーザ識別情報を特定してゲーム結果情報を登録するようにしてもよい。
特に本実施形態では、ユーザは、他のユーザと所定の期間(バトル期間)内にゲームの勝敗を競い合う「バトル」を楽しむことができる。具体的には、ユーザが対戦相手を指定してバトルの申込みを行い、バトルを申し込まれたユーザがそのバトルを受付けることでバトルが成立する。そして、バトルが成立すると、所定のバトル期間が設定されてバトル開始となる。
バトルの相手となる各ユーザは、バトル期間内にゲーム装置40で繰り返しゲームをプレイし、サーバ20にゲーム結果情報を送信する。サーバ20は、取得したゲーム結果情報を各ユーザのユーザ識別情報に対応づけて登録し、バトル期間中に登録されたゲーム結果情報に基づいてバトルの勝敗を決定する。そして、サーバ20は、バトル期間が終了すると、各ユーザの端末10にバトルの結果(勝敗等)を通知し、各ユーザがバトルの結果を知ることができるようになっている。
また、本実施形態では、各ユーザは、バトル期間中にバトルの途中経過も知ることができるようになっている。
また、ユーザは、他のユーザにサーバ20が提供するサービスへの参加を勧誘し、当該他のユーザはその勧誘を受け入れて当該サービスに参加することでバトルができるようにしてもよい。また、当該サービスへの参加を勧誘されたユーザがその勧誘を受け入れたことを条件として、参加を勧誘したユーザおよび勧誘されたユーザの少なくとも一方に対して、バトル期間中に登録されたゲーム結果情報の少なくとも一部の要素(得点やゲームに用いられるパラメータ情報等)を変更してバトルの勝敗を決定するようにしてもよい。
1−2.ゲーム装置の概要
本実施形態では、ゲーム装置40は、楽曲データの基準タイミングに合わせて、プレーヤが擬似的・仮想的に太鼓等の打楽器を叩く入力を行い、楽曲データのリズムに合わせた演奏を行うことが可能な音楽ゲームを提供する。
図2は、ゲーム装置40の外観の一例を示す図である。図2に示すように、本実施形態のゲーム装置40は、筐体42の前面に、2個の太鼓型の操作入力部44と、画像を表示する表示部46と、音を出力する音出力部48と、ゲーム料金を受け入れる料金受入口50とが設けられており、音楽ゲームを実行する。
操作入力部44は、太鼓の形状を有しており、プレーヤがスティックや手で叩くことにより操作入力を行うものである。図示しないが、この操作入力部44の円形の皮面52の内部には、プレーヤが円形の皮面52を叩いたことを検出するセンサが設けられており、皮面52の周縁54の内部には、プレーヤが皮面52の周縁54を叩いたことを検出するセンサが設けられている。従って、ゲーム装置40は、プレーヤが皮面52を叩いたか、皮面52の周縁54を叩いたかを判別することができる。ゲーム装置40は、2個の操作入力部44を有しており、同時に二人のプレーヤが音楽ゲームをプレーすることができる。
料金受入口50に所定の硬貨が投入されると音楽ゲームが開始され、プレーヤは皮面52や周縁54を叩いて複数の楽曲データの中から1つの楽曲データを選択する。そして、ゲーム装置40は、プレーヤが選択した楽曲データの楽曲音を音出力部48から出力させるとともに、表示部46にゲーム画像を表示させる。
図3は、ゲーム装置40の表示部46に表示されるゲーム画像の一例を示す。図3に示すように、楽曲データの再生処理に連動して、表示部46の右側から左側に向けて、複数種類の音符(音符A、音符B、音符Cなど)が移動経路62上を移動する。具体的には、楽曲データに合わせて予め定められた各音符にそれぞれ基準タイミングが対応付けられており、各音符は、それぞれの基準タイミングで固定的な所定位置Oに達するように、移動経路62に沿って所定の移動速度vで移動する。所定位置Oを中心とする円形の判定枠60が常に表示されており、プレーヤが音符毎の基準タイミングを視覚的に認識できるようになっている。
各音符はプレーヤに対する入力指示に応じて形状や色が異なっている。具体的には、音符Aは、オレンジ色の円形の画像(オブジェクト)であり、プレーヤに対して皮面52を叩く操作を指示する。また、音符Bは、水色の円形の画像(オブジェクト)であり、プレーヤに対して皮面52の周縁54を叩く操作を指示する。また、音符Cは、黄色の円筒形の画像(オブジェクト)であり、プレーヤに対して皮面52をできるだけ速く連続して叩く(連打)操作を指示する。さらに、各音符の下部には、音符の識別情報に対応する文字表記(音符Aに対する「ドン」、音符Bに対する「カッ」、音符Cに対する「連打〜」)が表示され、この文字表記は音符に付随して音符と同じ移動速度で移動する。
そして、プレーヤが各音符が所定位置Oに位置するタイミングで入力操作を行うと、音出力部48から太鼓の皮面52を叩いたときの「ドン」という効果音、または太鼓の皮面52の周縁54を叩いたときの「カッ」という効果音が出力されるとともに、プレーヤの入力タイミングと各音符の基準タイミングとの一致度(ズレの程度)に基づいて、プレーヤの入力が「良」、「可」、「不可」の3段階で評価される。
例えば、所与の音符Aに関連する基準タイミングがT1である場合、プレーヤの入力タイミングと基準タイミングT1のずれが所定時間S1の範囲であれば、基準タイミングT1に対するプレーヤの入力を「良」と評価する。プレーヤの入力タイミングと基準タイミングT1のずれが所定時間S1から所定時間S2の範囲であれば、基準タイミングT1に対するプレーヤの入力を「可」と評価する。また、プレーヤの入力タイミングと基準タイミングT1のずれが所定時間S2を超えれば、基準タイミングT1に対するプレーヤの入力を「不可」と評価する。ただし、プレーヤの入力操作が音符によって指示された入力操作と異なる場合にはプレーヤの入力は評価されないようになっている。
基準タイミングとプレーヤの入力タイミングとの評価結果は、例えば、図3に示すように、判定枠60の上部(或いは下部)に「良」と表示される。
そして、プレーヤの入力評価に応じた得点が加算される。具体的には、入力評価結果が「良」或いは「可」であれば、入力評価に応じた得点がスコアXに加算される。なお、スコアXを0〜100%に変換したスコアゲージGがスコアXの上部に表示されようになっている。
さらに、プレーヤの入力評価結果が連続して「良」又は「可」であると、連続数(コンボ数)が表示されると共に、連続数に応じた点(例えば、10コンボ単位で100点など)がスコアXに加算される。つまり、次々と所定位置Oに達する音符に対して連続して「良」或いは「可」の入力評価結果であると、高得点を得ることができるようになっている。
そして、楽曲データの再生が終了すると、その楽曲データのスコアゲージGがノルマ値(しきい値)を超えたか否かが判定される。スコアゲージGがノルマ値を超えた場合には、次の楽曲データの選択を受け付けて、次の楽曲データを再生し、プレーヤが次のゲームを楽しむことができる。一方、スコアゲージGがノルマ値以下であるとゲームが終了する。
本実施形態では、ゲームが終了すると、QRコードとひらがなのパスワードを含むゲーム終了画像が表示部46に表示される。このQRコードには、サーバ20のサービス提供用のURL、スコア、曲名、曲の難易度(「かんたん」、「ふつう」、「むずかしい」、「おに」)、プレイした日時、プレイした状態(1人用か2人用、1Pか2P等)、クリアしたか否か、フルコンボクリア(「不可」なしでクリア)か否か、「良」「可」「不可」の数、連打音符(音符C)に対する連打数等の情報が含まれており、プレーヤは、端末10を用いてこのQRコードを読み取ることで、スコア等の情報をサーバ20に送信することができる。また、ひらがなパスワードにはQRコードと同じ情報が含まれており、プレーヤは、端末10を用いてサーバ20により提供されるサービスのWebページにアクセスしてこのひらがなパスワードを入力することによっても、スコア等の情報をサーバ20に送信することができるようになっている。
1−3.端末の構成
図4に本実施形態の端末の機能ブロック図の例を示す。なお本実施形態の端末は図4の構成要素(各部)の一部を省略した構成としてもよい。
入力部160は、ユーザからの入力情報を入力するためのものであり、ユーザの入力情報を処理部100に出力する。入力部160は、例えば、ボタン、マイク、タッチパネル型ディスプレイ、キーボード、マウスなどがある。
記憶部170は、処理部100や通信部196などのワーク領域となるもので、その機能はRAM(VRAM)などにより実現できる。
情報記憶媒体180(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)などにより実現できる。処理部100は、情報記憶媒体180に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。情報記憶媒体180には、本実施形態の各部としてコンピュータを機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)を記憶することができる。
なお、本実施形態では、サーバ20が有する情報記憶媒体280や記憶部270に記憶されている本実施形態の各部としてコンピュータを機能させるためのプログラムやゲームデータを、ネットワークを介して受信し、受信したプログラムやデータを情報記憶媒体180に記憶するようにしてもよい。サーバ20から受信したプログラムやデータを記憶部170に記憶してもよい。このようにプログラムやデータを受信してネットワークシステムを機能させる場合も本発明の範囲内に含む。
表示部190は、本実施形態により生成された画像を出力するものであり、その機能は、CRT、LCD、タッチパネル型ディスプレイ、或いはHMD(ヘッドマウントディスプレイ)などにより実現できる。
音出力部192は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
通信部196は外部(例えば他の端末、サーバ)との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ASICなどのハードウェアや、プログラムなどにより実現できる。
処理部100(プロセッサ)は、入力部160からの入力情報やプログラムなどに基づいて、通信制御処理、画像生成処理、音生成処理などの処理を行う。
この処理部100は記憶部170内の主記憶部172をワーク領域として各種処理を行う。処理部100の機能は各種プロセッサ(CPU、DSP等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。
処理部100は、通信制御部110、表示制御部120、音信号処理部130を含む。
通信制御部110は、サーバ20とデータを送受信する処理を行う。例えば、通信制御部110は、サーバのIPアドレスやポート番号を指定してデータを送受信する処理を行う。また、通信制御部110は、サーバ20から受信したデータを記憶部170に格納する処理、受信したデータを解析する処理、その他のデータの送受信に関する制御処理等を行う。なお、通信制御部110は、サーバの宛先情報(IPアドレス、ポート番号)を情報記憶媒体180に記憶し、管理する処理を行うようにしてもよい。また、通信制御部110は、ユーザからの通信開始の入力情報を受け付けた場合に、サーバ20との通信を行うようにしてもよい。
特に本実施形態の通信制御部110は、バトル結果情報取得部111、バトル申込情報送信部112、バトル申込通知取得部113、バトル受付情報送信部114、ゲーム結果情報送信部115、ユーザ勧誘情報送信部118、ユーザ参加情報送信部119を含む。なお、通信制御部110はこれらの一部を省略する構成としてもよい。
バトル結果情報取得部111は、サーバ20から通知されたバトルの結果を含む情報を取得する。取得した情報は、表示制御部120の処理により表示部190に表示される。
バトル申込情報送信部112は、ユーザの入力操作に基づいて、バトルの相手となるユーザが指定されたバトル申込みの情報を生成してサーバ20に送信する処理を行う。
バトル申込通知取得部113は、サーバ20からバトルの申込みの通知を取得する処理を行う。取得した通知は、表示制御部120の処理により表示部190に表示される。
バトル受付情報送信部114は、ユーザの入力操作に基づいて、バトルの申込みの通知に対して当該バトルを受け付けるか否かを決定し、受け付ける場合は当該バトルを受付けることを示す情報をサーバ20に送信する処理を行う。
ゲーム結果情報送信部115は、ユーザがゲーム装置40でゲームをプレイしたゲーム結果情報をゲーム装置40から取得してサーバ20に送信する処理を行う。
ユーザ勧誘情報送信部118は、ユーザの入力操作に基づいて、サーバ20が提供するサービスへの参加を勧誘する他のユーザが指定された情報を生成してサーバ20に送信する処理を行う。
ユーザ参加情報送信部119は、ユーザの入力操作に基づいて、サーバ20が提供するサービスに参加することを示す情報を送信する処理を行う。
表示制御部120は、サーバ20から受信したデータ(Webデータ、HTML形式で作成されたデータなど)を、ブラウザなどを用いて表示部190に表示させる処理を行う。そして、表示制御部120は、以下の実施例で説明する画面遷移の制御を行い、表示部190に以下の実施例で説明する画面(Webページ)が表示され、入力部160からユーザの入力を受け付ける。
音信号処理部130は、入力部160などから入力される音信号を処理したり、音出力部180から出力される音信号を生成する。
1−4.サーバの構成
図5に本実施形態のサーバ20の機能ブロック図の例を示す。本実施形態のサーバ20は図5の構成要素(各部)の一部を省略した構成としてもよい。
記憶部270は、処理部200や通信部296などのワーク領域となるもので、その機能はRAM(VRAM)などにより実現できる。記憶部270は、格納部260(例えば、データベース)を含む。
情報格納部260には、本実施形態のネットワークシステムに参加する複数のユーザそれぞれのユーザ情報300が格納されている。
情報記憶媒体280(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(CD、DVD)、光磁気ディスク(MO)、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ(ROM)などにより実現できる。処理部200は、情報記憶媒体280に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体280には、本実施形態の各部としてコンピュータを機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)が記憶される。
通信部296は外部(例えば、端末、他のサーバや他のネットワークシステム)との間で通信を行うための各種制御を行うものであり、その機能は、各種プロセッサ又は通信用ASICなどのハードウェアや、プログラムなどにより実現できる。
処理部200(プロセッサ)は、情報記憶媒体280に記憶されるプログラム等に基づいて、所与の処理を行う。例えば、端末10からの要求に応じて所与のサービスを提供する。
また、処理部200は記憶部270内の主記憶部272をワーク領域として各種処理を行う。処理部200の機能は各種プロセッサ(CPU、DSP等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。
特に、本実施形態のサーバの処理部200は、ネットワーク設定部210、通信制御部220、バトル結果情報生成部230、バトル期間決定部232、段位情報生成部234とを含む。なおこれらの一部を省略する構成としてもよい。
ネットワーク設定部210は、ユーザ識別情報や端末識別情報などを端末10から取得し、ユーザ識別情報に対応づけて、ユーザ情報300を、情報格納部(例えばデータベース)260に格納する。また、ネットワーク設定部210は、ユーザ識別情報に基づいて、当該ユーザのユーザ情報を参照、更新(変更)、削除する処理を行う。
通信制御部220は、端末10とネットワークを介してデータを送受信する処理を行う。つまり、通信制御部220は、ユーザの端末からの要求に基づいて、当該ユーザに関連付けられている他のユーザの情報(例えば「ユーザ名」など)を当該ユーザの端末に送信する処理を行う。
特に本実施形態の通信制御部220は、ゲーム結果情報取得部221、バトル結果情報通知部222、バトル申込情報取得部223、バトル申込通知部224、バトル受付情報取得部225、投稿メッセージ送信部226、ユーザ勧誘情報取得部227、ユーザ参加情報取得部228、ユーザ判定部229とを含む。なおこれらの一部を省略する構成としてもよい。
ゲーム結果情報取得部221は、ユーザがゲームをプレイしたゲーム結果情報をユーザ識別情報に対応づけて取得する処理を行う。具体的には、ゲーム結果情報取得部221は、ユーザがゲーム装置40でゲームをプレイして当該ユーザの端末10を用いて当該ゲーム装置から取得したゲーム結果情報をネットワーク30を介して取得する。
バトル結果情報通知部222は、バトルの相手となる複数のユーザのの各々の端末10にバトルの結果情報を通知する処理を行う。さらに、バトル結果情報通知部222は、バトルの相手となる複数のユーザの端末10に、所与のタイミングで(毎日決まった時刻、バトルの途中経過情報が更新される毎、ユーザからの要求に応じて等)バトルの途中経過情報を通知する処理を行うようにしてもよい。
また、バトル結果情報通知部222は、バトル期間中にバトルの暫定の勝敗が変更された場合、敗者となっているユーザの端末にバトルの暫定の勝敗が変更されたことを通知するようにしてもよい。
バトル申込情報取得部223は、ユーザの端末10からバトルの相手となるユーザが指定されたバトル申込みの情報を取得する処理を行う。
バトル申込通知部224は、バトルの相手として指定されたユーザの端末10にバトルの申込みがあったことを通知する処理を行う。
バトル受付情報取得部225は、バトルの申込みがあったことを通知されたユーザの端末10からバトルを受付けることを示す情報を取得する処理を行う。
投稿メッセージ送信部226は、所与の条件が成立した場合に、所与のメッセージ投稿サービスを提供するサーバに投稿メッセージを送信する処理を行う。
ユーザ勧誘情報取得部229は、ユーザの端末10からサーバ20が提供するサービスへの参加を勧誘するユーザが指定された情報を取得する処理を行う。
ユーザ参加情報取得部239は、ユーザの端末10からサーバ20が提供するサービスに参加することを示す情報を取得する処理を行う。
バトル結果情報生成部230は、バトルの相手となる複数のユーザの各々のユーザ識別情報に対応付けて所定のバトル期間内に取得されたゲーム結果情報に基づいて、当該バトルの結果情報を生成する処理を行う。
例えば、バトル結果情報生成部230は、バトル期間内に取得されたゲーム結果情報の所定の要素(例えば得点)について、バトルの相手となる複数のユーザの各々のバトル期間における最高値(例えば最高得点)を比較し、比較結果に基づいてバトルの勝敗を決定するようにしてもよい。
また、例えば、バトル結果情報生成部230は、バトル期間内に取得されたゲーム結果情報の所定の要素(例えば得点)について、バトルの相手となる複数のユーザの各々のバトル期間における累計値(例えば累計得点)を比較し、比較結果に基づいてバトルの勝敗を決定するようにしてもよい。
また、例えば、バトル結果情報生成部230は、バトル期間内に取得されたゲーム結果情報に所与の付加情報を付加して演算し、バトルの勝敗を決定するようにしてもよい。例えば、バトル結果情報生成部230は、バトルの相手となる複数のユーザの各々のバトル期間におけるゲームのプレイ回数を付加情報として、バトルの勝敗を決定するようにしてもよい。また、例えば、バトル結果情報生成部230は、ランダムな情報を付加情報としてバトルの勝敗を決定してもよいし、各ユーザの段位の情報を付加情報として(例えば、段位の低いユーザほど有利にして)バトルの勝敗を決定するようにしてもよいし、投稿メッセージの送信回数を付加情報として(例えば、投稿メッセージの送信回数が多いユーザほど有利にして)バトルの勝敗を決定するようにしてもよい。
さらに、バトル結果情報生成部230は、バトル期間内に新たに取得されたゲーム結果情報に基づいてバトルの途中経過情報を生成する処理を行うようにしてもよい。
また、バトル結果情報生成部230は、バトル期間内に新たに取得されたゲーム結果情報に基づいてバトルの暫定の勝敗を判定する処理を行うようにしてもよい。
また、バトル結果情報生成部230は、バトル参加情報取得部229によりバトルに参加することを示す情報が取得された場合、当該バトルへの参加を勧誘したユーザ及び勧誘されて参加したユーザの少なくとも一方のバトル期間内におけるゲーム結果情報の少なくとも一部の要素を変更し、当該バトルの結果情報を生成するようにしてもよい。
バトル期間決定部232は、バトルの申込みがあったことを通知されたユーザの端末10からバトルを受付けることを示す情報がゲーム結果情報取得部221によって取得された時刻情報に基づいてバトル期間を決定する処理を行う。例えば、ゲーム結果情報取得部221がバトルを受付けることを示す情報を取得した時刻(バトルが成立した時刻)から所定期間(例えば1週間)をバトル期間として決定するようにしてもよい。
段位情報生成部234は、ゲーム結果情報取得部221によって取得されたゲーム結果情報に基づいて各ユーザの段位の情報を生成する処理を行う。例えば、段位情報生成部234は、ゲーム回数(ゲーム結果情報の取得(登録)回数)、累計得点、バトルの勝利数などの所与の条件をクリアすることで、ユーザの段位を上げるようにしてもよい。
ユーザ判定部238は、ユーザ勧誘情報取得部229が取得する情報とユーザ参加情報取得部239が取得する情報に基づいて、サーバ20が提供するサービスに参加するユーザが当該サービスへの参加を勧誘された他のユーザであるか否かを判定する処理を行う。
2.本実施形態の手法
2−1.ユーザ情報
図6は、ユーザ情報について説明するための図である。
ユーザ情報300は、ユーザ識別情報310とともにユーザ識別情報310に対応づけられる種々の情報を含む。本実施形態では、ユーザ識別情報310に対応づけられる情報として、端末識別情報312、プロフィール情報320、ゲーム結果情報リスト330、累計得点350、段位360、バトル情報リスト370、メッセージ投稿情報390等が含まれる。
ユーザ識別情報310は、各ユーザに割り振られた識別IDでもよいし、ユーザによって登録されたゲームIDでもよい。
端末識別情報312は、端末10に割り振られた識別IDである。
プロフィール情報320は、ネットワークシステム1を利用する各ユーザが初回利用時に入力するプロフィールに基づいて生成・登録される情報である。図7は、プロフィール情報の一例を示す図である。図7に示すように、例えば、プロフィール情報320は、ユーザのニックネーム321、性別322、年齢(生年月日)323、在住する都道府県324、得意曲325、自己紹介文326、後述するバトル受付の許否327の情報を含む。
ゲーム結果情報リスト330は、各ユーザがゲーム装置40を用いてプレイしたゲーム結果情報のリストである。図8は、ゲーム結果情報リストの一例を示す図である。図8に示すように、ゲーム結果情報リスト330はゲーム結果情報331(331−1、331−2、・・・)を含み、各ゲーム結果情報331は、例えば、プレイ日時332、プレイ状態333(1人プレイか2人プレイか、右側か左側のいずれでプレイしたか等)、プレイした曲名334及び難易度335、ノルマクリア336(ノルマをクリアしたか否か)、フルコンボ337(フルコンボでクリアしたか否か)、得点338、「良」の数339、「可」の数340、「不可」の数341、連打音符(音符C)に対する連打数342、コンボ数343等の情報を含む。これらの情報は、前述したQRコード又はひらがなパスワードに含まれる情報であり、サーバ20がQRコード又はひらがなパスワードを受信する毎に、ユーザ識別情報310に対応づけてゲーム結果情報331として登録する。
累計得点350は、各ユーザが登録したゲーム結果情報331に含まれる得点338の累計である。サーバ20は、新たなゲーム結果情報331を登録する毎に累計得点350を更新する。
段位360は、各ユーザのレベルを示し、ユーザが所定の条件(ゲーム回数、累計得点、バトルの勝利数など)をクリアすることで、段位360が上がっていく。サーバ20は、新たなゲーム結果情報331を登録する毎に、所定の条件がクリアされたか否かをチェックし、クリアされていれば段位360を更新する。
バトル情報リスト370は、各ユーザの現在及び過去のバトルに関する情報である。図9は、バトル情報リストの一例を示す図である。図9に示すように、バトル情報リスト370はバトル情報371(371−1、371−2、・・・)を含み、各バトル情報371は、バトル対象曲の曲名372及び難易度373、対戦相手374、バトルの受付け/申込み375(バトルを受付ける側か申込む側か)、バトル状態376(バトル終了、バトル中、バトル開始前等)、バトルの終了日時377、バトルの決着日378、バトルの勝敗379、自分の得点380(例えばバトル期間中の自分の最高得点)、相手の得点381(例えばバトル期間中の相手の最高得点)等の情報を含む。サーバ20は、バトルの申込みが行われると、バトルを申し込んだユーザのバトル情報リスト370に新たなバトル情報371を登録するとともに、バトルを申し込まれたユーザのバトル情報リスト370に新たなバトル情報371を登録する。
本実施形態では、ユーザ毎に同時に行うことができるバトルの数に制限が設けられている。具体的には、各ユーザは、最大N人(以下の実施例では8人)のユーザからのバトルの申込みを同時に受け付けることができ(バトル受付枠がN)、最大M人(以下の実施例では1人)のユーザに同時にバトルを申し込むことができる(バトル申込枠がM)。バトルは1対1の個人戦であってもよいし、複数のユーザが2チームに分かれたチーム戦であってもよい。
また、本実施形態では、バトル期間は、バトルが成立した(バトルの申込みが受け付けられた)時刻からバトルが成立した日の1週間後の午前10時までに設定される。例えば、図9のバトル情報371−1のバトル終了日時377が「2010/8/1 10:00」になっているが、2010年7月25日の例えば午後2時にバトルが成立し、バトルが成立した2010年7月25日の午後2時から2010年8月1日(2010年7月25日の1週間後)の午前10時までの164時間がバトル期間として設定されている。ただし、バトル期間はこれに限らず任意に設定することができる、例えば、バトルの申し込みが受け付けられた日時から正確に1週間後(168時間後)までをバトル期間として設定してもよい。
メッセージ投稿情報390は、他のサーバが提供するメッセージ投稿サービスのWebページ(メッセージ投稿サイト)へのメッセージ投稿の各種設定を示す情報である。図10は、メッセージ投稿情報の一例を示す図である。図9に示すように、メッセージ投稿情報390は、メッセージ投稿サイトのユーザアカウント391やパスワード392、メッセージ投稿設定393(投稿条件(投稿タイミング)の設定、メッセージ文をカスタマイズするか否か等)、メッセージ文394(カスタマイズする場合のメッセージ文)等の情報を含む。サーバ20は、新たなゲーム結果情報331を登録する毎に、メッセージ投稿設定393で設定された投稿条件(投稿タイミング)を満たすか否かをチェックし、満たされていればメッセージ投稿サービスを提供するサーバに所定のメッセージ文又はメッセージ文394を送信し、送信したメッセージ文がメッセージ投稿サイトに投稿される。
2−2.ユーザ登録
図11は、ユーザ登録に関する端末10の画面遷移例である。図11において、400、410、420、430は端末10の表示部に表示される画面(Webページ)の例を示している。
未登録のユーザが、サーバ20が提供するサービスのTOPページにアクセスすると、端末10の表示部に画面400が表示される。画面400には、「利用登録」ページへのリンク401、「各種ランキング」ページへのリンク402、「ユーザ検索」ページへのリンク403等が含まれている。未登録のユーザであっても、「各種ランキング」ページへのリンク402や「ユーザ検索」ページへのリンク403の選択操作を行うことで種々のランキング情報や登録済みユーザのプロフィール情報を見ることができるようになっている。そして、ユーザが「利用登録」ページへのリンク401の選択操作を行うと、端末10の表示部に画面410が表示される。
画面410は、プロフィール情報の入力画面であり、ニックネームの入力欄411、性別の選択欄412、年齢(生年月日)の入力欄413、在住都道府県の選択欄414、得意曲の入力欄415、自己紹介文の入力欄416、バトル受付の許否の選択欄417、確認ボタン418が設けられている。また、画面410には、性別の選択欄412、年齢(生年月日)の入力欄413、在住都道府県の選択欄414の右側には、表示/非表示選択欄412a、413a、414aが設けられており、それぞれ、412、413、414に入力又は選択された情報を他のユーザに対して表示(公開)するか非表示(非公開)にするかを個別に選択できるようになっている。そして、ユーザが、各欄への入力操作又は選択操作を行った後、確認ボタン418の押下操作を行うと、端末10の表示部に画面420が表示される。
画面420には、ユーザが画面410で入力又は選択した情報が表示される。また、画面420には、登録ボタン421とキャンセルボタン422が設けられており、ユーザがキャンセルボタン422の押下操作を行うと、端末10の表示部に画面410が表示される。一方、ユーザが登録ボタン421の押下操作を行うと、端末10の表示部に登録完了を示す画面430が表示される。
この一連の操作が終了すると、サーバ20に、端末識別情報(端末10の識別ID)とともにプロフィール情報(ニックネーム、性別、年齢(生年月日)、在住都道府県、得意曲、自己紹介文、バトル受付の許否)が送信され、サーバ20は、取得した端末識別情報とプロフィール情報を新たなユーザ識別情報310に対応付けて新たなユーザ情報300を作成し、情報格納部260に登録する。
2−3.バトル
本実施形態のネットワークシステムでは、登録済みのユーザ同士が所定の期間(バトル期間)内にゲーム装置40でプレイしたゲームの結果に基づいて勝敗を争う「バトル」を楽しむことができるようになっている。
[バトルの申込み]
登録済みのユーザは、対戦相手候補のユーザを探してバトルを申し込むことができる。図12は、対戦相手候補のユーザ検索に関する端末10の画面遷移例である。図12において、440、450、460は端末10の表示部に表示される画面(Webページ)の例を示している。
登録済みのユーザが、サーバ20により提供されるサービスのTOPページにアクセスすると、端末10の表示部に画面440が表示される。画面440には「ユーザ検索」ページへのリンク441が含まれており、ユーザが「ユーザ検索」ページへのリンク441の選択操作を行うことで、登録済みユーザを検索できるようになっている。そして、ユーザが「ユーザ検索」ページへのリンク441の選択操作を行うと、端末10の表示部に画面450が表示される。
画面450は、ユーザ検索情報の入力画面であり、ユーザネームの入力欄451、在住都道府県の選択欄452、段位の入力欄453、検索ボタン454が設けられている。そして、ユーザが、例えば、ユーザネームの入力欄451に「○○」を入力(ニックネームの一部を入力)し、在住都道府県の選択欄452を未選択にし、段位の選択欄453で「八段」を選択して、検索ボタン454の押下操作を行うと、ニックネームに「○○」が含まれ、かつ、段位が八段のすべてのユーザが検索される。
検索が終了すると、端末10の表示部に検索結果の画面460が表示される。画面460には、検索された各ユーザの、ニックネーム461(461−1、461−2、461−3、・・・)、在住都道府県462(462−1、462−2、462−3、・・・)、段位463(463−1、463−2、463−3、・・・)が含まれている。各ニックネーム461(461−1、461−2、461−3、・・・)には、各ユーザのプロフィールページへのリンクが設定されており、バトルの申込みは各ユーザのプロフィールページから行うことができるようになっている。
図13は、バトル申込みに関する端末10の画面遷移例である。図13において、470、480、490、500は端末10の表示部に表示される画面(Webページ)の例を示している。
画面470は、対戦相手候補として選ばれたユーザのプロフィールページの画面である。例えば、図12に示したユーザ検索結果の画面460に含まれるいずれかのユーザのニックネーム461(461−1、461−2、461−3、・・・)を選択操作することで、端末10の表示部に画面470が表示される。
画面470には、段位の表示471、累計得点の表示472、「個人成績」ページへのリンク473、後述する「バトル履歴」ページへのリンク474、後述する「メッセージ投稿」ページへのリンク475、「挑戦状を送ります」の表示476、プロフィール477等が含まれている。そして、「挑戦状を送ります」の表示476には、バトル申込ページへのリンクが設定されており、ユーザが「挑戦状を送ります」の表示476の選択操作を行うと、端末10の表示部に画面480が表示される。
画面480は、バトル申込ページの画面であり、バトル曲のジャンルの選択欄481、バトル曲の曲名の選択欄482、バトル曲の難易度の選択欄483、コメントの入力欄484、確認ボタン485が設けられている。そして、ユーザが、各欄への入力操作又は選択操作を行った後、確認ボタン485の押下操作を行うと、端末10の表示部に画面490が表示される。
画面490には、ユーザが画面480で入力又は選択した情報が含まれる。また、画面490には、申込ボタン491が設けられており、ユーザが申込ボタン491の押下操作を行うと、端末10の表示部にバトル申込の完了を示す画面500が表示される。
なお、対戦相手候補として選ばれたユーザのバトル受付枠が埋まっている場合には、例えば、画面470において「挑戦状を送ります」の表示476の代わりに「バトル枠がいっぱいです/バトル中(○/○まで)」と表示するようにしてもよい。また、バトル受付枠の一部のみが埋まっている場合には、例えば、画面470において「挑戦状を送ります」の表示476の代わりに「バトル中(○/○まで)/挑戦状を送ります」と表示するようにしてもよい。また、対戦相手候補として選ばれたユーザのプロフィール情報320のバトル受付の許否327がバトルを受付けない設定になっている場合は、例えば、画面470において「挑戦状を送ります」の表示476の代わりに「バトルの受付を拒否しています」等と表示するようにしてもよい。
この一連の操作が終了すると、サーバ20は、端末10に関連付けられるユーザ情報300において、バトル申込枠がいっぱいでなければ新たなバトル情報371を作成して登録する。さらに、サーバ20は、対戦相手候補として選ばれたユーザのユーザ情報300において、バトル受付枠がいっぱいでなければ新たなバトル情報371を作成して登録する。
[バトルの受付け]
バトルの申込みをされたユーザ(対戦相手候補として選ばれたユーザ)は、バトルを受付けるか否かを選択することができ、バトルを受付けた時点でバトルが成立する。
図14は、バトル受付けに関する端末10の画面遷移例である。図14において、510、520、530、540、550、560は端末10の表示部に表示される画面(Webページ)の例を示している。
画面510は、バトルを申し込まれたユーザのTOPページの画面である。画面510には、バトル情報の項目に「挑戦状が届いています」の表示512が含まれている。「挑戦状が届いています」の表示512には、バトル受付ページへのリンクが設定されており、ユーザが「挑戦状が届いています」の表示512の選択操作を行うと、端末10の表示部にバトル受付ページの画面540が表示される。
また、画面510には、プロフィールページへのリンクが設定された「○○さんのマイプロフィールへ」の表示511と「マイプロフィール」の表示513が含まれており、ユーザが「○○さんのマイプロフィールへ」の表示511又は「マイプロフィール」の表示513の選択操作を行うと、端末10の表示部にプロフィールページの画面520が表示される。この画面520にも「挑戦状が届いています」の表示522(バトル受付ページへのリンクが設定されている)が含まれており、ユーザが「挑戦状が届いています」の表示522の選択操作を行うと、端末10の表示部にバトル受付ページの画面540が表示される。
さらに、画面510には、バトル管理ページへのリンクが設定された「バトル」の表示514が含まれており、ユーザが「バトル」の表示514の選択操作を行うと、端末10の表示部にバトル管理ページの画面530が表示される。バトル管理ページの画面530には、現在のバトル受付状況(5人のユーザとそれぞれバトル中であり、2人のユーザからバトルを申し込まれており、バトル受付枠があと1つ残っている)が含まれており、ユーザが、例えば、**さんの「受付ページ」の表示532の選択操作を行うと、端末10の表示部にバトル受付ページの画面540が表示される。
バトル受付ページの画面540には、バトル曲の曲名541、バトル曲の難易度542、コメント543等が含まれている。この曲名541、難易度542、コメント543は、バトルを申し込んだユーザが図13に示したバトル申込ページの画面480の482、483、484の各欄に入力又は選択した情報である。
また、バトル受付ページの画面540には受付ボタン544と拒否ボタン545が設けられている。そして、ユーザが受付ボタン544の押下操作を行うと端末10の表示部にバトルを受け付けたことを示す画面550が表示されてバトルが成立する。一方、ユーザが拒否ボタン545の押下操作を行うと端末10の表示部にバトルを拒否したことを示す画面560が表示されてバトルが不成立になる。
バトルが成立した場合は、サーバ20は、バトルを申し込んだユーザのバトル情報リスト370に含まれる所望のバトル情報371のバトル状態376を「バトル中」に設定するとともに、バトルを受け付けたユーザのバトル情報リスト370に含まれる所望のバトル情報371のバトル状態376を「バトル中」に設定する。
一方、バトルが不成立の場合は、サーバ20は、バトルを申し込んだユーザのバトル情報リスト370に含まれる所望のバトル情報371のバトル状態376を「バトル不成立」に設定するとともに(あるいは、バトル情報371を削除してもよい)、バトルを受付けたユーザのバトル情報リスト370に含まれる所望のバトル情報371のバトル状態376を「バトル不成立」に設定する(あるいは、バトル情報371を削除してもよい)。
なお、端末10の表示部にバトル管理ページの画面530を再表示させると、バトルが成立した場合には現在のバトル受付状況の「**さん」の「バトル受付ページ」の表示が「バトル中」の表示に変更され、バトルが不成立の場合には現在のバトル受付状況から「**さん」の表示が削除される。
[ゲーム結果情報の登録]
バトルが成立した場合、所定のバトル期間が設定されてバトルが開始する。各ユーザは、バトル期間中にゲーム装置40で音楽ゲームをプレイしてゲーム結果情報を登録し、バトル期間中に登録されたゲーム結果情報に基づいてバトルの勝敗が決定される。
図15は、ゲーム結果情報の登録に関する端末10の画面遷移例である。図15において、570、580は端末10の表示部に表示される画面(Webページ)の例を示している。
前記の通り、ゲーム装置40でのプレイが終了すると表示部46にQRコードとひらがなパスワードを含む画像が表示される。そして、サーバ20に登録された端末10でQRコードを読み取ることで、QRコードがサーバ20に送信される。あるいは、所定のWebページにアクセスしてひらがなパスワードを入力することで、ひらがなパスワードがサーバ20に送信される。サーバ20は、QRコード又はひらがなパスワードを受信し、これを解析してゲーム結果情報を抽出し、ユーザの端末10にゲーム結果情報の一部のデータを返信する。これを受けて、端末10の表示部にゲーム結果情報の登録を確認する画面570が表示される。
画面570には、登録ボタン571が設けられており、ユーザが登録ボタン571の押下操作を行うと端末10の表示部にゲーム結果の登録が完了したことを示す画面580が表示される。
この一連の操作が終了すると、サーバ20は、端末10に関連付けられるユーザ情報300のゲーム結果情報リスト330に新たなゲーム結果情報331を作成して登録する。また、サーバ20は、新たに登録したゲーム結果情報331に基づいて、累計得点350を更新するとともに、所定の条件をクリアしていれば段位360を更新する。また、サーバ20は、新たに登録したゲーム結果情報331がバトル対象のゲーム結果情報であれば、当該ゲーム結果情報331に基づいて現時点での暫定の勝敗を判定し、勝敗が入れ替わった場合は当該バトルを行っている各ユーザのバトル情報371の勝敗379を変更する。また、新たに登録したゲーム結果情報331がバトル対象のゲーム結果情報であれば、当該ゲーム結果情報331の得点338がバトル期間中の最高得点であるか否かを判定し、最高得点であった場合は当該バトルを行っている各ユーザのバトル情報371の自分の得点380又は相手の得点381を当該得点に更新する。
[バトルの途中経過の表示]
各ユーザは、バトル期間中であれば何度でも繰り返し、音楽ゲームをプレイしてゲーム結果情報を登録することができる。そして、新たなゲーム結果情報が登録される毎にその時点までの暫定の勝敗が判定され、バトル期間終了時に最終的な勝敗が決定する。各ユーザは端末10を用いてバトルの途中経過を知ることができるようになっている。
図16は、バトルの途中経過の表示に関する端末10の画面遷移例である。図16において、590、600は端末10の表示部に表示される画面(Webページ)の例を示している。
画面590はバトル管理ページの画面であり、ユーザが、例えば、△△さんの「バトル中」の表示591の選択操作を行うと、端末10の表示部にバトルの途中経過を示すバトルページの画面600が表示される。
バトルページの画面600には、バトルの途中経過(どちらが優勢か)を示すゲージ601、各ユーザの得点602、603、バトルが終了する日時604等が含まれている。
バトルページの画面600に含まれる情報は、ユーザがバトルページの画面600を開く毎に最新の情報が更新される。ただし、サーバ20の負荷を考慮し、例えば、毎日決まった時刻に1度だけその時点での最新の情報に更新するようにしてもよい。
バトル中の各ユーザは、バトルページを見ることでバトルの途中経過を確認し、現在劣勢(暫定の敗者)であれば相手に勝つ(例えば相手よりも高い得点を出す)ために、現在優勢(暫定の勝者)であれば相手に差をつける(例えば相手との得点差を大きくする)ために、それぞれバトル期間中に音楽ゲームを繰り返しプレイする意欲を高めることができる。
なお、バトルの途中経過情報をユーザの端末10にメールで通知するようにしてもよい。
特に、優勢(暫定の勝者)から劣勢(暫定の敗者)になったユーザに対しては、劣勢(暫定の敗者)になったことを当該ユーザのTOPページやプロフィールページ等に表示したり、メールで通知するようにしてもよい。このようにすれば、ユーザが優勢(暫定の勝者)から劣勢(暫定の敗者)になったことを知ることで、勝者となるためにバトル期間内に繰り返しゲームをプレイする意欲を高めることができるとともに、各ユーザが不意打ちで敗者となることを避けることができる。
[バトルの勝敗の判定]
バトル期間が終了すると最終的な勝敗が決定する。バトルの勝敗(バトル期間中は優勢か劣勢か)は、バトル期間中に登録されたゲーム結果情報に基づいて判定される。
例えば、バトル期間中に登録された最高得点が高い方のユーザを勝者(優勢)としてもよい。このようにすれば、ユーザの実力をバトルの勝敗に直接的に反映させることができる。例えば、バトル期間中に実力に差があるユーザが同じ回数ずつプレイした場合、実力の高いユーザが勝利する可能性が高い。ただし、実力の低いユーザが、実力の高いユーザよりもかなり多くプレイすれば、実力の低いユーザが勝利するかもしれない。つまり、実力の低いユーザであってもプレイ回数を増やすことで実力の高いユーザに勝つ確率を上げることができるので、バトル期間内に繰り返しゲームをプレイする意欲を高めることができる。とはいえ、実力の低いユーザは、最高得点の比較ではかなり実力差のあるユーザに勝てる可能性は低いので、バトルを申込まない可能性もある。
そこで、例えば、バトル期間中に登録された累計得点が高い方のユーザを勝者(優勢)としてもよい。このようにすれば、実力の低いユーザであってもバトル期間内にプレイするゲーム回数を増やすことで実力の高いユーザに勝てる確率を格段に上げることができる。例えば、バトル期間中に実力の高いユーザが5回プレイし、実力の低いユーザが10回プレイした場合、実力の低いユーザは、バトル期間中の最高得点の比較では勝利する可能性が低いが、バトル期間中の累計得点の比較では勝利する可能性が格段に上がる。従って、実力の低いユーザであっても実力の高いユーザにバトルを申込みやすくなるとともに、バトル期間内に繰り返しゲームをプレイする意欲を高めることができる。
また、例えば、バトル期間中に登録された得点を所与の付加情報に応じて修正し、バトル期間中の最高得点が高い方のユーザを勝者(優勢)としてもよい。このようにすれば、実力に応じた勝敗の確率を付加情報に応じて変動させることができる。従って、実力の低いユーザであっても実力の高いユーザにバトルを申込みやすくなるとともに、バトル期間内に繰り返しゲームをプレイする意欲を高めることができる。
例えば、バトル期間中に登録された得点に、プレイ回数(付加情報の一例)に応じた何らかの点数を加算してバトルの勝敗を決定するようにしてもよい。
また、例えば、バトル期間中に登録された得点を、バトル期間中に登録されたゲーム結果情報331の要素(付加情報の一例であり、例えば、フルコンボクリア337、「良」の数339、「可」の数340、「不可」の数341、連打数342、コンボ数343等)で修正してもよい。
また、例えば、バトル期間中に登録された得点をランダムな要素(乱数)(付加情報の一例)で修正してもよい。例えば、ゲーム結果情報331の要素であるプレイ日時332やプレイ状態333、あるいはゲーム結果情報331を登録した時刻を種としてランダムな得点を生成し、登録された得点に加えてもよい。
また、例えば、バトル期間中に登録された得点を、各ユーザの段位360(付加情報の一例)に応じて修正してもよい(例えば、段位の低いユーザにハンデを与えてもよい)し、メッセージ投稿情報390に基づくメッセージの投稿回数に応じて修正してもよい(例えば、メッセージの投稿回数に応じて得点を加算してもよい)。
また、得点だけでなく、他のゲーム条件を満たすか否かでバトルの勝敗を決定するようにしてもよい。ゲーム条件としては、例えば、所定の入力を行なったり、所定のゲーム結果を出現させることが出来たかどうかなどでもよい。
また、例えば、ユーザが他のユーザ(友人等)を勧誘し、当該他のユーザがユーザ登録をした場合、勧誘したユーザ又は勧誘されて登録したユーザのいずれか一方、又は両者に対してゲーム結果情報の少なくとも一部の要素(得点やゲームに用いられるパラメータ情報等)を変更してバトルの勝敗が有利になるようにしてもよい。このようにすれば、サーバ20が提供するサービスに参加するユーザの数が増えることが期待できる。なお、例えば、勧誘したユーザ又は勧誘されて登録したユーザが初めてバトルを行う場合には、特別状態であることを示す特別状態フラグを1に設定してゲーム結果情報を特別用で変更し(例えば、得点に第1の点数を加算し)、2回目以降のバトルを行う場合には、特別状態フラグを0に設定(更新)し、ゲーム結果情報を通常用で変更し(例えば、得点に第2の点数を加算し)又はゲーム結果情報を変更せずにバトルの勝敗を決定するようにしてもよい。
[バトル履歴の表示]
各ユーザは、端末10を用いてバトル期間が終了した過去のバトルの履歴を見ることができるようになっている。
図17は、バトル履歴の表示に関する端末10の画面遷移例である。図17において、610、620は端末10の表示部に表示される画面(Webページ)の例を示している。
画面610は、プロフィールページの画面であり、ユーザが、「バトル履歴」ページへのリンク611の選択操作を行うと、端末10の表示部に過去のバトルの履歴を示すバトル履歴ページの画面620が表示される。
画面620には、過去に行った各バトルの結果情報621(621−1、621−2、621−3、・・・)が含まれる。各バトルの結果情報621には、勝敗622、決着日623、曲名624、難易度625、自分の得点626、対戦相手627、対戦相手の得点628等が含まれる。
2−4.メッセージ投稿の設定
本実施形態のネットワークシステムでは、他のサーバが提供するメッセージ投稿サイトへのメッセージ投稿の内容や条件等を設定できるようになっている。特に、メッセージを投稿する条件をバトルに関連付けて設定できるようになっている。
図18は、メッセージ投稿の設定に関する端末10の画面遷移例である。図18において、630、640は端末10の表示部に表示される画面(Webページ)の例を示している。
画面630は、ユーザのプロフィールページの画面であり、ユーザが「メッセージ投稿」ページへのリンク631の選択操作を行うと、メッセージ投稿のアカウントが登録されていれば端末10の表示部にメッセージ投稿の設定ページの画面640が表示される。
画面640には、「メッセージ投稿をやめる」と表示されたボタン641、「メッセージ投稿の設定変更」と表示されたボタン642、「登録済みメッセージ投稿アカウントを削除する」と表示されたボタン643等が設けられている。
ユーザが「メッセージ投稿をやめる」と表示されたボタン641の押下操作を行うと、以降のメッセージの投稿が行われなくなるとともに、ボタン641の表示が「メッセージ投稿をする」に変わる。ユーザが「メッセージ投稿をする」と表示されたボタン641の押下操作を行うと、以降のメッセージの投稿が行われるとともに、ボタン641の表示が「メッセージ投稿をやめる」に変わる。
また、ユーザがボタン642の押下操作を行うと、端末10の表示部にメッセージ投稿の設定変更ページの画面650が表示される。
画面650には、「得点を投稿する」を選択するチェックボックス651、「挑戦状が届いた場合にお知らせ」を選択するチェックボックス652、「バトルで勝利したら投稿する」を選択するチェックボックス653、登録ボタン656等が設けられている。
また、画面650には、「投稿する内容をカスタマイズする」を選択するチェックボックス654が設けられており、ユーザがチェックボックス654のチェック操作を行うとメッセージの内容の入力欄655に入力が可能となり、入力欄655に入力されたメッセージが投稿されるようになる。なお、ユーザがチェックボックス654にチェックが入っていなければ、デフォルトにおメッセージが投稿される。
そして、ユーザが登録ボタン656の押下操作を行うと、サーバ20は、メッセージ投稿情報390を画面650で設定された内容に変更する。
3.本実施形態の処理
3−1.バトルの全体処理
次に、本実施形態のバトルの全体処理の一例について図19(A)及び図19(B)のフローチャートを用いて説明する。図19(A)は端末10の処理のフローチャート図であり、図19(B)はサーバ20の処理のフローチャート図である。
[端末の処理]
図19(A)に示すように、端末10は、まず、バトルの申込み情報をサーバ20に送信する処理を行う(ステップS10)。
次に、端末10は、バトルの申込みが受け付けられたことの通知をサーバ20から取得する処理を行う(ステップS20)。
バトル期間が開始すると、端末10は、バトル期間が終了するまで(ステップS40のN)、ゲーム結果情報をサーバ20に送信する処理を繰り返し行う(ステップS30)。
そして、バトル期間が終了すると(ステップS40のY)、端末10はサーバ20からバトルの結果情報を取得する処理を行い(ステップS50)、処理を終了する。
[サーバの処理]
図19(B)に示すように、サーバ20は、まず、バトルの申込み処理を行う(ステップS110)。
次に、サーバ20は、バトルの受付け処理を行う(ステップS120)。
バトル期間が開始すると、サーバ20は、バトル期間が終了するまで(ステップS140のN)、端末10からゲーム結果情報を取得・登録する処理を行う(ステップS130)。
そして、バトル期間が終了すると(ステップS140のY)、サーバ20はバトルの結果情報を生成して端末10に送信する処理を行う(ステップS150)、処理を終了する。
3−2.バトルの申込み処理
次に、本実施形態のバトルの申込みに関する処理の一例について図20(A)及び図20(B)のフローチャートを用いて説明する。図20(A)は、端末10の処理のフローチャート図であり、図19(A)のステップS10の処理に対応する。また、図20(B)はサーバ20の処理のフローチャート図であり、図19(B)のステップS110の処理に対応する。
[端末の処理]
図20(A)に示すように、端末10は、ユーザによるバトル申込ページの選択操作を検出すると(ステップS11のY)、表示部にバトル申込ページの画面(図13の画面480)を表示する(ステップS12)。
端末10は、ユーザによるバトル申込みの各項目の入力操作の終了(図13の491の選択操作)を検出すると(ステップS13のY)、バトル申込みの情報(図13のジャンル480、曲名482、難易度483、コメント484等に入力又は選択した内容を含む情報)を生成してサーバ20に送信する(ステップS14)。
そして、端末10は、サーバ20からバトル申込み完了の通知を取得すると(ステップS15のY)、表示部にバトル申込の完了画面(図13の画面500)を表示し(ステップS16)、処理を終了する。
[サーバの処理]
図20(B)に示すように、サーバ20は、端末10からバトル申込みの情報を取得すると(ステップS111)、バトルを申し込んだユーザのバトル情報リスト370を参照し、バトル申込枠に空きがあるか否かチェックする(ステップS112)。
サーバ20は、バトル申込枠に空きがあれば(ステップS113のY)、バトルを申し込んだユーザのバトル情報リスト370に新たなバトル情報371を登録する(ステップS114)とともに、バトルを申し込まれたユーザのバトル情報リスト370に新たなバトル情報371を登録する(ステップS115)。
そして、サーバ20は、バトルを申し込んだユーザの端末10にバトル申込みの完了を通知する(ステップS116)とともに、バトルを申し込まれたユーザの端末10にバトルの申込みがされたことを通知し(ステップS117)、処理を終了する。
3−3.バトルの受付け処理
次に、本実施形態のバトルの受付けに関する処理の一例について図21(A)及び図21(B)のフローチャートを用いて説明する。図21(A)は、端末10の処理のフローチャート図であり、図19(A)のステップS20の処理に対応する。また、図21(B)はサーバ20の処理のフローチャート図であり、図19(B)のステップS120の処理に対応する。
[端末の処理]
図21(A)に示すように、端末10は、ユーザによるバトル受付ページの選択操作を検出すると(ステップS21のY)、表示部にバトル受付ページの画面(図14の画面540)を表示する(ステップS22)。
端末10は、ユーザによるバトルを受付けるか否かの選択操作の終了(図14の544又は545の選択操作)を検出すると(ステップS23のY)、バトルを受付けるか否かの情報をサーバ20に送信する(ステップS24)。
そして、端末10は、表示部にバトル受付の完了画面(図14の画面550又は560)を表示し(ステップS25)、処理を終了する。
[サーバの処理]
図21(B)に示すように、サーバ20は、端末10からバトルを受付けるか否かの情報を取得する(ステップS121)。
サーバ20は、ステップS121でバトルを受付ける情報を取得した場合(ステップS122のY)、バトル期間を決定し(ステップS123)、バトルを申し込んだユーザの端末10にバトルが受付けられたことを通知する(ステップS124)。
そして、サーバ20は、バトルを申込まれたユーザのバトル情報371(バトル状態375、終了日時377等)を更新する(ステップS125)とともに、バトルを申し込んだユーザのバトル情報371(バトル状態375、終了日時377等)を更新し(ステップS126)、処理を終了する。
3−4.ゲーム結果情報の登録処理
次に、本実施形態のゲーム結果情報の登録に関する処理の一例について図22(A)及び図22(B)のフローチャートを用いて説明する。図22(A)は、端末10の処理のフローチャート図であり、図19(A)のステップS30の処理に対応する。また、図22(B)はサーバ20の処理のフローチャート図であり、図19(B)のステップS130の処理に対応する。
[端末の処理]
図22(A)に示すように、端末10は、ユーザによるゲーム結果コード(QRコード又はひらがなパスワード)の入力操作を検出すると(ステップS31のY)、ゲーム結果コードを取得してサーバ20に送信する(ステップS32)。
そして、端末10は、サーバ20からゲーム結果情報331の登録完了の通知を取得すると(ステップS33のY)、表示部にゲーム結果情報331の登録完了画面(図15の画面580)を表示し(ステップS34)、処理を終了する。
[サーバの処理]
図22(B)に示すように、サーバ20は、端末10からゲーム結果コードを取得し(ステップS131)、取得したゲーム結果コードを解析してゲーム結果情報331を生成し、ゲーム結果情報リスト330に登録する(ステップS132)。
そして、サーバ20は、端末10にゲーム結果情報331の登録完了を通知する(ステップS133)。
さらに、サーバ20は、バトル中のユーザのゲーム結果情報か否かをチェックし(ステップS134)、バトル中のユーザのゲーム結果情報であれば(ステップS135)、バトル中のユーザのバトル情報371(途中経過のバトルの勝敗379、自分の得点380、相手の得点381等)を更新し(ステップS136)、処理を終了する。
3−5.バトルの結果情報(バトル履歴)の表示処理
次に、本実施形態のバトルの結果情報(バトル履歴)の表示に関する処理の一例について図23(A)及び図23(B)のフローチャートを用いて説明する。図23(A)は、端末10の処理のフローチャート図であり、図19(A)のステップS50の処理に対応する。また、図23(B)はサーバ20の処理のフローチャート図であり、図19(B)のステップS150の処理に対応する。
[端末の処理]
図23(A)に示すように、端末10は、ユーザによるバトル履歴ページの選択操作を検出すると(ステップS51のY)、サーバ20にバトルの結果情報を要求する(ステップS52)。
そして、端末10は、サーバ20からバトルの結果情報を取得し(ステップS53)、表示部にバトル履歴ページの画面(図17の画面620)を表示し(ステップS54)、処理を終了する。
[サーバの処理]
図23(B)に示すように、サーバ20は、端末10からバトルの結果情報の要求を取得すると(ステップS151)、端末10のユーザのバトル情報リスト370から当該バトルのバトル情報371を参照し、バトルの結果情報を作成する(ステップS152)。
そして、サーバ20は、ユーザの端末10にバトルの結果情報を送信し(ステップS153)、処理を終了する。
以上に説明した、本実施形態によれば、バトルの相手となる複数のユーザがバトル期間内にプレイしたゲーム結果情報に基づいてバトルの結果情報を生成し、バトルの結果情報が各ユーザの端末10に通知されるので、各ユーザは、バトルに勝つために、バトル期間中に確実に対戦相手よりも良いと思われるゲーム結果が得られるまでゲームを繰り返しプレイする意欲を高めることができる。
また、バトルの申込みと受付けにより対戦相手同士の意思が合致してはじめてバトルが成立するので、対戦を望むユーザ同士でバトルを開始することができる。これにより、各ユーザはバトルに勝ちたい気持ちがより高まり、バトル期間中にゲームを繰り返しプレイする意欲をより高めることができる。
また、本実施形態によれば、ゲーム装置40がネットワーク30に接続されていなくても、ゲーム装置40でプレイしたゲーム結果情報を端末10を用いてサーバ20に送信することでバトルの結果に反映させることができる。これにより、例えば、業務用のゲーム機(ゲーム装置の一例)と携帯電話機(端末の一例)を連動させたサービスを提供することができる。
4.動画像を生成する処理の説明
4−1.概要
本実施形態では、図17に示すように、ユーザの端末において、過去に行ったバトル結果情報621を表示するが、ユーザはどのようにして相手に勝ち、負け、或いは引き分けたのかイメージできない。
そこで、本実施形態では、サーバ20が記憶部に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報(例えば、バトル結果情報)に基づいて動画像データを選択し、選択された動画像データを用いてユーザのキャラクタ(ユーザ識別情報に対応付けられたキャラクタ)を含むキャラクタ動画像(ユーザのキャラクタが登場する動画像)を生成する処理を行い、生成されたキャラクタ動画像を端末の表示部に表示させるようにしてもよい。
例えば、ユーザU1とユーザU2とのバトルの結果、ユーザU1がユーザU2に勝利した場合には、図24に示すように、ユーザU1のキャラクタCA1が、格闘して勝利するようなキャラクタ動画像を生成し、生成されたキャラクタ動画像を端末の表示部に表示させる。このようにすれば、ユーザU1は、どのようにして勝ったのかをイメージすることができる。
4−2.ネットワークシステムの説明
本実施形態のネットワークシステムは、図1に示すように、サーバ20が、ネットワークを介してユーザの端末10に動画像を提供することができる。
例えば、サーバ20は、ユーザU1の端末10Aから、ゲーム終了後に得られるユーザのゲーム結果情報を取得し、ユーザのゲーム結果情報に基づいて、ユーザU1のゲーム評価を行い、ユーザU1のゲーム評価結果情報を端末10Aに送信する。
そして、サーバ20は、記憶部270に記憶されたユーザU1のキャラクタCA1を含むキャラクタ動画像を生成する処理を行う。例えば、サーバ20は、記憶部270に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報に基づいて一の動画像データを選択し、選択された動画像データを用いてユーザU1のキャラクタCA1を含むキャラクタ動画像を生成する。そして、サーバ20は、ユーザU1のキャラクタ動画像を、端末10Aに送信する処理を行う。
一方、端末10Aは、サーバ20から、ユーザU1のゲーム評価結果情報を受信し、受信したゲーム評価結果情報を端末10Aの表示部に表示する表示制御を行う。そして、サーバ20からユーザU1のキャラクタ動画像を受信する処理を行い、ゲーム評価結果情報を表示した後に、キャラクタ動画像を端末10Aの表示部に表示させる表示制御を行う。
4−2−1.サーバ
図25は、動画像を生成する本実施形態のサーバ20の機能ブロック図の例を示す。本実施形態のサーバ20は、図25の構成要素(各部)の一部を省略した構成としてもよい。なお、図5に示すサーバ20の機能と同じ構成要素については説明を省略する。
取得部227は、ユーザのゲーム情報を取得する。例えば、取得部227は、ゲーム終了後に得られるユーザのゲーム結果情報を取得する。なお、取得部227は、複数のユーザのゲーム結果情報を取得するようにしてもよい。例えば、第1のユーザのゲーム結果情報と、第2のユーザのゲーム結果情報とを取得するようにしてもよい。また、取得部227は、所定イベント発生時から所定期間内にユーザのゲーム結果情報を取得可能とするようにしてもよい。なお、取得部227は、ゲーム結果情報取得部221、バトル申込情報取得部223、バトル受付情報取得部225、ユーザ勧誘情報取得部229、ユーザ参加情報取得部239とを含む。つまり、取得部227に含まれるユーザ勧誘情報取得部229は、第1のユーザの端末からゲームへの参加を勧誘する第2のユーザが指定された情報を取得する。また、取得部227に含まれるユーザ参加情報取得部239は、ユーザの端末から前記ゲームに参加することを示す情報を取得する。
ユーザ判定部238は、ユーザ勧誘情報取得部229が取得する情報とユーザ参加情報取得部239が取得する情報とに基づいて、ゲームに参加するユーザが第1のユーザが勧誘した第2のユーザであるか否かを判定する。
送信部228は、ゲーム評価部235が行ったユーザのゲーム評価結果情報を端末10に送信する処理を行う。また、送信部228は、ユーザのキャラクタ動画像を、端末に送信する処理を行う。なお、送信部228は、端末10からのキャラクタ動画像の要求データを受信した場合に、応答データとして、ユーザのキャラクタ動画像を、端末に送信する処理を行うようにしてもよい。なお、送信部228は、バトル結果情報通知部222、バトル申込通知部224、投稿メッセージ送信部226とを含む。
ゲーム評価部235は、ユーザのゲーム情報に基づいて、ユーザのゲーム評価を行う。例えば、ゲーム評価部235は、ユーザのゲーム結果情報(例えば、得点)をゲーム情報とし、当該ユーザのゲーム結果情報に基づいて、ユーザのゲーム評価を行う。例えば、ゲーム評価部235は、第1のユーザのゲーム結果情報と、第2のユーザのゲーム結果情報とを比較し、比較結果に基づいて第1、第2のユーザのゲーム評価(例えば、勝敗判定)を行う。例えば、第1のユーザの得点が第2のユーザの得点よりも大きい値である場合に第1のユーザを「勝ち」と評価し、第2のユーザを「負け」と評価する。また、第1のユーザの得点と第2のユーザの得点とが同値である場合に第1のユーザと、第2のユーザとが引き分けたと評価する。また、第1のユーザの得点が第2のユーザの得点よりも小さい値である場合に第1のユーザを「負け」と評価し、第2のユーザを「勝ち」と評価する。
なお、ゲーム評価部235は、ユーザの複数のゲーム結果情報に基づいて、当該ユーザのゲーム評価を行うようにしてもよい。例えば、ユーザの端末からゲーム結果情報(例えば、得点)を複数受信した場合には、受信した複数のゲーム結果情報に基づいて、ユーザのゲーム評価を行う。
また、ゲーム評価部235は、所定期間内に取得されたユーザのゲーム結果情報に基づいてゲーム評価を行うようにしてもよい。また、ゲーム評価部235は、所定期間内に、ユーザU1、ユーザU2とがバトルをする場合には、各ユーザU1、U2端末からゲーム結果情報(得点)を受信する度に、暫定ゲーム評価(暫定勝敗判定)を行うようにしてもよい。なお、ゲーム評価部235は、バトル結果情報生成部230を含む。
動画像生成部236は、記憶部270に記憶されたユーザのキャラクタを含むキャラクタ動画像を生成する処理を行う。より具体的に説明すると、動画像生成部236は、ユーザのユーザ識別情報310に対応づけられたキャラクタ391に基づいて、キャラクタ391を構成するキャラクタのオブジェクトを、動画像データと合成してキャラクタ動画像を生成する。
動画像生成部236は、記憶部270に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報に基づいて動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行う。
動画像生成部236は、複数のユーザがバトルを行った場合には、各ユーザのゲーム評価結果情報に基づいて、動画像データを選択し、選択された動画像データを用いて各ユーザのキャラクタを含む共通のキャラクタ動画像を生成する処理を行うようにしてもよい。
動画像生成部236は、複数のユーザそれぞれに対してユーザ固有のキャラクタ動画像を生成するようにしてもよい。つまり、ユーザ毎に異なるキャラクタ動画像を生成するようにしてもよい。例えば、動画像生成部236は、記憶部270に記憶された複数の異なる動画像データの中から、第1のユーザのゲーム評価結果情報に基づいて第1の動画像データを選択し、選択された第1の動画像データを用いて第1のユーザのキャラクタを含む第1のキャラクタ動画像を生成し、記憶部270に記憶された複数の異なる動画像データの中から、第2のユーザのゲーム評価結果情報に基づいて第2の動画像データを選択し、選択された第2の動画像データを用いて第2のユーザのキャラクタを含む第2のキャラクタ動画像を生成する処理を行う。
動画像生成部236は、ユーザのゲーム結果情報を取得した取得回数に基づいて記憶部270に記憶された複数の動画像データの中から動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成するようにしてもよい。
動画像生成部236は、記憶部270に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報及びユーザの複数のゲーム結果情報に基づいて、動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行うようにしてもよい。
また、動画像生成部236は、記憶部270に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報及び所定期間内に取得されたユーザのゲーム結果情報に基づいて、動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行うようにしてもよい。
動画像生成部236は、ゲーム装置40においてゲーム演算を行う際に表示されるゲーム動画像とは異なるキャラクタ動画像を生成するようにしてもよい。
動画像生成部236は、選択された動画像データを用いてユーザのキャラクタと、記憶部270に記憶されたユーザのアイテムとを含むキャラクタ動画像を生成する処理を行うようにしてもよい。
動画像生成部236は、記憶部270に記憶された複数の異なる動画像データの中から、ランダムに動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行うようにしてもよい。
また、動画像生成部236は、ゲームに参加するユーザが第1のユーザが勧誘した第2のユーザである場合に、第1のユーザに対して、第1のユーザのキャラクタを含む特別用のキャラクタ動画像を生成する処理を行う。また、動画像生成部236は、ゲームに参加するユーザが第1のユーザが勧誘した第2のユーザである場合に、第2のユーザに対して、第2のユーザのキャラクタを含む特別用のキャラクタ動画像を生成する処理を行う。
なお、動画像生成部236が、リアルタイムに動画像を構成する各フレームの画像を生成する場合には、描画部が処理を行う。
描画部は、各フレーム画像を生成する。例えば、描画部が生成する画像は、いわゆる2次元画像であってもよいし、いわゆる3次元画像であってもよい。
2次元画像を生成する場合には、オブジェクト(スプライト)毎に優先度を設定し、設定された優先度が低いオブジェクトから順に描画する。オブジェクト同士が重なる場合には、優先度が低いオブジェクトの上に、優先度の高いオブジェクトを描画する。例えば、ユーザのキャラクタのオブジェクトを優先度を最も高くして描画するようにしてもよい。
いわゆる3次元ゲーム画像を生成する場合には、まずユーザのキャラクタのオブジェクト(モデル)の各頂点の頂点データ(頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等)を含むオブジェクトデータ(モデルデータ)が入力され、入力されたオブジェクトデータに含まれる頂点データに基づいて、頂点処理(頂点シェーダによるシェーディング)が行われる。なお頂点処理を行うに際して、必要に応じてポリゴンを再分割するための頂点生成処理(テッセレーション、曲面分割、ポリゴン分割)を行うようにしてもよい。
頂点処理では、頂点処理プログラム(頂点シェーダプログラム、第1のシェーダプログラム)に従って、頂点の移動処理や、座標変換、例えばワールド座標変換、視野変換(カメラ座標変換)、クリッピング処理、透視変換(投影変換)、ビューポート変換等のジオメトリ処理が行われ、その処理結果に基づいて、オブジェクトを構成する頂点群について与えられた頂点データを変更(更新、調整)する。
そして、頂点処理後の頂点データに基づいてラスタライズ(走査変換)が行われ、ポリゴン(プリミティブ)の面とピクセルとが対応づけられる。そしてラスタライズに続いて、画像を構成するピクセル(表示画面を構成するフラグメント)を描画するピクセル処理(ピクセルシェーダによるシェーディング、フラグメント処理)が行われる。ピクセル処理では、ピクセル処理プログラム(ピクセルシェーダプログラム、第2のシェーダプログラム)に従って、テクスチャの読出し(テクスチャマッピング)、色データの設定/変更、半透明合成、アンチエイリアス等の各種処理を行って、画像を構成するピクセルの最終的な描画色を決定し、透視変換されたオブジェクトの描画色を描画バッファ(ピクセル単位で画像情報を記憶できるバッファ。VRAM、レンダリングターゲット)に出力(描画)する。すなわち、ピクセル処理では、画像情報(色、法線、輝度、α値等)をピクセル単位で設定あるいは変更するパーピクセル処理を行う。これにより、オブジェクト空間内において仮想カメラ(視点)から見える画像が生成される。なお、仮想カメラ(視点)が複数存在する場合には、それぞれの仮想カメラから見える画像を分割画像として1画面に表示できるように画像を生成することができる。
なお、描画部は、オブジェクト空間内の所与(任意)の視点から見える画像を生成するための仮想カメラ(視点)の制御処理を行う。具体的には、3次元の画像を生成する場合には、ワールド座標系における仮想カメラの位置(X、Y、Z)又は回転角度(例えば、X、Y、Z軸の各軸の正方向からみて時計回りに回る場合における回転角度)を制御する処理を行う。要するに、視点位置、視線方向、画角を制御する処理を行う。また、仮想カメラ制御部は、仮想カメラを、予め決められた回転角度で回転させてもよい。この場合には、仮想カメラの位置又は回転角度を特定するための仮想カメラデータに基づいて仮想カメラを制御する。なお、仮想カメラ(視点)が複数存在する場合には、それぞれの仮想カメラについて上記の制御処理が行われる。
例えば仮想カメラによりオブジェクト(例えば、ユーザのキャラクタ)を後方から撮影する場合には、オブジェクトの位置、向きの変化に仮想カメラが追従するように、仮想カメラの位置、仮想カメラの向きを制御する。この場合には、移動・動作処理部112で得られたオブジェクトの位置、向き又は速度などの情報に基づいて、仮想カメラを制御できる。或いは、仮想カメラを、予め決められた向きに設定したり、予め決められた移動経路で移動させる制御を行ってもよい。この場合には、仮想カメラの位置(移動経路)又は向きを特定するための仮想カメラデータに基づいて仮想カメラを制御する。なお、仮想カメラ(視点)が複数存在する場合には、それぞれの仮想カメラについて上記の制御処理が行われる。
なお頂点処理やピクセル処理は、シェーディング言語によって記述されたシェーダプログラムによって、ポリゴン(プリミティブ)の描画処理をプログラム可能にするハードウェア、いわゆるプログラマブルシェーダ(頂点シェーダやピクセルシェーダ)により実現される。プログラマブルシェーダでは、頂点単位の処理やピクセル単位の処理がプログラム可能になることで描画処理内容の自由度が高く、従来のハードウェアによる固定的な描画処理に比べて表現力を大幅に向上させることができる。
そして描画部は、オブジェクトを描画する際に、ジオメトリ処理、テクスチャマッピング、隠面消去処理、αブレンディング等を行う。
ジオメトリ処理では、オブジェクトに対して、座標変換、クリッピング処理、透視投影変換、或いは光源計算等の処理が行われる。そして、ジオメトリ処理後(透視投影変換後)のオブジェクトデータ(オブジェクトの頂点の位置座標、テクスチャ座標、色データ(輝度データ)、法線ベクトル、或いはα値等)は、オブジェクトデータ記憶部に保存される。
テクスチャマッピングは、記憶部170のテクスチャ記憶部に記憶されるテクスチャ(テクセル値)をオブジェクトにマッピングするための処理である。具体的には、オブジェクトの頂点に設定(付与)されるテクスチャ座標等を用いて記憶部170のテクスチャ記憶部からテクスチャ(色(RGB)、α値などの表面プロパティ)を読み出す。そして、2次元の画像であるテクスチャをオブジェクトにマッピングする。この場合に、ピクセルとテクセルとを対応づける処理や、テクセルの補間としてバイリニア補間などを行う。
隠面消去処理としては、描画ピクセルのZ値(奥行き情報)が格納されるZバッファ(奥行きバッファ)を用いたZバッファ法(奥行き比較法、Zテスト)による隠面消去処理を行うことができる。すなわちオブジェクトのプリミティブに対応する描画ピクセルを描画する際に、Zバッファに格納されるZ値を参照する。そして参照されたZバッファのZ値と、プリミティブの描画ピクセルでのZ値とを比較し、描画ピクセルでのZ値が、仮想カメラから見て手前側となるZ値(例えば小さなZ値)である場合には、その描画ピクセルの描画処理を行うとともにZバッファのZ値を新たなZ値に更新する。
αブレンディング(α合成)は、α値(A値)に基づく半透明合成処理(通常αブレンディング、加算αブレンディング又は減算αブレンディング等)のことである。
なお、α値は、各ピクセル(テクセル、ドット)に関連づけて記憶できる情報であり、例えば色情報以外のプラスアルファの情報である。α値は、マスク情報、半透明度(透明度、不透明度と等価)、バンプ情報などとして使用できる。
また、カウント処理部237は、ユーザのゲーム結果情報を取得した取得回数をカウントする。
4−2−2.端末
図26は、端末10の機能ブロック図の例を示す。本実施形態の端末10は、図26の構成要素(各部)の一部を省略した構成としてもよい。なお、図4に示す端末10の機能と同じ構成要素については説明を省略する。
通信制御部110の取得部116は、サーバ20から端末を操作するユーザのゲーム評価結果情報を受信する処理を行う。また、通信制御部110の取得部116は、サーバ20からユーザのキャラクタ動画像を受信する処理を行う。例えば、通信制御部110の送信部117は、キャラクタ動画像の要求データをサーバ20に送信し、取得部116が、その要求データに対する応答データとして、キャラクタ動画像を受信するようにしてもよい。
なお、通信制御部110の取得部116は、バトル結果情報取得部111、バトル申込通知取得部113を含む。また通信制御部110の送信部117は、バトル申込情報送信部112、バトル受付情報送信部114、ゲーム結果情報送信部115、ユーザ勧誘情報送信部118と、ユーザ参加情報送信部119を含む。
表示制御部120は、ユーザのゲーム評価結果情報を表示する表示制御を行う。そして、表示制御部120は、キャラクタ動画像を表示させる表示制御を行う。例えば、表示制御部120は、ゲーム評価結果情報を表示した後に、キャラクタ動画像を表示部に表示させる処理を行う。なお、通信制御部110の送信部117が、キャラクタ動画像の要求データをサーバ20に送信し、取得部116がキャラクタ動画像を受信した場合に、当該キャラクタ動画像を表示部に表示させる処理を行うようにしてもよい。
キャラクタ動画像データ記憶部173は、サーバ20から受信したキャラクタ動画像を格納する領域である。例えば、端末は、サーバ20から受信したキャラクタ動画像をキャラクタ動画像データ記憶部173に記憶させ、表示部120は、キャラクタ動画像データ記憶部173に記憶されているキャラクタ動画像を表示部190に表示させる処理を行う。
4−3.ユーザのキャラクタを含む動画像を生成する処理の説明
本実施形態のサーバ20は、記憶部270に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報に基づいて動画像データを選択し、選択された動画像データを用いて、ユーザのキャラクタ(ユーザ識別情報に対応づけられたキャラクタ)を含むキャラクタ動画像を生成する処理を行い、サーバ20は、ユーザの端末10にキャラクタ動画像を送信する。そして、ユーザの端末10は、サーバ20から、キャラクタ動画像を受信し、受信したキャラクタ動画像を表示部に表示させるように制御する。
例えば、図27(A)に示すように、ユーザの端末がゲーム情報(ゲーム結果情報)をサーバに送信し、サーバが、受信した端末のゲーム情報に基づいてゲーム評価処理を行い、ゲーム評価結果情報を端末に送信し、端末側でそのゲーム評価結果情報を単に表示させるだけでは、ユーザは、どのようにしてゲーム評価結果に至ったのかイメージできない。例えば、ユーザU1が、ユーザU2とのバトルに勝利した場合は、どのようにして勝ったのか、或いは、負けた場合には、どのように負けたのか今ひとつイメージすることができない。
そこで、本実施形態では、記憶部に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報に基づいて動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像(ユーザのキャラクタが登場する動画像)を生成する処理を行う。例えば、図27(B)に示すように、ユーザの端末からキャラクタ動画像要求データをサーバが受信した場合に、記憶部に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報に基づいて動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行うようにし、生成されたキャラクタ動画像を端末に送信してもよい。そして、端末は、キャラクタ動画像をサーバから受信し、受信したキャラクタ動画像を表示部に表示させるようにする。
このようにすれば、ユーザは、どのようにしてゲーム評価結果に至ったのかイメージすることができる。また、いわゆるリプレイ画像の生成とは異なり処理負荷を軽減し、かつデータ容量を抑えてキャラクタ動画像を生成することができる。
また、ゲーム結果情報とは、ゲームのゲーム終了後に得られるユーザのプレイ結果を示す情報であり、例えば、ゲームで得られた得点(スコア)などである。より具体的には、図8に示すように、ゲーム結果情報は、プレイ日時332、プレイ状態333、プレイした曲名334、難易度335、ノルマクリア336、フルコンボ337、得点338、「良」の数339、「可」の数340、「不可」の数341、連打音符(音符C)に対する連打数342、コンボ数343の少なくとも1つを含む。
また、ゲーム評価結果情報とは、バトル結果情報生成部230において生成された、バトルの結果情報である。言い換えると、ゲーム結果情報に基づいて、ユーザのゲーム評価を行った結果を示す情報である。
4−3−1.ユーザのキャラクタ
図28は、ユーザ情報300の例を示す。例えば、サーバ20は、ユーザ識別情報310に対応づけて、キャラクタ391、アイテム392を記憶部に記憶させておく。
本実施形態のサーバは、ユーザU1の端末から、ユーザ識別情報とキャラクタ動画像要求データとを受信すると、当該ユーザU1のユーザ識別情報に対応するキャラクタCA1を含むキャラクタ動画像を生成する。そして、サーバは、ユーザU1の端末に、キャラクタCA1を含むキャラクタ動画像を送信する。つまり、サーバは、図24に示すように、少なくともユーザU1のキャラクタCA1が登場するキャラクタ動画像を生成する。
4−3−2.動画像データ
図29は、ゲーム評価結果情報と動画像データとの関係を示す。本実施形態の動画像データ700は、ゲーム評価結果になるまでのイメージ動画像を構成するフレーム画像を生成するために用いられる画像データである。例えば、動画像データ700は、キャラクタをオブジェクト空間(2次元空間、3次元空間)に配置させるための位置情報、移動情報(移動方向、移動量、及び移動速度の少なくとも一つ)や、アイテムをオブジェクト空間(2次元空間、3次元空間)に配置させるための位置情報、移動情報(移動方向、移動量、及び移動速度の少なくとも一つ)の少なくとも1つを含む。
また、動画像データ700は、3次元のキャラクタ動画像を生成する場合には、仮想カメラの情報(仮想カメラの位置、仮想カメラの向き、仮想カメラの画角の少なくとも1つ)を含む。つまり、仮想カメラの情報に基づいて仮想カメラを制御し、当該仮想カメラから見えるユーザのキャラクタオブジェクトを含む画像を生成する。また、動画像データは、オブジェクトのモーションデータ(動きデータ)を含む。また、動画像データは、すでに描画されているムービーデータ、アニメーションデータとしてもよい。
4−3−3.動画像データを選択する処理
そして、サーバ20は、ゲーム評価結果に基づいて、例えば、図29に示すように複数の動画像データ1〜300の中から一の動画像データを選択する。例えば、ゲーム評価結果の一例として、勝敗データを用いる場合について説明する。
まず、ユーザU1の勝敗データが「勝ち」である場合には、記憶部に記憶された複数の異なる動画像データ1〜300のうち、「勝ち」の複数の異なる動画像データ1〜100中から、一の動画像データ(例えば、動画像データ1)を選択する。なお、動画像データ1〜100中から、一の動画像データを選択する場合には、ランダムに選択してもよいし、ID(動画像データの識別情報)の1から100の範囲で順に選ぶようにしてもよい。
また、ユーザU1の勝敗データが「負け」である場合には、記憶部に記憶された複数の異なる動画像データ1〜300のうち、「負け」の複数の異なる動画像データ101〜200中から、一の動画像データ(例えば、動画像データ101)を選択する。なお、動画像データ101〜200中から、一の動画像データを選択する場合には、ランダムに選択してもよいし、ID(動画像データの識別情報)の101から200の範囲で順に選ぶようにしてもよい。
また、ユーザU1の勝敗データが「引き分け」である場合には、記憶部に記憶された複数の異なる動画像データ1〜300のうち、「引き分け」の複数の異なる動画像データ201〜300中から、一の動画像データ(例えば、動画像データ201)を選択する。なお、動画像データ201〜300中から、一の動画像データを選択する場合には、ランダムに選択してもよいし、ID(動画像データの識別情報)の201から300の範囲で順に選ぶようにしてもよい。
4−3−4.キャラクタ動画像を生成する処理
本実施形態では、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行う。
例えば、サーバは、例えば、ユーザU1の勝敗データが「勝ち」である場合に、動画像データ1を選択した場合には、動画像データ1を用いてユーザのキャラクタCA1を含むキャラクタ動画像を生成する。具体的には、図24に示すように、ユーザU1用に、「勝ち」をイメージさせる動画像を生成する。このように、本実施形態では、図3に示すような、ゲーム装置40のゲームプレイ中に表示される動画像とは異なるキャラクタ動画像を生成するようにしてもよい。このようにすれば、ゲームプレイ中にユーザが見ることができないキャラクタ動画像を生成することができ、ユーザを飽きさせない面白みのある動画を生成することができる。
なお、サーバは、生成されたキャラクタ動画像800は、記憶部に一旦記憶させ、その後、ユーザの端末に送信するようにしてもよい。なお、キャラクタ動画像800は、3次元の動画像でもよい(立体視の動画像でもよい)、2次元の動画像(アニメーション)でもよい。
例えば、3次元のキャラクタ動画像を生成する場合には、リアルタイムに動画像を生成してもよい。かかる場合には、予め用意された3次元の動画像データに、ユーザのキャラクタに対応する動画データとを合成するようにしてもよい。また、オブジェクト空間に、動画像データに基づいて定義された配置位置に、ユーザのキャラクタを配置させ、動画像を構成する各画像を生成するようにしてもよい。
また、2次元のキャラクタ動画像を生成する場合には、リアルタイムに動画像を生成してもよい。かかる場合には、予め用意された2次元の動画像データ(アニメーション)に、ユーザのキャラクタに対応する動画データ(アニメーション)とを合成するようにしてもよい。
4−3−4.効果
以上のように、本実施形態では、ゲーム評価結果に基づいて、キャラクタ動画像を生成するので、ユーザは、どのようにしてゲーム評価結果に至ったのかイメージできる。また、本実施形態では、いわゆるリプレイのように、ユーザのプレイデータ(キャラクタの位置や、タイミング情報など)を逐次記憶したデータに基づいてキャラクタ動画像を生成するものではない。したがって、リプレイとは異なり処理負荷を軽減し、かつデータ容量を抑えてキャラクタ動画像を生成することができる。
4−4.ユーザ毎に動画像を生成する処理の説明
本実施形態では、複数のユーザのバトルを行った各ユーザのゲーム結果情報に基づいてゲーム評価を行い、当該ゲーム評価結果情報に基づいて、ユーザ毎にキャラクタの動画像を生成してもよい。
つまり、第1のユーザのゲーム結果情報と、第2のユーザのゲーム結果情報とを比較し、比較結果に基づいて第1、第2のユーザのゲーム評価を行う場合には、記憶部に記憶された複数の異なる動画像データの中から、第1のユーザのゲーム評価結果情報に基づいて第1の動画像データを選択し、選択された第1の動画像データを用いて第1のユーザのキャラクタを含む第1のキャラクタ動画像を生成する。そして、記憶部に記憶された複数の異なる動画像データの中から、第2のユーザのゲーム評価結果情報に基づいて第2の動画像データを選択し、選択された第2の動画像データを用いて第2のユーザのキャラクタを含む第2のキャラクタ動画像を生成するようにしてもよい。
例えば、ユーザU1と、ユーザU2とのバトルが開始され、ユーザU1が勝ち、ユーザU2が負けた場合について説明する。本実施形態では、サーバが記憶部に記憶された複数の異なる動画像データ1〜300の中から、第1のユーザU1のゲーム評価結果情報(つまり、「勝ち」)に基づいて第1の動画像データを選択する。例えば、ゲーム評価結果情報の勝ちに対応する動画データ群1〜100の中から一の動画像データ(例えば、動画像データ1)を選択する。そして、選択された第1の動画像データを用いて第1のユーザのキャラクタCA1を含む第1のキャラクタ動画像を生成する。例えば、図24に示すように、ユーザU1用には、「勝ち」のイメージ動画像を生成する。なお、図24に示すように、相手ユーザU2のキャラクタCA2を含む動画像を生成してもよい。
また、サーバは、記憶部に記憶された複数の異なる動画像データ1〜300の中から、第2のユーザのゲーム評価結果情報(つまり、「負け」)に基づいて第2の動画像データを選択する。例えば、ゲーム評価結果情報の負けに対応する動画データ群101〜200の中から一の動画像データ(例えば、動画像データ101)を選択する。そして、選択された第2の動画像データを用いて第2のユーザのキャラクタCA2を含む第2のキャラクタ動画像を生成する。例えば、図30に示すように、ユーザU2用には、「負け」のイメージ動画像を生成する。なお、図30に示すように、相手ユーザU1のキャラクタCA1を含む動画像を生成してもよい。
このように、ユーザ毎に、そのユーザのキャラクタを登場させるとともに、ゲーム評価結果が反映された動画像を生成することができ、各ユーザは、自分のゲーム評価に至った経緯をキャラクタ動画像を見ることによって、分かりやすくイメージすることができる。
なお、本実施形態では、複数のユーザのバトルを行った各ユーザのゲーム結果情報に基づいてゲーム評価を行い、当該ゲーム評価結果情報に基づいて、当該複数のユーザにおいて共通のキャラクタの動画像を生成してもよい。例えば、ユーザU1と、ユーザU2とのバトルが開始され、ユーザU1が勝ち、ユーザU2が負けた場合において、ユーザU1のキャラクタCA1とユーザU2のキャラクタCA2とを少なくとも含むキャラクタ動画像を生成してもよい。例えば、図24に示すような、ユーザU1、U2において共通のキャラクタ動画像M1を生成し、ユーザU1、U2の各端末に、このキャラクタ動画像M1を送信するようにしてもよい。また、図26に示すような、ユーザU1、U2において共通のキャラクタ動画像M2を生成し、ユーザU1、U2の各端末に、このキャラクタ動画像M2を送信するようにしてもよい。
4−5.ゲーム結果情報の取得回数に基づいて、動画像を生成する処理の説明
本実施形態のサーバは、ユーザのゲーム結果情報を取得した取得回数をカウントし、ユーザのゲーム結果情報を取得した取得回数に基づいて、記憶部に記憶された複数の動画像データの中から動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成するようにしてもよい。
ここで、ユーザのゲーム結果情報を取得した取得回数は、ユーザのゲーム結果情報を取得した累積取得回数、所定期間内にユーザのゲーム結果情報を取得した回数とすることができる。
例えば、ユーザU1のゲーム結果情報を取得した取得回数が1回の場合には、動画像データ1を選択し、ユーザU1のゲーム結果情報を取得した取得回数が2回の場合には、動画像データ2を選択し、ユーザU1のゲーム結果情報を取得した取得回数が3回の場合には、動画像データ3を選択する。言い換えると、サーバ20は、取得回数に応じて異なる動画像データを選択する。このようにすれば、ゲーム結果情報の取得回数に基づいて動画像を生成すれば、ユーザに繰り返し多くのゲームを行わせる動機を与えることができる。
なお、本実施形態では、ユーザのゲーム評価結果情報が「勝ち」の場合には、図29に示す動画データ群1〜100の中から、取得回数に基づいて、一の動画像データを選択するようにし、ユーザのゲーム評価結果情報が「負け」の場合には、動画データ群101〜200の中から、取得回数に基づいて、一の動画像データを選択するようにし、ユーザのゲーム評価結果情報が「引き分け」の場合には、動画データ群201〜300の中から、取得回数に基づいて、一の動画像データを選択するようにする。
4−6.複数のゲーム結果情報に基づいて動画像を生成する処理の説明
本実施形態のサーバは、ユーザの複数のゲーム結果情報を取得し、ユーザの複数のゲーム結果情報に基づいて、ユーザのゲーム評価を行い、記憶部に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報及びユーザの複数のゲーム結果情報に基づいて、動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行うようにしてもよい。このようにすれば、複数のゲーム結果情報をキャラクタの動画像に反映させることができ、ユーザは、ゲーム評価結果に至るまでの経緯をよりイメージすることができる。
例えば、図31に示すように、サーバが、ユーザU1の端末からT11、T13時点で取得した各ゲーム結果情報(得点)を取得している。したがって、サーバは、ゲーム評価結果情報「勝ち」と、T11、T13時点で取得した各ゲーム結果情報(得点)に基づいて、「勝ち」の動画像データ1〜100の中から一の動画像データを選択する。
例えば、サーバは、「勝ち」の動画像データ1〜100のうち、動画像データ11〜20を、低得点(0〜20000点)用の動画データ群、動画像データ21〜30を、高得点スコア(20000点以上)用の動画像データ群として記憶部に記憶する。そして、サーバは、取得した各ゲーム結果情報(得点)の最高得点に基づいて、動画像データを選択する。例えば、ユーザU1の最高得点が30000点である場合には、動画像データ21〜30の中から一の動画像データ(例えば、動画像データ21)を選択し、選択された動画像データを用いてユーザU1のキャラクタCA1を含むキャラクタ動画像を生成する。
なお、本実施形態では、ユーザU1の端末からT11、T13時点で取得した得点の合計得点に基づいて、動画像データを選択するようにしてもよいし、スコア以外のゲーム結果情報(例えば、難易度、ノルマクリアしたか否か、フルコンボを達成したか否か、「良」の数が所定数以上か否か、連打数が所定連打数以上か否か、コンボ数が所定コンボ数以上か否かの少なくとも1つ)に基づいて記憶部に記憶された複数の異なる動画像データの中から、動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行うようにしてもよい。
4−7.所定期間内に取得されたゲーム結果情報に基づいて動画像を生成する処理の説明
本実施形態のサーバは、記憶部に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報及び所定期間内に取得されたユーザのゲーム結果情報に基づいて、動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行ようにしてもよい。このようにすれば、ユーザに所定期間内に繰り返し多くのゲームを行わせる動機を与えることができる。
なお、所定期間とは、例えば、所定イベント発生時から期間である。具体的には、バトル期間を所定期間とすることができる。また、所定のイベントが発生した時点からの期間を所定期間としてもよい。
例えば、図31に示すように、ユーザU1から所定期間内(T10〜T14以内)に取得されたユーザのゲーム結果情報(T11、T13時点に取得したスコア)に基づいて、記憶部に記憶された複数の異なる動画像データの中から、動画像データを選択し、選択された動画像データを用いてユーザU1のキャラクタを含むキャラクタ動画像を生成する処理を行ようにしてもよい。
また、ユーザU2から所定期間内(T10〜T14以内)に取得されたユーザのゲーム結果情報(T12時点に取得したスコア)に基づいて、記憶部に記憶された複数の異なる動画像データの中から、動画像データを選択し、選択された動画像データを用いてユーザU2のキャラクタを含むキャラクタ動画像を生成する処理を行ようにしてもよい。
また、本実施形態では、所定期間において行われる第1、第2のユーザのゲーム評価結果情報(バトル結果情報)、及び、所定期間において行われる第1、第2のユーザの各ゲーム結果情報に基づいて、記憶部に記憶された複数の異なる動画像データの中から、第1のユーザ用の動画像データを選択し、選択された動画像データを用いてユーザU1のキャラクタを含むキャラクタ動画像を生成する処理を行ようにしてもよい。
同様に、所定期間において行われる第1、第2のユーザのゲーム評価結果情報(バトル結果情報)、及び、所定期間において行われる第1、第2のユーザの各ゲーム結果情報に基づいて、記憶部に記憶された複数の異なる動画像データの中から、第2のユーザ用の動画像データを選択し、選択された動画像データを用いてユーザU2のキャラクタを含むキャラクタ動画像を生成する処理を行ようにしてもよい。
より詳しく説明すると、まず、図31に示すように、第1のユーザU1、第2のユーザU2のゲーム結果情報を取得する度に、第1のユーザのゲーム結果情報と、第2のユーザのゲーム結果情報とを比較し、比較結果に基づいて第1、第2のユーザの暫定ゲーム評価を行う。
そして、第1のユーザのキャラクタ動画像を生成する場合には、第1のユーザU1、第2のユーザU2のゲーム結果情報を取得する度に評価した第1のユーザの暫定ゲーム評価(「勝ち」、「負け」、「勝ち」)、及び、T14時点のゲーム評価結果(バトル結果)の「勝ち」に基づいて、記憶部に記憶された複数の異なる動画像データの中から、第1の動画像データを選択する。
つまり、図31に示すように、ユーザU1とユーザU2との勝敗が「勝ち」→「負け」→「勝ち」で最終的にユーザU1が勝った場合、ユーザU1のキャラクタCA1が一旦負けそうになって勝利するキャラクタ動画像を生成することが望ましい。つまり、ユーザU1のゲーム評価結果は、T14時点で「勝ち」であるが、一旦、相手ユーザU2よりもスコアが低く負けている状態があったことをキャラクタ動画像に反映することが好ましい。
そこで、本実施形態では、例えば、「勝ち」の動画像データのうち予め動画像データ51〜60を、「勝ち」→「負け」→「勝ち」の変化のある動画像データ群とし、サーバは、動画像データ51〜60の中から一の動画像データ(例えば、動画像データ51)を選択し、選択された動画像データを用いてユーザU1のキャラクタCA1を含むキャラクタ動画像を生成する。例えば、図32に示すように、一旦、キャラクタCA1が相手キャラクタCA2に負けそうになるが、最終的に勝利するような動画像を生成する。
一方、第2のユーザのキャラクタ動画像を生成する場合には、第1のユーザU1、第2のユーザU2のゲーム結果情報を取得する度に評価した第2のユーザの暫定ゲーム評価(「負け」、「勝ち」、「負け」)及び、T14時点のゲーム評価結果(バトル結果情報)の「負け」に基づいて、記憶部に記憶された複数の異なる動画像データの中から、第2の動画像データを選択する。
つまり、図31に示すように、ユーザU2が、「負け」→「勝ち」→「負け」で、最終的にユーザU2が負けた場合には、ユーザU2のキャラクタCA2が一旦勝ちそうになるが、結果的に負けるようなキャラクタ動画像を生成することが望ましい。つまり、ユーザU2のゲーム評価結果はT14時点で「負け」であるが、一旦、相手ユーザU1よりも優勢状態があったことをキャラクタ動画像に反映することが好ましい。
そこで、本実施形態では、「負け」の動画像データ101〜200のうち予め動画像データ151〜160を、「負け」→「勝ち」→「負け」の変化のある動画像データ群とし、サーバは、動画像データ151〜160の中から一の動画像データ(例えば、動画像データ151)を選択し、選択された動画像データを用いてユーザU2のキャラクタCA2を含むキャラクタ動画像を生成する。例えば、図33に示すように、一旦、キャラクタCA2が相手キャラクタCA1に攻撃しかけるが、負けてしまう動画像を生成する。
このようにすれば、ユーザU1、U2は、各ゲーム結果情報の変化(例えば、優勢になったり、劣勢になったり等)をイメージしたキャラクタ動画像を生成することができる。
なお、本実施形態では、複数の動画像データを組み合わせて1つの動画像データを生成してもよい。例えば、ユーザU1の暫定ゲーム評価結果毎に複数の動画像データの中から一の動画像データを選択する。そして、各暫定ゲーム評価結果の動画像データを組み合わせた動画像データに基づいて、ユーザU1のキャラクタCA1を含むキャラクタ動画像を生成してもよい。
具体的には、図31に示すように、ユーザU1の第1の暫定ゲーム評価(T11時点の暫定ゲーム評価)で「勝ち」である場合には、記憶部に記憶された複数の異なる動画像データ1〜300のうち、「勝ち」の複数の異なる動画像データ1〜100中から、一の動画像データを選択する。そして、ユーザU1の第2の暫定ゲーム評価(T12時点の暫定ゲーム評価)で「負け」である場合には、記憶部に記憶された複数の異なる動画像データ1〜300のうち、「負け」の複数の異なる動画像データ101〜200中から、一の動画像データを選択する。そして、ユーザU1の第3の暫定ゲーム評価(T13時点の暫定ゲーム評価)で「勝ち」である場合には、記憶部に記憶された複数の異なる動画像データ1〜300のうち、「勝ち」の複数の異なる動画像データ1〜100中から、一の動画像データを選択する。そして、第1、第2、第3の各暫定ゲーム評価に基づき選択された複数の動画像データを組み合わせ、組み合わせた動画像データを用いて、ユーザU1のキャラクタCA1を含むキャラクタ動画像を生成する処理を行う。
4−8.ユーザのアイテムを含む動画像を生成する処理の説明
本実施形態のサーバは、選択された動画像データを用いてユーザのキャラクタと、記憶部に記憶されたユーザのアイテム(ユーザ識別情報に対応付けられたアイテム)とを含むキャラクタ動画像を生成するようにしてもよい。
図28に示すように、ユーザ識別情報310に対応づけて、キャラクタ391とアイテム392を記憶部に記憶させておく。
そして、図34に示すように、本実施形態のサーバは、ユーザU1の端末から、ユーザ識別情報とキャラクタ動画像要求データとを受信すると、複数の異なる動画像データの中から動画像データを選択し、選択された動画像データを用いて、当該ユーザU1のユーザ識別情報に対応するキャラクタCA1と、アイテムIT1とを含むキャラクタ動画像を生成する。そして、サーバは、ユーザU1の端末に、キャラクタCA1とアイテムIT1とを含むキャラクタ動画像を送信する。
例えば、ユーザU1の勝敗データが「勝ち」である場合には、記憶部に記憶された複数の異なる動画像データ1〜300のうち、「勝ち」の複数の異なる動画像データ1〜100中から、一の動画像データ(例えば、動画像データ1)を選択する。そして、図34に示すように、選択された動画像データを用いて、当該ユーザU1のユーザ識別情報に対応するキャラクタCA1と、アイテムIT1とを含むキャラクタ動画像を生成する。
一方、ユーザU2の勝敗データが「負け」である場合には、記憶部に記憶された複数の異なる動画像データ1〜300のうち、「負け」の複数の異なる動画像データ101〜200中から、一の動画像データ(例えば、動画像データ101)を選択する。そして、図35に示すように、選択された動画像データを用いて、当該ユーザU2のユーザ識別情報に対応するキャラクタCA2と、アイテムIT2とを含むキャラクタ動画像を生成する。
このように本実施形態では、キャラクタと、アイテムが登場するキャラクタ動画像を生成するので、ユーザ毎にそのユーザに適したオリジナリティ溢れるキャラクタ動画像を生成することができる。
4−9.フローチャート
本実施形態のサーバにおいてキャラクタの動画像を生成する処理の流れを、図36を用いて説明する。
まず、ユーザの端末からキャラクタ動画像要求データを受信する(ステップS201)。次に、当該ユーザのゲーム評価結果情報に基づいて、動画像データを選択する処理を行う(ステップS202)。そして、選択された動画像データを用いて当該ユーザのキャラクタを含むキャラクタ動画像を生成する(ステップS203)。そして、ユーザ端末に生成されたキャラクタ動画像を送信する処理を行う(ステップS204)。以上で処理が終了する。
4−10.キャラクタの動画像を生成する処理の応用例
本実施形態では、ユーザのゲーム情報を取得し、そのユーザのゲーム情報に基づいて、ユーザのゲーム評価を行うゲームに応用してもよい。例えば、ゲーム情報に基づいてユーザのゲーム評価を行った当該ユーザのゲーム評価結果情報に基づいて、複数の異なる動画像データの中から動画像データを選択し、選択された動画像データを用いてキャラクタ動画像を生成するようにしてもよい。そして、ユーザのゲーム評価結果情報を端末の表示部に表示させ、ゲーム評価結果情報を表示した後に、キャラクタ動画像を表示させるようにしてもよい。
ここで、ゲーム情報とは、ゲームのプレイ中で得られる情報や、ゲームのゲーム終了後に得られるユーザのゲーム結果情報も含む。また、ゲーム情報は、ユーザの端末において入力された入力情報、ユーザ識別情報に関連付けられたキャラクタのレベル情報や、アイテム情報、ゲーム結果情報を含む。
また、サーバは、ユーザのゲーム情報に基づいて、ユーザが所定の入力を行うことができたか否かのゲーム評価を行うようにしてもよい。言い換えると、サーバは、ユーザの端末から取得した入力情報が所定情報であるか否かを判定するゲーム評価を行うようにしてもよい。例えば、ユーザが所定の入力を行うことができた場合「成功」と評価し、ユーザが所定の入力を行うことができない場合「失敗」と評価する。
また、サーバは、ユーザが所定のゲーム結果を出現させることができたか否かのゲーム評価を行うようにしてもよい。例えば、ユーザが所定のゲーム結果を出現させることができた場合「成功」と評価し、ユーザが所定のゲーム結果を出現させることができない場合「失敗」と評価する。
そして、サーバは、ゲーム評価結果情報に基づいて、複数の異なる動画像データの中から動画像データを選択し、選択された動画像データを用いてキャラクタ動画像を生成するようにしてもよい。
例えば、ユーザのゲーム評価結果情報が第1の評価(例えば、「成功」等)の場合には、複数の動画データからなる第1の動画データ群から、一の動画データを選択し、選択された動画像データを用いてキャラクタ動画像を生成する。一方、ユーザのゲーム評価結果情報が第2の評価(例えば、「失敗」等)の場合には、複数の動画データからなる第2の動画データ群から、一の動画データを選択し、選択された動画像データを用いてキャラクタ動画像を生成する。
4−11.特別用のキャラクタ動画像
本実施形態では、第1のユーザが第2のユーザに対してゲームへ参加するよう勧誘を行い、第2のユーザが第1のユーザの勧誘にしたがってゲームへ参加した場合には、第1のユーザに対して、第1のユーザのキャラクタを含む特別用のキャラクタ動画像を生成するようにしてもよい。また、本実施形態では、第1のユーザが第2のユーザに対してゲームへ参加するよう勧誘を行い、第2のユーザが第1のユーザの勧誘にしたがってゲームへ参加した場合には、第2のユーザに対して、第2のユーザのキャラクタを含む特別用のキャラクタ動画像を生成するようにしてもよい。
このようにすれば、第2のユーザがゲームへ参加することにより、第1のユーザは、第1のユーザのキャラクタを含む特別用のキャラクタ動画像を見ることができる。つまり、第1のユーザに対して、勧誘活動を行わせる動機を与えることができる。また、第2のユーザがゲームへ参加することにより、第2のユーザは、第2のユーザのキャラクタを含む特別用のキャラクタ動画像を見ることができる。つまり、第2のユーザに対してゲームへ参加させる動機を与えることができる。
具体的に説明すると、本実施形態のサーバは、第1のユーザの端末からゲームへの参加を勧誘する第2のユーザが指定された情報(勧誘情報)を取得する。なお、第1のユーザ端末又はサーバは、第1のユーザの端末からゲームへの参加を勧誘する第2のユーザが指定された情報(勧誘情報)を、第2のユーザ端末に送信するようにしてもよい。
また、本実施形態のサーバは、所与のユーザの端末からゲームに新たに参加することを示す情報(参加情報)を取得する。
そして、サーバは、第1のユーザの端末からゲームへの参加を勧誘する第2のユーザが指定された情報(勧誘情報)と、所与のユーザの端末からゲームに新たに参加することを示す情報(参加情報)とに基づいて、ゲームに新たに参加するユーザが、第1のユーザが勧誘した第2のユーザであるか否かを判定し、ゲームに参加する新たなユーザが、第1のユーザが勧誘した第2のユーザである場合に、第1のユーザに対して、第1のユーザのキャラクタを含む特別用のキャラクタ動画像を生成する処理を行う。また、サーバは、ゲームに参加する新たなユーザが、第1のユーザが勧誘した第2のユーザである場合に、第2のユーザに対して、第2のユーザのキャラクタを含む特別用のキャラクタ動画像を生成する処理を行う。
例えば、本実施形態では、複数の動画像データからなる通常動画像データ群(例えば、図29に示す動画像データ1〜300)と、複数の画像データからなる特別動画像データ群(図示しない、動画像データ301〜600)とを記憶部に記憶させておく。なお、特別動画像データ群301〜600は、ゲーム評価結果に対応づけて記憶されている。例えば、ゲーム評価結果の「勝ち」に対応する特別動画像データ301〜400、ゲーム評価結果の「負け」に対応する特別動画像データ401〜500、ゲーム評価結果の「引き分け」に対応する特別動画像データ501〜600に対応づけて記憶されている。
そして、ユーザU1のゲーム評価結果に基づいてサーバが特別用のキャラクタ動画像を生成する場合には、ユーザU1のゲーム評価結果に基づいて当該特別動画像データ群から特別動画像データを選択し、選択された特別動画像データを用いて、ユーザU1のキャラクタCA1を含むキャラクタ動画像を生成する。
一方、サーバが、ユーザU1のゲーム評価結果に基づいて通常のキャラクタ動画像を生成する場合には、ユーザU1のゲーム評価結果に基づいて通常動画像データ群(動画像データ1〜300)から通常動画像データを選択し、選択された通常動画像データを用いて、ユーザU1のキャラクタCA1を含むキャラクタ動画像を生成する。
なお、第1のユーザが第2のユーザにゲームへ勧誘(招待)し、第2のユーザが第1のユーザの勧誘に応じて参加した場合であって、第1、第2のユーザが初めてバトル(ゲーム評価)を行う場合には、特別状態であることを示す特別状態フラグを1に設定し、特別用のキャラクタ動画像を生成する。そして、当該第1のユーザと当該第2のユーザとが2回目以降のバトル(ゲーム評価)を行う場合には、特別状態フラグを0に設定(更新)し、通常のキャラクタ動画像を生成する。
4−12.その他
本実施形態では、ゲーム装置40(ゲーム装置40のゲーム演算部)が、ユーザからの入力部の入力情報に基づいて、ゲーム演算を行っているが、サーバ、又は端末がゲーム演算を行うようにしてもよい。例えば、端末10の入力部からの入力情報をサーバ20に送信してサーバ20の処理部200がゲーム演算を行うようにしてもよい。また、本実施端末10の入力部からの入力情報に基づいて端末10の処理部100がゲーム演算を行うようにしてもよい。
また、本実施形態ではゲームシステム(端末)に応用してもよい。つまり、動画像を生成する処理を行うゲームシステムであって、ゲーム終了後に得られるユーザのゲーム結果情報を取得し、ユーザの前記ゲーム結果情報に基づいて、ユーザのゲーム評価を行うゲームシステムに応用してもよい。例えば、ゲームシステムが、記憶部に記憶された複数の異なる動画像データの中から、ゲーム評価結果情報に基づいて動画像データを選択し、選択された動画像データを用いてユーザのキャラクタを含むキャラクタ動画像を生成する処理を行い、ゲーム評価結果情報を表示した後に、キャラクタ動画像を表示させるようにしてもよい。
なお、本実施形態では、ゲーム装置20のゲームプレイ中に表示される動画像とは異なるキャラクタ動画像を生成しているが、ゲームプレイ中に表示される動画像と同じような画像を生成するようにしてもよい。
5.応用例
本実施形態では、音楽ゲームに限らず、レースゲーム、アクションゲーム、格闘ゲーム、ロールプレイングゲームなど、種々のゲームに応用することができる。つまり、本実施形態では、複数のユーザによる対戦が可能な他のゲームに応用してもよい。
また、本実施形態では、ゲーム装置40の表示部に表示されるゲーム結果情報(QRコード、ひらがなパスワード)を端末10に入力し、端末10からサーバ20にゲーム結果情報を送信する例について説明したが、ゲーム装置40がネットワーク30に接続されており、ユーザがユーザ識別情報を記憶したカードをゲーム装置40に挿入してゲームをプレイし、ゲーム終了後にゲーム装置40からサーバ20にゲーム結果情報を送信するように構成してもよい。あるいは、ユーザが、ゲーム装置40の代わりにゲームプログラムがダウンロードされた端末10でゲームをプレイし、ゲーム終了後に端末10からサーバ20にゲーム結果情報を送信するように構成してもよい。
なお、本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語として引用された用語は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。
本発明は、実施の形態で説明した構成と実質的に同一の構成(例えば、機能、方法及び結果が同一の構成、あるいは目的及び効果が同一の構成)を含む。また、本発明は、実施の形態で説明した構成の本質的でない部分を置き換えた構成を含む。また、本発明は、実施の形態で説明した構成と同一の作用効果を奏する構成又は同一の目的を達成することができる構成を含む。また、本発明は、実施の形態で説明した構成に公知技術を付加した構成を含む。