JP2008073259A - ゲーム装置 - Google Patents

Abstract

【課題】ゲームプログラムが扱いやすいセーブデータを提供する。
【解決手段】セーブ用ＡＰＩ処理モジュール３００ａは、データセーブ用のセーブデータユーティリティ関数がアプリケーション処理部１２４により呼び出されることで構成される。状態取得部３１０は、ゲームプログラムの実行環境の状態を示す状態情報を取得し、付加処理部３２４は、取得された状態情報を、ゲームデータ取得部３２２により取得されたゲームデータに付加情報として付加して、ハードディスクに記憶する。一方、ロード用ＡＰＩ処理モジュール３００ｂにおける付加情報取得部３４２は、セーブデータから付加情報を取得し、判定部３４４が、現在の状態情報と付加情報との一致性を判定する。この判定結果は、通知部３４６によりアプリケーション処理部１２４に通知される。
【選択図】図５

Description

本発明は、ゲームアプリケーションを実行するゲーム装置に関し、特にゲームデータをセーブおよび／またはロードする機能を備えたゲーム装置に関する。

ユーザは、ゲームプレイの進行状況を記憶装置に格納（セーブ）しておくことで、記憶装置に格納したゲームデータを用いて、前回の続きからゲームをプレイすることができる。セーブデータは、たとえばゲームアプリケーションに対応付けられたディレクトリに格納される。ゲーム装置は、実行するゲームアプリケーションに対応付けられるディレクトリからセーブデータを内部メモリにロードする。

たとえば育成シミュレーションゲームは、時間をかけてキャラクタを成長させることを楽しませるゲームであるが、成長したキャラクタのセーブデータが実行ユーザ以外のユーザに対して複製されると、そのユーザは、いきなり高いレベルのキャラクタデータを取得できることになり、ゲームの意味が台無しにされる。他の種類のゲームでも事情は同じであり、セーブデータの複製が安易に行われるようになると、自力でゲームを進行させようとする意欲が減退するため、ゲームアプリケーションの価値を低減することにもつながる。

このような事情のもとでは、ゲーム装置が、ゲームアプリケーションに対して、必要な場合に何らかの対策を講じることができるような環境を提供することが好ましい。なお、他人の高レベルなセーブデータを複製したいという要望の度合いは、ゲームアプリケーションにより異なるため、ゲーム装置により提供される環境を利用するか否かは、ゲームアプリケーションごとに設定されることが好ましい。

そこで本発明は、ゲームプログラムが所望の処理を可能とするセーブデータに関する技術を提供することを目的とし、またそのようなセーブデータを処理する技術を提供することを目的とする。

上記課題を解決するために、本発明のある態様のゲーム装置は、ゲームプログラムを実行するアプリケーション処理部と、ゲーム進行に関するゲームデータを記憶装置にセーブするセーブ処理部と、セーブデータを記憶装置からロードするロード処理部と、ゲームプログラムの実行環境の状態を示す状態情報を取得する状態取得部とを備える。セーブ処理部は、状態取得部により取得された状態情報を、ゲームデータに付加情報として付加して記憶装置に記憶する付加処理部を備え、ロード処理部は、記憶装置に記憶されたゲームデータから付加情報を取得する付加情報取得部と、状態取得部により取得された状態情報と、付加情報取得部により取得された対応する付加情報との一致性を判定する判定部と、判定結果をアプリケーション処理部に通知する通知部とを備える。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明の情報処理技術によると、ゲームプログラムが所望の処理を可能とするセーブデータに関する技術を提供することができ、またそのようなセーブデータを処理する技術を提供することが可能となる。

図１は、本発明の実施例にかかるゲームシステムを示す。ゲームシステム１は、ゲームアプリケーションを実行するゲーム装置１０と、ゲーム装置１０における処理結果を出力する出力装置１２とを備える。

ゲーム装置１０は、ゲームアプリケーションを処理して、ゲームアプリケーションの処理結果を示す画像信号および音声信号を生成する情報処理装置である。ゲーム装置１０は、少なくとも１つの出力装置１２に接続して、出力装置１２に映像を表示し、また音声を出力する。出力装置１２は、画像を出力するディスプレイ部を有して構成され、さらに音声を出力する音声出力部を有するテレビであってよい。出力装置１２は、ゲーム装置１０に有線ケーブルで接続されてよく、また無線ＬＡＮ（Local Area Network）などにより無線接続されてもよい。

図２は、ゲーム装置１０の機能ブロック図を示す。ゲーム装置１０は、電源ボタン２０、ＬＥＤ２２、システムコントローラ２４、デバイスコントローラ３０、メディアドライブ３２、ハードディスクドライブ３４、スイッチ３６、無線インタフェース３８、メインコントローラ１００、メインメモリ１０２および出力処理部２００を有して構成される。ゲーム装置１０は、自身を識別するための識別情報（以下、「本体ＩＤ」とよぶ）をフラッシュメモリに保持している。

電源ボタン２０は、ユーザからの操作入力が行われる入力部であって、ゲーム装置１０への電源供給をオンまたはオフするために操作される。電源ボタン２０は押下ボタンであってよく、押下されることで電源のオンまたはオフが制御されてもよい。なお電源ボタン２０は、タッチセンサなど、ユーザが電源のオンオフを行える他の構造をとってもよい。ＬＥＤ２２は、電源のオンまたはオフの状態を点灯表示する。システムコントローラ２４は、電源ボタン２０の押下状態または非押下状態を検出し、電源オフの状態から押下状態への状態遷移を検出すると、メインコントローラ１００を起動して、オペレーティングシステムのブートシーケンスを立ち上げるとともに、ＬＥＤ２２を点灯制御する。ゲーム装置１０に電源ケーブルが差し込まれている場合、システムコントローラ２４は、電源オフの状態であってもスタンバイモードを維持して、電源ボタン２０の押下を監視する。

デバイスコントローラ３０は、サウスブリッジのようにデバイス間の情報の受け渡しを実行するＬＳＩ（Large-Scale Integrated Circuit）として構成される。図示のように、デバイスコントローラ３０には、システムコントローラ２４、メディアドライブ３２、ハードディスクドライブ３４、スイッチ３６およびメインコントローラ１００などのデバイスが接続される。デバイスコントローラ３０は、それぞれのデバイスの電気特性の違いやデータ転送速度の差を吸収し、データ転送のタイミングを制御する。

メディアドライブ３２は、ゲームプログラムを記録したメディア５０を駆動して、メディア５０からゲームプログラムを読み出すドライブ装置である。メディア５０は、光ディスクや光磁気ディスク、ブルーレイディスクなどの記録媒体であり、メディアドライブ３２に挿入されてゲームプログラムの供給媒体として利用される。メディア５０は、自身を識別するための識別情報（以下、「メディアＩＤ」とよぶ）を所定の格納領域に記録している。メディアＩＤは、メディア固有の番号であり、メディアごとに異なっている。なおメディアＩＤは、ゲームプログラムを記録可能な記録媒体の全てに付与されてもよく、たとえばハードディスクやフラッシュメモリ１４０など、内蔵型の記録媒体に付与されてもよい。以下では、説明の便宜上、記録媒体を代表してメディア５０にメディアＩＤが付与されている例について示す。

ゲームプログラムは、ゲームアプリケーションを実行させる実行プログラムと、ゲームアプリケーションを特定するための情報（以下、「アプリケーションＩＤ」とよぶ）を含んでいる。実行プログラムは、アプリケーション処理に必要なプログラムであり、実行プログラムを走らせることで、ゲームアプリケーションが進行する。アプリケーションＩＤは、ゲームアプリケーションの種類ごとに設定され、メディア５０の所定の格納領域に記録されている。

ハードディスクドライブ３４は、内蔵ハードディスクを駆動して、データの書込／読出を行うドライブ装置である。ゲーム装置１０において、ゲーム進行に関するゲームデータは、内蔵ハードディスクに格納（セーブ）される。ゲームデータには、ゲームプレイの進行状況を表すデータ、ゲームのハイスコアデータ、キャラクタデータなどが含まれる。なお、これらのデータが全てハードディスクにセーブされる必要はなく、ゲームアプリケーションごとにセーブされるゲームデータが設定される。

スイッチ３６は、イーサネットスイッチ（イーサネットは登録商標）であって、外部の機器と有線または無線で接続して、情報の送受信を行うデバイスである。ゲーム装置１０は、スイッチ３６を介して外部のインターネットなどのネットワークに接続できる。本実施例において、外部ネットワークには、配信サーバが設けられ、たとえばゲーム装置１０は、アプリケーションをサーバからダウンロードすることができる。このとき、ユーザはサーバにユーザ登録する必要があり、ユーザを特定するための情報（以下、「ユーザＩＤ」とよぶ）が設定される。設定されたユーザＩＤは、配信サービスの提供を受ける際に必要となるが、ゲーム装置１０において、ユーザを一意に特定するための情報としても利用される。そのため、ゲーム装置１０は、配信サーバから通知されるユーザＩＤをフラッシュメモリに格納する。なお、サーバにユーザ登録をしていないユーザは、ユーザＩＤを有していない。

スイッチ３６は無線インタフェース３８に接続し、無線インタフェース３８は、Bluetooth（登録商標）プロトコルやIEEE802.11プロトコルなどの通信プロトコルで無線通信機能をもつゲームコントローラ４０と接続する。ゲームコントローラ４０は、ユーザからの操作入力が行われる入力部として機能する。

メインコントローラ１００は、マルチコアＣＰＵを備え、１つのＣＰＵの中に１つの汎用的なプロセッサコアと、複数のシンプルなプロセッサコアを有する。本実施例では、汎用プロセッサコアをＰＰＵ（Power Processing Unit）と呼び、残りのプロセッサコアをＳＰＵ（Synergistic-Processing Unit）と呼ぶ。

メインコントローラ１００では、ゲーム装置１０を効率よく使用するための機能、環境を提供し、装置全体を統括的に制御するオペレーティングシステム（以下、単に「ＯＳ（Operating System）」と呼ぶ）が実行される。ＯＳ上では、複数のアプリケーションソフトウェアを実行できる。本実施例におけるゲーム装置１０のＯＳ階層は、上位から、ユーザ層、カーネル（Kernel）層、ハイパーバイザ（Hypervisor）層の３階層をとる。ゲーム装置１０において、ユーザ層、カーネル層とハイパーバイザ層のソフトウェアが一体となって、ゲーム装置１０の「ＯＳ」として機能する。ハイパーバイザ層を管理するソフトウェアのことを「特権ソフトウェア」とよぶ。ハイパーバイザ層は最下層の機能を担当し、電源ボタン２０より電源投入されると、特権ソフトウェアにより必ず最初に優先起動される。

図３は、ＯＳ階層を示す。電源ボタン２０により電源投入されると、システムコントローラ２４は、デバイスコントローラ３０を経由して、メインコントローラ１００および出力処理部２００などに電源を供給する。メインコントローラ１００に電源が供給されると、ＰＰＵは、まずＯＳのブートローダを実行して特権ソフトウェアを読み出し、特権ソフトウェアによりホストＯＳのハイパーバイザ層を起動する。つづいて、ＰＰＵは、ＯＳのカーネル層を起動し、さらにユーザ層を起動して、メディア５０から供給されるゲームプログラムの受入態勢を整える。

本実施例のゲーム装置１０は、複数のＯＳを搭載してもよい。そのときは、図３に示すＯＳがホストＯＳとして機能し、ホストＯＳのハイパーバイザ層に作成された仮想マシン上でゲストＯＳを動作させる機能をもつ。メインコントローラ１００による管理上、仮想マシン環境とゲストＯＳは、ホストＯＳ上で動作するプログラムであるため、ゲストＯＳを動作させるためには、ホストＯＳのハイパーバイザ層が常に起動している必要がある。ホストＯＳの起動はＰＰＵにより実行されるが、ＳＰＵと協同して実行されてもよい。

カーネル層はシステムのリソースを管理し、他のプログラムがそれらのリソースを使って動作できるようにする。具体的にカーネル層は、メモリ、ＣＰＵや他のデバイスを含めたハードウェアと、上位のソフトウェアの間の通信を管理し、ＯＳの中核部分を構成する。

ユーザ層は、アプリケーションプログラムを効率的に実行できるように、カーネル層との間の橋渡しを行う。ユーザ層は、複数の機能モジュールから構成されてよく、ゲームプログラムに提供するＡＰＩ（アプリケーションプログラミングインタフェース）の機能を実現するＡＰＩ処理モジュールも含まれる。ＡＰＩは、プログラミングのためのインターフェースであり、プログラム作成時の規則を生成する。本実施例では、ゲームデータをセーブするためのセーブプログラム、およびセーブデータをロードするためのロードプログラムがライブラリ（以下、「セーブデータユーティリティ」とよぶ）として用意され、セーブデータユーティリティ関数を呼び出すことで、ＡＰＩ処理モジュールが構成される。セーブ用またはロード用のＡＰＩ処理モジュールを構成することで、ゲームプログラムがゲームデータをハードディスクにセーブし、またハードディスクからセーブデータをロードすることが可能となる。本実施例のゲーム装置１０は複数のタイプのセーブ／ロード処理機能を有しており、ハードディスクには、実行する処理に応じたセーブデータユーティリティ関数が用意される。

以下、ゲーム装置１０における複数種類のセーブ処理、ロード処理の概略を説明する。なお、以下のセーブ処理、ロード処理のそれぞれに対してセーブデータユーティリティ関数が用意され、ゲームプログラムが要求するセーブデータユーティリティ関数が呼び出されることで、ＯＳのユーザ層にＡＰＩ処理モジュールが構成される。これにより、ゲームプログラムが所望するセーブ処理またはロード処理が実行可能となる。

（１）リスト選択型セーブ／ロード処理
リスト選択型セーブ処理（ListSave()）では、既存のセーブデータのリストをユーザに提示して、いずれかのセーブデータに上書き保存するか、または新規作成するかをユーザに選択させる。
リスト選択型ロード処理（ListLoad()）では、既存のセーブデータのリストをユーザに提示して、ユーザが選択したセーブデータをロードする。

（２）固定型セーブ／ロード処理
固定型セーブ処理（FixedSave()）では、アプリケーションが指定した１つのセーブデータをユーザに提示して、そのセーブデータに上書き保存する。
固定型ロード処理（FixedLoad()）では、アプリケーションが指定した１つのセーブデータをユーザに提示して、そのセーブデータをロードする。

（３）オートセーブ／ロード処理
オートセーブ処理（AutoSave()）では、１つのセーブデータをアプリケーションが指定し、ユーザに提示することなく、そのセーブデータに上書き保存する。
オートロード処理（AutoLoad()）では、１つのセーブデータをアプリケーションが指定し、ユーザに提示することなく、そのセーブデータをロードする。

メインコントローラ１００は、メインメモリ１０２に接続するメモリコントローラを備える。ＰＰＵはレジスタを有し、演算実行主体としてメインプロセッサを備えて、各アプリケーションにおける基本処理単位としてのタスクを各ＳＰＵに効率的に割り当てる。なお、ＰＰＵ自身がタスクを実行してもよい。ＳＰＵはレジスタを有し、演算実行主体としてのサブプロセッサとローカルな記憶領域としてのローカルメモリ（専用ＲＡＭ）を備える。ＳＰＵは制御ユニットとして専用のＤＭＡ（Direct Memory Access）コントローラをもち、メインメモリ１０２とローカルメモリの間のデータ転送を行うことで、データを高速にストリーム処理でき、また出力処理部２００に内蔵されるフレームメモリとローカルメモリの間で高速なデータ転送を実現できる。

出力処理部２００は、出力装置１２に接続されて、アプリケーションの処理結果である映像信号および音声信号を出力する。出力処理部２００は、画像処理機能を実現するＧＰＵ（Graphics Processing Unit）を備える。ＧＰＵは、ＨＤＭＩ（High Definition Multimedia Interface）を採用し、アナログを介さずに、映像信号をデジタル出力できる。

図４は、メインコントローラ１００の内部構成を示す。メインコントローラ１００は、入力受付部１０４、実行処理部１２０、フラッシュメモリ１４０、メモリコントローラ１６０およびローカルメモリ１６２を備える。

図４において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ（Central Processing Unit）、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。既述したように、メインコントローラ１００には１つのＰＰＵと複数のＳＰＵとが設けられており、ＰＰＵおよびＳＰＵがそれぞれ単独または協同して、各機能ブロックを構成できる。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

メインコントローラ１００は、デバイスコントローラ３０との間で制御情報を送受する手段として入力受付部１０４を有する。入力受付部１０４は、ユーザのゲームコントローラ４０からの操作入力を受け付け、またネットワーク上の配信サーバから、ユーザ登録時に設定されたユーザＩＤを受け付ける。ゲームシステム１において、ユーザはゲームコントローラ４０を用いて、ゲームの操作入力を行ってゲームを進行させることができ、またゲームデータのセーブ／ロード時には、ＯＳのＡＰＩなどにより出力装置１２の画面に表示されるＧＵＩ（Graphical User Interface）をみながら、ゲームデータのセーブまたはロードを指示する操作入力を行うことができる。本実施例において、ユーザは、少なくともデータのセーブまたはロードを指示するための操作入力を行い、入力受付部１０４は、その指示を受け付けて実行処理部１２０に通知する。セーブ／ロード処理が開始されると、ユーザは、実行処理部１２０から提示されるＧＵＩから所定の確認入力や選択入力を行う。

フラッシュメモリ１４０は、その格納領域に、本体ＩＤ保持部１４２およびユーザＩＤ保持部１４４を有する。本体ＩＤ保持部１４２は、ゲーム装置１０の識別情報として本体ＩＤを保持する。ユーザＩＤ保持部１４４は、入力受付部１０４において受け付けたユーザＩＤを保持する。既述したように、ユーザＩＤは、配信サーバへのユーザ登録に際して付与されるものであるため、ユーザ登録を行っていない場合は、ユーザＩＤ保持部１４４には空のデータが書き込まれている。

本実施例のゲーム装置１０において、ゲーム装置１０に設定されている本体ＩＤや、付与されたユーザＩＤなどの情報は、フラッシュメモリ１４０ではなく、ハードディスクのレジストリに記憶されてもよい。図４に示した本体ＩＤ保持部１４２およびユーザＩＤ保持部１４４は、便宜上フラッシュメモリ１４０の領域を使用するように図示しているが、ハードディスクや他の記憶装置の領域であっても構わない。

実行処理部１２０は、ＯＳを実行するＯＳ実行部１２２と、アプリケーションを実行するアプリケーション処理部１２４とを有する。電源が投入されると、ＯＳ実行部１２２は、ＯＳのハイパーバイザ層を優先起動し、続いてカーネル層、必要なユーザ層を起動する。これにより、アプリケーション処理部１２４がゲームの実行プログラムを実行する環境が提供される。

メモリコントローラ１６０は、外部のメインメモリ１０２や、ＳＰＵに内蔵されているローカルメモリ１６２の書込／読出を制御する。メモリコントローラ１６０は、ハードディスクやメディア５０などから読み出したデータを、メインメモリ１０２ないしはローカルメモリ１６２に記憶させる。実行処理部１２０は、メインメモリ１０２および／またはローカルメモリ１６２に記憶されたデータをもとに、処理を実行する。

ゲームデータのセーブ処理またはロード処理を行う際、アプリケーション処理部１２４は、ＯＳ実行部１２２に対して、所望のタイプのセーブ処理またはロード処理を実行するためのセーブデータユーティリティ関数を呼び出す。ＯＳ実行部１２２がこの呼出要求を受けると、ＯＳのユーザ層にＡＰＩ処理モジュールが起動される。

本実施例において、セーブ用のＡＰＩ処理モジュールは、ゲームデータにゲームプログラムの実行環境を示す状態情報を付加してハードディスクにセーブする機能をもつ。またロード用のＡＰＩ処理モジュールは、ハードディスクからセーブデータをロードする際に、セーブデータの付加情報と、ロード時のゲームプログラムの実行環境を示す状態情報とから、セーブデータの検証処理を行う機能をもつ。

図５は、ＯＳ実行部１２２において構成されるＡＰＩ処理モジュールの機能ブロックを示す。セーブ用ＡＰＩ処理モジュール３００ａは、データセーブ用のセーブデータユーティリティ関数がアプリケーション処理部１２４により呼び出されることで構成される。セーブ用ＡＰＩ処理モジュール３００ａは、状態取得部３１０およびセーブ処理部３２０を備え、セーブ処理部３２０は、ゲームデータ取得部３２２および付加処理部３２４を有する。

状態取得部３１０は、ゲームプログラムの実行環境の状態を示す状態情報を取得する。実行環境の状態を示す要素としては、ゲームアプリケーションを実行するゲーム装置自体、ゲーム装置１０にゲームプログラムを供給するメディア５０、ゲームプログラムの種類、ゲームをプレイするユーザなどがあげられる。これらの要素に対応して、状態取得部３１０は、状態情報として、ゲーム装置１０を特定する本体ＩＤ、メディア５０を特定するメディアＩＤ、ゲームプログラムのアプリケーション（ゲーム種類）を特定するアプリケーションＩＤ、ゲームユーザを特定するユーザＩＤを取得する。

状態取得部３１０は、本体ＩＤ保持部１４２から本体ＩＤを、メディア５０からメディアＩＤおよびアプリケーションＩＤを、ユーザＩＤ保持部１４４からユーザＩＤをそれぞれ読み出して取得する。なお、メディアＩＤおよびアプリケーションＩＤは、メインメモリ１０２やローカルメモリ１６２などの内部メモリに既に読み出されている場合は内部メモリから取得されてもよく、ハードディスクに既に読み出されている場合は、ハードディスクから取得されてもよい。なお、状態取得部３１０は、２つ以上の状態情報を取得することが好ましく、さらにはこれらの全てを取得することが好ましい。取得する状態情報の数が多いほど、ゲームプログラムにとって、使用できる状態情報の数を増やすことができ、すなわちゲームプログラムは、必要な状態情報を状況に応じて選択的に使用でき、使用した状態情報に対応する所望の処理を実行できる。

セーブ処理部３２０は、ゲーム進行に関するゲームデータをハードディスクにセーブする機能をもつ。ゲームデータ取得部３２２は、アプリケーション処理部１２４からアプリケーションの処理結果などのセーブすべきゲームデータを取得する。付加処理部３２４は、状態取得部３１０により取得された状態情報を、ゲームデータ取得部３２２により取得されたゲームデータに付加情報として付加して、ハードディスクに記憶する。これにより、セーブデータは、付加情報付きのゲームデータとして記憶される。

このように、セーブすべきゲームデータに状態情報を付加することで、ゲームデータ自体に、セーブ時の環境状態を含めさせることができる。これにより、ゲーム装置１０は、セーブデータの付加情報を参照すれば、そのゲームデータのセーブ時の環境を知ることができる。

たとえば状態情報として本体ＩＤが付加されるとき、ゲーム装置１０は、付加された本体ＩＤを参照することで、そのゲームデータをセーブしたのが自分であるか、または他のゲーム装置であるかを判定できる。

また状態情報としてメディアＩＤが付加されるとき、ゲーム装置１０は、付加されたメディアＩＤを参照することで、セーブデータが現在起動しているメディアと同じメディアで作成されたか、または別のメディアで作成されたかを判定できる。

また状態情報としてアプリケーションＩＤが付加されるとき、ゲーム装置１０は、付加されたアプリケーションＩＤを参照することで、セーブデータが現在起動しているアプリケーションと同じアプリケーションで作成されたか、または別のアプリケーションで作成されたかを判定できる。

また状態情報としてユーザＩＤが付加されるとき、ゲーム装置１０は、付加されたユーザＩＤを参照することで、セーブデータが現在のユーザによりセーブされたか、または別のユーザによりセーブされたかを判定できる。

ロード用ＡＰＩ処理モジュール３００ｂは、データロード用のセーブデータユーティリティ関数がアプリケーション処理部１２４により呼び出されることで構成される。ロード用ＡＰＩ処理モジュール３００ｂは、状態取得部３３０、ロード処理部３４０およびロード実行部３５０を備え、ロード処理部３４０は、付加情報取得部３４２、判定部３４４および通知部３４６を有する。

状態取得部３３０は、状態取得部３１０と同様に、ゲームプログラムの実行環境の状態を示す状態情報を取得する。状態取得部３３０は、状態情報として、本体ＩＤ、メディアＩＤ、アプリケーションＩＤ、ユーザＩＤの少なくとも２つを取得することが好ましい。状態取得部３１０および３３０は、同一のプログラムモジュールで構成され、それぞれ同一種類の状態情報を取得する。

ロード処理部３４０は、セーブデータをハードディスクからロードする機能をもつ。まず、付加情報取得部３４２は、ゲームデータのロード実行前に、ハードディスクに記録されたゲームデータから付加情報を取得する。判定部３４４は、状態取得部３３０により取得されたロード前の状態情報と、付加情報取得部３４２により取得された付加情報との一致性を判定する。なお、一致性の判定は、原則として完全一致か否かで行われる。通知部３４６は、判定部３４４による一致性の判定結果をアプリケーション処理部１２４に通知する。

判定部３４４は、複数種類のロード時の状態情報およびゲームデータの付加情報について、それぞれの一致性を判定して、それぞれの判定結果を生成する。たとえば、状態取得部３１０および３３０が、状態情報として、本体ＩＤ、メディアＩＤ、アプリケーションＩＤ、ユーザＩＤを取得する場合、判定部３４４は、本体ＩＤ、メディアＩＤ、アプリケーションＩＤ、ユーザＩＤについて一致性を判定し、通知部３４６は、それぞれの判定結果をアプリケーション処理部１２４に通知する。これにより、ロード用ＡＰＩ処理モジュール３００ｂは、アプリケーション処理部１２４に対して、きめ細かな環境状態に関する情報を提供できる。アプリケーション処理部１２４は、環境状態のそれぞれについての変化の有無を認識できるため、個々の環境変化に応じたアプリケーション処理を実行することができる。また複数の状態情報をもとにセーブデータの検証処理を行うため、検証処理自体の確実性をますことができ、また様々なゲームプログラムに有用な情報を供給できる可能性も高めることができる。

判定部３４４は、ロード時の状態情報と、セーブデータの付加情報とが一致していない場合にエラー判定を行い、通知部３４６は、エラー情報をアプリケーション処理部１２４に通知する。たとえば判定結果はフラグにより表現されてよく、ロード時の状態情報とセーブデータの付加情報とが一致している場合はフラグ値「０」、異なっている場合はフラグ値「１」とする。一致していない場合には、判定結果が単にエラー情報（すなわち、フラグ値「１」）としてアプリケーション処理部１２４に通知されるため、アプリケーション処理部１２４による判定部３４４の判定結果の取り扱いが容易となる。

図６は、リスト選択型ロード処理（ListLoad()）のシーケンス図である。アプリケーション処理部１２４が、ListLoad()関数の呼出要求をＯＳ実行部１２２に送る（Ｓ１０）。引数として、取得対象とするセーブデータのディレクトリ名プレフィックスや、コールバック関数（データリストコールバック、データステータスコールバック、ファイル操作コールバック）へのポインタなどが指定される。ＯＳ実行部１２２においてListLoad()関数が呼び出され（Ｓ１２）、ロード用ＡＰＩ処理モジュール３００ｂが構成される。ロード用ＡＰＩ処理モジュール３００ｂは、ディレクトリ名プレフィックスをもとに、ハードディスクからセーブデータのリストを取得する（Ｓ１４）。

ロード用ＡＰＩ処理モジュール３００ｂは、セーブデータのリストを引数としてデータリストコールバックを呼び出す（Ｓ１６）。データリストコールバックでは、渡されたセーブデータのリストをもとに、ユーザに提示するセーブデータリストを作成する（Ｓ１８）。データリストコールバックからリターンし、ユーザ提示用リストがロード用ＡＰＩ処理モジュール３００ｂに渡されると（Ｓ２０）、ロード用ＡＰＩ処理モジュール３００ｂは、セーブデータのリストをＧＵＩにより画面表示して（Ｓ２２）、ユーザからの応答を待つ。ユーザがロード対象とするセーブデータを選択すると（Ｓ２４）、選択内容がロード用ＡＰＩ処理モジュール３００ｂに通知され（Ｓ２６）、ロード用ＡＰＩ処理モジュール３００ｂは、確認ダイアログをＧＵＩにより画面表示する（Ｓ２８）。ユーザが確認応答を行うと（Ｓ３０）、セーブデータの検証処理を行う（Ｓ３２）。この検証処理では、図５に関連して説明したように、セーブ時の状態情報と、現在（ロード時）の状態情報を比較し、一致性を判定する。

ロード用ＡＰＩ処理モジュール３００ｂは、データステータスコールバックを呼び出す（Ｓ３４）。データステータスコールバックに渡される情報は、セーブデータの検証処理の結果や、選択されたセーブデータのディレクトリ名、更新日時などの属性情報である。

アプリケーション処理部１２４は、セーブデータの検証処理の結果から、たとえばロード処理を実行するか否かを判定する（Ｓ３８）。たとえば、本体ＩＤに関してエラー情報が通知された場合、ゲーム装置１０とは別の機器でセーブデータが作成されたことが分かる。このような場合、他人のセーブデータを利用してゲームを実行しようとする可能性が高いため、アプリケーション処理部１２４は、ロード処理を終了してもよい（Ｓ３８のＮ）。

一方、全ての状態情報についてエラーが通知されない場合、アプリケーション処理部１２４は、ロード処理を実行することを判定し（Ｓ３８のＹ）、データステータスコールバックからリターンして、ファイル操作前処理を指定する（Ｓ４０）。ロード用ＡＰＩ処理モジュール３００ｂはファイル操作前処理を行い（Ｓ４２）、セーブデータを構成するファイルひとつひとつについてファイル操作コールバックを呼び出す（Ｓ４４）。ファイル操作コールバックに渡される情報は、リード処理を特定する制御情報などである。アプリケーション処理部１２４は、セーブデータの全ファイルをロードするまで（Ｓ４６のＮ）、読み出すファイルを指定し（Ｓ４８）、ロード実行部３５０は、ハードディスクからデータをロードする（Ｓ５０）。全ファイルをロードすると（Ｓ４６のＹ）、アプリケーション処理部１２４は、ロード用ＡＰＩ処理モジュール３００ｂに対してロード処理の終了指示を通知し（Ｓ５２）、ロード用ＡＰＩ処理モジュール３００ｂは、画面に完了メッセージを表示して、ロード処理を終了する。

以上の例では、アプリケーション処理部１２４が、Ｓ３２におけるセーブデータの検証処理の結果を受けてロードの実行の可否を判定するものとした。アプリケーション処理部１２４は、エラー情報の種類に応じて、様々な態様で振る舞うことができる。

Ａ）本体ＩＤにエラー情報が発生した場合
アプリケーション処理部１２４は、上記したようにロード処理を停止してもよい。これにより、他人によるセーブデータの利用を困難にでき、また他人によるセーブデータの複製も困難にできる。特に、ネットワーク上でセーブデータが公開されることが頻繁に生じるような場合に、本体ＩＤが異なれば、その利用および複製をできなくすることで、セーブデータをネットワーク上に公開する意味をなくすことができる。また、異なるゲーム装置によるセーブデータを使用する場合には、ゲストユーザとしてゲーム装置１０が取り扱えるようにしてもよい。

Ｂ）メディアＩＤにエラー情報が発生した場合
アプリケーション処理部１２４は、ロード処理を停止する。これにより、他人によるセーブデータの利用を困難にでき、また他人によるセーブデータの複製も困難にできる。特に、ネットワーク上でセーブデータが公開されることが頻繁に生じるような場合に、メディアＩＤが異なれば、その利用および複製をできなくすることで、セーブデータをネットワーク上に公開する意味をなくすことができる。また、異なるメディアによるセーブデータを使用する場合には、ゲストユーザとしてゲーム装置１０が取り扱えるようにしてもよい。

Ｃ）アプリケーションＩＤにエラー情報が発生した場合
たとえば、シリーズもののゲームアプリケーションで、旧バージョンのゲームデータを新バージョンで使用したい場合に、ゲーム装置１０は、そのゲームデータに対して特典をつけた処理を実行してもよい。

Ｄ）ユーザＩＤにエラー情報が発生した場合
まず、ユーザＩＤが存在しない場合、一致性の判定処理において比較対象が存在しないため、エラー情報が発生される。またゲーム装置１０は、ユーザが配信サーバに登録していないことを判定できる。ユーザＩＤが必要なゲームでは、アプリケーション処理部１２４が、そのセーブデータの使用を制限してもよい。

また、ユーザＩＤが異なっていた場合、ゲーム装置１０は、異なるユーザによりセーブされたセーブデータであることを認識できるとともに、セーブしたユーザの特定が可能となる。なお、ユーザＩＤについては、フラグではなく、ユーザＩＤそのものをアプリケーション処理部１２４に通知してもよい。

このように、アプリケーション処理部１２４が、複数の環境状態情報を用いることで、状態情報の一致性判定結果ごとに、様々なバリエーションの処理を実行できるようになる。これにより、ゲームプログラムの保護レベルを高めることができ、またゲーム進行に対して特典を与えるような対応をすることで、ゲームプログラムの魅力を高めることもできる。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

本発明の実施例にかかるゲームシステムを示す図である。 ゲーム装置の機能ブロック図を示す図である。 ＯＳ階層を示す図である。 メインコントローラの内部構成を示す図である。 ＯＳ実行部において構成されるＡＰＩ処理モジュールの機能ブロックを示す図である。 リスト選択型ロード処理（ListLoad()）のシーケンス図である。

符号の説明

１・・・ゲームシステム、１０・・・ゲーム装置、１２・・・出力装置、２０・・・電源ボタン、２２・・・ＬＥＤ、２４・・・システムコントローラ、３０・・・デバイスコントローラ、３２・・・メディアドライブ、３４・・・ハードディスクドライブ、３６・・・スイッチ、３８・・・無線インタフェース、４０・・・ゲームコントローラ、５０・・・メディア、１００・・・メインコントローラ、１０２・・・メインメモリ、１０４・・・入力受付部、１２０・・・実行処理部、１２２・・・ＯＳ実行部、１２４・・・アプリケーション処理部、１４０・・・フラッシュメモリ、１４２・・・本体ＩＤ保持部、１４４・・・ユーザＩＤ保持部、１６０・・・メモリコントローラ、１６２・・・ローカルメモリ、２００・・・出力処理部、３００ａ・・・セーブ用ＡＰＩ処理モジュール、３００ｂ・・・ロード用ＡＰＩ処理モジュール、３０２・・・状態取得部、３１０・・・状態取得部、３２０・・・セーブ処理部、３２２・・・ゲームデータ取得部、３２４・・・付加処理部、３３０・・・状態取得部、３４０・・・ロード処理部、３４２・・・付加情報取得部、３４４・・・判定部、３４６・・・通知部、３５０・・・ロード実行部。

Claims (8)

1. ゲームプログラムを実行するアプリケーション処理部と、
   ゲーム進行に関するゲームデータを記憶装置にセーブするセーブ処理部と、
   セーブデータを記憶装置からロードするロード処理部と、
   ゲームプログラムの実行環境の状態を示す状態情報を取得する状態取得部とを備え、
   前記セーブ処理部は、
   前記状態取得部により取得された状態情報を、ゲームデータに付加情報として付加して前記記憶装置に記憶する付加処理部を備え、
   前記ロード処理部は、
   前記記憶装置に記憶されたゲームデータから付加情報を取得する付加情報取得部と、
   前記状態取得部により取得された状態情報と、前記付加情報取得部により取得された対応する付加情報との一致性を判定する判定部と、
   判定結果を前記アプリケーション処理部に通知する通知部と、
   を備えることを特徴とするゲーム装置。
2. 前記状態取得部は、複数の状態情報を取得して、前記付加処理部が、複数の状態情報をゲームデータに付加情報として付加し、
   前記判定部は、前記状態取得部により取得された複数の状態情報と、前記付加情報取得部により取得された対応する付加情報とのそれぞれの一致性を判定し、
   前記通知部は、それぞれの判定結果を前記アプリケーション処理部に通知することを特徴とする請求項１に記載のゲーム装置。
3. 前記状態取得部は、状態情報として、当該ゲーム装置の識別情報、ゲームプログラムの供給媒体の識別情報、ゲームプログラムのアプリケーション情報、ゲームユーザを特定する識別情報の少なくとも２つを取得することを特徴とする請求項２に記載のゲーム装置。
4. 前記判定部は、ロード時の状態情報と、セーブデータの付加情報とが一致していない場合に、エラー判定を行うことを特徴とする請求項１から３のいずれかに記載のゲーム装置。
5. 前記アプリケーション処理部は、所定の状態情報についてエラー判定が行われた場合には、ロード処理を実行しないことを特徴とする請求項１から４のいずれかに記載のゲーム装置。
6. 前記セーブ処理部および前記ロード処理部は、ゲームプログラムに提供するＡＰＩ（アプリケーションプログラミングインタフェース）の機能を実現するＡＰＩ処理モジュールとして構成されることを特徴とする請求項１から５のいずれかに記載のゲーム装置。
7. コンピュータに、
   ゲームプログラムを実行する機能と、
   ゲーム進行に関するゲームデータを記憶装置にセーブする機能と、
   セーブデータを記憶装置からロードする機能と、
   ゲームプログラムの実行環境の状態を示す複数の状態情報を取得する機能とを実現させ、
   前記セーブ機能は、
   取得された複数の状態情報を、ゲームデータに付加情報として付加して記憶装置に記憶する機能を備え、
   前記ロード機能は、
   記憶装置に記憶されたゲームデータから付加情報を取得する機能と、
   取得された複数の状態情報と、取得された対応する付加情報とのそれぞれの一致性を判定する機能と、
   それぞれの判定結果を、ゲームアプリケーション実行機能に通知する機能とを、実現させるためのプログラム。
8. 請求項７に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images