以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
1.ゲームシステム
図1は、本実施形態のゲームシステム(シミュレーションシステム、シミュレータ)の構成例を示すブロック図である。本実施形態のゲームシステムは、例えばバーチャルリアリティ(VR)をシミュレートするシステムに適用できる。なお、本実施形態のゲームシステムは図1の構成に限定されず、その構成要素(各部)の一部(例えば仮想空間設定部、仮想カメラ制御部等)を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
操作部160は、ユーザ(プレーヤ)が種々の操作情報(入力情報)を入力するためのものである。操作部160は、例えば操作ボタン、方向指示キー、ジョイスティック、ハンドル、ペダル又はレバー等の種々の操作デバイスにより実現できる。
記憶部170は各種の情報を記憶する。記憶部170は、処理部100や通信部196などのワーク領域として機能する。ゲームプログラムや、ゲームプログラムの実行に必要なゲームデータは、この記憶部170に保持される。記憶部170の機能は、半導体メモリ(DRAM、VRAM)、HDD(ハードディスクドライブ)、SSD、光ディスク装置などにより実現できる。記憶部170は、オブジェクト情報記憶部172、キャラクタ情報記憶部174、会話情報記憶部175、メニュー情報記憶部176、描画バッファ178を含む。
情報記憶媒体180(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(DVD、BD、CD)、HDD、或いは半導体メモリ(ROM)などにより実現できる。処理部100は、情報記憶媒体180に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体180には、本実施形態の各部としてコンピュータ(入力装置、処理部、記憶部、出力部を備える装置)を機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)が記憶される。
表示部190は、本実施形態により生成された画像を出力するものであり、その機能は、後述する図2のHMD(頭部装着型表示装置)、LCD、有機ELディスプレイ、或いはCRTなどにより実現できる。音出力部192は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
I/F(インターフェース)部194は、携帯型情報記憶媒体195とのインターフェース処理を行うものであり、その機能はI/F処理用のASICなどにより実現できる。携帯型情報記憶媒体195は、ユーザが各種の情報を保存するためのものであり、電源が非供給になった場合にもこれらの情報の記憶を保持する記憶装置である。携帯型情報記憶媒体195は、ICカード(メモリカード)、USBメモリ、或いは磁気カードなどにより実現できる。
通信部196(通信インターフェース)は、有線や無線のネットワークを介して外部(他の装置)との間で通信を行うものであり、その機能は、通信用ASIC又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。
なお本実施形態の各部としてコンピュータを機能させるためのプログラム(データ)は、サーバ(ホスト装置)が有する情報記憶媒体からネットワーク及び通信部196を介して情報記憶媒体180(あるいは記憶部170)に配信してもよい。このようなサーバ(ホスト装置)による情報記憶媒体の使用も本発明の範囲内に含めることができる。
処理部100(プロセッサ)は、操作部160からの操作情報や、後述する図2のHMD200(頭部装着型表示装置)でのトラッキング情報(HMDの位置及び方向の少なくとも一方の情報。視点位置及び視線方向の少なくとも一方の情報)や、プログラムなどに基づいて、キャラクタ処理、提示処理、仮想空間設定処理、仮想カメラ制御処理、ゲーム処理、表示処理、或いは音処理などを行う。
処理部100の各部が行う本実施形態の各処理(各機能)はプロセッサ(ハードウェアを含むプロセッサ)により実現できる。例えば本実施形態の各処理は、プログラム等の情報に基づき動作するプロセッサと、プログラム等の情報を記憶するメモリにより実現できる。プロセッサは、例えば各部の機能が個別のハードウェアで実現されてもよいし、或いは各部の機能が一体のハードウェアで実現されてもよい。例えば、プロセッサはハードウェアを含み、そのハードウェアは、デジタル信号を処理する回路及びアナログ信号を処理する回路の少なくとも一方を含むことができる。例えば、プロセッサは、回路基板に実装された1又は複数の回路装置(例えばIC等)や、1又は複数の回路素子(例えば抵抗、キャパシター等)で構成することもできる。プロセッサは、例えばCPU(Central Processing Unit)であってもよい。但し、プロセッサはCPUに限定されるものではなく、GPU(Graphics Processing Unit)、或いはDSP(Digital Signal Processor)等、各種のプロセッサを用いることが可能である。またプロセッサはASICによるハードウェア回路であってもよい。またプロセッサは、アナログ信号を処理するアンプ回路やフィルター回路等を含んでもよい。メモリ(記憶部170)は、SRAM、DRAM等の半導体メモリであってもよいし、レジスターであってもよい。或いはハードディスク装置(HDD)等の磁気記憶装置であってもよいし、光学ディスク装置等の光学式記憶装置であってもよい。例えば、メモリはコンピュータにより読み取り可能な命令を格納しており、当該命令がプロセッサにより実行されることで、処理部100の各部の処理(機能)が実現されることになる。ここでの命令は、プログラムを構成する命令セットでもよいし、プロセッサのハードウェア回路に対して動作を指示する命令であってもよい。
処理部100は、入力処理部102、演算処理部110、出力処理部140を含む。演算処理部110は、キャラクタ処理部112、提示処理部114、仮想空間設定部116、仮想カメラ制御部117、ゲーム処理部11、表示処理部120、音処理部130を含む。上述したように、これらの各部により実行される本実施形態の各処理は、プロセッサ(或いはプロセッサ及びメモリ)により実現できる。なお、これらの構成要素(各部)の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
入力処理部102は、操作情報やトラッキング情報を受け付ける処理や、記憶部170から情報を読み出す処理や、通信部196を介して情報を受信する処理を、入力処理として行う。例えば入力処理部102は、操作部160を用いてユーザが入力した操作情報やHMDのセンサ部等により検出されたトラッキング情報を取得する処理や、読み出し命令で指定された情報を、記憶部170から読み出す処理や、外部装置(サーバ等)からネットワークを介して情報を受信する処理を、入力処理として行う。ここで受信処理は、通信部196に情報の受信を指示したり、通信部196が受信した情報を取得して記憶部170に書き込む処理などである。
演算処理部110は、各種の演算処理を行う。例えばキャラクタ処理、提示処理、仮想空間設定処理、仮想カメラ制御処理、ゲーム処理(シミュレーション処理)、表示処理、或いは音処理などの演算処理を行う。
キャラクタ処理部112(キャラクタ処理のプログラムモジュール)はキャラクタについての種々の処理を行う。提示処理部114(提示処理のプログラムモジュール)は、注文対象の提示処理などの種々の処理を行う。キャラクタ処理部112、提示処理部114の詳細については後述する。
仮想空間設定部116(仮想空間設定処理のプログラムモジュール)は、複数のオブジェクトが配置される仮想空間(オブジェクト空間)の設定処理を行う。例えば、キャラクタ(人、ロボット、モンスター又は動物等)、マップ(地形)、建物、観客席、コース(道路)、樹木、壁、水面などの表示物を表す各種オブジェクト(ポリゴン、自由曲面又はサブディビジョンサーフェイスなどのプリミティブ面で構成されるオブジェクト)を仮想空間に配置設定する処理を行う。即ちワールド座標系でのオブジェクトの位置や回転角度(向き、方向と同義)を決定し、その位置(X、Y、Z)にその回転角度(X、Y、Z軸回りでの回転角度)でオブジェクトを配置する。具体的には、記憶部170のオブジェクト情報記憶部172には、仮想空間でのオブジェクト(パーツオブジェクト)の位置、回転角度、移動速度、移動方向等の情報であるオブジェクト情報がオブジェクト番号に対応づけて記憶される。仮想空間設定部116は、例えば各フレーム毎にこのオブジェクト情報を更新する処理などを行う。
仮想カメラ制御部117は、ユーザの視点に対応する仮想カメラの制御処理を行う。例えば仮想カメラ制御部117は、ユーザの一人称視点として設定される仮想カメラの制御を行う。例えば実空間のユーザに対応する仮想空間の仮想ユーザの視点に対応する位置に、仮想カメラを設定して、仮想カメラの視点位置や視線方向を設定することで、仮想カメラの位置(位置座標)や姿勢(回転軸回りでの回転角度)を制御する。そして表示処理部120は、表示部190(HMD等)の表示画像(表示映像)として、仮想空間において仮想カメラ(ユーザ視点)から見える画像を生成する。例えば仮想空間であるオブジェクト空間において所与の視点から見える画像を生成する。生成される画像は例えば立体視用の画像である。
ゲーム処理部118(ゲーム処理のプログラムモジュール)はユーザがゲームをプレイするための種々のゲーム処理を行う。別の言い方をすれば、ゲーム処理部118(シミュレーション処理部)は、ユーザが仮想現実(バーチャルリアリティ)を体験するための種々のシミュレーション処理を実行する。ゲーム処理は、例えば、ゲーム開始条件が満たされた場合にゲームを開始する処理、開始したゲームを進行させる処理、ゲーム終了条件が満たされた場合にゲームを終了する処理、或いはゲーム成績を演算する処理などである。
表示処理部120(表示処理のプログラムモジュール)は、ゲーム画像(シミュレーション画像)の表示処理を行う。例えば処理部100で行われる種々の処理(ゲーム処理、シミュレーション処理)の結果に基づいて描画処理を行い、これにより画像を生成し、表示部190に表示する。具体的には、座標変換(ワールド座標変換、カメラ座標変換)、クリッピング処理、透視変換、或いは光源処理等のジオメトリ処理が行われ、その処理結果に基づいて、描画データ(プリミティブ面の頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等)が作成される。そして、この描画データ(プリミティブ面データ)に基づいて、透視変換後(ジオメトリ処理後)のオブジェクト(1又は複数プリミティブ面)を、描画バッファ178(フレームバッファ、ワークバッファ等のピクセル単位で画像情報を記憶できるバッファ)に描画する。これにより、オブジェクト空間(仮想空間)において仮想カメラ(所与の視点。左目用、右目用の第1、第2の視点)から見える画像が生成される。なお、表示処理部120で行われる描画処理は、頂点シェーダ処理やピクセルシェーダ処理等により実現することができる。
音処理部130(音処理のプログラムモジュール)は、処理部100で行われる種々の処理の結果に基づいて音処理を行う。具体的には、楽曲(音楽、BGM)、効果音、又は音声などのゲーム音を生成し、ゲーム音を音出力部192に出力させる。
出力処理部140は各種の情報の出力処理を行う。例えば出力処理部140は、記憶部170に情報を書き込む処理や、通信部196を介して情報を送信する処理を、出力処理として行う。例えば出力処理部140は、書き込み命令で指定された情報を、記憶部170に書き込む処理や、外部の装置(サーバ等)に対してネットワークを介して情報を送信する処理を行う。送信処理は、通信部196に情報の送信を指示したり、送信する情報を通信部196に指示する処理などである。
そして本実施形態のゲームシステムは、図1に示すようにキャラクタ処理部112と記憶部170と提示処理部114を含む。
キャラクタ処理部112はキャラクタを動作(行動)させる処理を行う。具体的にはゲーム空間においてキャラクタを動作させたり移動させる処理を行う。例えばキャラクタ処理部112は、記憶部170のキャラクタ情報記憶部174に記憶されるキャラクタ情報に基づいて、ゲーム空間においてキャラクタを行動させるための種々の処理を行う。例えばキャラクタが仮想空間に登場するオブジェクトである場合には、キャラクタ処理部112は、仮想空間に登場するキャラクタ(移動体)についての種々の処理を行う。例えばキャラクタ処理部112は、操作部160によりユーザが入力した操作情報や、取得されたトラッキング情報や、プログラム(移動・動作アルゴリズム)や、各種データ(モーションデータ)などに基づいて、キャラクタ(モデルオブジェクト)を仮想空間内で移動させたり、キャラクタを動作(モーション、アニメーション)させる制御処理を行う。具体的には、キャラクタの移動情報(位置、回転角度、速度、或いは加速度)や動作情報(パーツオブジェクトの位置、或いは回転角度)を、1フレーム(例えば1/60秒)毎に順次求めるシミュレーション処理を行う。なおフレームは、キャラクタの移動・動作処理(シミュレーション処理)や画像生成処理を行う時間の単位である。
またキャラクタ処理部112は、キャラクタとユーザの対話処理を行う。例えばキャラクタがユーザに対して会話(質問)するための種々の処理を行う。具体的には、キャラクタ処理部112は、記憶部170の会話情報記憶部175に記憶されるキャラクタの会話情報(質問情報)に基づいて、キャラクタの発話の音声を音出力部192に出力させたり、キャラクタの会話内容を表示部190に表示させる処理を行う。またキャラクタの会話情報であるシナリオ情報に基づいて、各種のシナリオに応じた会話の分岐処理を行う。
記憶部170は、注文対象のリストであるメニューの情報を記憶する。具体的にはメニュー情報記憶部176が、メニューの情報をキャラクタに対応づけて記憶する。例えばキャラクタ情報記憶部174には、ゲームに登場する複数のキャラクタについてのキャラクタ情報が記憶されている。メニュー情報記憶部176(広義には記憶部)は、これらの複数のキャラクタの各キャラクタに対応づけてメニュー情報を記憶する。メニューには、複数の注文対象がリスト形式で対応づけられている。このメニューは、表示物としてユーザに表示されるものであってもよく、この場合には複数の注文対象がメニューに表示される画像がユーザに表示される。
注文対象は、例えばユーザが購入する商品である。注文対象である商品としては、食べ物、衣服、装飾品、靴、玩具、ゲーム関連商品、家電製品、カメラ等の映像機器、スマートフォン等の携帯通信端末、パーソナルコンピュータ、時計、本、家具、キッチン用品、インテリア用品、食品、CD、DVD、スポーツ関連商品、アウトドア関連商品、生活雑貨関連商品、或いは住宅関連商品などの種々の商品を想定できる。また注文対象は、ユーザに提供されるサービス(役務)であってもよい。例えば注文対象であるサービスとしては、宿泊等の旅行関連のサービス、アミューズメントやホビー関連のサービス、保険関連のサービス、食品関連のサービス、催し関連のサービス、美容やヘルス関連のサービス、住宅関連のサービス、引っ越し関連のサービス、或いはスポーツ関連のサービスなどの種々のサービスを想定できる。また注文対象は、実空間の商品やサービスには限定されず、仮想空間(ゲーム空間、ネットワーク)での仮想的な商品、サービスであってもよい。このような仮想空間の注文対象としては、ゲームのアイテム、ゲームに登場するキャラクタ、ゲームカード等のゲーム媒体、或いは仮想空間でのVR体験のサービスなどの種々のものを想定できる。
提示処理部114は、注文対象について提示処理を行う。例えば提示処理部114は、キャラクタが行った質問に対するユーザの回答を受け付ける。そしてユーザの回答結果に基づき決定された注文対象を、キャラクタを用いてユーザに提示するための処理を行う。例えばユーザの回答結果に基づき決定された注文対象(お勧めの注文対象)を、キャラクタがユーザに対して提示するための処理を行う。例えばキャラクタが会話を行うことで、決定された注文対象をユーザに提示する。ユーザに提示する注文対象の決定処理は、注文対象決定部115が行う。
具体的には本実施形態では、ゲーム空間(仮想空間)に第1、第2のキャラクタを含む複数のキャラクタが登場する。そして提示処理部114は、第1のキャラクタが行った質問に対するユーザの回答や、第2のキャラクタが行った質問に対するユーザの回答を受け付ける。そして提示処理部114は、第1のキャラクタが行った質問に対するユーザの回答結果及び第2のキャラクタが行った質問に対するユーザの回答結果の少なくとも一方に基づいて、第1のキャラクタに対応するメニューと第2のキャラクタに対応するメニューの少なくとも一方のメニューの中から、ユーザに対して提示する注文対象を決定する処理を行う。例えば第1のキャラクタが行った質問に対するユーザの回答結果と、第2のキャラクタが行った質問に対するユーザの回答結果の両方に基づいて、ユーザに対して提示する注文対象を決定する。或いは、第1のキャラクタが行った質問に対するユーザの回答結果と、第2のキャラクタが行った質問に対するユーザの回答結果の一方に基づいて、ユーザに対して提示する注文対象を決定してもよい。例えば第1、第2のキャラクタの一方のキャラクタのみがユーザに対して質問し、当該質問に対するユーザの回答結果に基づいて、第1のキャラクタに対応するメニューと第2のキャラクタに対応するメニューのいずれかから、ユーザに対して提示する注文対象を決定してもよい。そして提示処理部114は、決定された注文対象を、キャラクタを用いてユーザに提示するための処理を行う。なお第1のキャラクタに対応するメニューと第2のキャラクタに対応するメニューは違ったメニューである必要は無く、例えば一部においてリストされる注文対象が共通であってもよい。例えば第1のキャラクタに対応するメニューと第2のキャラクタに対応するメニューの一方のメニューから、ユーザに対して提示する注文対象を決定してもよいし、両方のメニューから、ユーザに対して提示する注文対象を決定してもよい。
ユーザは、例えば音声により、質問に対する回答を入力してもよいし、操作部160のキー入力やタッチパネルのタッチ操作などにより、回答を入力してもよい。音声で回答が入力された場合には、提示処理部114は、例えば回答の会話の音声認識処理を行い、例えば回答の会話内容をテキストデータ等の会話データとして取得する。例えばユーザの音声から音響モデルに基づき音素列を抽出し、音素列から単語候補を推定する。そして推定された単語候補から言語モデルに基づいて音声の会話内容の認識処理を行って、回答の会話データを取得する。キー入力やタッチ操作により回答が入力された場合には、キー入力やタッチ操作の操作情報に基づいて、回答の会話データを取得する。そして提示処理部114は、取得された回答の会話データに基づいて、キャラクタが行った質問に対するユーザの回答結果を判断する。この場合に例えば質問に対する回答を、複数の選択肢として用意しておき、ユーザがどの選択肢を回答として選択したかを判断することで、質問に対するユーザの回答結果を判断してもよい。こうすることで、より簡素な処理で、質問に対するユーザの回答結果を判断できる。
そして提示処理部114は、このようにして判断されたユーザの回答結果に基づいて、例えば複数の注文対象のリストであるメニューの中から、ユーザに提示する注文対象を決定する。例えば、ユーザへのお勧めの注文対象を決定する。そして、決定された注文対象を、キャラクタを用いてユーザに提示する。この注文対象の提示は、キャラクタの音声による会話により行ってもよいし、表示部190に注文対象を表示することで提示してもよい。例えば、ユーザへのお勧めの注文対象を、キャラクタが音声の会話により喋ったり、お勧めの注文対象の文字等が表示された吹き出し形式の画像等を表示部190に表示する。
またユーザに提示する注文対象(お勧めの注文対象)の決定処理としては種々の処理を想定できる。例えばメニューは第1~第Mの注文対象(Mは2以上の整数)のリストとなっている。そしてキャラクタはユーザに対して第1~第N(Nは2以上の整数)の質問を行う。そして第1~第Nの質問の各質問に対して、ユーザがどのような回答を行ったかに応じて、メニューの第1~第Mの注文対象の各注文対象に対して重み付けポイントを付与する。一例としては、第1~第Nの質問の各質問に対して複数の選択肢が用意されており、質問に対する回答として、ユーザがどの選択肢を選択したかに応じて、メニューの第1~第Mの注文対象の各注文対象に対して重み付けポイントを付与する。そしてキャラクタによる第1~第Nの質問が終了すると、第1~第Mの注文対象の各注文対象について、重み付けポイントの合算値を求め、求められた合算値に基づいて、第1~第Mの注文対象の中から、ユーザに提示する注文対象(お勧めの注文対象)を決定して、ユーザに提示する。但し、ユーザに提示する注文対象の決定処理は、上記のような処理に限定されず、種々の変形実施が可能である。例えば第1~第Nの質問に対するユーザの回答を入力とするテーブル、或いは、当該回答を入力とする所定の関数を用意して、当該テーブル又は関数に基づいて、ユーザに提示する注文対象を決定してもよい。例えばユーザに提示する注文対象の決定処理は、キャラクタの第1~第Nの質問に対するユーザの回答が同じであれば、同じ注文対象が一意に決定されるような処理である。
また提示処理部114は、ユーザの回答結果と、キャラクタに対するユーザの愛着度情報とに基づき、ユーザに提示する注文対象の決定処理を行う。例えば、ユーザの回答結果と、第1、第2のキャラクタに対するユーザの愛着度情報とに基づき、ユーザに提示する注文対象の決定処理を行う。例えばユーザが質問に対して回答した場合に、その回答結果に基づいて、第1、第2のキャラクタに対応するメニューのうち、愛着度が高いキャラクタに対応するメニューの中から、ユーザに提示する注文対象を決定する。また例えば上述の重み付けポイントの演算の際にキャラクタの愛着度情報を用いてもよい。
愛着度情報は、例えばキャラクタに対するユーザの愛着度の度合いを表すパラメータであり、愛着度の指標となるパラメータである。例えば愛着度情報は、ユーザが種々の操作や種々の行動を行うことで変化するキャラクタの特定のパラメータということができる。例えば下述するように、ユーザが、そのキャラクタを推しキャラクタとして選択したり、そのキャラクタを注視するような操作や行動を行うことで、当該キャラクタの愛着度に対応するパラメータが変化する。また、ユーザが、そのキャラクタと会うために実店舗や仮想店舗に来店したり、そのキャラクタのために課金アイテムを購入するなどして課金に対して対価を支払うと、当該キャラクタの愛着度に対応するパラメータが変化する。またユーザの位置が、そのキャラクタの位置に近づいたり、そのキャラクタのキャンペーン期間や、そのキャラクタ用の特別の日や特別の時間帯になると、当該キャラクタの愛着度に対応するパラメータが変化する。愛着度情報は、このようなユーザの操作や行動で変化するパラメータである。また愛着度情報は、ゲームパラメータの1つである愛着度パラメータとして、キャラクタ処理部112、提示処理部114、或いはゲーム処理部118の各処理に使用される。この愛着度情報は例えばキャラクタに対応づけて記憶部170に記憶される。例えば複数のキャラクタが登場する場合に、複数のキャラクタの各キャラクタに対するユーザの愛着度情報が記憶部170に記憶される。例えば第1のキャラクタに対するユーザの愛着度情報と第2のキャラクタに対するユーザの愛着度情報が記憶部170に記憶される。例えば愛着度情報はキャラクタに対応づけてキャラクタ情報としてキャラクタ情報記憶部174に記憶される。或いは複数のキャラクタの各キャラクタに対する愛着度情報を、ユーザ情報として記憶部170に記憶してもよい。
例えば複数のキャラクタの中からユーザが推しキャラクタを選択すると、提示処理部114は、その推しキャラクタの愛着度を増加させる処理を行う。例えば第1、第2のキャラクタのうちの一方のキャラクタが推しキャラクタとして選択されると、その推しキャラクタの愛着度を増加させる処理を行う。またキャラクタが質問をしている時に、ユーザが、タッチパネルディスプレイにおいてキャラクタをタッチしたり、HMD等によりユーザを注視していたことが検出された場合に、提示処理部114は、当該キャラクタに対する愛着度を増加させる処理を行う。この場合に、タッチ時間、タッチしている場所、注視時間、或いは注視している場所に応じて、愛着度を増加させたり、減少させたり、増加値又は減少値の大きさを制御してもよい。
また提示処理部114は、ユーザの回答結果と愛着度情報に基づき決定される注文対象がメニューの中になかった場合に、注文対象の非存在用の処理を行う。例えばユーザの回答結果とキャラクタの愛着度情報に応じた最適な商品等の注文対象がなかった場合には、特別な処理を行う。例えば注文対象の決定処理において、メニューのリストにある第1~第Mの注文対象の各注文対象に対して、ユーザの回答結果や愛着度情報に応じたポイントを付与する。例えば上記したような重み付けポイントのようなポイントを付与する。そしてキャラクタによる第1~第Nの質問が終了した際に、当該ポイントが所定のしきい値に達していなかった場合には、決定すべき注文対象(最適な注文対象)がメニュー(第1、第2のキャラクタの少なくとも一方のメニュー)の中になかったと判定する。そして提示処理部114は、注文対象の非存在用の処理を行う。
注文対象の非存在用の処理は、決定すべき注文対象がメニューになかった場合のために特別に用意された処理である。例えば注文対象の非存在用の処理としては、以下のような処理が考えられる。例えば注文対象の非存在用の処理は、第1のキャラクタ(例えばユーザの推しキャラクタ)が、第2のキャラクタのメニューの注文対象を選択するように誘導する会話を行わせる処理である。或いは、注文対象の非存在用の処理は、決定すべき注文対象が、推しキャラクタのメニューではなく、別のキャラクタのメニューにあった場合に、そのメニューの中から注文対象を決定する処理(ユーザに選択させる処理)である。この場合の別のキャラクタは、ユーザの目の前に登場していないキャラクタであってもよい。或いは、注文対象の非存在用の処理は、基本のメニューとは別に、ユーザに知らされていない裏メニューがあり、その裏メニューの中から注文対象を決定する処理である。
また提示処理部114は、愛着度情報に応じて、ユーザに対して行う質問を変化させる処理を行う。例えば第1、第2のキャラクタの少なくとも一方がユーザに対して行う質問を、愛着度情報に応じて変化させる。具体的には愛着度情報に応じて、第1、第2のキャラクタの少なくとも一方のキャラクタがユーザに対して行う質問の内容を変化させたり、質問の回数を増加又は減少させたり、質問の態様を変化させる。例えば愛着度が増加すると、それに応じて、キャラクタの質問に対するユーザの回答の選択肢が増えるようにする。或いは愛着度が増加すると、キャラクタの質問回数が増えるようにする。或いは愛着度が増加すると、それに応じて、質問の会話に分岐が追加されるようにする。例えば質問の会話のシナリオを増やす処理を行う。或いは、登場する第1、第2のキャラクタが質問を行う回数を、愛着度に応じて変化させる。例えば第1、第2のキャラクタのうち、ユーザの愛着度が高い方のキャラクタの質問回数を増加させる。
また提示処理部114は、愛着度情報に応じて、ユーザに提示する注文対象又はメニューを変化させる処理を行う。例えば第1、第2のキャラクタの少なくとも一方が提示する注文対象を愛着度情報に応じて変化させたり、第1、第2のキャラクタのメニュー自体を愛着度情報に応じて変化させる。例えばキャラクタに対する愛着度が所定のしきい値を超えたことを条件に出現するような注文対象やメニューを用意する。例えば所定の注文対象については、愛着度が所定のしきい値を超えないと、当該注文対象をキャラクタが提示しないようにする(勧めないようにする)。或いは、愛着度が所与のしきい値を超えると、通常とは異なる特別のメニューを出現させ、この特別のメニューの中から注文対象を決定して、ユーザに提示する。
また提示処理部114は、実店舗又は仮想店舗へのユーザの来店回数に応じて、愛着度情報により表される愛着度を増加させる処理を行う。例えば来店回数が増えるにつれて、当該実店舗又は仮想店舗に登場するキャラクタに対する愛着度を増加させる処理を行う。例えば愛着度を来店回数に応じて段階的に増加させる。例えば実店舗又は仮想店舗へのユーザの来店回数の情報を、ユーザ情報に関連づけて登録する。この来店回数の情報を含むユーザ情報を、図1の携帯型情報記憶媒体195に記憶しておき、次の来店時に来店回数を更新するようにしてもよい。或いはインターネット等のネットワークを介して店舗(店舗の管理装置)と通信接続されるサーバ(サーバシステム)のデータベース(記憶部)に、来店回数の情報を含むユーザ情報を記憶しておき、次の来店時に当該データベースにアクセスして、来店回数を更新するようにしてもよい。なお実店舗は、例えばHMDを用いたVRのシステムなどにおいてユーザが訪れる現実世界(実空間)の店舗である。仮想店舗は、例えばインターネットで利用可能なショッピングサイトなどにある仮想的な店舗である。
また提示処理部114は、ユーザに対する課金に応じて、愛着度情報により表される愛着度を増加させる処理を行う。例えばユーザに対する課金に対してユーザが対価を支払うと、特定のキャラクタに対するユーザの愛着度を増加させる。例えばユーザが推しキャラクタを指定して課金の対価を支払うと、例えば課金額等に応じて当該推しキャラクタに対するユーザの愛着度を増加させる。課金の支払いは、ゲーム内通貨で行ってもよいし、現実の通貨によって行ってもよい。また課金アイテム等を購入することによってユーザが課金に対する対価を支払うようにしてもよい。例えば、ユーザが、所望のキャラクタを指定して、課金アイテムであるプレゼントをそのキャラクタに渡すと、そのキャラクタに対する愛着度を増加させる。例えば課金アイテムを渡したキャラクタは、ユーザの推しキャラクタであると判断して、愛着度を増加させる。この場合の愛着度は、例えばユーザが実店舗又は仮想店舗を訪れた際のキャラクタに対する愛着度の初期値(オフセット値)であってもよい。課金に対する支払いによって、キャラクタの愛着度の初期値が増加すると、上述したような愛着度に応じた種々の処理(例えば質問、注文対象又はメニュー等を変化させる処理)において、よりユーザにとって有利な展開になる。
また提示処理部114は、キャラクタに対するユーザの愛着度が所与のしきい値を越えた場合に、注文対象に対して付加物を付加する処理を行う。例えば、愛着度が所与のしきい値を越えると、ユーザに提示する注文対象に付加物を付加して提示する。即ち、注文対象に付加物を加えてユーザに提示する。或いは、ユーザに対して注文対象を提示し、その注文対象をユーザが注文した場合に、注文対象と付加物をユーザに付与するようにする。付加物は、例えば注文対象のおまけとなるものである。注文対象が商品である場合に、付加物はおまけの商品である。
また提示処理部114は、ユーザ及びキャラクタに関連する外部情報に基づいて、キャラクタの愛着度情報を変化させる処理を行う。例えばユーザ及びキャラクタに関連する外部情報として、連動するゲーム(キャラクタが登場するゲーム)の情報や、キャラクタに関連する商品についてのユーザの購入情報(購入履歴情報)を外部から取得(ネットワーク等を介して取得)する。そしてゲームの情報や商品の購入情報などの外部情報に応じて、愛着度情報により表される愛着度(パラメータ)を変化させる。
また提示処理部114は、実店舗又は仮想店舗へのユーザの来店回数、ユーザに対する課金、ユーザの位置情報、及び日時情報の少なくとも1つを含むユーザ情報を取得する。そしてユーザ情報に応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる注文対象、及びキャラクタの対話内容の少なくとも1つを設定する処理を行う。例えば来店回数、課金、位置情報又は日時情報などのユーザ情報に応じて、質問、メニュー、注文対象又は対話内容を変化させる。ユーザの来店回数やユーザに対する課金については、前述した通りである。ユーザの位置情報は、例えば携帯通信端末の位置センサー(GPS等)により判断してもよいし、ユーザがどの店舗に居るかによって判断してもよい。日時情報は、ユーザがゲームをプレイしている日時の情報(時刻、日にち等)である。提示処理部114は、来店回数、課金、位置情報又は日時情報に応じて、質問の内容や回数を変化させたり、メニューの種類や内容を変化させたり、メニューに含まれる注文対象の種類や数を変化させたり、或いはキャラクタがユーザに対して行う会話の内容や会話の分岐などを変化させる。
また提示処理部114は、実店舗又は仮想店舗へのユーザの来店回数、ユーザに対する課金、ユーザの位置情報、及び日時情報の少なくとも1つを含むユーザ情報を取得する。そしてユーザの回答結果とユーザ情報とに基づき、ユーザに提示する注文対象の決定処理を行う。例えばユーザが質問に対して回答した場合に、その回答結果と、ユーザの来店回数、課金額、位置情報又は日時情報などのユーザ情報に基づいて、ユーザに提示する注文対象を決定する。即ち、メニューの中から、ユーザに提示する注文対象を決定する際に、ユーザの来店回数、課金額、位置情報又は日時情報などのユーザ情報を反映させて、ユーザに提示する注文対象を決定する。例えば来店回数が多いか少ないか、課金額が多いか、少ないか、ユーザがどの場所にいるか、或いは、ユーザがゲームをプレイしている時刻や日にちなどに応じて、メニューの中から選択するユーザに提示する注文対象を変化させる。
また提示処理部114は、ユーザの回答結果とユーザ情報に基づき決定される注文対象がメニューの中になかった場合に、注文対象の非存在用の処理を行う。例えばユーザの回答結果とユーザ情報に応じた最適な商品等の注文対象がなかった場合には、特別な処理を行う。例えば注文対象の決定処理において、メニューのリストにある第1~第Mの注文対象の各注文対象に対して、ユーザの回答結果やユーザ情報に応じたポイントを付与する。例えば上記したような重み付けポイントのようなポイントを付与する。そしてキャラクタによる第1~第Nの質問が終了した際に、当該ポイントが所定のしきい値に達していなかった場合には、決定すべき注文対象(最適な注文対象)がメニュー(第1、第2のキャラクタの少なくとも一方のメニュー)の中になかったと判定する。そして提示処理部114は、注文対象の非存在用の処理を行う。注文対象の非存在用の処理としては、上述のような種々の処理が考えられる。
また本実施形態のゲームシステムは、図1に示すように、仮想空間の設定処理を行う仮想空間設定部116と、仮想空間に登場するキャラクタの処理を行うキャラクタ処理部112と、注文対象のリストであるメニューの情報を記憶する記憶部170と、提示処理部114と表示処理部120を含む。そして提示処理部114は、キャラクタが行った質問に対するユーザの回答を受け付け、ユーザの回答結果に基づき決定された注文対象を、キャラクタを用いてユーザに対して提示する処理を行う。また表示処理部120は、仮想空間において仮想カメラから見える画像として、ユーザが視界を覆うように装着するHMD200(図2)の表示画像を生成する。
例えば仮想カメラ制御部117は、ユーザの視点情報のトラッキング情報に基づいて、ユーザの視点変化に追従するように仮想カメラを制御する。具体的には入力処理部102(入力受け付け部)は、HMD200を装着するユーザの視点情報のトラッキング情報を取得する。例えばユーザの視点位置、視線方向の少なくとも1つである視点情報のトラッキング情報(視点トラッキング情報)を取得する。このトラッキング情報は、例えばHMD200のトラッキング処理を行うことで取得できる。なおトラッキング処理によりユーザの視点位置、視線方向を直接に取得するようにしてもよい。一例としては、トラッキング情報は、ユーザの初期視点位置からの視点位置の変化情報(視点位置の座標の変化値)、及び、ユーザの初期視線方向からの視線方向の変化情報(視線方向の回転軸回りでの回転角度の変化値)の少なくとも一方を含むことができる。このようなトラッキング情報が含む視点情報の変化情報に基づいて、ユーザの視点位置や視線方向(ユーザの頭部の位置、姿勢の情報)を特定できる。
そして仮想カメラ制御部117は、取得されたトラッキング情報(ユーザの視点位置及び視線方向の少なくとも一方の情報)に基づいて仮想カメラの視点位置、視線方向を変化させる。例えば、仮想カメラ制御部117は、実空間でのユーザの視点位置、視線方向の変化に応じて、仮想空間での仮想カメラの視点位置、視線方向(位置、姿勢)が変化するように、仮想カメラを設定する。このようにすることで、ユーザの視点情報のトラッキング情報に基づいて、ユーザの視点変化に追従するように仮想カメラを制御できる。
このようにすれば、いわゆるVRのシステムにおいて、例えば3次元オブジェクトで表されるキャラクタが仮想空間に登場して、当該キャラクタがユーザに対して質問を行うようになる。そして、キャラクタの質問に対してユーザが回答すると、回答結果に基づき決定された注文対象を、3次元オブジェクトで表されるキャラクタが、例えばお勧めの注文対象としてユーザに提示するようになる。このようにすることで、ユーザは、あたかも本物の人物から質問を受けて、その質問の回答結果に応じた注文対象を、当該人物が勧めてくるような仮想現実を体験できるようになる。これによりユーザの仮想現実感の向上を図れる。
またこの場合に提示処理部114は、キャラクタに対するユーザの注視情報に応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる注文対象、及びキャラクタの対話内容の少なくとも1つを設定してもよい。例えばキャラクタに対する注視情報に応じて、質問、メニュー、注文対象又は対話内容を変化させる。ここでユーザの注視情報は、前述したようなHMD200等を利用して取得されたトラッキング情報に基づいて判断できる。そしてユーザが注視しているキャラクタ、注視時間又は注視場所に応じて、質問、メニュー、注文対象又は対話内容を変化させる。例えばユーザが複数のキャラクタ(第1、第2のキャラクタ)のうちのいずれのキャラクタを注視しているかに応じて、質問、メニュー、注文対象又は対話内容を変化させる。或いは、ユーザが注視している時間を注視時間として測定したり、ユーザがキャラクタのどの場所(部位)を注視しているのかを検出し、注視時間や注視している場所(部位)に応じて、質問、メニュー、注文対象又は対話内容を変化させる。
なお図1の本実施形態のゲームシステムの処理は、店舗等の施設に設置されるPC等の処理装置、ユーザが所持するスマートフォン等の携帯通信端末、家庭用ゲーム装置、或いは業務用ゲーム装置などの種々の端末装置により実現できる。或いは本実施形態のゲームシステムの処理を、ネットワークを介して端末装置と通信接続されるサーバシステムにより実現したり、サーバシステムと端末装置の分散処理により実現してもよい。
2.HMD、トラッキング処理
次に本実施形態の手法をVRのシステムに適用した場合に用いられるHMD200や、HMD200を用いたトラッキング処理について説明する。
図2にHMD200の一例を示す。図2に示すように、ユーザUSは、視界を覆うようにHMD200を装着して、VRの世界を楽しむ。図2ではユーザはヘッドフォン270を装着しており、これによりキャラクタの質問等の会話を聞くことができる。また不図示のマイク等を設けて、ユーザが音声入力をできるようにしてもよい。
HMD200は、センサ部や表示部や処理部を含むことができる。なおHMD200に発光素子を設ける変形実施も可能である。センサ部は、例えばヘッドトラッキングなどのトラッキング処理を実現するためものである。例えばセンサ部を用いたトラッキング処理により、HMD200の位置、方向を特定する。HMD200の位置、方向が特定されることで、ユーザの視点位置、視線方向を特定できる。
トラッキング方式としては種々の方式を採用できる。トラッキング方式の一例である第1のトラッキング方式では、HMD200に設けられるセンサ部として複数の受光素子(フォトダイオード等)を設ける。そして外部に設けられた発光素子(LED等)からの光(レーザー等)をこれらの複数の受光素子により受光することで、現実世界の3次元空間でのHMD200(ユーザの頭部)の位置、方向を特定する。第2のトラッキング方式では、複数の発光素子(LED)をHMD200に設ける。そして、これらの複数の発光素子からの光を、外部に設けられた撮像部で撮像することで、HMD200の位置、方向を特定する。第3のトラッキング方式では、センサ部としてモーションセンサを設け、このモーションセンサを用いてHMD200の位置、方向を特定する。モーションセンサは例えば加速度センサやジャイロセンサなどにより実現できる。例えば3軸の加速度センサと3軸のジャイロセンサを用いた6軸のモーションセンサを用いることで、現実世界の3次元空間でのHMD200の位置、方向を特定できる。なお、第1のトラッキング方式と第2のトラッキング方式の組合わせ、或いは第1のトラッキング方式と第3のトラッキング方式の組合わせなどにより、HMD200の位置、方向を特定してもよい。またHMD200の位置、方向を特定することでユーザの視点位置、視線方向を特定するのではなく、ユーザの視点位置、視線方向を直接に特定するトラッキング処理を採用してもよい。
HMD200の表示部は例えば有機ELディスプレイ(OEL)や液晶ディスプレイ(LCD)などにより実現できる。例えばHMD200の表示部には、ユーザの左眼の前に設定される第1のディスプレイ又は第1の表示領域と、右眼の前に設定される第2のディスプレイ又は第2の表示領域が設けられており、立体視表示が可能になっている。立体視表示を行う場合には、例えば視差が異なる左眼用画像と右眼用画像を生成し、第1のディスプレイに左眼用画像を表示し、第2のディスプレイに右眼用画像を表示する。或いは1つのディスプレイの第1の表示領域に左眼用画像を表示し、第2の表示領域に右眼用画像を表示する。またHMD200には左眼用、右眼用の2つの接眼レンズ(魚眼レンズ)が設けられており、これによりユーザの視界の全周囲に亘って広がるVR空間が表現される。そして接眼レンズ等の光学系で生じる歪みを補正するための補正処理が、左眼用画像、右眼用画像に対して行われる。
またHMD200として、いわゆるスマートフォンVR又はVRゴーグルと呼ばれるタイプのものを用いてもよい。このタイプのHMD200では、スマートフォンの表示部がユーザの目に対向するように、図2のゴーグル部の中にスマートフォンを収納する。ゴーグル部(VRゴーグル)の内側には、左眼用接眼レンズ、右眼用接眼レンズが内蔵されている。ユーザは、スマートフォンの表示部に表示された左眼用画像、右眼用画像を、各々、左眼用接眼レンズ、右眼用接眼レンズを介して見ることで、VRの立体視画像を鑑賞することができる。そしてユーザの視点位置、視線方向を特定するトラッキング処理は、スマートフォンに内蔵されるモーションセンサ(加速度センサ、ジャイロセンサ)などに基づいて実現できる。そしてこの場合には本実施形態のゲームシステムは、スマートフォンにインストールされるアプリケーションのプログラムとスマートフォンのハードウェアとにより実現されることになる。
3.本実施形態の手法
次に本実施形態の手法について詳細に説明する。なお、以下では、注文対象が、食べ物などの商品である場合について主に説明するが、本実施形態の注文対象は、現実世界の商品以外にも、現実世界のサービスや、仮想空間での仮想的な商品やサービスであってもよい。また以下では、HMDに画像が表示されるゲームシステムに本実施形態の手法を適用した場合を主に例にとり説明するが、HMD以外の表示部にゲーム画像が表示されるゲームシステムに対しても本実施形態の手法は適用可能である。
3.1 VRカフェ
本実施形態ではユーザは、VRのカフェ(カフェバー)に訪れ、そのカフェにいるキャラクタとのインタラクティブなコミュニケーションを楽しむ。キャラクタは、例えばゲームメーカなどが販売する有名なゲームソフトに登場するキャラクタであり、ユーザは、VRカフェにおいて、このゲームのキャラクタとの会話などを楽しむことができる。
図3は、ユーザが訪れる仮想的なカフェであるVRカフェを示す図である。ユーザが図2のHMD200を装着すると、図3に示すようなVRカフェの画像がユーザに表示される。ユーザがHMD200を装着することで、ユーザの全周囲の方向に亘って、仮想空間(VR空間)の世界が広がっている。例えばHMD200を装着したユーザが前方向を向けば、仮想空間において前方向に見える画像がHMD200に表示され、ユーザが右方向を向けば、仮想空間において右方向に見える画像がHMD200に表示される。これにより、あたかも本当に仮想空間の中に入り込んだかのような仮想現実感をユーザに与えることができる。また本実施形態では、例えば現実世界の店舗と提携して、このVRカフェのシステムを実現してもよい。例えば現実世界の店舗を模擬したVRカフェを仮想空間に構築する。そしてユーザは、その店舗に訪れて、HMD200を装着することで、その店舗に対応するVRカフェの様子をHMD200を介して見ることができる。
ユーザが図3のVRカフェを訪れると、店長である女性のキャラクタや、ゲームに登場するキャラクタがユーザを迎えてくれる。ユーザは図3のA1に示すカウンターの椅子に腰掛けて、キャラクタとの会話を楽しむ。例えば図4では、ユーザUSの両サイドに、キャラクタCHA、CHBが訪れており、ユーザUSはキャラクタCHA、CHBに挟まれる形でカウンターの椅子に座っている。そしてユーザUSは、VR空間のキャラクタCHA、CHBとのインタラクティブなコミュニケーションを楽しむ。
本実施形態では、VR空間のキャラクタがユーザに向かってコミュニケーションをしてくれる。例えばユーザの推しキャラクタなどが、おもむろに自分の隣に座ってくれる。そして、キャラクタが、ユーザの気分をくんで、VRカフェのメニューの中から、お勧めの商品(食べ物)を選んでくれる。例えばユーザが、キャラクタに差し入れをすれば(課金アイテムを購入すれば)、キャラクタからお礼のファンサービスを受けることができる。
例えば図5(A)では、キャラクタCHAがユーザUSの隣にやって来て、ユーザUSの代わりにメニューの商品を決めることを提案している。具体的には図5(B)に示すようにキャラクタCHAがユーザUSに対して質問する。キャラクタCHAは、有名なゲームであるRPGに登場するキャラクタであるため、ゲームに関連する質問を行っている。具体的には、RPGのマップにおいて街に訪れた時の宝箱の集め方について質問している。具体的には、キャラクタCHAは、質問に対する回答の選択肢を提示し、ユーザUSはその選択肢の中から選ぶことで、質問に対して回答する。ユーザUSが回答すると、図6(A)に示すようにキャラクタCHAは次の質問をする。具体的には、戦闘前に行う準備について質問している。この場合も回答として3つの選択肢が提示されており、ユーザUSは、その選択肢の中から選ぶことで、質問に対して回答する。
このようにして、キャラクタCHAがユーザUSに対して次々と質問をして行く。この質問は、ユーザUSがメニューの中から選ぶ商品とは直接的な関係は無く、キャラクタCHAが登場するゲームに関連する質問が行われる。そして全ての質問が終わると、図6(B)に示すように、キャラクタCHAに対応するメニューの中から、ユーザUSにお勧めの商品(食べ物)をキャラクタCHAが提示する。キャラクタCHAのメニューは、スイーツに関するメニューであり、そのメニューの中から、図6(B)では特製デザートプレートをお勧め商品としてユーザUSに提示している。ユーザUSは、自身が愛着しているキャラクタCHA(推しキャラクタ)からのお勧めであるため、喜んでその商品を注文する。具体的には、例えばユーザUSは、VRカフェに対応する現実世界の店舗において、キャラクタCHAから勧められた商品(特製デザートプレート)を注文する。
また本実施形態ではユーザUSとインタラクティブなコミュニケーションを行うキャラクタとして、複数のキャラクタが登場する。例えば図7(A)では、二人のキャラクタCHA、CHBがユーザUSの席に来て、ユーザUSを挟むように話しかけている。これらのキャラクタCHA、CHBは、同じゲーム(RPG)に登場するキャラクタである。ユーザUSは、例えばキャラクタCHA、CHBのいずれか一方を、自身の推しキャラクタとして選択することができる。
図7(A)では、キャラクタCHAがケーキ派であり、キャラクタCHBがプリン派であることを、ユーザUSに伝えている。従って、キャラクタCHAは、例えばケーキのメニューの中からお勧め商品を選び、キャラクタCHBは、例えばプリンのメニューの中からお勧め商品を選ぶことになる。
図7(B)ではキャラクタCHAが、ゲームにおいて欲しい装備がある時にユーザUSがとる行動について、質問している。具体的には、回答となる3つの選択肢が提示され、ユーザUSは、その中から、欲しい装備があるときには資金集めを行うという選択肢を選択している。この時、もう一方のキャラクタCHBは、ユーザUSの回答に対応するような会話(「やっぱり世の中はお金だよな」)を行う。このようにユーザUSの回答に対してキャラクタCHBの会話が連動することで、インタラクティブなコミュニケーションとしての会話の楽しみをユーザUSに与えることができる。
このようにして、本実施形態では、キャラクタCHA、CHBがユーザUSに対して次々と質問をする。この場合にキャラクタCHA、CHBの両方のキャラクタがユーザUSに対して質問をするようにしてもよいし、一方のキャラクタだけがユーザUSに対して質問をするようにしてもよい。一方のキャラクタだけが質問をする場合には、例えば図7(B)に示すように、他方のキャラクタはユーザUSの回答に相槌を打つなどして、会話を盛り上げる立場となる。
そして全ての質問が終わると、図8に示すようにキャラクタCHA、CHBは、自身のメニューの中からお勧め商品を選択してユーザUSに提示する。例えばケーキ派のキャラクタCHAは、自身のケーキのメニューの中から特製フルーツタルトを、お勧め商品としてユーザUSに提示している。またプリン派のキャラクタCHBは、自身のプリンのメニューの中からチョコバナナプリンを、お勧め商品としてユーザUSに提示している。例えばユーザUSにとっては、キャラクタCHBが推しキャラクタであるため、キャラクタCHBが勧めた商品を注文することを決める。そしてユーザUSは、現実世界の店舗において、キャラクタCHBから勧められた商品(チョコバナナプリン)を注文する。なお、キャラクタCHA、CHBの両方のキャラクタが、自身のメニューの中からお勧め商品を提示してもよいし、一方のキャラクタ(例えばユーザの推しキャラクタ)のみが、自身のメニューの中からお勧め商品を提示してもよい。またキャラクタCHA、CHBが、一部又は全部が共通のメニューの中からお勧め商品を選択して提示するようにしてもよい。
3.2 メニューの中からの注文対象の提示
以上のように本実施形態は、VRカフェでユーザが注文をする際に、単純に紙のメニューから選ぶのではなく、複数のキャラクタとの会話を楽しんでいる間に、キャラクタがメニューの中から、お勧めの注文対象である商品を決めてくれるシステムとなっている。具体的には、ユーザがキャラクタの質問に回答しながら、注文する商品を決めるイベントにおいて、キャラクタはお勧め商品が登録されているメニューのテーブルを持っている。そしてキャラクタとして第1のキャラクタと第2のキャラクタが登場し、キャラクタからユーザに質問の内容が提示される。そしてユーザの回答結果に応じて、キャラクタはメニューテーブルの中から、お勧め商品となる最適な商品を選んでユーザに提示する。
具体的には本実施形態では、図5(A)~図6(B)に示すように仮想空間(ゲーム空間)でキャラクタCHAを動作させる。例えば仮想空間においてキャラクタCHAはユーザUSの位置に移動し、ユーザUSに対して会話するなどの動作を行う。またキャラクタCHAが提示する商品(広義には注文対象)のリストであるメニューの情報は、記憶部170に記憶されている。そして図5(B)、図6(A)に示すように、キャラクタCHAが一連の質問を行う。ユーザUSがこれに回答すると、図6(B)に示すようにキャラクタCHAは、回答結果に基づき決定された商品をお勧め商品として、ユーザUSに提示する。例えば、注文する商品をなかなか決められないユーザUSの代わりに、注文する商品をキャラクタCHAが選んであげる。
この場合にキャラクタCHAが行う質問は、例えば心理テストのような質問であり、一例としてはキャラクタCHAが登場するゲームに関連する質問である。例えば前述の特許文献1の従来技術では、ユーザが購入したい商品を的確に把握するための商品説明を、店員キャラクタが行っている。しかしながらこの従来技術の手法では、店員キャラクタは単なる説明者に過ぎず、ユーザの思い入れや愛着の対象となるものではない。
これに対して本実施形態では、ゲームにも登場するキャラクタCHAは、ユーザUSの思い入れや愛着の対象である。そしてキャラクタCHAが、商品とは直接的には関係ない心理テストのような質問を行うため、あたかもキャラクタCHAがユーザUSの事を知りたいために質問を行っているような感覚を、ユーザUSに与えることができる。またキャラクタCHAが質問し、ユーザUSが回答すると、その回答内容に基づいてキャラクタCHAがユーザUSの事を理解したかのように、ユーザUSに感じさせることができる。そして、このようにユーザUSの事を理解したキャラクタCHAが、メニューの中からユーザUSにお勧め商品を選んでくれる。従って、ユーザUSは、自身が愛着を持っているキャラクタCHAが、質問を通じて自分の事を理解して、お勧め商品を選んでくれているように感じることができる。このため、ユーザUSは、例えば勧められた商品が自分の好みではなかったとしても、愛着のあるキャラクタCHAが勧めてくれたのだから、注文してみようと思うようになる。従来技術では、ユーザ自身が好む商品しか選ばれないが、本実施形態では、ユーザUSとキャラクタCHAとのコミュニケーションを通じて、注文する商品が選択される。従って、キャラクタCHAとのインタラクティブなコミュニケーションを介した注文商品の選択が可能になり、従来技術では実現できないシステムの提供が可能になる。
また本実施形態では、図7(A)に示すように複数のキャラクタCHA、CHBが登場する。そしてキャラクタCHA(第1のキャラクタ)が行った質問に対するユーザUSの回答結果及びキャラクタCHB(第2のキャラクタ)が行った質問に対するユーザUSの回答結果の少なくとも一方に基づいて、ユーザに提示する商品が決定される。例えばキャラクタCHAに対応するメニューとキャラクタCHBに対応するメニューの少なくとも一方のメニューの中から、ユーザに提示されるお勧め商品が決定される。例えば図7(A)では、キャラクタCHAはプリン派であるため、キャラクタCHAに対応するメニューはプリンのメニューになる。一方、キャラクタCHBはケーキ派であるため、キャラクタCHBに対応するメニューはケーキのメニューになる。そして図7(B)では、キャラクタCHAがユーザUSに対して心理テストのような質問をしており、ユーザUSが質問に回答している。キャラクタCHBは、例えばユーザUSの回答に相槌を打つような会話をしており、ユーザUSとキャラクタCHA、CHBとの対話処理が実行されている。また図7(B)のキャラクタCHAの質問に続いて、例えばキャラクタCHBがユーザUSに対して質問し、ユーザUSが回答する。このように図7(A)、図7(B)では、キャラクタCHA、CHBの少なくとも一方のキャラクタの質問に対してユーザUSが回答するというように、ユーザUSとキャラクタCHA、CHBとのインタラクティブな会話が行われる。そして全ての質問が終了すると、図8に示すように、キャラクタCHAが、自身のメニューの中からお勧め商品をユーザUSに提示し、キャラクタCHBも自身のメニューの中からお勧め商品をユーザUSに提示する。なお、一方のキャラクタのメニューの中からお勧め商品を提示してもよい。
このようにすれば、ユーザUSと複数のキャラクタCHA、CHBとのインタラクティブな質問と回答のやり取りの中から、ユーザUSへのお勧め商品が選択されて提示されるようになる。例えばユーザUSが複数のキャラクタCHA、CHBとの会話を楽しんでいる間に、その会話での質問に対する回答に応じたお勧め商品が選択されて、ユーザUSに提示されるようになる。従ってユーザUSは、会話を楽しむだけで、その会話の中からお勧め商品が選択されるようになるため、ユーザUSにとって飽きが来にくいゲームシステムの実現が可能になる。即ち、ユーザUSとキャラクタCHA、CHBとのインタラクティブなコミュニケーションを実現しながらユーザに提示する注文対象を決定できるゲームシステムの実現が可能になる。
次に、メニューの中からユーザに提示する商品を決定する処理の具体例について説明する。図9(A)はメニュー情報の例である。メニューMAは図7(A)のキャラクタCHAに対応するメニューであり、メニューMBはキャラクタCHBに対応するメニューである。キャラクタCHAはプリンを好むプリン派であるため、メニューMAの商品IA1~IA5は、種類が異なる複数のプリンのリストになる。キャラクタCHBはケーキを好むケーキ派であるため、メニューMBの商品IB1~IB5は、種類が異なる複数のケーキのリストになる。これらのメニューMA、MBの情報は図1のメニュー情報記憶部176に記憶されている。
図9(B)はユーザに提示する商品の決定処理に使用される演算テーブルの例である。演算テーブルTBAはキャラクタCHA用のテーブルであり、演算テーブルTBBはキャラクタCHB用のテーブルである。AC1、AC2、AC3は図7(B)で説明した回答の選択肢である。演算テーブルTBAのIA1~IA5は、図9(A)のメニューMAにリストされる商品である。演算テーブルTBBのIB1~IB5は、メニューMBにリストされる商品である。そして演算テーブルTBAでは、IA1~IA5の各商品に対して、ユーザがAC1、AC2、AC3の各選択肢を選択したときの重み付けポイントが設定されている。演算テーブルTBBでは、IB1~IB5の各商品に対して、ユーザがAC1、AC2、AC3の各選択肢を選択したときの重み付けポイントが設定されている。
例えばキャラクタCHAの質問に対する回答として、ユーザが選択肢AC1を選択すると、演算テーブルTBAに基づいて、メニューMAの商品IA1、IA2、IA3、IA4、IA5に対して、各々、重み付けポイント3、1、3、1、2が付与される。ユーザが選択肢AC2を選択すると、商品IA1、IA2、IA3、IA4、IA5に対して、各々、重み付けポイント1、4、2、2、1が付与される。ユーザが選択肢AC3を選択した場合も同様である。またキャラクタCHBの質問に対する回答として、ユーザが選択肢AC1を選択すると、演算テーブルTBBに基づいて、メニューMBの商品IB1、IB2、IB3、IB4、IB5に対して、各々、重み付けポイント2、2、3、2、1が付与される。ユーザが選択肢AC2、AC3を選択した場合も同様である。
このように、キャラクタCHA、CHBが行う各質問に対して、図9(B)に示すような演算テーブルTBA、TBBが用意される。そして、キャラクタCHA、CHBからの各質問に対して、ユーザが選択肢を選んで回答すると、上述したように選択した選択肢に応じて、各商品に対して重み付けポイントが付与される。このようにして各質問が行われ、全ての質問が終了すると、各商品に付与された重み付けポイントの合計値が求められる。そして重み付けポイントの合計値が最も大きい商品が、ユーザに提示するお勧め商品として決定される。
このようにすれば、一連の質問の回答としてユーザが選択肢を選択した場合に、選択された選択肢に応じた重み付けポイントを求め、その重み付けポイントの合計値を求めることで、ユーザに提示するお勧め商品を決定できるようになる。この場合に図9(B)の手法によれば、複数の質問に対するユーザの回答が同じであれば、同じ商品が一意に決定されるようになるため、お勧め商品の適正な決定処理を実現できるようになる。
なお図9(B)の演算テーブルTBA、TBBでは、各商品の縦列での重み付けポイントの合計値は同じ値(例えば6)になっている。このようにすれば、各商品が同じ確率でお勧め商品として選ばれるようになる。
一方、図9(C)の演算テーブルTBAでは、商品IA1の縦列での重み付けポイントの合計値は10であり、他の商品IA2~IA5の縦列での重み付けポイントの合計値よりも大きくなっている。このような演算テーブルTBAの設定にすれば、商品IA1が、商品IA2~IA5に比べてより高い確率で選ばれるようになる。例えばVRカフェに対応する現実世界の店舗において、ユーザに対してより注文して欲しいが商品がIA1である場合には、演算テーブルTBAの重み付けポイントを図9(C)に示すような設定にすればよい。
3.3 種々の処理例
次に本実施形態の種々の処理例について説明する。例えば本実施形態ではキャラクタに対して愛着度(広義には愛着度情報。以下、同様)が設定されている。そしてユーザの回答結果と、キャラクタに対するユーザの愛着度とに基づき、ユーザに提示する商品(注文対象)を決定する処理を行う。即ち、回答結果と愛着度に基づいて、メニューの中からお勧め商品を選択して提示する。
例えば図10にキャラクタ情報の例を示す。このキャラクタ情報は図1のキャラクタ情報記憶部174に記憶されている。図10のキャラクタ情報では、各キャラクタに対応づけて、メニューID、愛着度、属性、相性度が設定されている。メニューIDは、図9(A)に示す各キャラクタに対応するメニューを指定するIDである。このようなメニューIDを設けることで、各キャラクタに対してそのキャラクタが使用するメニューを対応づけることができる。
愛着度(愛着度情報)は、キャラクタに対するユーザの愛着度の度合いを表すパラメータである。例えば図10では、キャラクタCHAに対するユーザの愛着度はAFAに設定されており、キャラクタCHBに対するユーザの愛着度はAFBに設定されている。このように愛着度は各キャラクタ毎に設定される。属性は、キャラクタの属性パラメータであり、例えばキャラクタに備わっている固有の性質や特徴を表すものである。相性度は、例えばユーザとそのキャラクタとの相性度や、キャラクタ間での相性度である。例えばユーザとキャラクタとの相性度が高いほど、後述する愛着度の増加処理における愛着度の増加度合いが大きくなる。また互いの相性度が高い複数のキャラクタが登場して、会話を行うと、愛着度の増加度合が大きくなるなどして、ユーザにとってより有利な展開になる。
図11(A)にユーザの推しキャラクタの選択画面の例を示す。ユーザは図11(A)の選択画面において、ユーザは、複数のキャラクタの中から推しキャラクタを選択する。すると、推しキャラクタとして選択されたキャラクタの愛着度が増加する。推しキャラクタは、ユーザが愛着を感じており、好意を抱いているキャラクタである。例えば推しキャラクタはユーザが応援しているキャラクタである。例えば推しキャラクタは、当該キャラクタが登場するゲームにおいてユーザの使用頻度が高いキャラクタである。
また本実施形態では、ユーザの注視情報に応じてキャラクタの愛着度を変化させる。注視情報は、ユーザがキャラクタを注視しているか否かを表す情報、注視時間、或いは注視場所についての情報である。例えば図11(B)では、ユーザUSは複数のキャラクタCHA、CHBのうちのキャラクタCHAの方を注視している。即ち視線方向VLをキャラクタCHAの方に向けている。この場合にはキャラクタCHAに対するユーザUSの愛着度が増加する。このとき、注視していない方のキャラクタCHBに対する愛着度を減少させてもよい。ユーザUSがキャラクタを注視しているかどうかは、例えば前述したHMDのトラッキング処理に基づき取得されるユーザUSの視線方向VLなどに基づき判断できる。或いはタッチパネルディスプレイにおいて、ユーザUSがキャラクタにタッチしているか否かに応じて、当該キャラクタを注視しているか否かを判断してもよい。例えばユーザUSがキャラクタCHAを注視している注視時間に応じてキャラクタに対する愛着度を変化させる。例えば注視時間が長いほど愛着度の増加値を大きくする。また注視時間が所与の時間を越えたことを条件に愛着度を段階的に変化させてもよい。例えば注視時間は注視カウンターなどに基づき判断できる。具体的には注視時間は、例えばユーザUSの視線方向がキャラクタの方を向いている時間を測定したり、ユーザUSがタッチパネルディスプレイにおいてキャラクタをタッチしている時間を測定することで、求めることができる。またユーザUSの注視場所に応じて愛着度を変化させてもよい。例えばユーザUSがキャラクタの第1の部位(例えば顔、頭部)を注視している場合には、愛着度を増加させ、第2の部位(例えば胸、臀部)を注視している場合には、愛着度の増加率を小さくしたり、愛着度を減少させてもよい。
そして本実施形態では、このようにして設定されたキャラクタに対する愛着度と、ユーザの回答結果に基づいて、ユーザに提示する商品の決定処理を行う。例えばキャラクタCHAの方がキャラクタCHBよりもユーザの愛着度が高かった場合には、キャラクタCHAのメニューの中から、ユーザに提示するお勧め商品を決定する。或いはキャラクタCHA、CHBのいずれがお勧め商品を提示するかを、愛着度に応じた確率情報などに基づいて決定する。或いは図9(B)で説明した演算テーブルに基づく演算処理において愛着度を用いる。例えば、ユーザの選択肢の選択により各商品に重み付けポイントを付与する際に、キャラクタに対する愛着度が大きいほど、付与する重み付けポイントを大きくする。例えば愛着度が高いキャラクタのメニューの商品の方が、愛着度が低いキャラクタのメニューの商品に比べて、お勧め商品として、より選ばれるようにする。
このようにすれば、例えばキャラクタに対する愛着度が高いか低いかに応じて、ユーザに提示されるお勧め商品が変化するようになり、ユーザに提示するお勧め商品の決定処理に対して、キャラクタに対するユーザの愛着度を反映させることが可能になる。
また本実施形態では、ユーザの回答結果と愛着度(愛着度情報)に基づき決定される商品(注文対象)がメニューの中になかった場合に、注文対象の非存在用の処理を行う。図12に、この場合の処理例のフローチャートを示す。まずユーザとキャラクタの対話処理を行う(ステップS1)。例えばキャラクタがユーザに質問し、ユーザが質問に回答するための対話処理を行う。そしてユーザの回答結果とキャラクタに対するユーザの愛着度とに基づいて、メニューの中からお勧め商品を選択する処理を実行する(ステップS2)。例えば図9(B)で説明した演算テーブル等を用いて当該処理を実行する。
次にメニューの中にお勧め商品があるか否かを判断する(ステップS3)。例えば重み付けポイント等のポイントを演算して、お勧め商品の選択処理を行う場合に、当該ポイントが所与のしきい値を超えたか否かなどに応じて、メニューの中にお勧め商品があるか否かを判断する。そして、メニューの中にお勧め商品があった場合には、そのお勧め商品をユーザに提示する(ステップS4)。例えば重み付けポイント等のポイントが所与のしきい値を超えた商品があった場合には、当該商品をお勧め商品としてユーザに提示する。一方、メニューの中にお勧め商品がなかった場合には、お勧め商品の非存在用の処理を実行する(ステップS5)。例えば重み付けポイント等のポイントが所与のしきい値を超えた商品がなかった場合には、お勧め商品の非存在用の特別な処理を実行する。
このような特別な処理(お勧め商品の非存在用の処理)としては、以下のような処理が考えられる。例えば図13(A)に示すようにキャラクタCHAが、キャラクタCHBのメニューの中から商品を勧めて貰うように誘導する会話処理を、上記の特別な処理として行う。即ち図13(A)では、キャラクタCHAのメニューの中にはお勧め商品が存在しないと判断されている。このためキャラクタCHAが、キャラクタCHBのメニューの中にお勧め商品がないかを聞くように、ユーザに話している。すると、キャラクタCHBが、自身のメニューの中からお勧め商品を選択してユーザに提示する。例えば前述のように、愛着度に基づくお勧め商品の決定処理として、推しキャラクタと、推しキャラクタではない別のキャラクタがいる場合に、愛着度の高い推しキャラクタのメニューの方から優先してお勧め商品を選択するようにする。そして、この推しキャラクタのメニューの中にお勧め商品がないと判断された場合には、推しキャラクタではない別のキャラクタのメニューの中からお勧め商品を選択する。
或いは、基本のメニューとは別に、裏メニュー(隠しメニュー)を用意しておき、基本のメニューの中にお勧め商品がなかった場合には、上記の特別な処理として、裏メニューの中からお勧め商品を選択する処理を行う。例えば図13(B)では、キャラクタCHAは、基本のメニューの中にはお勧め商品がなかったため、裏メニューの中からお勧め商品を選択することを、ユーザUSに対して話している。なお、推しキャラクタが自身のメニューの中からお勧め商品を選択するが、その際にフォロー演出が入るようにしてもよい。例えばユーザがニンジン嫌いであるのに、メニューの中にニンジンを使用した食べ物しかない場合に、「君の嫌いなにんじんが入ってるけど、よけて食べてね」というようなフォロー演出の会話をキャラクタが行う。
このようにすれば、ユーザの回答結果と愛着度に基づき決定されるお勧めの商品が無いような状況が発生した場合にも、注文対象の非存在用の特別な処理を行うことで、これに対処できるようになる。
また本実施形態では、愛着度に応じて、ユーザに対して行う質問を変化させる処理を行う。例えばキャラクタに対する愛着度が増加すると、それに応じて、回答の選択肢が増えるようにする。例えば初めは、選択肢が3つであり、三択だったのが、愛着度の増加に伴い、選択肢が3つから4つ、4つから5つというように増えて行く。即ち、選択肢が、三択から四択、四択から五択に変化する。或いは、愛着度が増加すると、質問回数が増えるようする。例えば通常は、全体でキャラクタが10回の質問を行うが、愛着度が増加して所与のしきい値を超えると、質問回数が増加して、例えば12回になる。或いは、愛着度が増加すると、それに応じて、質問の分岐が追加されるようにしてもよい。例えば会話のシナリオの分岐を増やして、異なるシナリオによる質問が行われるようにする。或いは、キャラクタCHA、CHBが登場する場合に、キャラクタCHA、CHBの愛着度に応じて、各キャラクタの質問回数を異ならせる。例えばキャラクタCHAの方かCHBよりも愛着度が高い場合には、キャラクタCHAの方の質問回数をCHBよりも多くする。例えば、初期状態では、キャラクタCHA、CHBの質問回数が、各々、5回、5回であったのを、キャラクタCHAの愛着度が増加すると、質問回数を、各々、7回、3回に変化させる。
図14は、愛着度に応じて質問を変化させる処理のフローチャートである。まず愛着度の増加イベントが発生したか否かを判断し、増加イベントが発生した場合にはキャラクタの愛着度の増加処理を実行する(ステップS11、S12)。例えば前述したようにキャラクタが推しキャラクタとして選択されたり、ユーザがキャラクタを注視すると、そのキャラクタの愛着度が増加するイベントが発生し、当該キャラクタの愛着度が増加する。次に、キャラクタの愛着度がしきい値VTAを越えたか否かを判断する(ステップS13)。そして愛着度がしきい値VTAを越えた場合には、回答の選択肢の増加処理、質問回数の増加処理、又は会話のシナリオ分岐の追加処理を実行する(ステップS14)。例えば前述したように、ユーザの質問に対する選択肢の数を増やしたり、キャラクタがユーザにする質問の回数を増やしたり、新たなシナオリ分岐を発生する。
このようにすれば、キャラクタに対する愛着度に応じて、キャラクタがユーザに対して行う質問が多様に変化するようになり、ユーザにとって、より飽きが来にくいゲームシステムの実現が可能になる。
また本実施形態では愛着度に応じて、ユーザに提示する注文対象又はメニューを変化させる処理を行う。例えば愛着度が所与のしきい値を越えたことを条件に出現するような商品やメニューを用意する。例えば特定の商品は、愛着度が所与のしきい値が越えないと、メニューの中に入らないようにする。或いは、愛着度が所与のしきい値を超えると、特別なメニューが発生するようにする。或いは、特定の商品については、愛着度が所与のしきい値を超えないと、キャラクタがユーザに対して勧めないようにする。
図15は、愛着度に応じて商品又はメニューを変化させる処理のフローチャートである。まず愛着度の増加イベントが発生したか否かを判断し、増加イベントが発生した場合にはキャラクタの愛着度の増加処理を実行する(ステップS21、S22)。次に、キャラクタの愛着度がしきい値VTBを越えたか否かを判断する(ステップS23)。そして愛着度がしきい値VTBを越えた場合には、新商品、新メニューの発生処理を実行する(ステップS24)。例えば、メニューの中に新製品を追加したり、特別なメニューを出現させて、その特別なメニューの中からお勧め商品を選択して、ユーザに提示する。
このようにすれば、キャラクタに対する愛着度に応じて、新たな商品や新たなメニューが出現するようになり、新たな商品をお勧め商品としてユーザに提示したり、新たなメニューの中から選択されたお勧め商品をユーザに提示できるようになる。
また本実施形態では、実店舗又は仮想店舗へのユーザの来店回数に応じて、愛着度を増加させる処理を行う。例えば前述のVRカフェのように、VRカフェに対応する現実世界の実店舗がある場合には、その実店舗への来店回数に応じて、VRカフェのキャラクタに対する愛着度を増加させる。またインターネットのショッピングサイトなどにおける仮想店舗の場合には、そのサイトの仮想店舗にアクセスすることによる来店回数に応じて、その仮想店舗のキャラクタに対する愛着度を増加させる。ユーザの来店回数は、ユーザが所持する携帯型情報記憶媒体195(図1)に記録することで、管理してもよい。或いは、ユーザの来店回数をユーザ情報として、サーバシステムのデータベースに記録し、サーバシステムと通信接続される実店舗の来店回数や、ネットワーク上の仮想店舗の来店回数を管理してもよい。一例としては、図16に示すように、実店舗や仮想店舗への初来店時には、愛着度の初期値を0に設定し、キャラクタに対する愛着度が0から開始するようにする。そして例えば2回目~3回目の来店時には、愛着度の初期値を10に設定し、キャラクタに対する愛着度が例えば10から開始にするようにする。同様に4回目~6回目の来店時においては、愛着度の初期値を15に設定し、7回目以降の来店時においては、愛着度の初期値を20に設定する。即ち実店舗や仮想店舗への来店回数に応じて、初期値である愛着度を段階的に変化させる。このようにすれば、愛着度の増加が動機づけとなって、実店舗や仮想店舗へのユーザの来店を促すことが可能になる。
また本実施形態では、ユーザに対する課金に応じて、愛着度を増加させる処理を行う。例えばユーザに対する課金に対してユーザが対価を支払うと、キャラクタに対する愛着度を増加させる。例えば、プレゼント等の課金アイテムを購入して、キャラクタに渡すと、そのキャラクタに値する愛着度が増加する。例えばユーザは、自身がお気に入りの推しキャラクタに対して、プレゼント等の課金アイテムを購入して渡すことで、その推しキャラクタの愛着度を増加させることができる。例えばユーザが課金アイテムを購入した場合に、キャラクタの愛着度の初期値を0ではなく、20に設定する。また課金アイテムをキャラクタに渡した場合に、キャラクタが、ファンサービスなどをするお礼の演出を行うようにしてもよい。
例えば図17(A)では、ユーザUSは、課金ポイント(ゲーム内通貨)を消費することで、ハートのプレゼントを購入し、このプレゼントを、推しキャラクタであるキャラクタCHAに渡している。これにより、キャラクタCHAに対するユーザの愛着度が10だけ上昇している。
このように、ユーザに対する課金に応じて愛着度が増加することで、前述したように、例えばユーザに提示されるお勧め商品が変化したり、キャラクタの質問が変化したり、或いは新たな商品やメニューが発生するようになる。従って、課金アイテムを購入するなどして課金の対価を支払うことの効果的な動機づけを、ユーザに与えることができる。
なお、前述のVRカフェにおいて、曜日(月曜日~日曜日)によって、デフォルトで登場するキャラクタを変えるようにしてもよい。例えば月曜日は、キャラクタCHAがデフォルトのキャラクタとして登場し、火曜日は、別のキャラクタCHBがデフォルトのキャラクタとして登場するようにする。そしてユーザが、課金アイテム等を購入して課金の対価を支払えば、例えば月曜日において、キャラクタCHAとは異なる自分の推しキャラクタを、VRカフェに登場させることができるようにする。このようにすることで、課金の対価を支払うことの効果的な動機づけをユーザに与えることができる。
また本実施形態ではキャラクタに対するユーザの愛着度が、所与のしきい値を越えた場合に、注文対象に対して付加物を付加する処理を行う。例えばキャラクタの愛着度が所与のしきい値を超えると、注文した商品に対して、おまけ商品がついてくるようにする。例えば図17(B)では、前述したような愛着度の増加イベントが発生することで、愛着度が、しきい値である30を越えている。この場合には、キャラクタCHAが、注文したコーヒーに対して、おまけ商品であるクッキーをつけるという会話をする。例えば、ユーザUSの回答結果等に応じて、キャラクタCHAは、お勧め商品としてコーヒーを提示している。そしてこのときに、愛着度がしきい値を超えているため、ユーザUSがコーヒーを注文すると、おまけとしてクッキーがついてくるようになる。
このようにすれば、愛着度がしきい値を超えることで、ユーザは、お勧め商品のみならず、おまけ商品も得ることができるため、愛着度を高めることの効果的な動機づけをユーザに与えることができる。
また本実施形態では、ユーザ及びキャラクタに関連する外部情報に基づいて、愛着度(パラメータ)を変化させる。例えばユーザ及びキャラクタに関連する外部情報を、外部から取得する。具体的には、ユーザ情報に関連して、連動するゲームの情報や、商品の購入情報を呼び出す。例えばキャラクタが登場するゲームの情報や、キャラクタに関連する商品についてのユーザの購入情報を、外部情報として呼び出す。そして、これらのゲームの情報や商品の購入情報を、キャラクタについての愛着度(パラメータ)に反映させる。例えば、ゲームにおいてメインに使用しているキャラクタ(使用頻度が高いキャラクタ)が、VRカフェに登場するキャラクタであった場合には、ゲームの情報(ゲーム成績、ゲームでの取得ポイント、ゲームの進行度合い、又はゲームでのキャラクタやユーザのステータス情報等)を、VRカフェに登場するキャラクタに反映させて、愛着度を変化させる。例えばゲーム成績が良いほど、或いは取得ポイントが高いほど、或いはゲームの進行度合いが進んでいるほど、愛着度を増加させる。或いは、そのキャラクタに関連する商品の過去の購入履歴情報を取得する。そして、キャラクタに関連する商品の購入の度合いに応じて、愛着度を変化させる。例えば商品の購入回数が多いほど、或いは購入頻度が高いほど、愛着度を増加させる。こうすることで、ユーザ及びキャラクタに関連する外部情報を反映させた愛着度の設定処理が可能になる。
また本実施形態では、実店舗又は仮想店舗へのユーザの来店回数、ユーザに対する課金、ユーザの位置情報、及び日時情報の少なくとも1つに応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる注文対象、及びキャラクタの対話内容の少なくとも1つを設定する。例えば、来店回数、課金、位置情報、又は日時情報に応じて、質問、メニュー、注文対象、又は対話内容を変化させる処理を行う。図18に、この処理の詳細を説明するフローチャートである。
まず、ユーザの来店回数、ユーザの課金額、ユーザの位置情報、又は日時情報を含むユーザ情報を取得する(ステップS31)。ユーザの来店回数は、前述したように実店舗又は仮想店舗への来店回数である。ユーザの課金額は、ユーザが課金に対して支払った対価の額である。ユーザの位置情報は、例えばVRカフェに対応する実店舗の位置情報や、ユーザの所持する携帯通信端末等により検出される位置情報である。日時情報は、日にちや時間についての情報である。
次に、取得されたユーザ情報に応じて、キャラクタに対するユーザの愛着度を設定する(ステップS32)。例えば来店回数が多いほど、愛着度を高くしたり、課金額が多いほど、愛着度を高くする。或いは、ユーザの位置情報や日時情報に応じて、愛着度を増減する。例えばユーザが、イベント会場などの特定の場所に来た場合には、愛着度を増加させる。また、イベント期間などの特別な期間、クリスマス、バレンタインデーなどの特別な日にち、或いは、特定の時間帯などにおいて、愛着度を増加させる。また、取得されたユーザ情報に応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる商品、或いはキャラクタの対話内容を変化させる(ステップS33)。例えば、ユーザの来店回数や課金額に応じて、ユーザに対して行う質問の回数や内容を変化させたり、メニュー自体を変化させたり、メニューに含まれる商品の種類や個数を変化させたり、キャラクタの対話内容を変化させる。或いは、ユーザの位置情報や日時情報に応じて、質問の回数や内容を変化させたり、メニューや商品の種類や個数を変化させたり、キャラクタの対話内容を変化させる。また、ユーザの回答結果と、取得されたユーザ情報に応じて、ユーザに提示する商品の決定処理を行い、ユーザの回答結果とユーザ情報に基づき決定される商品(お勧め商品)がメニューの中になかった場合には、お勧め商品非存在用の処理を実行する(ステップS34)例えば、質問に対するユーザの回答結果に加えて、ユーザの来店回数、ユーザの課金額、ユーザの位置情報、又は日時情報などのユーザ情報を加味して、お勧め商品としてユーザに提示する商品の決定処理を行う。そして、そのような商品がメニューの中になかった場合には、図12~図13(B)で説明したように、お勧め商品非存在用の処理を実行する。
以上のようにすれば、ユーザの来店回数、課金額、位置情報又は日時情報などのユーザ情報に応じて、キャラクタの愛着度を様々に変化させたり、質問、メニュー、商品又は対話内容を様々に変化させることが可能になる。またユーザ情報を反映させたお勧め商品の決定処理を実現できるようになる。
4.詳細な処理
次に本実施形態の詳細な処理例について図19、図20のフローチャートを用いて説明する。
図19では、まず、キャラクタCHA、CHBがユーザに対して質問する対話処理を実行する(ステップS41)。そしてキャラクタCHA、CHBが行った質問に対するユーザの回答を受け付ける(ステップS42)。これにより図7(A)、図7(B)に示すように、キャラクタCHAやキャラクタCHBがユーザUSに対して様々な質問を行い、これに対してユーザが応えるというような一連の対話が実現される。
そして全ての質問が終了したか否かを判断する(ステップS43)。そしてキャラクタCHA、CHBによる全ての質問が終了した場合には、キャラクタCHA、CHBが行った質問に対するユーザの回答結果に基づいて、キャラクタCHA、CHBに対応するメニューの中から、ユーザに提示する商品を選択する(ステップS44)。例えば図9(A)に示すようなメニューMA、MBの中から、図9(B)で説明したような選択処理を行うことで、ユーザに提示する商品を選択する。そして選択した商品をお勧め商品としてユーザに提示する(ステップS45)。これにより図8に示すように、キャラクタCHA、CHBのお勧め商品をユーザUSに提示できるようになり、ユーザUSによるお勧め商品の注文が可能になる。
図20では、まず仮想空間の設定処理を行う(ステップS51)。例えば図3に示すようなVRカフェが構築される仮想空間の設定処理を行う。そして、設定された仮想空間においてキャラクタを移動、動作させる処理を行う(ステップS52)。例えば図5(A)、図5(B)等に示すように、キャラクタCHAをユーザUSのいる場所に移動させたり、キャラクタCHAに会話動作を行わせる。
次にキャラクタに対するユーザの注視情報を取得する(ステップS53)。例えば図11(B)で説明したように、ユーザUSがキャラクタCHA等を注視しているか否かの情報、注視時間の情報又は注視場所の情報を、注視情報として取得する。そして、取得された注視情報に応じて、ユーザに対して行う質問、ユーザに提示するメニュー、メニューに含まれる商品、或いはキャラクタの対話内容を設定する(ステップS54)。例えば、注視情報に応じて、質問、メニュー、商品又は対話内容を変化させる。
このように図20の処理を行うことで、VRカフェのような仮想空間を設定し、この仮想空間において仮想カメラから見える画像として、ユーザUSが視界を覆うように装着するHMD200の表示画像を生成できる。そしてこの仮想空間にキャラクタを登場させ、このキャラクタの質問に対するユーザの回答結果に基づき決定された商品を、キャラクタを用いてユーザに提示できる。また、ユーザが、キャラクタを注視したか否か、或いはユーザが複数のキャラクタのうちのどのキャラクタを注視したか、或いはユーザの注視時間や注視場所に応じて、キャラクタの質問の回数や内容が変化したり、メニューが変化したり、メニューに含まれる商品の種類や個数が変化したり、キャラクタの対話内容が変化するようになる。これによりユーザの注視状況を反映させた多様な処理を実現できるようになる。
なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語(注文対象、愛着度情報等)と共に記載された用語(商品、愛着度等)は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。またキャラクタ処理、注文対象の決定処理、提示処理、愛着度の設定処理、仮想空間の設定処理、仮想カメラの背魚処理、ゲーム処理、L表示処理等も、本実施形態で説明したものに限定されず、これらと均等な手法・処理・構成も本発明の範囲に含まれる。また本発明は種々のゲームに適用できる。また本発明は、業務用ゲーム装置、家庭用ゲーム装置、又は多数のユーザが参加する大型アトラクションシステム等の種々のゲームシステムに適用できる。