以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
1.処理システム、サーバシステム、端末装置の構成
図1、図2に本実施形態の処理システムの構成例を示す。この処理システムは、サーバシステム500と端末装置TM1、TM2を含む。
サーバシステム500(情報処理システム)は、ネットワーク510を介して、端末装置TM1、TM2と通信接続される。例えばサーバシステム500はホストであり、端末装置TM1、TM2はクライアントである。サーバシステム500は例えば1又は複数のサーバ(管理サーバ、ゲームサーバ、サービス提供サーバ、コンテンツ配信サーバ、認証サーバ、データベースサーバ、通信サーバ又は課金サーバ等)により実現できる。ネットワーク510(配信網、通信回線)は、例えばインターネットや無線LAN等を利用した通信路であり、直接接続のための専用線(専用ケーブル)やイーサネット(登録商標)等によるLANの他、電話通信網やケーブル網や無線LAN等の通信網を含むことができる。また通信方法については有線/無線を問わない。
端末装置TM1、TM2は、例えばネット接続機能(インターネット接続機能)を有する端末である。そして端末装置TM1は、例えば、業務用ゲーム装置、携帯型ゲーム装置、或いは家庭用ゲーム装置などのゲーム装置である。端末装置TM2は、例えば、スマートフォン、フューチャーフォン、或いは携帯電話機などの携帯端末である。例えば、図1では端末装置TM1は業務用ゲーム装置となっており、図2では端末装置TM1は携帯型ゲーム装置となっている。但し、本実施形態はこれに限定されず、端末装置TM1が携帯端末であり、端末装置TM2がゲーム装置であってもよい。或いは、端末装置TM1、TM2の両方がゲーム装置(異なるタイプのゲーム装置)であってもよく、端末装置TM1、TM2の両方が携帯端末(異なるタイプの携帯端末)であってもよい。或いは、端末装置TM1、TM2の少なくとも一方が、例えばパーソナルコンピュータ(PC)などの情報処理装置であってもよい。
本実施形態では、端末装置TM1においては、第1のゲーム処理により、ユーザは第1のゲームをプレイできるようになっている。一方、端末装置TM2においては、第2のゲーム処理により、ユーザは第2のゲームをプレイできるようになっている。なお、第1、第2のゲーム処理は、それぞれ、端末装置TM1、TM2上で実行される第1、第2のゲームプログラムにより実現してもよいし、サーバシステム500上で実行される第1、第2のゲームプログラムにより実現してもよい。或いは、第1、第2のゲーム処理を、端末装置TM1、TM2とサーバシステム500の分散処理により実現してもよい。
図3に本実施形態のサーバシステム500(ホスト装置、情報処理システム)の構成例を示す。なお、サーバシステム500の構成は図3に限定されず、その構成要素(各部)の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
サーバシステム500は、処理部600、操作部660、記憶部670、通信部696を含む。
処理部600は、通信部696を介して受信したデータや、記憶部670に記憶されるデータ、プログラム等に基づいて、サーバの各種サービス・管理に必要な種々の処理を行う。この処理部600の機能は、各種プロセッサ(CPU、GPU等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。
処理部600は、受信処理部602、送信処理部604、制御処理部606、ゲーム処理部608、管理処理部610、画像情報生成部620、音情報生成部630を含む。
受信処理部602は、端末装置等からの情報の受信処理を行う。送信処理部604は、端末装置等への情報の送信処理を行う。ここで受信処理は、通信部696に情報の受信を指示したり、通信部696が受信した情報を取得して記憶部670に書き込む処理などである。送信処理は、通信部696に情報の送信を指示したり、送信する情報を通信部696に指示する処理などである。
制御処理部606は、各種の制御処理を行う。具体的には制御処理部606はゲーム処理の制御処理を行う。例えば制御処理部606は、図1、図2で説明した第1、第2のゲーム処理の実行や、実行の中断・中止・再開等を制御する。また、第1、第2のゲーム処理の処理モード(セーブ処理、ポーズ処理、スローモーション処理等)の制御処理なども行う。この制御処理部60の詳細については後述する。
ゲーム処理部608は、各種のゲーム処理を行う。ここでゲーム処理としては、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、ゲーム終了条件が満たされた場合にゲームを終了する処理、或いはゲーム結果を演算する処理などがある。具体的には、サーバ側がゲーム処理を行う場合には、サーバ側のゲーム処理部608が、端末装置に入力されたユーザの操作情報に基づいて、ゲームを開始したり、ゲームを進行させたり、ゲームを終了させたりするなどのゲーム処理を行う。また、ユーザの操作情報に基づいて、キャラクタ等のオブジェクトを移動させたり、動作させるゲーム処理を行う。また、例えば、第1のゲーム処理においては、ゲームステージ毎にゲーム結果(ゲーム成績)を演算する処理を行ったり、第2のゲーム処理においては、ユーザの操作毎にゲーム結果を演算する処理を行う。またゲーム処理部608は、ゲーム情報である画像情報や音情報を生成させるための処理を行う。具体的には、ゲーム画面等を端末装置に表示するためのゲーム処理や、ゲーム音を端末装置に出力させるためのゲーム処理を行う。
管理処理部610は、サーバの各種の管理処理を行う。例えば、サーバが提供する各種サービスの管理処理、サーバ管理情報などの各種情報の管理処理を行う。画像情報生成部620は、画像の生成のための情報である画像情報を生成する。音情報生成部630は、音(音声、ゲーム音、効果音)の生成のための情報である音情報を生成する。具体的には、画像情報は、本実施形態の手法により生成される画像を各端末装置TM1〜TMnにおいて生成・表示するための情報であり、画像データそのものであってもよいし、各端末装置が画像を生成・表示するために使用する各種データ(表示画面の設定データ、オブジェクトデータ等)であってもよい。音情報生成部630が生成する音情報についても同様である。
操作部660は、システムの管理者(運営者)が種々の情報を入力するためのものである。
記憶部670は、処理部600や通信部696などのワーク領域となるものであり、その機能はRAM(DRAM、SRAM、VRAM)やSSD(Solid State Drive)やHDD(Hard Disk Drive)などにより実現できる。記憶部670は、サーバ管理情報記憶部672、優先度情報記憶部674を含む。これらの詳細については後述する。
情報記憶媒体680(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク(CD、DVD)、HDD、或いはメモリ(ROM等)などにより実現できる。この情報記憶媒体680には、サーバシステム500(処理システム)の各部をコンピュータとして機能させるためのプログラムが記憶されている。
通信部696は、有線や無線のネットワーク510を介して端末装置TM1〜TMnや他の外部サーバとの通信を行うものであり、その機能は、通信用ASIC又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。
図4に本実施形態の端末装置(クライアント装置)の構成例を示す。なお、端末装置の構成は図4に限定されず、その構成要素(各部)の一部を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。図4は、図1、図2の端末装置TM1、TM2の機能的な構成例を示す図である。即ち、ゲーム装置や携帯端末の構成例を示すものである。但し、実際には端末装置TM1とTM2とでは、そのハードウェア構成が異なっている。
端末装置は、処理部200、操作部260、撮像部264、記憶部270、表示部290、音出力部292、I/F部294、通信部296を含む。
処理部200(プロセッサ)は、操作部260からの操作情報やプログラムなどに基づいて、各種サービス提供のための処理、ゲーム処理、画像表示処理、或いは音出力処理などを行う。処理部200は、記憶部270をワーク領域として各種処理を行う。この処理部200の機能は、各種プロセッサ(CPU、GPU等)、ASIC(ゲートアレイ等)などのハードウェアや、プログラムにより実現できる。
処理部200は、入力受け付け部201、受信処理部202、送信処理部204、ゲーム処理部208、表示制御部120、音制御部130を含む。
入力受け付け部201は、ユーザ(プレーヤ)からの入力情報の受け付け処理を行う。例えば操作部260を介して入力された情報の受け付け処理を行う。受信処理部202は、サーバシステムや他の端末装置等の外部装置からの情報の受信処理を行う。送信処理部204は、サーバシステムや他の端末装置等の外部装置への情報の送信処理を行う。
ゲーム処理部208は、各種のゲーム処理を行う。ゲーム処理は、前述したように、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、ゲーム終了条件が満たされた場合にゲームを終了する処理、或いはゲーム結果を演算する処理などである。例えば端末装置側がゲーム処理を行う場合には、端末装置側のゲーム処理部208が、操作部260により入力されたユーザの操作情報に基づいて、ゲームを開始したり、ゲームを進行させたり、ゲームを終了させたりするなどのゲーム処理を行う。また、ユーザの操作情報に基づいて、キャラクタ等のオブジェクトを移動させたり、動作させるなどのゲーム処理を行う。また、例えば、第1のゲーム処理においては、ゲームステージ毎にゲーム結果を演算する処理を行ったり、第2のゲーム処理においては、ユーザの操作毎にゲーム結果を演算する処理を行う。またゲーム処理部208は、ゲーム画像を生成したり、ゲームオンを生成するための処理を行う。
なお、第1、第2のゲーム処理等のゲーム処理は、図3に示すサーバ側のゲーム処理部608がサーバ上で実行してもよいし、図4に示す端末装置側のゲーム処理部208が端末装置上で実行してもよい。或いは、第1、第2のゲーム処理等のゲーム処理を、サーバ側のゲーム処理部608と端末装置側のゲーム処理部208の分散処理時により実行してもよい。例えばゲーム処理の一部を端末装置側が行い、ゲーム処理の他の部分をサーバ側が行うようにする。
表示制御部220は、表示部290に画像を表示するための制御を行う。例えば端末装置側で画像を生成する場合には、処理部200で行われる種々の処理(アプリケーション処理、ゲーム処理)の結果に基づいて描画処理を行い、これにより画像を生成し、表示部290に出力する。サーバ側で画像を生成する場合には、サーバシステムからの画像情報(画像生成用データ)に基づく画像を表示部290に表示する制御を行う。音制御部230は、処理部200で行われる種々の処理の結果に基づいて音制御を行う。これにより、BGM、効果音、又は音声などが音出力部292から出力されるようになる。
操作部260は、ユーザ(プレーヤ)が、操作情報等の種々の情報を入力するためのものであり、その機能は、操作ボタン、方向指示キー、アナログスティック、レバー、各種センサ(角速度センサ、加速度センサ等)、マイク、或いはタッチパネル型ディスプレイなどにより実現できる。
撮像部264(カメラ)は、被写体の撮像を行うものであり、CCDやCMOSセンサなどの画像センサと、フォーカスレンズ等により構成される光学系などにより実現される。
記憶部270は、処理部200や通信部296などのワーク領域となるもので、その機能はRAMやSSDやHDDなどにより実現できる。
情報記憶媒体280(コンピュータにより読み取り可能な媒体)は、プログラムやデータなどを格納するものであり、その機能は、光ディスク、HDD、或いはメモリなどにより実現できる。処理部200は、情報記憶媒体280に格納されるプログラム(データ)に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体280には、本実施形態の各部としてコンピュータ(操作部、処理部、記憶部、出力部を備える装置)を機能させるためのプログラム(各部の処理をコンピュータに実行させるためのプログラム)が記憶される。
表示部290は、本実施形態により生成された画像を出力するものであり、その機能は、LCD、有機ELディスプレイ、CRT、或いはHMDなどにより実現できる。音出力部292は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。
I/F(インターフェース)部294は、不揮発性記憶装置295(携帯型情報記憶媒体)とのインターフェース処理を行うものであり、その機能はI/F処理用のASICなどにより実現できる。不揮発性記憶装置295は、ユーザが各種の情報を保存するためのものであり、電源が非供給になった場合にもこれらの情報の記憶を保持する記憶装置である。不揮発性記憶装置295は、ICカード(メモリーカード)、USBメモリー、或いは磁気カードなどにより実現できる。
通信部296は、ネットワーク510を介して外部装置(サーバシステム、他の端末装置等)との間で通信を行うものであり、その機能は、通信用ASIC又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。
そして本実施形態では図3に示すように、サーバシステム500が、受信処理部602と送信処理部604と制御処理部606を含む。またサーバ管理情報を記憶する記憶部670(データベース)を含む。
ここで、サーバシステム500の受信処理部602は、ネットワーク510を介して情報を受信する処理を行う。送信処理部604は、ネットワーク510を介して情報を送信する処理を行う。例えば受信処理部602、送信処理部604は、第1、第2のゲーム処理等のゲーム処理を制御するための情報の受信・送信処理を行う。例えば、ゲーム処理の制御指示情報の受信・送信処理や、制御指示情報に対する応答情報の受信・送信処理を行う。また、受信処理部602、送信処理部604は、サーバ管理情報記憶部672に記憶されるサーバ管理情報の更新処理のための情報の受信・送信処理を行う。例えば更新指示情報の受信・送信処理や、更新指示情報の応答情報の受信・送信処理を行う。
またサーバシステム500の記憶部670は、ゲーム処理の更新対象となる情報を、サーバ管理情報として記憶する。具体的には、記憶部670に設けられたサーバ管理情報記憶部672が、このサーバ管理情報を記憶する。
そして本実施形態では、サーバシステム500の制御処理部606は、第1のゲーム処理の実行中に、第2のゲーム処理の実行要求(実行)が検出された場合に、ゲーム処理の競合時用の処理を行う。例えば、競合時用に予め用意された処理を行う。
例えばサーバシステム500の制御処理部606は、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出された場合に、第2のゲーム処理の実行を禁止する処理を、競合時用処理として行う。例えば第2のゲーム処理の実行要求が来た場合にも、その実行要求を受け付けず、第2のゲーム処理が実行されないように禁止する。
そして制御処理部606は、1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出された場合に、第2のゲーム処理が行われる端末装置に対して、第2のゲーム処理の実行が禁止であることを通知する処理を、競合時用処理として行う。例えば図1、図2において、端末装置TM1の第1のゲーム処理の実行中に、端末装置TM2の第2のゲーム処理の実行要求が来た場合には、端末装置TM2の表示部に対して、第1のゲーム処理が実行中であるため、第2のゲーム処理の実行を禁止する旨の通知表示を行う。このようにすることで、ユーザは、第1のゲーム処理が実行中であるため第2のゲーム処理の第2のゲームをプレイできないことを、当該通知に容易に把握できるようになる。
また制御処理部606は、第1のゲーム処理の実行中に第2のゲーム処理の実行要求(実行)が検出された場合に、第1のゲーム処理及び前記第2のゲーム処理の一方のゲーム処理を中止又は中断する処理を、競合時用処理として行う。具体的には、第1のゲーム処理の実行を中止又は中断して、第2のゲーム処理が実行されるようにする。或いは、逆に、第2のゲーム処理の実行を中止又は中断(禁止)して、第1のゲーム処理が実行されるようにする。即ち、第1、第2のゲーム処理が排他的に実行されるように、一方のゲーム処理だけを実行させる。
この場合に制御処理部606は、第1のゲーム処理及び第2のゲーム処理のいずれのゲーム処理を中止又は中断するかを、ゲーム処理の優先度情報に基づいて判断してもよい。具体的には、ゲーム進行状況情報及び課金状態情報の少なくとも一方により設定された優先度情報に基づいて判断する。
例えば図3に示すように、この優先度情報はサーバシステム500の記憶部670の優先度情報記憶部674に記憶されている。そして、この優先度情報は、例えばゲーム進行状況情報や課金状態情報などの各種情報により設定される。そして、ゲーム進行の観点から、第1、第2のゲーム処理のいずれか一方のゲーム処理が優先されると優先度情報に基づき判断した場合には、他方のゲーム処理を中止又は中断する。また、課金状態の観点から、第1、第2のゲーム処理のいずれか一方のゲーム処理が優先されると優先度情報に基づき判断した場合には、他方のゲーム処理を中止又は中断する。
また制御処理部606は、第1のゲーム処理の実行中に第2のゲーム処理の実行要求(実行)が検出された場合に、第1のゲーム処理の再開に必要なセーブ情報のセーブ処理を行う。例えば、第1のゲーム処理を再開するのに必要な各種の情報(進行状況情報、パラメータ情報)を保存する。例えばサーバ又は端末装置の記憶部に保存する。そして制御処理部606は、セーブ処理の後に第1のゲーム処理を中断して、第2のゲーム処理を実行した場合には、第2のゲーム処理の終了後に、セーブ情報に基づいて、第1のゲーム処理を再開する。即ち、第2のゲーム処理の終了後に、記憶部670に保存しておいたセーブ情報を読み出して、これらのセーブ情報に基づいてゲーム処理の再開に必要な各種の設定処理を行って、第1のゲーム処理を再開する。
また制御処理部606は、第1のゲーム処理の実行中に第2のゲーム処理の実行要求(実行)が検出された場合に、第1のゲーム処理の終了後に、第2のゲーム処理によるサーバ管理情報の更新処理を許可する。具体的には、例えば、第2のゲーム処理の実行要求が検出されると、第1のゲーム処理を中断して、第2のゲーム処理を実行し、第1のゲーム処理の終了後に、第2のゲーム処理によるサーバ管理情報の更新処理を許可する。即ち、第2のゲーム処理による更新処理を、第1のゲーム処理が終了するまでウェイトする。そして第1のゲーム処理が終了後に、第2のゲーム処理の実行結果に基づくサーバ管理情報を更新処理が行われるようにする。具体的には、ゲームパラメータ情報、ゲームアイテム情報、又はゲーム成績情報等の更新処理が行われるようにする。
また制御処理部606は、第1のゲーム処理の実行中に第2のゲーム処理の実行要求(実行)が検出された場合に、第1のゲーム処理のポーズ処理又はスローモーション処理を行う。そして例えば、ポーズ処理の期間又はスローモーション処理の期間において、第2のゲーム処理によるサーバ管理情報(ゲームパラメータ情報、ゲームアイテム情報、ゲーム成績情報等)の更新処理を許可する。
また、第1のゲーム処理のゲームが、複数のゲームステージ又は複数のゲームシーンにより構成されていたとする。例えば、複数のゲームステージを順次クリアすることで、第1のゲーム処理のゲームがクリアされる。或いは、複数のゲームシーンが順次移行して、各ゲームシーンでの映像が再生されることで、ユーザは、第1のゲームを鑑賞して楽しむ。
このとき、制御処理部606は、第1のゲーム処理の実行中に第2のゲーム処理の実行要求(実行)が検出された場合に、第2のゲーム処理によるサーバ管理情報の更新処理を、複数のゲームステージの各ステージの終了後又は複数のゲームシーンの各ゲームシーンの終了後に許可する。即ち、各ステージ又は各ゲームシーンが終了するまでは、第2のゲーム処理によるサーバ管理情報の更新処理を禁止し、各ステージ又は各ゲームシーンが終了したことを条件に、第2のゲーム処理によるサーバ管理情報の更新処理を許可する。
また制御処理部606は、第1のゲーム処理の実行中に第2のゲーム処理の実行要求(実行)が検出された場合に、第1のゲーム処理及び第2のゲーム処理の少なくとも一方のゲーム処理での画像表示又は音出力を変更する処理を、競合時処理として行ってもよい。具体的には、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出されると、第1のゲーム処理における音出力のレベルを小さくする処理を行う。或いは、第1のゲーム処理における画像表示を、競合時用に用意された画像に切り替えてもよい。
或いは制御処理部606は、第1のゲーム処理の実行中に第2のゲーム処理の実行要求(実行)が検出された場合に、第1のゲーム処理のゲーム画面に、第2のゲーム処理のゲーム画面を表示するための処理を行ってもよい。例えば第1のゲーム処理のゲーム画面に対して、第2のゲーム処理のゲーム画面をウィンドウ表示(スーパーインポーズ表示)する処理を行う。
なお第1のゲーム処理と第2のゲーム処理は、例えば同一ユーザがプレイするゲームのゲーム処理である。例えば、同一のユーザIDのユーザによりプレイされるゲーム処理である。この場合に制御処理部606は、第1のゲーム処理と第2のゲーム処理とが、同一ユーザがプレイするゲームのゲーム処理であることを、ユーザがプレイする端末装置からのユーザ識別情報に基づいて判断する。
例えば端末装置が、ユーザID(ユーザ識別情報)が書き込まれたメモリーカードを装着して、ゲームをプレイするタイプの装置である場合には、端末装置に装着されたメモリーカードからユーザIDを読み出すことで、ユーザを識別して、第1のゲーム処理と第2のゲーム処理が同一ユーザがプレイするゲームであるか否かを判断する。
一方、端末装置が、ユーザIDやパスワードによりログインして、ゲームをプレイするタイプの装置である場合には、ログイン時に入力されたユーザIDに基づいて、ユーザを識別して、第1のゲーム処理と第2のゲーム処理が同一ユーザがプレイするゲームであるか否かを判断する。
なお、第1のゲーム処理は、例えばユーザの操作情報に基づいてゲーム処理が行われ、ゲームを構成する複数のゲームステージ又は複数のゲームシーンの各ゲームステージ毎又は各ゲームシーン毎に、サーバ管理情報の更新処理が行われるゲーム処理である。
例えば、ゲームステージ(ゲームシーン)でのゲームプレイ期間においては、端末装置の操作部からの操作情報に基づきゲーム処理(リアルタイムゲーム処理)が行われ、このゲームプレイ期間ではサーバ側のサーバ管理情報は更新されない。一方、ゲームステージ(ゲームシーン)が終了すると、サーバ管理情報へのアクセスが行われて、サーバ管理情報のゲーム成績情報等の更新処理が行われる。例えば業務用ゲーム装置や家庭用ゲーム装置のゲーム(格闘技ゲーム等)では、このような第1の方式のゲーム処理が行われる場合が多い。
これに対して、第2のゲーム処理は、ユーザの操作情報の入力毎に、サーバ管理情報の更新処理が行われるゲーム処理である。例えば、ユーザが端末装置の操作部を操作する毎に、サーバのサーバ管理情報に対するアクセス要求が行われて、その操作に応じたゲームパラメータ等のサーバ管理情報の更新処理が行われる。例えば携帯端末等のアプリゲーム(ソーシャルゲーム)では、このような第2の方式のゲーム処理が行われる場合が多い。なお、第2のゲーム処理は、このような第2の方式のゲーム処理のみならず、上述の第1の方式のゲーム処理を含んでいてもよい。
2.本実施形態の手法
次に本実施形態の手法について詳細に説明する。なお、以下では、サーバシステムを、適宜、単にサーバと記載する。また、以下では、第1のゲーム処理用の端末装置がゲーム装置であり、第2のゲーム処理用の端末装置が携帯端末である場合を主に例にとり説明するが、本実施形態はこれに限定されるものではない。
2.1 競合時用処理
さて、前述した図1、図2に示すように、本実施形態では、端末装置TM1においては、第1のゲーム処理により、ユーザは第1のゲームをプレイできるようになっている。一方、端末装置TM2においては、第2のゲーム処理により、ユーザは第2のゲームをプレイできるようになっている。
ここで第1、第2のゲームは、同様のゲームタイトル(同一シリーズのゲームタイトル)のゲームであり、例えば、共通のキャラクタ、ゲームステージ、又はマップ等を使用できるようになっている。即ち、第1、第2のゲームを実現する第1、第2のゲーム処理は連携しており、ユーザは、端末装置TM1でプレイできるゲームタイトルを、端末装置TM2においてプレイできるようになっている。
このようにすれば、例えば端末装置TM1の第1のゲームで育成したキャラクタを、端末装置TM2の第2のゲームのキャラクタとして使用したり、逆に、端末装置TM2の第2のゲームで育成したキャラクタを、端末装置TM1の第1のゲームのキャラクタとして使用することが可能になり、好適な連携システムを実現できる。
例えば端末装置TM2の第2のゲームでキャラクタを育成して、そのステータス・パラメータを上昇させると、端末装置TM1の第1のゲームにおいても、ステータス・パラメータが上昇したキャラクタを使用して、ゲームをプレイできるようになる。また、例えば端末装置TM2の第2のゲームでキャラクタに武器や衣装などのアイテムを装備させると、端末装置TM1の第1のゲームにおいても、当該アイテムが装備されたキャラクタを使用して、ゲームをプレイできるようになる。
そして、このように、端末装置TM1でユーザがプレイする第1のゲームと、端末装置TM2でユーザがプレイする第2のゲームとで、共通のキャラクタやゲームステージ等をユーザが使用できるようにするためには、ゲーム処理自体は異なっていても、キャラクタ等のゲームパラメータや装備アイテム等のゲームデータについては、共通のゲームパラメータや共通のゲームデータを使用できるようにすることが望ましい。
しかしながら、このようにゲームパラメータやゲームデータ等を連携させた場合に、第1のゲーム処理と第2のゲーム処理が競合して、予期せぬ不具合等の問題が発生するおそれがある。
そこで本実施形態では、端末装置TM1の第1のゲーム処理の実行中に、端末装置TM2の第2のゲーム処理の実行要求(実行)が検出された場合に、ゲーム処理の競合時用処理を行うことで、上記問題を解決している。
例えば図5(A)に示すように、第1のゲーム処理の実行の際には、サーバ上のサーバ管理情報が参照されて、その更新処理が行われる。同様に、第2のゲーム処理の実行の際にも、サーバ上のサーバ管理情報が参照されて、その更新処理が行われる。このサーバ管理情報は、図3に示すようにサーバのサーバ管理情報記憶部672に記憶されている。
ここでサーバ管理情報は、サーバの管理対象(更新対象)となる各種情報であり、図5(A)、図5(B)に示すように、例えばゲームパラメータ情報、ゲームアイテム情報、ゲーム成績情報(ゲーム結果情報)、或いはユーザ情報などである。
ゲームパラメータ情報は、ゲーム処理における各種の判断処理(ゲーム進行の判断処理、ゲーム結果の判断処理等)や設定処理に使用されるパラメータ(変数)である。ゲームパラメータとしては、例えばキャラクタ等の状態(体力、攻撃力、守備力、耐久度、レベル等)を量的、質的に表すステータス・パラメータなどがある。ゲームアイテム情報は、ゲームに登場して使用される各種のアイテムの情報である。アイテムとしては、例えばキャラクタが身につける武器アイテム等の装着アイテム、キャラクタのステータスを変更する回復アイテム等のステータス変更アイテム、或いはキャラクタを成長させるための成長アイテムなどがある。ゲーム成績情報は、ゲームにおけるユーザ(プレーヤ)の得点やポイントや勝敗などを表す情報である。ユーザ情報は、例えばユーザの個人情報などであり、ユーザID、パスワード、性別、生年月日、或いは住所等などである。
そして図5(A)、図5(B)に示すように、第1のゲーム処理と第2のゲーム処理は、同じサーバ管理情報を更新対象とするゲーム処理である。例えば、第1のゲーム処理と第2のゲーム処理とは、図3のサーバ管理情報記憶部672に記憶されるゲームパラメータ情報、ゲームアイテム情報、ゲーム成績情報、或いはゲーム成績情報などのサーバ管理情報を、共通のサーバ管理情報として、その更新処理の対象とする。
例えば、第1のゲーム処理による第1のゲームと、第2のゲーム処理による第2のゲームには、共通のキャラクタが登場する。そして、この共通のキャラクタのステータス・パラメータなどのゲームパラメータ情報は、第1のゲーム処理によって更新されると共に、第2のゲーム処理によっても更新される。
また、第1のゲーム処理による第1のゲームと、第2のゲーム処理による第2のゲームには、共通のアイテムが登場する。そして、この共通のアイテムの情報は、第1のゲーム処理によって更新されると共に、第2のゲーム処理によっても更新される。例えば第1、第2のゲームのいずれか一方のゲームおいて、アイテムが獲得されると、他方のゲームにおいても、そのアイテムが獲得されて登場するようになる。また第1、第2のゲームのいずれか一方のゲームにおいて、ユーザのゲーム成績が演算されて更新されると、他方のゲームにおいても、ユーザのゲーム成績が更新されるようになる。
ここで、例えば図6(A)に示すように、第1のゲーム処理の実行中に、第2のゲーム処理の実行要求があり、第1のゲーム処理と第2のゲーム処理が同時に実行された場合を想定する。
このような場合には、第1のゲーム処理と第2のゲーム処理の両方により、ゲームパラメータ情報やゲームアイテム情報などのサーバ管理情報が更新されてしまうと、サーバ管理情報に不具合が発生するおそれがある。即ち、サーバ管理情報のゲームパラメータ情報やゲームアイテム情報に矛盾等が生じ、最悪の場合、第1のゲーム処理と第2のゲーム処理の両方がハングアップするような事態が生じるおそれがある。
そこで本実施形態では、図6(B)に示すように、第1のゲーム処理の実行中に、第1のゲーム処理と同じサーバ管理情報を更新対象とする第2のゲーム処理の実行要求が検出された場合に、ゲーム処理の競合時用の処理を実行する。
このようにすれば、このゲーム処理の競合時用の処理が実行されることで、第1のゲーム処理と第2のゲーム処理の競合による不具合の発生等を抑制することが可能になり、サーバ管理情報のゲームパラメータ情報やゲームアイテム情報に矛盾等が生じ、第1、第2のゲーム処理の両方がハングアップするような事態の発生を効果的に防止できる。
ここで、ゲーム処理の競合時用の処理は、第1のゲーム処理と第2のゲーム処理が競合した場合のために、例えば予め用意された処理であり、競合時用の制御処理としてプログラミングされた処理であり、サーバの制御処理部606により実行される。なお、以下では制御処理部606の競合時用処理の対象となるゲーム処理が、第1、第2のゲーム処理というように2つのゲーム処理である場合を主に例にとり説明するが、本実施形態はこれに限定されない。例えば競合時用処理の対象となるゲーム処理は、例えば第1〜第3のゲーム処理というように3つ以上のゲーム処理であってもよい。
2.2 第1、第2のゲーム処理
次に、第1、第2のゲーム処理や第1、第2のゲーム処理により実現される第1、第2のゲームの具体例について説明する。
図7(A)、図7(B)は第1のゲーム処理とそれにより実現される第1のゲームの例である。この第1のゲームは、いわゆる格闘技ゲームである。この第1のゲームでは、ユーザは図4の操作部260を操作して、自身が操作するキャラクタであるプレーヤキャラクタCHPを操作する。そして、コンピュータ又は相手プレーヤが操作する敵キャラクタCHEと対戦する。そして、敵キャラクタCHEのヒットポイントが0になるなどの所定条件が満たされると、ユーザの勝利となり、図7(B)に示すような画面が表示される。
このように第1のゲーム処理は、ユーザの操作情報に基づいて、ゲーム処理が行われ、ゲームを構成する複数のゲームステージ(又は複数のゲームシーン)の各ゲームステージ毎(又は各ゲームシーン毎)に、サーバ管理情報の更新処理が行われるゲーム処理である。
即ち、図7(A)に示すように、ユーザが入力した操作情報(ゲーム操作)に基づいて、複数のゲームステージ(又は複数のゲームシーン)の各ゲームステージ(又は各ゲームシーン)での処理が行われる。例えば操作情報に基づいて、プレーヤキャラクタCHPを動作させるなどの処理(モーション処理)が行われる。そして、このゲームステージ(ゲームシーン)の期間内では、サーバ管理情報へのアクセスは行われず、サーバ管理情報の更新処理は行われない。
一方、ゲームステージ(ゲームシーン)が終了すると、サーバ管理情報へのアクセスが行われ、サーバ管理情報の更新処理が行われる。具体的には、各ゲームステージでのゲーム結果に基づいて、サーバ管理情報のゲーム成績情報が更新される。例えばゲームステージの勝敗結果等に基づいて、ゲーム成績情報の勝敗情報等が更新される。また各ゲームステージでのゲーム結果に基づいて、サーバ管理情報のキャラクタのパラメータ情報の更新処理が行われる。例えば、ゲームステージでのゲーム結果に基づいて、キャラクタのステータス・パラメータが更新され、キャラクタの育成処理等が行われる。
図8(A)、図8(B)は、第2のゲーム処理とそれにより実現される第2のゲームの例である。この第2のゲームは、いわゆるソーシャルゲーム等で行われる手法のゲームである。例えばユーザは図8(A)のA1に示すようにゲーム画面上に表示された実行ボタンをタッチする。すると、例えば敵への攻撃等が行われる。そして、敵の撃破に成功すると、図8(B)に示すようなゲーム画面が表示される。
そして、この第2のゲーム処理では、A1に示すようにユーザがゲーム操作を行う毎に、A2に示すようにサーバへのアクセス処理が行われて、ゲームパラメータ情報等のサーバ管理情報の更新が行われる。このように第2のゲーム処理は、ユーザの操作情報の入力毎に、サーバ管理情報の更新処理が行われるゲーム処理である。例えばソーシャルゲーム等では、ハードウェア等の制約から、そのゲーム処理の処理負荷を軽くする必要がある。また、ゲームプレイへのユーザの拘束時間を少なくして、ユーザが手軽にゲームを楽しめるようにしている。このため図8(A)、図8(B)に示すような簡素な操作でゲーム処理が実行されて、ユーザがゲームを手軽に楽しめるようになっている。
図9(A)、図9(B)は、第2のゲーム処理の他の例である。この第2のゲーム処理では、自身が操作するキャラクタのパワーアップや育成のために、アイテムをネット購入するためのゲーム処理が行われる。例えば図9(A)では、ユーザが選択したゲームタイトルにおいてネット購入できる商品のリストが表示される。そして、ユーザが端末装置の操作部260を操作して、図9(B)のように商品であるアイテムを購入すると、サーバのサーバ管理情報へのアクセスが行われ、サーバ管理情報のゲームアイテム情報等が更新される。
なお、以上では、図7(A)、図7(B)のようなゲーム処理を、第1のゲーム処理として、図8(A)〜図9(B)のようなゲーム処理を、第2のゲーム処理としたが、本実施形態はこれに限定されない。例えば、逆に、図7(A)、図7(B)のようなゲーム処理を、第2のゲーム処理として、図8(A)〜図9(B)のようなゲーム処理を、第1のゲーム処理としてもよい。
2.3 競合時用処理の第1の例
図10に、ゲーム処理の競合時用処理の第1の例を示す。図10では、第1のゲーム処理の実行中に、第2のゲーム処理の実行要求が検出されている。前述した図5(A)、図5(B)に示すように、この第2のゲーム処理は、第1のゲーム処理と同じサーバ管理情報(同じ記憶領域に記憶されるサーバ管理情報)を更新対象とするゲーム処理である。
このように、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出された場合に、図10では、第2のゲーム処理の実行を禁止する処理を、競合時用処理として行っている。更に、第2のゲーム処理が行われる端末装置に対して、第2のゲーム処理の実行が禁止であることを通知する処理を、競合時用処理として行っている。
例えばユーザが業務用ゲーム装置で図7(A)、図7(B)に示す第1のゲームをプレイしていたとする。このような場合に、そのユーザが、図7(A)、図7(B)で操作しているキャラクタCHPと同じキャラクタを用いて図8(A)、図8(B)に示すようなゲームをプレイしたり、図9(A)、図9(B)に示すようにアイテムを購入したとする。すると、図7(A)、図7(B)で戦闘中のキャラクタCHPのゲームパラメータの値が、予期しない値に変更されてしまったり、図8(A)、図8(B)のアイテム購入により、図7(A)、図7(B)の戦闘中のキャラクタが不正にパワーアップしてしまうなどの事態が生じる。
従って、このような場合には、図7(A)、図7(B)の第1のゲーム処理を優先して、図8(A)〜図9(B)の第2のゲーム処理については、その実行を禁止するようにする。また、実行が禁止されたことをユーザに知らせるために、実行の禁止を通知する表示を、例えば第2のゲームを行っている端末装置(図1、図2のTM2)の表示部に表示する。
このような競合時用の処理を行えば、第1のゲーム処理の実行中は、第2のゲーム処理が禁止されて、実行されないようになる。従って、第1、第2のゲーム処理が並列に実行されて、サーバ管理情報等にデータの不整合が生じたり、第1、第2のゲーム処理の両方がハングアップするような事態の発生を効果的に防止できる。具体的には、第1のゲームの途中で、第1のゲームのキャラクタのパラメータや所持アイテムが変更されてしまうような事態の発生を防止できる。また、第2のゲーム処理の実行が禁止された旨をユーザに伝えることで、ユーザが不自然に思うなどの事態を防止でき、ユーザの利便性を向上できる。
2.4 競合時用処理の第2の例
図11(A)、図11(B)に、ゲーム処理の競合時用処理の第2の例を示す。図11(A)では、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出されると、制御処理部606は、第1のゲーム処理及び第2のゲーム処理の一方のゲーム処理を中止又は中断する処理を、競合時用処理として行う。
例えば図11(A)において、第2のゲーム処理の方を優先する場合には、制御処理部606は、第1のゲーム処理の実行を中止又は中断する。そして、第2のゲーム処理だけが実行されるように制御する。そして、このような競合時に第1のゲーム処理を中断した場合には、例えば第2のゲーム処理の終了後に、第1のゲーム処理を再開する。一方、第1のゲーム処理の方を優先する場合には、制御処理部606は、第2のゲーム処理を中止又は中断(禁止)する。そして、第1のゲーム処理だけが実行されるように制御する。
このような競合時用の処理を行えば、第1、第2のゲーム処理の一方が中止又は中断されるため、第1、第2のゲーム処理が並列に実行されてしまう事態を防止できる。従って、第1、第2のゲーム処理が並列に実行されて、サーバ管理情報等にデータの不整合が生じたり、ゲーム処理のハングアップ等の事態が発生するのを防止できる。
そして図11(A)のように、第1、第2のゲーム処理の一方を中止又は中断する場合には、その判断基準として、優先度情報を用いることが望ましい。
具体的には図11(B)に示すように、制御処理部606は、第1、第2のゲーム処理のいずれのゲーム処理を中止又は中断するかを、ゲーム処理の優先度情報に基づいて判断する。例えば、優先度情報に基づいて、第1のゲーム処理の方がゲーム処理の優先度が高いと判断された場合には、第2のゲーム処理を中断又は中止する。一方、優先度情報に基づいて、第2のゲーム処理の方がゲーム処理の優先度が高いと判断された場合には、第1のゲーム処理を中断又は中止する。
この場合に優先度情報は、図11(B)に示すよう、例えばゲーム進行状況情報や課金状態情報に基づき設定できる。
例えば図11(B)において、第1のゲーム処理のゲーム進行が進んでおり、第1のゲーム処理を中止又は中断することが望ましくない場合がある。例えば長いゲームステージの後半まで第1のゲーム処理のゲーム進行が進んでいる場合には、第1のゲーム処理の方を優先すべきである。従って、この場合には、ゲーム進行状況情報に基づき設定された優先度情報に基づいて、第2のゲーム処理を中止又は中断し、第1のゲーム処理の実行を継続する。
また、例えば第1のゲーム処理による第1のゲームが、例えば1ゲームのプレイ毎にゲーム料金を投入するゲーム(例えば業務用ゲーム装置のゲーム)であり、第2のゲーム処理による第2のゲームが、例えば月単位でゲーム料金を支払うゲーム(例えばソーシャルゲーム等のゲームアプリ)であったとする。この場合には、1ゲーム分のゲーム料金が投入されてゲームプレイが行われている第1のゲーム処理の方を中止又は中断するのは適切ではない。従って、この場合には、課金状態情報に基づき設定された優先度情報に基づいて、第2のゲーム処理の実行の方を中止又は中断し、第1のゲーム処理の実行を継続する。
なお、このようなゲーム処理の中止、中断を判断する基準となる優先度情報の設定は、ゲーム進行状況情報や課金状態情報による設定には限定されず、種々の変形実施が可能である。例えば第1のゲームがメインのゲームであり、第2のゲームがサブのゲームである場合には、常に第1のゲーム処理の方を優先するというような優先度情報の設定にしてもよい。
2.5 競合時用処理の第3の例
図12(A)、図12(B)に、ゲーム処理の競合時用処理の第3の例を示す。図12(A)では、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出されると、制御処理部606は、競合時用の処理として、第1のゲーム処理のセーブ情報のセーブ処理を行う。即ち、第1のゲーム処理の再開に必要な様々なデータをセーブ情報として保存する。そして図12(A)に示すように、セーブ処理の後に、第1、第2のゲーム処理のいずれか一方のゲーム処理を実行する。この場合に他方のゲーム処理については中止又は中断する。
また図12(B)に示すように、セーブ処理の後に、第1のゲーム処理を中断して、第2のゲーム処理を実行したとする。この場合には、第2のゲーム処理の終了後に、セーブ情報に基づいて、第1のゲーム処理を再開する。
即ち、セーブ処理後に第1のゲーム処理を中断して、その中断期間において、第2のゲーム処理を実行する。このようにすれば、この中断期間では、第1、第2のゲーム処理が並列に実行されないようになる。従って、不正な更新処理によりサーバ管理情報等にデータの不整合が生じたり、ゲーム処理のハングアップ等の事態が発生するのを防止できる。
また、第2のゲーム処理が終了した後に、セーブ情報に基づいて第1のゲーム処理を再開すれば、第2のゲーム処理のみならず、第1のゲーム処理についても、その処理の最後まで実行して、第1のゲーム処理を適正に終了させることが可能になる。
2.6 競合時用処理の第4の例
図13に、ゲーム処理の競合時用処理の第4の例を示す。図13では、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出された場合に、第1のゲーム処理の終了後に、第2のゲーム処理によるサーバ管理情報の更新処理を許可する。更に具体的には、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出されると、第1のゲーム処理を中断して、第2のゲーム処理を実行する。即ち、第2のゲーム処理の方を優先して実行する。そして、第2のゲーム処理が終了し、その後に、例えば第1のゲームが再開されて終了すると、その第1のゲーム処理の終了後に、第2のゲーム処理によるサーバ管理情報の更新処理を許可する。
このようにすれば、第1のゲーム処理の実行期間中に、第2のゲーム処理の方を優先して実行した場合においても、その第2のゲーム処理によるサーバ管理情報の更新処理により、サーバ管理情報にデータの不整合等の不具合が発生するのを効果的に防止できる。
具体的には、第1のゲーム処理の実行期間中に、第2のゲーム処理の方を優先して実行して、第2のゲーム処理が終了した場合に、その第2のゲーム処理の終了時点では、第2のゲーム処理によるサーバ管理情報の更新処理は行わないようにする。
そして、その後に、第1のゲーム処理が再開され、第1のゲーム処理が終了すると、その終了時点において、第1のゲーム処理によるサーバ管理情報の更新処理を行う。これにより、第1のゲーム処理の結果が、サーバ管理情報に対して反映されることになる。
そして、その後に、第2のゲーム処理によるサーバ管理情報の更新処理を行う。このようにすれば、第1のゲーム処理によるサーバ管理情報の更新処理が行われた後に、第2のゲーム処理によるサーバ管理情報の更新処理が行われることになる。従って、サーバ管理情報の更新処理に競合が起きて、サーバ管理情報にデータの不整合が生じるなどの事態を効果的に防止できる。
なお、上記では、第1のゲーム処理の終了後に、第1のゲーム処理によるサーバ管理情報の更新処理を行い、その後に、第2のゲーム処理によるサーバ管理情報の更新処理を行う場合について説明したが、本実施形態はこれに限定されない。例えば、第1のゲーム処理の終了後に、第2のゲーム処理によるサーバ管理情報の更新処理を行い、その後に、第1のゲーム処理によるサーバ管理情報の更新処理を行ってもよい。この場合に、第1、第2の処理のいずれのゲーム処理によるサーバ管理情報の更新処理を優先するかは、図11(B)で説明したような優先度情報などに基づいて判断すればよい。
2.7 競合時用処理の第5の例
図14に、ゲーム処理の競合時用処理の第5の例を示す。図14では、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出された場合に、第1のゲーム処理のポーズ処理又はスローモーション処理を行う。そして例えば、このポーズ処理又はスローモーション処理の期間において、第2のゲーム処理によるサーバ管理情報の更新処理を許可する。
例えば第1のゲーム処理が、図7(A)、図7(B)のような格闘技ゲームの処理であり、第2のゲーム処理が、図9(A)、図9(B)のようなアイテムをネット購入するための処理であったとする。
この場合に、ユーザは、例えば図7(A)、図7(B)のように格闘技ゲームをプレイしている途中で、自身のキャラクタCHPをパワーアップ等するアイテムを購入して、戦闘を有利に進めたい場合もある。具体的には、業務用ゲーム装置(図1のTM1)で図7(A)、図7(B)の格闘技ゲームをプレイしている最中に、スマートフォン等の携帯端末(図1のTM2)を用いて、キャラクタCHPのパワーアップ用のアイテムをネット購入する。そして、不利な戦況等を解消して、逆転勝利等を狙う場合がある。
例えば、このようなゲーム途中によるアイテム購入を、不正使用であるとして認めない場合には、図10で説明した手法により、第2のゲーム処理の実行を禁止すればよい。
しかしながら、このようなゲーム途中によるアイテム購入を認めることで、逆に、これまでにないタイプのゲームを創出して、ゲームの面白みを増すことができる。
ところが、図7(A)、図7(B)の格闘技ゲームの処理は、リアルタイム処理であるため、この第1のゲーム処理が通常の処理速度で実行されてしまうと、ユーザがアイテム等を購入する期間を確保できなくなってしまう。例えば業務用ゲーム装置で格闘技ゲームをプレイしながら、スマートフォン等の携帯端末でアイテムを購入するのは、難易度が高い。
そこで、このような場合に対応するために、図14では、アイテム購入等のための第2のゲーム処理の実行が要求されると、リアルタイム処理である第1のゲーム処理のポーズ処理又はスローモーション処理を行う。
このようにすれば、ユーザは、このポーズ処理又はスローモーション処理の期間を利用して、第2のゲーム処理によりアイテムをネット購入し、自身が操作中のプレーヤキャラクタCHPをパワーアップさせることなどが可能になる。或いは、対戦相手である敵キャラクタCHEとの相性を考えたアイテム装備などを行うことも可能になる。従って、これまでにないタイプのネットワークゲームの連携システムを実現できる。
なお、第1のゲーム処理のポーズ処理やスローモーション処理は、キャラクタ等のモデルオブジェクトのモーション処理を制御することで実現可能である。具体的には、ポーズ処理では、キャラクタ等のモデルオブジェクトのモーションが停止するようにモーション処理を制御する。またスローモーション処理では、モデルオブジェクトのモーション速度が遅くなるようにモーション処理を制御する。
モーション処理は、モデルオブジェクトのモーションを、モーションデータ記憶部に記憶されているモーションデータに基づいて再生することなどで実現できる。例えばモデルオブジェクトのスケルトンを構成する骨(モーション骨、関節、パーツオブジェクト)の位置、回転角度が、モーションデータとして記憶される。例えば、キャラクタ等の歩きモーションが、複数の基準モーションにより構成されている場合に、これらの各基準モーションでの各骨の位置又は回転角度が、モーションデータとして予め記憶されている。そして、例えば第1の基準モーションの各骨(各パーツオブジェクト)の位置、回転角度を読み出し、次に第2の基準モーションの各骨の位置、回転角度を読み出すというように、基準モーションのモーションデータを時間経過に伴い順次読み出すことで、モーション処理が実現される。そして、上述のポーズ処理やスローモーション処理は、この基準モーションのモーションデータの読み出し速度等を制御することで実現できる。
以上のように本実施形態の種々の処理例について説明したが、本実施形態はこれに限定されず、種々の変形実施が可能である。
例えば図15には、第2のゲーム処理によるサーバ管理情報の更新処理の他の例を示す。図15では、第1のゲーム処理のゲームは、複数のゲームステージにより構成される。即ち、一連の複数のゲームステージの各ゲームステージを順次クリアすることで、ゲームを進めて行く。或いは、第1のゲーム処理のゲームは、複数のゲームシーンにより構成され、ゲームシーンの切り替わりイベントが発生する毎に、ゲームシーンが切り替わって行く。例えば各ゲームシーンは、CGムービーなどの映像単位で構成される。
そして図15では、このような第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出されると、第2のゲーム処理によるサーバ管理情報の更新処理を、各ゲームステージの終了後又は各ゲームシーンの終了後に許可する。
例えば図15のように、第1のゲーム処理の第1のゲームステージの期間において、第2のゲーム処理の実行要求が来た場合には、この第1のゲームステージの期間内においては、第2のゲーム処理によるサーバ管理情報の更新処理を不許可とする。そして、第1のゲームステージが終了した後に、第2のゲーム処理によるサーバ管理情報の更新処理を許可して実行させる。
同様に、第1のゲーム処理の第2のゲームステージの期間において、第2のゲーム処理の実行要求が来た場合には、この第2のゲームステージの期間内においては、第2のゲーム処理によるサーバ管理情報の更新処理を不許可とする。そして、第2のゲームステージが終了した後に、第2のゲーム処理によるサーバ管理情報の更新処理を許可して実行させる。
このようにすれば、第1のゲーム処理のゲームにおいて区切りが良いタイミングで、サーバ管理情報の更新処理を実行できるようになる。例えば、ゲームステージやゲームシーンが終了して、例えば第1のゲーム処理によるサーバ管理情報の更新処理が終了した後に、第2のゲーム処理によるサーバ管理情報の更新処理を行うというような制御処理が可能になる。従って、サーバ管理情報の更新処理の競合により、サーバ管理情報にデータの不整合等が生じる事態を、効果的に抑制できる。
また本実施形態では、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出された場合に、第1のゲーム処理及び前記第2のゲーム処理の少なくとも一方のゲーム処理での画像表示又は音出力を変更する処理を、競合時処理として行ってもよい。
例えば図16では、第1のゲーム処理の実行中に、第2のゲーム処理の実行要求があった場合に、第1のゲーム処理での音出力レベルを小さくしている。例えば第1のゲーム処理として図7(A)、図7(B)に示すような格闘技ゲームなどの処理が行われていると、ゲーム装置の音出力レベルが非常に大きくなっている場合が想定される。従って、例えば図14に示すようなポーズ処理等を行ったとしても、音出力レベルの大きさが邪魔になって、ユーザがスムーズはゲーム操作を行えない事態が生じるおそれがある。この点、このような場合に、例えば第1のゲーム処理による音出力レベルを低くすれば、ユーザのスムーズなゲーム操作等を実現することができ、ユーザの利便性を向上できる。
或いは、第1のゲーム処理の実行中に第2のゲーム処理の実行要求が検出された場合に、第1のゲーム処理のゲーム画面に、第2のゲーム処理のゲーム画面を表示するための処理を行ってもよい。
例えば図17では、第1のゲーム処理の第1のゲームとして、図7(A)、図7(B)で示すような格闘技ゲームがプレイされており、このような格闘技ゲームの際に、例えば第2のゲーム処理として、図9(A)、図9(B)に示すようなアイテムの購入処理が行われている。
このような場合に図17のB1に示すように、第2のゲーム処理であるアイテムの購入処理のゲーム画面を、第1のゲーム処理のゲーム画面上に表示する。
このようにすれば、ユーザは、格闘技ゲーム等の第1のゲームのゲーム画面を見ながら、このゲーム画面上で、アイテムの購入についても確認できるようになる。従って、ユーザは、スムーズな操作でアイテムを購入できるようになり、ユーザにとって利便性の高いインターフェース環境を提供できる。
なお、以上に説明した第1、第2のゲーム処理は、例えば同一ユーザがプレイするゲームのゲーム処理である。即ち本実施形態では、例えば第1のユーザがプレイする第1のゲーム処理の実行中に、同じ第1のユーザがプレイする第2のゲーム処理の実行要求が検出された場合に、ゲーム処理の競合時用の処理を行う。具体的な状況としては、例えばゲームセンター等のアミューズメント施設で、第1のユーザが図7(A)、図7(B)に示すような第1のゲーム処理による第1のゲームをプレイし、そのプレイの最中に、その第1のユーザが、図8(A)、図8(B)や図9(A)、図9(B)に示すような第2のゲーム処理による第2のゲームをプレイする。本実施形態では、このような状況において、ゲーム処理の競合時用の処理を行う。
この場合に、第1のゲーム処理と第2のゲーム処理とが、同一ユーザがプレイするゲームのゲーム処理であることは、ユーザがプレイする端末装置からのユーザ識別情報に基づいて判断することができる。
例えば図18において、ユーザは、業務用ゲーム装置TM1で第1のゲームをプレイし、携帯端末TM2で第2のゲームをプレイしている。
そして、業務用ゲーム装置TM1では、いわゆるICカード(メモリーカード)にユーザIDが記憶されており、このICカードを、業務用ゲーム装置のカードリーダー等に装着したり、かざすことで、ユーザIDが読み取られ、業務用ゲーム装置TM1でプレイしているユーザが第1のユーザであることが認識される。
一方、携帯端末TM2では、そのゲームタイトルをプレイする際に、ユーザIDやパスワードを入力してログインするため、その時のユーザIDに基づいて、携帯端末TM2でそのゲームタイトルをプレイしているユーザが第1のユーザであることが認識される。
そして、業務用ゲーム装置TM1でプレイしているユーザが第1のユーザであり、携帯端末TM2で同じゲームタイトルをプレイしているユーザが同じ第1のユーザであり、且つ、業務用装置TM1の第1のゲーム処理と携帯端末TM2の第2のゲーム処理が競合している判断された場合に、本実施形態の競合時用処理が実行されることになる。
このようにすれが、第1のユーザについてのサーバ管理情報が、第1、第2のゲーム処理の競合により、そのデータに不整合が起きるなどの不具合を、効果的に防止できるようになる。
3.詳細な処理例
次に本実施形態の詳細な処理例について図19〜図22のフローチャートを用いて説明する。
図19は、図10で説明した手法の詳細な処理例を示すフローチャートである。まず、第1のゲーム処理を実行する(ステップS1)。そして、この第1のゲーム処理の実行中に第2のゲーム処理の実行が要求されたか否かを判断する(ステップS2)。そして、第2のゲーム処理の実行が要求された場合には、第2のゲーム処理の実行を禁止する(ステップS3)。そして、この実行禁止の通知を、第2のゲーム処理のゲーム画面に表示する(ステップS4)。
図20は、図11(A)、図11(B)で説明した手法の詳細な処理例を示すフローチャートである。まず、第1のゲーム処理を実行する(ステップS11)。そして、この第1のゲーム処理の実行中に第2のゲーム処理の実行が要求されたか否かを判断する(ステップS12)。そして、第2のゲーム処理の実行が要求された場合には、ゲーム処理についての優先度情報を参照してゲーム処理の優先度を判断する(ステップS13)。そして優先度情報に基づいて、第1のゲーム処理と第2のゲーム処理のいずれか一方のゲーム処理を中止又は中断する処理を行う(ステップS14)。
図21は、図12(A)、図12(B)、図13で説明した手法の詳細な処理例を示すフローチャートである。まず、第1のゲーム処理を実行する(ステップS21)。そして、この第1のゲーム処理の実行中に第2のゲーム処理の実行が要求されたか否かを判断する(ステップS22)。そして、第2のゲーム処理の実行が要求された場合には、第1のゲーム処理のセーブ情報のセーブ処理を行う(ステップS23)。そして第1のゲーム処理を中断する(ステップS24)。
次に、第2のゲーム処理を実行する(ステップS25)。そして、第2のゲーム処理が終了したか否かを判断する(ステップS26)。そして、第2のゲーム処理が終了した場合には、ステップS23で保存されたセーブ情報に基づいて、第1のゲーム処理を再開する(ステップS27)。
次に、再開した第1のゲーム処理が終了したか否かを判断する(ステップS28)。そして第1のゲーム処理が終了したと判断した場合に、第2のゲーム処理によるサーバ管理情報の更新処理を許可する(ステップS29)。
図22は、図14で説明した手法の詳細な処理例を示すフローチャートである。まず、第1のゲーム処理を実行する(ステップS31)。そして、この第1のゲーム処理の実行中に第2のゲーム処理の実行が要求されたか否かを判断する(ステップS32)。そして、第2のゲーム処理の実行が要求された場合には、第1のゲーム処理のポーズ処理又はスローモーション処理を行う(ステップS33)。
次に、第2のゲーム処理を実行する(ステップS34)。そして、この際に、第2のゲーム処理によるサーバ管理情報の更新処理を許可する(ステップS35)。
次に、第2のゲーム処理が終了したか否か(一定時間が経過したか否か)を判断する(ステップS36)。そして第2のゲーム処理が終了した場合(一定時間が経過した場合)には、ステップS33で開始した第1のゲーム処理のポーズ処理又はスローモーション処理を解除する(ステップS37)。
なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語(端末装置等)と共に記載された用語(ゲーム装置・携帯端末等)は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。また、ゲーム処理の競合時用処理、第1、第2のゲーム処理、第1、第2のゲーム処理の制御処理、サーバ管理情報の更新・管理処理、情報の送受信処理等も本実施形態で説明したものに限定されず、これらと均等な手法も本発明の範囲に含まれる。