JP2015088144A - 情報処理装置およびゲームデータのデータ構造 - Google Patents
情報処理装置およびゲームデータのデータ構造 Download PDFInfo
- Publication number
- JP2015088144A JP2015088144A JP2013228809A JP2013228809A JP2015088144A JP 2015088144 A JP2015088144 A JP 2015088144A JP 2013228809 A JP2013228809 A JP 2013228809A JP 2013228809 A JP2013228809 A JP 2013228809A JP 2015088144 A JP2015088144 A JP 2015088144A
- Authority
- JP
- Japan
- Prior art keywords
- file
- game
- data
- information
- hash value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】新たなゲームデータのデータ構造を提供する。
【解決手段】ゲームデータは、1または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含んで構成される。このゲームデータは、メタデータとして、ファイルのフルパス情報のハッシュ値と、ファイルの記録位置を特定するための情報とを対応付けたフラットパステーブル220と、ハッシュ値が衝突するフルパス情報に対して、ファイル名とファイルの記録位置を特定するための情報とを対応付けた衝突ファイル222とを有している。
【選択図】図12
【解決手段】ゲームデータは、1または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含んで構成される。このゲームデータは、メタデータとして、ファイルのフルパス情報のハッシュ値と、ファイルの記録位置を特定するための情報とを対応付けたフラットパステーブル220と、ハッシュ値が衝突するフルパス情報に対して、ファイル名とファイルの記録位置を特定するための情報とを対応付けた衝突ファイル222とを有している。
【選択図】図12
Description
本発明は、ゲームデータのデータ構造に関し、また当該データ構造を有するゲームデータを処理する情報処理装置に関する。
従来よりゲームプログラムを含むゲームデータ(ゲームソフトウェア)は、光ディスクや光磁気ディスク、ブルーレイディスクなどのROM媒体の形態で流通、販売されてきた。最近ではインターネットにおけるデータ通信の高速化により、サーバがインターネット経由でゲームデータのイメージファイルを配信できるようになっている。
ゲームソフトウェアは、起動ファイル、ゲームプログラムなどのゲームを実行するためのリソースファイル群、およびゲーム装置のオペレーティングシステム(OS:Operating System)が使用するファイル群を含んでいる。ゲーム装置のハードウェアスペックが飛躍的に向上したことにともない、ゲームソフトウェアに含まれるファイル数は多くなり、データサイズは大規模化する傾向にある。ゲームソフトウェアは、複数のゲームファイルと、各ファイルのメタデータを含んで構成されるが、ゲームプログラムの実行時、メタデータは、ファイルが格納されているセクタを特定するなどの目的のために予めメモリに読み出されて、ファイルアクセス処理に利用されることが好ましい。メモリのサイズは有限であるため、メタデータのデータサイズを、できるだけ小規模に抑えたデータ構造の開発が望まれている。
またメタデータをメモリに展開することは、ファイルアクセスの高速化に寄与するが、ゲームファイルを記憶する記憶部からのデータ読出速度は様々であり、一般に、ROM媒体を装着するメディアドライブからのデータ読出速度は遅く、DRAMからのデータ読出速度は速いことが知られている。そこで複数の記憶部にゲームファイルが記憶されている場合に、効率的なファイルアクセスを行う技術の開発が望まれている。
上記課題を解決するために、本発明のある態様の情報処理装置は、ゲームデータに含まれるファイルにアクセスする情報処理装置であって、ゲームデータは、ファイルのフルパス情報のハッシュ値と、ファイルの記録位置を特定するための情報とを対応付けた対応ファイルを有しており、ゲームからファイルのフルパス情報を含む読出要求を受け付ける受付部と、フルパス情報のハッシュ値を導出する導出部と、対応ファイルを参照して、ハッシュ値を用いて、ファイルの記録位置を特定するための情報を取得する取得部と、取得した情報をもとに、ファイルにアクセスするファイルアクセス部とを備える。
本発明の別の態様は、ゲームデータのデータ構造である。このゲームデータのデータ構造は、コンピュータにより実行されるプログラムファイルを含むゲームデータのデータ構造であって、ゲームデータは、1または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含んで構成されており、ファイルのフルパス情報のハッシュ値と、ファイルの記録位置を特定するための情報とを対応付けた対応ファイルと、ハッシュ値が衝突するフルパス情報に対して、ファイル名とファイルの記録位置を特定するための情報とを対応付けた衝突ファイルとを備える。
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
本発明の情報処理技術によると、ユーザが快適にゲームをプレイすることのできる環境を実現することが可能となる。
図1は、本発明の実施例にかかる情報処理システム1を示す。情報処理システム1は、情報処理装置10と、ネットワークサーバ5と、デジタルコンテンツを配信するコンテンツサーバ12と、デジタルコンテンツを販売するストアサーバ16とを備え、これらはインターネットやLAN(Local Area Network)などのネットワーク3を介して接続している。コンテンツサーバ12は、デジタルコンテンツのメーカやパブリッシャなどにより保守、管理される。
アクセスポイント(以下、「AP」とよぶ)8は、無線アクセスポイントおよびルータの機能を有し、情報処理装置10は、無線または有線経由でAP8に接続して、ネットワーク3上のネットワークサーバ5、コンテンツサーバ12、ストアサーバ16と通信可能に接続する。
情報処理装置10は、ユーザが操作する入力装置6と無線または有線で接続し、入力装置6はユーザの操作結果を示す操作情報を情報処理装置10に出力する。情報処理装置10は入力装置6から操作情報を受け付けるとOS(システムソフトウェア)やアプリケーションソフトウェアの処理に反映し、出力装置4から処理結果を出力させる。情報処理システム1において情報処理装置10はゲームソフトウェアを実行するゲーム装置であり、入力装置6はゲームコントローラなど情報処理装置10に対してユーザの操作情報を供給する機器であってよい。ゲームをプレイするためにユーザは情報処理装置10のOS(システムソフトウェア)にログインする。OSにログインするユーザは、情報処理装置10において登録されているユーザアカウントによって管理される。
ネットワークサーバ5は情報処理システム1の運営主体により保守、管理され、情報処理システム1のユーザに対してゲームのネットワークサービスを提供する。ネットワークサーバ5はユーザを識別するネットワークアカウントを管理しており、ユーザは、ネットワークアカウントを用いて、ネットワークサーバ5が提供するネットワークサービスにサインインする。ユーザは情報処理装置10からネットワークサービスにサインインすることで、ストアサーバ16からデジタルコンテンツを購入し、またコンテンツサーバ12からデジタルコンテンツの配信を受けることができる。なお本実施例において、デジタルコンテンツは、様々な種類のアプリケーションソフトウェアであってよいが、以下では、特にデジタルコンテンツがゲームソフトウェアである場合について説明する。
補助記憶装置2はHDD(ハードディスクドライブ)やフラッシュメモリなどの大容量記憶装置であり、USB(Universal Serial Bus)などによって情報処理装置10と接続する外部記憶装置であってよく、内蔵型記憶装置であってもよい。出力装置4は画像を出力するディスプレイおよび音声を出力するスピーカを有するテレビであってよく、またコンピュータディスプレイであってもよい。出力装置4は、情報処理装置10に有線ケーブルで接続されてよく、無線接続されてもよい。
入力装置6は複数のプッシュ式の操作ボタンや、アナログ量を入力できるアナログスティック、回動式ボタンなどの複数の入力部を有して構成される。撮像装置であるカメラ7は出力装置4の近傍に設けられ、出力装置4周辺の空間を撮像する。図1ではカメラ7が出力装置4の上部に取り付けられている例を示しているが、出力装置4の側方に配置されてもよく、いずれにしても出力装置4の前方でゲームをプレイするユーザを撮像できる位置に配置される。情報処理装置10は、カメラ7の撮像画像からユーザを顔認証する機能をもつ。
図2は、情報処理装置10の機能ブロック図を示す。情報処理装置10は、メイン電源ボタン20、電源ON用LED21、スタンバイ用LED22、システムコントローラ24、クロック26、デバイスコントローラ30、メディアドライブ32、USBモジュール34、フラッシュメモリ36、無線通信モジュール38、有線通信モジュール40、サブシステム50およびメインシステム60を有して構成される。
メインシステム60は、メインCPU(Central Processing Unit)、主記憶装置であるメモリおよびメモリコントローラ、GPU(Graphics Processing Unit)などを備える。GPUはゲームプログラムの演算処理に主として利用される。これらの機能はシステムオンチップとして構成されて、1つのチップ上に形成されてよい。メインCPUはOSを起動し、OSが提供する環境下において、補助記憶装置2やROM媒体44に記録されたゲームソフトウェアを実行する機能をもつ。
サブシステム50は、サブCPU、主記憶装置であるメモリおよびメモリコントローラなどを備え、GPUを備えない。サブCPUの回路ゲート数は、メインCPUの回路ゲート数よりも少なく、サブCPUの動作消費電力は、メインCPUの動作消費電力よりも少ない。上記したように、サブCPUは、メインCPUがスタンバイ状態にある間に動作するものであり、消費電力を低く抑えるべく、その処理機能を制限されている。なおサブCPUおよびメモリは、別個のチップに形成されてもよい。
メイン電源ボタン20は、ユーザからの操作入力が行われる入力部であって、情報処理装置10の筐体の前面に設けられ、情報処理装置10のメインシステム60への電源供給をオンまたはオフするために操作される。以下、メイン電源がオン状態にあるとは、メインシステム60がアクティブ状態にあることを意味し、メイン電源がオフ状態にあるとは、メインシステム60がスタンバイ状態にあることを意味する。電源ON用LED21は、メイン電源ボタン20がオンされたときに点灯し、スタンバイ用LED22は、メイン電源ボタン20がオフされたときに点灯する。
システムコントローラ24は、ユーザによるメイン電源ボタン20の押下を検出する。メイン電源がオフ状態にあるときにメイン電源ボタン20が押下されると、システムコントローラ24は、その押下操作を「オン指示」として取得し、一方で、メイン電源がオン状態にあるときにメイン電源ボタン20が押下されると、システムコントローラ24は、その押下操作を「オフ指示」として取得する。
メインCPUは補助記憶装置2やROM媒体44に記録されているゲームプログラムを実行する機能をもつ一方で、サブCPUはそのような機能をもたない。しかしながらサブCPUは補助記憶装置2にアクセスする機能、ネットワークサーバ5やコンテンツサーバ12などの間で情報を送受信する機能を有している。サブCPUは、このような制限された処理機能のみを有して構成されており、したがってメインCPUと比較して小さい消費電力で動作できる。これらのサブCPUの機能は、メインCPUがスタンバイ状態にある際に実行される。
クロック26はリアルタイムクロックであって、現在の日時情報を生成し、システムコントローラ24やサブシステム50およびメインシステム60に供給する。
デバイスコントローラ30は、サウスブリッジのようにデバイス間の情報の受け渡しを実行するLSI(Large-Scale Integrated Circuit)として構成される。図示のように、デバイスコントローラ30には、システムコントローラ24、メディアドライブ32、USBモジュール34、フラッシュメモリ36、無線通信モジュール38、有線通信モジュール40、サブシステム50およびメインシステム60などのデバイスが接続される。デバイスコントローラ30は、それぞれのデバイスの電気特性の違いやデータ転送速度の差を吸収し、データ転送のタイミングを制御する。
メディアドライブ32は、ゲームなどのアプリケーションソフトウェア、およびライセンス情報を記録したROM媒体44を装着して駆動し、ROM媒体44からプログラムやデータなどを読み出すドライブ装置である。以下では、プログラムおよびデータを特に区別しない場合には、まとめてデータと呼ぶこともあるが、データは、ファイルを構成する要素を表現するものとしても使用する。ROM媒体44は、光ディスクや光磁気ディスク、ブルーレイディスクなどの読出専用の記録メディアである。
USBモジュール34は、外部機器とUSBケーブルで接続するモジュールである。USBモジュール34は補助記憶装置2およびカメラ7とUSBケーブルで接続してもよい。フラッシュメモリ36は、内部ストレージを構成する補助記憶装置である。無線通信モジュール38は、Bluetooth(登録商標)プロトコルやIEEE802.11プロトコルなどの通信プロトコルで、たとえば入力装置6と無線通信する。なお無線通信モジュール38は、ITU(International Telecommunication Union;国際電気通信連合)によって定められたIMT−2000(International Mobile Telecommunication 2000)規格に準拠した第3世代(3rd Generation)デジタル携帯電話方式に対応してもよく、さらには別の世代のデジタル携帯電話方式に対応してもよい。有線通信モジュール40は、外部機器と有線通信し、たとえばAP8を介してネットワーク3に接続する。
図1に戻ってコンテンツサーバ12およびストアサーバ16は、情報処理装置10にゲームソフトウェアを提供する。ゲームソフトウェアは、起動ファイル、ゲームプログラムなどのゲームを実行するためのリソースファイル群、および情報処理装置10のOSが使用するファイル群を含んでおり、本来ROM媒体44に記録されているゲームソフトウェアのイメージファイルを情報処理装置10に提供する。ゲームプログラムは、ゲームの実行に必要なプログラムであり、ゲームプログラムを走らせることで、ゲームが進行する。起動ファイルは、ゲームプログラムを起動するためのプログラムであり、起動ファイルを実行すると、ゲームプログラムが呼び出されて実行される。OSが使用するファイル群は、たとえば、情報処理装置10におけるメニュー画面に表示されるゲームアイコン画像などを含む。
ゲームソフトウェアはツリー型ディレクトリ構造を有し、ルートディレクトリには起動ファイルが含まれている。下層のサブディレクトリは、ファイルの種類ごとに分類され、たとえば3Dモデル用のサブディレクトリ、テクスチャ用のサブディレクトリ、スクリプト用のサブディレクトリなどが形成されている。
図3は、ゲームソフトウェアのファイル構成の概念図を示す。本実施例のゲームソフトウェア70の本体は複数のファイルによって構成され、図示されるように複数のグループ72に論理的に分割される。各ファイルは複数のグループ72のうち少なくとも1つのグループに属し、また各グループ72には少なくとも1つのファイルが属している。図3に示すゲームソフトウェア70には、先頭グループとして第1グループ72aが存在し、それに後続するグループとして第2グループ72b、第3グループ72c、第4グループ72d、第5グループ72e、第6グループ72fが存在している。なお第6グループ72fに後続する7番目以降のグループ72が存在していてもよい。各グループは、第1、第2などのグループ番号によって識別される。
論理的に分割された各グループには、複数のサブディレクトリに含まれるファイルが属し、すなわち各グループは、種類の異なるファイルによって構成され、情報処理装置10がゲーム中のシーンやステージなどの特定の単位を実行するのに必要なファイルが属するように設定されている。
第1グループ72aには、ゲームソフトウェア70の起動に必要なプログラムファイルおよびデータファイルが属している。したがって情報処理装置10は、ゲームソフトウェア70をコンテンツサーバ12やストアサーバ16から取得する場合、第1グループ72aに属する全てのファイルをダウンロードすれば、後続の第2グループ72b以降のファイルをダウンロードしなくても、ただちにゲームソフトウェア70を起動することが可能となる。なお情報処理装置10は、第1グループ72aに属する全てのファイルを取得して、ゲームソフトウェア70を起動した後に、後続のグループ72に属するファイルをバックグランドでダウンロードする。このようにゲームの実行に必要な最低限のファイルをまず最初にダウンロードさせ、それらのファイルが揃った時点でゲームを実行可能とすることで、ユーザのダウンロード待ち時間を短くすることが可能となる。なお、本実施例においては、ROM媒体44に記録されるゲームソフトウェア70も、コンテンツサーバ12などからダウンロードされるゲームソフトウェア70も、同じファイルおよびディレクトリ構成をもつデータ構造を有している。
図4は、ゲームソフトウェアの具体的なファイル構成例を示す。第1グループ72aは、ゲームソフトウェア70の中で一番最初にダウンロードされるべきファイル群で構成されており、ここではゲームパラメータファイル、グループファイル、起動ファイルおよび必須リソースファイルが示されている。
ここでゲームパラメータファイルは、情報処理装置10のOSが使用するファイルであり、たとえばタイトルIDやディスプレイ解像度などの情報、またアイコン画像データなどを含んでいる。
グループファイルは、各ファイルがどのグループに含まれるかを記述する定義ファイルである。たとえばグループファイルはXMLで表現されてよいが、他のプログラム言語によって表現されてもよく、その形式は問わない。グループファイルについては、図5、図6に関して後述する。
起動ファイルは、ゲームプログラムを起動するためのプログラムである。また必須リソースファイルは、ゲーム実行に必須となるプログラムなどのリソースファイルやゲーム全体で使用する共通ファイルなどを含む。
情報処理装置10は、ゲームソフトウェア70をコンテンツサーバ12などからダウンロードする場合、第1グループ72aに属するファイル群を全て取得すれば、ゲームを起動することができる。逆に言えば、第1グループ72aは、ユーザがゲームの一部をプレイするために必要なファイル群を含むように構成されている。なお、ここでいうゲームプレイは、たとえばユーザがキャラクタを決定したり、ゲームレベルを決定するなど、ゲーム開始時に行う設定行動も含むものであってよい。つまり第1グループ72aは、ゲームを起動し、ユーザが少なくとも何らかの動作を行える状態にするために必要なファイル群を含んで構成されている。第1グループ72aに含まれるファイル群を用いて実行可能となるゲームプレイは、たとえばゲームの初期設定だけであってもよく、またゲームの第1ステージまでプレイ可能とするものであってもよい。これはゲームメーカ次第である。
図4に示す例では、第2グループ72bには、シーン1用の複数のリソースファイルが属しており、第3グループ72cには、シーン2用の複数のリソースファイルが属しており、第4グループ72dには、シーン3用の複数のリソースファイルが属している。具体的に複数のリソースファイルは、特定のシーン用の3Dモデルファイル、テクスチャファイル、スクリプトファイルなどであり、ディレクトリ構造の複数のサブディレクトリに含まれるファイルを含む。また第10グループ72kには、英語用のリソースファイルが属しており、また第11グループ72lには、日本語用のリソースファイルが属している。
近年のゲームは、言語が異なる複数の国で実行可能に作成されているものが多い。音声データおよび画像データは、複数の言語に対応して作成され、複数言語の音声ファイルおよび画像ファイルが、1つのパッケージソフトウェアに収められている。以下、このようなファイルを「言語依存」ファイルと呼ぶこともあるが、音声ファイルおよび画像ファイルは、基本的にデータサイズが大きくなる傾向があり、このような言語依存ファイルのデータサイズは、ゲームソフトウェア全体のデータサイズに対して、かなりの割合を占めることがある。そこで本実施例のゲームソフトウェア70は、必要な言語依存ファイルのみを取得できるように、言語ごとに音声ファイルおよび画像ファイルを集合させた言語用のリソースファイルのグループを含むようにしている。
図5は、グループとファイルの関係の一例を示す。ここでは、ファイルA〜Nが、各グループ72に属していることが示される。図示されるように、各ファイルは複数のグループ72のうち少なくとも1つのグループに属し、また各グループ72には少なくとも1つのファイルが属している。なおファイルGは、第2グループ72b、第3グループ72cおよび第4グループ72dに属している。このことは、ファイルGが、ゲーム中のシーン1、シーン2、シーン3を構成する上で必要なファイルであることを意味し、このように1つのファイルが、複数のグループに所属することもある。なお同様にファイルKも、複数のグループ72、すなわち第4グループ72dおよび第5グループ72eに属している。
図6は、グループファイルの一例を示す。既述したように、グループファイルはXMLによって表現されてもよく、他のプログラム言語によって表現されてもよい。図6には、理解を容易にするために、グループとファイルの対応関係をテーブル形式で表現したグループファイルを示している。情報処理装置10は、ゲームソフトウェア70の各ファイルをダウンロードする際に、グループファイルを参照して、あるグループに属するファイルが全て揃ったか、または揃ってないかを判定することが可能となる。たとえば第1グループ72aに関して言えば、情報処理装置10はグループファイルを参照することで、第1グループ72aに属するファイルが、ファイルA,B,C,D,E,Fであることを認識できるため、これらのファイルが補助記憶装置2に記録されていれば、第1グループ72aに属するファイルが全て揃ったことを判定する。
以上のように、ゲームソフトウェア70は、様々なゲームファイルを含んで構成されている。以下、本実施例のゲームデータのデータ構造について説明する。本実施例では、UNIX(登録商標)で利用されるファイル管理手法を利用して、ゲームデータを構成する。ゲームデータは、上記したゲームソフトウェア70の本体(複数のゲームファイルから構成される)と、メタデータとを少なくとも含んで構成される。
ファイルは、1または複数のブロックを割り当てられて構成される。ブロックは、ファイルシステムがデータを転送する基本単位であり、1つのブロックは所定のデータサイズ(たとえば64kバイト)に設定される。そのため1280kバイトのファイルであれば、20個のブロックを割り当てられることになる。各ファイルには、ファイルを構成する1以上のデータブロックの記録場所を格納するための索引表が設定される。
図7は、ゲームファイルのデータブロックのアドレッシングに使用されるデータ構造の参考例を説明するための図である。最初の1段目の索引表はindex node(略して「iノード」)と呼ばれ、データブロックのアドレッシング用に合計15個のエントリを有する。全てのファイルはiノードとデータブロックから構成され、iノードは、ファイルシステムにおいてファイルを識別するためのiノード番号を付与されている。iノードは、属性情報として、iノード番号、ファイルの種類、ファイルのバイト長、アクセス権などを有している。
この参考例として示すデータ構造においては、iノードのエントリに、データブロックの記録場所を特定するための情報が記録されている。この情報は、たとえば記録ディスクもしくはパーティションの先頭からの相対位置を指定するブロック番号であってよい。なお、データブロックの記録場所を特定するための情報は、ブロック番号に限らず、たとえばブロック番号を算出するためのブロックサイズやファイルオフセットなどの情報であってもよい。またデータブロックの記録場所を特定するための情報は、直接的に記録場所を特定する記録ディスクのセクタ番号であってもよい。
ファイル名と、そのファイルを管理するiノードのiノード番号(iノードへのポインタとしての意味をもつ)は、ディレクトリのデータブロックにおいて対応付けて保持されている。したがってゲームプログラムがファイルをファイル名で参照するとき、OSのカーネルは、ディレクトリエントリの情報を参照して、そのファイル名に対応するiノード番号を取得し、iノード番号で特定されるiノードに含まれるブロック番号を用いて、ファイルにアクセスする。
iノードの12個のエントリは、ファイル内の先頭から12個までのデータブロックのブロック番号を記録するために使用される。したがってファイルが12個以内のデータブロックで構成されていれば、iノードは、ブロック数分のエントリを用いて各データブロックのブロック番号を記録できる。
なお、ファイルが13個以上のブロックで構成されていると、複数段の索引表が必要となる。図7に示す例では、iノードの13番目のエントリには、2段目の索引表(インダイレクトブロック)のブロック番号が記録され、iノードの13番目のエントリが、インダイレクトブロックにリンクして、1段階目の間接参照に利用される。インダイレクトブロックは、固定のデータサイズを有して、256個のエントリを有している。インダイレクトブロックのエントリには、2段目のデータブロックのブロック番号が記録される。
iノードの14番目のエントリには、3段目の索引表(ダブルインダイレクトブロック)をリンクするための2段目の索引表(インダイレクトブロック)のブロック番号が記録されている。インダイレクトブロックのエントリには、ダブルインダイレクトブロックのブロック番号が記録されている。ダブルインダイレクトブロックは、256個のエントリを有しており、そのエントリには、3段目のデータブロックのブロック番号が記録されている。このようにiノードの14番目のエントリは、2段階目の間接参照に利用される。
iノードの15番目のエントリには、4段目の索引表(トリプルインダイレクトブロック)をリンクするための3段目の索引表(ダブルインダイレクトブロック)をリンクするための2段目の索引表(インダイレクトブロック)のブロック番号が記録されている。インダイレクトブロックのエントリには、ダブルインダイレクトブロックのブロック番号が記録されている。ダブルインダイレクトブロックのエントリには、トリプルインダイレクトブロックのブロック番号が記録されている。トリプルインダイレクトブロックは、256個のエントリを有しており、そのエントリには、4段目のデータブロックのブロック番号が記録されている。このようにiノードの15番目のエントリは、3段階目の間接参照に利用される。
以下、2段目以降の索引表(つまりiノード以外の索引表)を、まとめてindirect Block(インダイレクトブロック)と呼ぶこともある。
以下、2段目以降の索引表(つまりiノード以外の索引表)を、まとめてindirect Block(インダイレクトブロック)と呼ぶこともある。
参考例として示すゲームファイルのデータ構造においては、索引表の各エントリに、ブロック番号とともに、データブロックに含まれるデータのハッシュ値も格納される。ハッシュ値はたとえば32バイトのデータ値であり、データブロックを登録するエントリにデータブロック内のデータのハッシュ値を記録することで、ブロックのデータが読み出される際に、そのデータが正しいデータであるか否かを検証できるようにし、またデータの改ざんを防止することも可能となる。
上記したように、インダイレクトブロックは固定のデータサイズを有しており、索引表としてインダイレクトブロックが使用される場合には、固定長の領域を確保する必要がある。たとえば1つのゲームファイルのブロック数が20個である場合、iノードの12個のエントリと、2段目のインダイレクトブロックの8個のエントリに、データブロックが登録されて、各エントリに、それぞれのブロック番号とハッシュ値とが記録されることになるが、その結果、2段目のインダイレクトブロックの残りの248(=256−8)個のエントリは空であり、メタデータとして寄与しない無駄な領域となる。
ゲームソフトウェア70の本体は、複数たとえば10000個を超えるゲームファイルを含んで構成されている。このファイルシステムでは、ゲームファイルの読出しの目的のために、iノードおよびインダイレクトブロックに記録されたメタデータは全て、DDR3などのメモリ上に展開される。なおメモリ上には、ゲームファイルも可能な限り読み出すことが好ましく、したがってメタデータのデータサイズは、できるだけ小さいことが好ましい。
しかしながら上記したように、インダイレクトブロックのエントリに空データが多く存在すると、その空データもメモリ上に展開されることになり、結果としてメモリ容量を圧迫することになる。特に、10000個を超えるファイルが存在するようなゲームソフトウェア70では、各ファイルの索引表を用意することで、空データを含むメタデータが1Gバイトを超えることも生じうる。
図8は、ゲームデータのデータ構造の参考例を示す。この参考例で示されるデータ構造は、複数(たとえば10000個)のゲームファイルを含むゲームデータ領域202に、スーパブロック、iノードリストおよび複数(N個)のインダイレクトブロックを含むメタデータ領域200を付加した構造をとる。スーパブロックには、ゲームデータ領域202に含まれるファイルの管理情報が記録され、ブロックサイズ、総ブロック数などのメタデータが含まれる。iノードリストは、iノードを、少なくともゲームデータ領域202に含まれるファイル数分(たとえば10000個)含んでいる。(なお正確には、このファイルシステムでは、ディレクトリやファイル名も1つのファイルとして扱われるため、iノードリストには、ディレクトリやファイル名に関するiノードも含まれることになる。)
インダイレクトブロックは、iノードの12エントリでデータブロックを登録しきれなかったファイルに関して設けられる。この参考例においては、既述したように、iノードおよびインダイレクトブロックのエントリに、ブロック番号と、データブロックに含まれるデータのハッシュ値が含まれている。
そのためゲームデータ領域202に10000個のファイルが含まれる場合には、インダイレクトブロックが多数存在することになり、インダイレクトブロックの中には上記したように、エントリのほとんどが空データを含むものも存在する。そのためメタデータ領域200のデータサイズは不必要に大きくなり、ゲームプログラムの実行中、メタデータ領域200に含まれるメタデータをメモリに展開することは、メモリの効率的な使用の観点から好ましくない。
そこで本実施例のゲームデータは、各ファイルのブロックごとにハッシュ値をもつデータ構造ではなく、メタデータのデータサイズを可能な限り小さくしたデータ構造をとるようにする。具体的には、署名(ハッシュ値)無しの複数のファイルを1まとめにした完全平文のイメージファイルを作成し、このイメージファイルに対して、メタデータを付加したゲームデータを作成する。なおイメージファイルとは、ファイルシステムの構造や制御情報などを含んで1つのファイルとして構成されるものを意味する。
このゲームデータのデータ構造では、複数のファイルを記録媒体上の連続した場所(ブロック)に記録する。これにより各ファイルの記録場所は、先頭位置とファイルサイズとをメタデータとしてiノードのエントリに保持しておくことで、特定されることが可能となるため、各データブロックごとのブロック番号などの記録場所を特定するための情報をもつ必要がなくなる。また、データブロックごとの署名をしないことで、各ファイルのメタデータとしてデータブロックごとのハッシュ値をもつ必要がなくなるため、各ファイルのメタデータは、iノードのエントリに収めることができるようになる。つまりブロックごとのハッシュ値を生成せず、さらにデータブロックを連続した番号のブロックに記録することで、インダイレクトブロックを必要とせずにすみ、メタデータのデータサイズを大幅に削減することが可能となる。
図9は、ゲームデータの作成方法を示すフローチャートである。このフローチャートに示すステップは、ゲームメーカにおいて、最終的なゲームパッケージソフトウェアを作成する過程を表現しており、パッケージ作成ソフトウェアにより実現される。まずパッケージ作成ソフトウェアは、平文(圧縮なし、暗号化なし、署名なし)のゲームデータのイメージファイルを作成する(S10)。既述したように、イメージファイルは、ファイルシステムの構造や制御情報などを含んだ1つのファイルとして構成される。
図10(a)は、本実施例のゲームデータの完全平文のイメージファイルの一例を示す。このイメージファイル210は、複数(たとえば10000個)のファイルを含むゲームデータ領域202に、スーパブロック、iノードリスト、スーパルートディレクトリおよびフラットパステーブルを含むメタデータ領域204を付加したデータ構造をとる。スーパルートディレクトリおよびフラットパステーブルについては後述する。スーパブロックには、ゲームデータ領域202に含まれるファイルの管理情報が記録され、ブロックサイズ、総ブロック数などのメタデータが含まれる。
ゲームデータ領域202に含まれる複数のゲームファイルには、連続した番号をもつ論理的なブロックが割り当てられている。ゲームデータ領域202に含まれる複数のゲームファイルに割り当てるブロックを整列することにより、1つのゲームファイルは、そのファイルが割り当てられた先頭のブロック番号と、ファイルのデータサイズとによって、記録媒体における格納場所を特定することが可能となる。そのためゲームファイルのiノードは、そのファイルの先頭のブロック番号と、ファイルのデータサイズとを記録しておくことで、ファイルの記録場所を特定する。これにより、OSが、ゲームファイルにアクセスする際には、ゲームファイルのiノード番号を取得することで、ゲームファイルの記録場所を知ることができる。
ゲームデータ領域202に記録されるゲームファイルは署名されないため、各ブロックごとのハッシュ値は存在しない。したがってファイルのメタデータを記録するためのインダイレクトブロックを用意する必要がなく、ファイルのメタデータは、iノードの1エントリに収めることが可能となる。そのためメタデータ領域204において、iノードリストは、ゲームデータ領域202におけるファイル数分のiノードを含む一方で、図8と比較して明らかなように、ファイルに関する複数のインダイレクトブロックはメタデータ領域204に含まれない。なお既述したように、このファイルシステムではディレクトリやファイル名も1つのファイルとして扱われるため、iノードリストには、ディレクトリやファイル名に関するiノードも含められることになるが、この場合にも、ディレクトリやファイル名は署名されないため、インダイレクトブロックを用意する必要がない。
図8に示すメタデータ領域200と比較すると、図10(a)に示すメタデータ領域204は、インダイレクトブロックを含まないために、そのデータサイズを大きく削減できている。そのためゲームプログラムの実行時、メタデータ領域204に含まれるメタデータをDDR3などのメモリに読み出しても、小さなデータサイズで済むことになる。
図9に戻り、パッケージ作成ソフトウェアは、図10(a)に示す平文のイメージファイル210を圧縮する(S12)。図10(b)は、圧縮したイメージファイルの一例を示す。パッケージ作成ソフトウェアは、圧縮したイメージファイル212に、連続した番号をもつ論理的なブロックを割り当てる。圧縮イメージファイル212においては、圧縮前と圧縮後のファイルのブロックの関係を示す圧縮テーブルが、メタデータ領域204に書き込まれる。圧縮テーブルでは、そのヘッダ部分に圧縮前の平文のイメージファイル210のサイズが記述され、またテーブル部分に圧縮前のブロック番号と、圧縮後のブロック番号および圧縮後のブロック番号のブロック内でのオフセット位置とが対応付けられて記述されている。このように圧縮することで、ゲームデータ領域206のデータサイズは、ゲームデータ領域202のデータサイズと比較して小さくなっている。
図10(a)および図10(b)に示すイメージファイル210、212は、このままでも、ゲームデータのイメージファイルとして使用されることが可能である。すなわち情報処理装置10において、OSは、イメージファイル210または212をゲームを実行するための所定のマウントポイント(以下、実行マウントポイントと呼ぶ)にマウントすると、起動ファイルが起動されて、ゲームプログラムが実行されることになる。このとき、メタデータ領域204のデータサイズは、インダイレクトブロックを含まずに小さくできているため、メモリ上にメタデータを効率的に展開できる。
しかしながら、イメージファイル210、212は署名されていないため、ブロックのデータが読み出される際に、そのデータが正しいデータであるか否かを検証することができず、またデータの改ざんを効果的に防止できないという欠点がある。そこで本実施例では、アーカイブ形式のイメージファイル212を1つのファイルとして扱って署名を行い、さらには暗号化も行って、セキュアなゲームデータを作成する。なお、ゲームデータ全体のデータサイズを小さくするためにイメージファイル212に対して署名および暗号化を施すこととしたが、圧縮前のイメージファイル210に対して署名および暗号化を施して、セキュアなゲームデータを作成してもよい。
パッケージ作成ソフトウェアは、圧縮したイメージファイル212を1つのファイルと見立てて、連続した番号をもつ論理的なブロックを割り当てる。パッケージ作成ソフトウェアは、圧縮イメージファイル212を構成する複数のブロックのそれぞれに署名を行い、具体的には各ブロックデータのハッシュ値を求め、イメージファイル212にメタデータとして付加する(S14)。なおパッケージ作成ソフトウェアは、ゲームデータのセキュリティを高めるために、作成したメタデータに署名を行い、さらにメタデータおよびゲームデータ本体に暗号化処理を行ってもよい。
図11は、本実施例のゲームデータのデータ構造の一例を示す。このデータ構造をもつゲームデータは、パッケージファイル214としてROM媒体44に記録され、またはパッケージファイル214としてコンテンツサーバ12やストアサーバ16から情報処理装置10にダウンロードされて、補助記憶装置2に記録される。
図11に示されるように、パッケージファイル214は、イメージファイル212をネストしたデータ構造をもつ。本実施例のデータ構造は、1つのファイルとして取り扱われるイメージファイル212に、スーパブロック、iノードリスト、複数(M個)のインダイレクトブロック、スーパルートディレクトリおよびフラットパステーブルを含むメタデータ領域208を付加した構造をとる。
スーパブロックには、イメージファイル212の管理情報が記録され、ブロックサイズ、総ブロック数などのメタデータが含まれる。iノードリストに含まれるイメージファイル212のiノードおよび複数のインダイレクトブロックは、1つのファイルとして見立てたイメージファイル212を分割したブロック数分を少なくとも含むエントリに、イメージファイル212の各ブロックのハッシュ値を含むメタデータを記録する。このようにパッケージファイル214は、1または複数のブロックを割り当てられたファイルを複数含み且つそれらのファイルのメタデータを含むゲームデータのイメージファイル212に、当該イメージファイル212を構成する複数のブロックのそれぞれに行った署名(ハッシュ値)を少なくとも含むメタデータが付加されたデータ構造を有して構成される。なお既述したように、イメージファイル212に含まれる各ファイルのブロックには、署名が行われていない。
記録媒体(ROM媒体44または補助記憶装置2)に記録されたパッケージファイル214は、イメージファイル212をネストしたデータ構造を有しているため、OSのカーネルは、パッケージファイル214を2度マウントすることで、ゲームデータ領域202に含まれる各ファイルにアクセスできるようになる。
第1段階のマウント処理では、カーネルが、パッケージファイル214を第1のマウントポイントにマウントして、パッケージファイル214のファイルシステムを認識できるようにする。具体的にカーネルは、パッケージファイル214のメタデータ領域208に含まれるメタデータを利用して、イメージファイル212を認識できるようにし、これによりイメージファイル212を1つのファイルとして見ることができるようになる。このマウント機能は、カーネルが第1のマウント処理部として動作することによって実現される。
第2段階のマウント処理では、カーネルがイメージファイル212を、ゲームプログラムを実行するための第2のマウントポイント(実行マウントポイント)にマウントして、イメージファイル212のファイルシステムを認識できるようにする。具体的にカーネルは、イメージファイル212のメタデータ領域204に含まれるメタデータを利用して、ゲームデータ領域206を認識できるようにし、これによりゲームデータ領域206に含まれる複数(たとえば10000個)のゲームファイルにアクセス可能となる。このマウント機能は、カーネルが第2のマウント処理部として動作することによって実現される。なお、第1段階のマウント処理における第1のマウントポイントは、第2段階のマウント処理における第2のマウントポイントと同じであってもよく、また異なっていてもよい。
第2段階のマウント処理を経て、カーネルは、起動ファイルを実行する。なお起動ファイルについてはゲームデータ領域206において圧縮が施されておらず、したがってカーネルは、起動ファイルをそのまま起動できる。イメージファイル212のメタデータ領域204のデータサイズは小さいため、メタデータを効率的にDDR3などのメモリに展開することができる。
以下、メタデータとしてイメージファイル210または212のメタデータ領域204に含まれるフラットパステーブルについて説明する。
本実施例のUNIXで利用されるファイル管理手法では、既述したようにディレクトリやファイル名もファイルの一種として取り扱われるため、ディレクトリやファイル名も1つのブロックに割り当てられて記録される。たとえば、「user/AAA/BBB/CCC/ファイル名」というディレクトリ構造があった場合、それぞれのディレクトリ名、ファイル名に対して1ブロックずつ割り当てられて、合計で5ブロックが必要となる。
本実施例のUNIXで利用されるファイル管理手法では、既述したようにディレクトリやファイル名もファイルの一種として取り扱われるため、ディレクトリやファイル名も1つのブロックに割り当てられて記録される。たとえば、「user/AAA/BBB/CCC/ファイル名」というディレクトリ構造があった場合、それぞれのディレクトリ名、ファイル名に対して1ブロックずつ割り当てられて、合計で5ブロックが必要となる。
特に、ゲームデータのファイル数が多くなると、ディレクトリの数も多くなる。既述したように、ファイルのiノードは、メタデータとしてDDR3などのメモリに読み出される必要があるため、可能な限りメタデータの容量を小規模化することが好ましい。そこで本実施例のデータ構造では、上記の例で示した(user/AAA/BBB/CCC/ファイル名)のフルパスの情報をメタデータとしては利用せず、メタデータ容量を削減する目的でフラットパステーブルを利用する。
フラットパステーブルは、ゲームファイルのフルパス情報のハッシュ値と、ゲームファイルの記録位置を特定するための情報とを対応付けた対応ファイルとして構成される。フラットパステーブルは、ゲームプログラムから読み出される可能性のある全てのゲームファイルのフルパス情報のハッシュ値と、そのゲームファイルの記録位置を特定するための情報とを対応付けて記録することが好ましい。ここで、ファイルの記録位置を特定するための情報は、記録媒体に記録されたファイルを一意に特定するiノード番号であってよい。したがって本実施例のフラットパステーブルでは、たとえばフルパス(user/AAA/BBB/CCC/ファイル名)のハッシュ値と、当該ファイルのiノード番号とが対応付けられて記録される。OSにおけるファイル読出API(Application Programming Interface)は、ゲームプログラムがフルパス情報を含むファイル読出要求を出力すると、逐次、フルパスのハッシュ値を求めて、そのハッシュ値から、フラットパステーブルにおけるiノード番号を探索し、ファイルを構成するブロックを特定するようにする。
図12(a)は、フラットパステーブルの一例を示す。フラットパステーブル220では、各フルパス情報のハッシュ値と、そのフルパス情報に対応するiノード番号とが対応付けて記録される。ここでハッシュ値は、たとえば4バイトの値として構成され、したがってフルパス情報のハッシュ値は、フルパス情報のデータ量と比較して、非常に小さく構成できる。フラットパステーブル220において、フルパス情報のハッシュ値は降順に並べられており、ここでは説明の便宜上、ハッシュ値を16進数で表現している。
一方で、ハッシュ値を採用することで、複数のフルパス情報のハッシュ値が同じになることが生じうる。これは一般に「ハッシュ値の衝突」と呼ばれるものであるが、フラットパステーブル220では、フルパス情報をデータ量の小さいハッシュ値に置換しているために、ハッシュ値同士の衝突が生じうる。その場合、異なるiノード番号に対応付けられた同じハッシュ値が並存することになるため、これらのハッシュ値を区別するために、フラットパステーブル220は、その付随ファイルとして、衝突ファイル222を定義する。
図12(b)は、衝突ファイルの一例を示す。衝突ファイル222は、ハッシュ値が衝突するフルパス情報に対して、ファイル名とファイルの記録位置を特定するための情報(ここではiノード番号)とが対応付けて記録する。
図12(a)のテーブル右項目における「iノード番号/オフセット」について説明する。この項目は、たとえば4バイトで表現されており、その上位ビットには、衝突の有無を示す情報が少なくとも設定されている。一例では、この情報は衝突フラグとして用意され、ここで衝突している場合には衝突フラグ1が、衝突していない場合には衝突フラグ0がセットされるものとする。
図12(a)のテーブル右項目における「iノード番号/オフセット」について説明する。この項目は、たとえば4バイトで表現されており、その上位ビットには、衝突の有無を示す情報が少なくとも設定されている。一例では、この情報は衝突フラグとして用意され、ここで衝突している場合には衝突フラグ1が、衝突していない場合には衝突フラグ0がセットされるものとする。
したがってフラットパステーブル220において、重複するハッシュ値が存在しないハッシュ値(非衝突ハッシュ値)については、上位ビットの衝突フラグが0に設定され、その下位ビットに、iノード番号が記述される。OSにおけるファイル読出APIは、ゲームプログラムがフルパス情報を指定したファイル読出要求を出力すると、フルパス情報のハッシュ値を求め、そのハッシュ値から、メモリ上に展開されているフラットパステーブルにおけるiノード番号を探索する。このとき対応するハッシュ値が非衝突ハッシュ値であれば(すなわち衝突フラグが0に設定されていれば)、テーブル右項目に記述されているiノード番号を特定して、ファイルを読み出す。
一方でフラットパステーブル220において、重複するハッシュ値が存在するハッシュ値(衝突ハッシュ値)については、上位ビットの衝突フラグが1に設定され、その下位ビットに、オフセット情報が記述されている。ここでオフセット情報は、衝突ファイルに対する記録位置のオフセットを示すものであり、衝突ファイルに含まれるデータが記述される最初の位置を特定する情報である。OSにおけるファイル読出APIは、ゲームプログラムがフルパス情報を指定したファイル読出要求を出力すると、フルパス情報のハッシュ値を求め、そのハッシュ値から、メモリ上に展開されているフラットパステーブルにおけるiノード番号を探索する。このとき対応するハッシュ値が衝突ハッシュ値であれば(すなわち衝突フラグが1に設定されていれば)、オフセット情報から、衝突ファイルにアクセスして、衝突ファイルに記録されたデータを探索する。
たとえば読出要求されたフルパス情報のハッシュ値が“012B341C”であり、テーブル右項目において衝突フラグが1に設定されていると、読出APIは、衝突ファイルを参照して、読出要求されたファイル名を探索する。図12(b)に示すように、衝突ファイルにおいては、ファイル名と、iノード番号とが対応付けて記録されており、読出APIは、衝突ファイルの内部を探索して、ファイル読出要求されたファイル名を見つけ出す。衝突ファイルにおいては、ファイル名に対してiノード番号が対応付けられているため、読出APIは、ファイル名をもとに、iノード番号を特定して、ファイルを読み出すことができる。
このようにイメージファイル210または212において、メタデータ領域204に、フルパス情報の代わりに、フラットパステーブルおよび衝突ファイルを用意しておくことで、プログラム実行時にメモリに読み出すメタデータ量を削減できるようになる。
次にスーパルートディレクトリについて説明する。
図13(a)は、通常のルートディレクトリおよび下層のサブディレクトリを示す。サブディレクトリは、ゲームプログラムの実行に必要なファイルの種類ごとに構成されている。カーネルは、ルートディレクトリを所定の実行マウントポイントにマウントすることで、ゲームプログラムを実行できる。
図13(a)は、通常のルートディレクトリおよび下層のサブディレクトリを示す。サブディレクトリは、ゲームプログラムの実行に必要なファイルの種類ごとに構成されている。カーネルは、ルートディレクトリを所定の実行マウントポイントにマウントすることで、ゲームプログラムを実行できる。
図13(b)は、本実施例で使用するスーパルートディレクトリおよび下層のサブディレクトリを示す。スーパルートディレクトリは、ルートディレクトリの上層に設定され、ルートディレクトリは、スーパディレクトリのサブディレクトリとなる。なお図13(b)に示すディレクトリ構造においても、カーネルが、スーパルートディレクトリをマウントすることで、ルートディレクトリの起動ファイルを実行できることには変わりないが、上層のスーパディレクトリを設けたことで、ルートディレクトリの下層を変更することなく、ルートディレクトリとは別に分岐したスーパディレクトリの下層に、サブディレクトリを容易に追加できるようになる。これにより、たとえばフラットパステーブルのファイルをスーパディレクトリの下層に配置できるようになり、拡張性に優れたファイルシステムを提供できる。
図14は、ゲームデータに含まれるファイルにアクセスするファイルアクセス機能を実現するための構成を示す。情報処理装置10は、受付部100、ハッシュ値導出部102、iノード番号取得部104およびファイルアクセス部106を備える。これらの構成は、ハードウエアコンポーネントでいえば、任意のコンピュータのCPU、メモリ、メモリにロードされたプログラム、ストレージなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。ここで受付部100、ハッシュ値導出部102およびiノード番号取得部104の機能は、上記した読出APIにより実現されてよい。
ゲームの実行中、受付部100は、ゲームからファイルのフルパス情報を含む読出要求を受け付ける。ハッシュ値導出部102は、受け取ったフルパス情報のハッシュ値を所定のハッシュ関数により導出する。iノード番号取得部104は、対応ファイルとして構成されるフラットパステーブル220を参照し、ハッシュ値を用いて、ファイルの記録位置を特定するための情報、ここではiノード番号を取得する。これによりファイルアクセス部106は、iノード番号を用いて、ゲームにより指定されたファイルにアクセスでき、当該ファイルを読み出す。
なお上記は、ハッシュ値導出部102が導出したハッシュ値が非衝突ハッシュ値である場合のファイルアクセス動作を示し、iノード番号取得部104は、導出したハッシュ値の衝突フラグが0に設定されている場合に、ハッシュ値が衝突していないことを判定して、フラットパステーブル220からiノード番号を取得できる。
一方で、ハッシュ値導出部102が導出したハッシュ値が衝突ハッシュ値である場合には、iノード番号取得部104は、導出したハッシュ値の衝突フラグが1に設定されていることから、ハッシュ値が衝突していることを判定する。したがってiノード番号取得部104は、当該ハッシュ値に対応付けられているオフセット情報から、衝突ファイル222にアクセスして、衝突ファイル222内で、フルパス情報で指定されたファイル名を探索する。衝突ファイル222において、ファイル名を見つけると、iノード番号取得部104は、ファイル名に対応付けられたiノード番号を取得する。このようにiノード番号取得部104は、ハッシュ値導出部102が導出したハッシュ値が衝突するものである場合に、衝突ファイル222を参照して、ファイル名からiノード番号を取得する。これによりファイルアクセス部106は、iノード番号を用いて、ゲームにより指定されたファイルにアクセスでき、当該ファイルを読み出す。
以上のようにファイルアクセス部106は、iノード番号を用いてファイルにアクセスするが、本実施例の情報処理装置10においては、ファイルを記憶する記憶部として、バッファとして動作するメモリ(たとえばDDR3)、補助記憶装置2およびROM媒体44が存在している。ROM媒体44はメディアドライブ32に装着されてデータの読出を行われるものであるが、ここで、メモリと、補助記憶装置2と、メディアドライブ32のデータ読出速度をそれぞれ比較すると、この順にデータ読出速度が高速となる。
この意味において本実施例では、メモリを高速デバイス、補助記憶装置2を中速デバイス、メディアドライブ32を低速デバイスと呼ぶ。以下において、このデータ読出速度の違いに着目したファイルアクセス処理を高速にする仕組みについて説明する。
なお、高速化の仕組みを説明する前に、情報処理装置10は、ROM媒体44に記録されたゲームソフトウェア70の実行中に、ROM媒体44に記録されたゲームソフトウェア70を補助記憶装置2にコピーする機能を有しており、まずは、このコピー機能について説明する。
図15は、ファイル管理機能を実現するための構成を示す。情報処理装置10は、ファイルアクセスを行うファイルアクセス部106と、ファイル管理を行うファイル管理部108を備える。ファイル管理部108は、ROM媒体44から補助記憶装置2にゲームソフトウェア70をコピーする機能も有する。情報処理装置10は、ファイルを記憶する記憶部120として、高速デバイスであるメモリ110、中速デバイスである補助記憶装置2、低速デバイスであるメディアドライブ32を有する。メモリ110は、補助記憶装置2またはメディアドライブ32と接続して、これらから読み出されるデータを一時的に記憶する役割をもつ。なおファイルアクセスを高速化するために、メモリ110には、図10に示すメタデータ領域204に含まれるメタデータが予め展開されている。
図14に関連して説明したように、ファイルアクセス部106は、iノード番号を用いて、ゲームによりフルパス情報で指定されたファイルにアクセスして、当該ファイルのデータを読み出す。具体的にファイルアクセス部106は、iノード番号により特定されるROM媒体44の記録領域からファイルデータをメモリ110に読み出し、メモリ110からファイルデータを取得して、ゲームプログラムに提供する。
図16は、コピー処理の一例を説明するための図である。このコピー処理においては、ゲームプログラムが実行されていることが前提となる。ゲームプログラムがデータの読み出しを要求すると、ファイルアクセス部106が、メディアドライブ32からROM媒体44に記録されたデータを読み出し、メモリ110が、読み出されたデータを一時的に記憶する(ST1)。ファイルアクセス部106は、メモリ110に記憶されたデータをゲームプログラムに提供する(ST2)。これによりゲームプログラムは、読み出しを要求したデータを用いてゲームを進行することができる。
このときファイル管理部108は、メモリ110に記憶されたデータを読み出し、補助記憶装置2に記録する(ST3)。このように、ゲームプログラムからの要求にしたがってメモリ110に読み出されたデータを、ゲームプログラムに提供するだけではなく、補助記憶装置2に記録することで、データを低速デバイスから中速デバイスにコピーすることが可能となる。補助記憶装置2にコピーされたデータは、ゲームプログラムにより次回必要とされたときに、補助記憶装置2からゲームに対して読み出される。
ファイル管理部108は、ROM媒体44から補助記憶装置2にコピーされたファイルを管理する。たとえばファイル管理部108は、1つのファイルに対して、コピーされたか否かを示す情報を、ビットマップとして管理してよい。なお本実施例において、ファイルは1以上のブロックから構成されており、したがってファイル管理部108は、ブロック単位で、コピーされたか否かを示す情報を管理することが好ましい。ファイル管理部108は、ROM媒体44から補助記憶装置2にデータブロックをコピーすると、ブロックビットマップ上において、対応するデータブロックがコピーされたことを示す情報(フラグ)を立てて、ブロックビットマップを更新する(ST4)。これによりファイル管理部108は、どのブロックがROM媒体44から補助記憶装置2にコピーされたかを知ることができる。
図17は、記憶部120の各記憶部の記憶領域の状態を模式的に示す。上段は、高速デバイスであるメモリ110の記憶領域の状態、中段は、中速デバイスである補助記憶装置2の記憶領域の状態、下段は、低速デバイスであるROM媒体44の記憶領域の状態を示す。各記憶領域を模式的に示す横長矩形領域において、縦線で区切られている領域はブロックを表現し、ハッチングが施されたブロックは、記憶領域に記憶済みであることを表現している。
ここで上段に示すメモリ110にはメタデータ領域204のメタデータが記憶され、さらに、余った記憶領域に、一部のゲームデータが一時的に記憶されている。メモリ110の記憶領域は小さいために、メタデータ領域204に含まれるメタデータのサイズを可能な限り小さくすることで、ゲームデータを一時記憶するための領域を広げることが可能となる。なお、ここではメモリ110の記憶領域がフルに使用されているように示されているが、実際には、メモリ110における所定サイズの記憶領域を示すのであって、フルに使用するわけではない。
ブロックビットマップ(ブロックBMP)は、ファイル管理部108により管理されるビットマップ情報を示す。ファイル管理部108は、ROM媒体44から補助記憶装置2にコピーされたブロックにはフラグ値1を、コピーされていないブロックにはフラグ値0をセットして、ブロックBMPを作成する。上記したように、ROM媒体44から補助記憶装置2へのブロックのコピーが行われる度に、ファイル管理部108は、ブロックBMPを更新する。これによりファイル管理部108は、補助記憶装置2の最新の記憶状態を把握している。中段に示す補助記憶装置2の一例であるHDD(ハードディスクドライブ)には、コピー処理によってROM媒体44からコピーされたブロックデータが記録される。ハッチングが施されていないブロック領域は、まだブロックのデータがコピーされていないことを示している。
下段に示すROM媒体44の一例であるBD(ブルーレイディスク)には、ゲームソフトウェアの全てのデータ(パッケージファイル214)が記録されているため、全ての記憶領域にハッチングが施されている。なおパッケージファイル214に含まれるゲームデータは、パッケージファイル214が実際には暗号化されたり圧縮されていることで、イメージファイル210のゲームデータ領域202のゲームデータとは異なるブロックが対応する。図17においては、復号後および/または圧縮解凍後のブロックが仮想的に表現されているのであって、各記憶領域の縦方向に重なるブロックは、同じブロックを示している。
図15に戻って、ファイルアクセス部106は、ファイル管理部108において管理されている記憶部120の各記憶状況をもとに、アクセスする記憶媒体を決定する。あらためて記憶部120におけるメモリ110、補助記憶装置2、ROM媒体44のゲームデータの記憶状況について説明する。
(1)メモリ110における記憶状況
メモリ110には、メタデータ領域204におけるメタデータの全てが記憶されている。これによりファイルアクセス部106は、記録媒体に記録されているメタデータをシークして探索する必要がなく、メモリ110に展開されたメタデータを参照して、ゲームから読出要求のあったファイルのiノード番号を高速に特定できるようになる。またメモリ110には、ゲームデータの一部も一時的に記憶されている。このゲームデータは、必要に応じて随時更新される。ファイル管理部108は、メモリ110における記憶状況を管理し、どのブロックのデータが記憶されているかを把握している。
メモリ110には、メタデータ領域204におけるメタデータの全てが記憶されている。これによりファイルアクセス部106は、記録媒体に記録されているメタデータをシークして探索する必要がなく、メモリ110に展開されたメタデータを参照して、ゲームから読出要求のあったファイルのiノード番号を高速に特定できるようになる。またメモリ110には、ゲームデータの一部も一時的に記憶されている。このゲームデータは、必要に応じて随時更新される。ファイル管理部108は、メモリ110における記憶状況を管理し、どのブロックのデータが記憶されているかを把握している。
(2)補助記憶装置2における記憶状況
補助記憶装置2には、ROM媒体44から一度メモリ110に読み出されたデータがコピーされて記憶されている。なお上記したコピー処理においては、ゲームから読出要求を受けてメモリ110に読み出されたデータをコピーすることを説明したが、たとえば、ゲームからの読出要求がない場合であっても、ファイル管理部108が、バックグランドでROM媒体44から補助記憶装置2にゲームデータをコピーしてもよい。この場合、補助記憶装置2には、読出要求を受けたゲームデータだけでなく、それ以外のゲームデータも記憶されることになる。このようなコピー処理により、補助記憶装置2は、ROM媒体44に記録されているゲームソフトウェアの全部または一部を記録している。ファイル管理部108は、補助記憶装置2における記憶状況をブロックビットマップによって管理し、どのブロックのデータが記憶されているかを把握している。
補助記憶装置2には、ROM媒体44から一度メモリ110に読み出されたデータがコピーされて記憶されている。なお上記したコピー処理においては、ゲームから読出要求を受けてメモリ110に読み出されたデータをコピーすることを説明したが、たとえば、ゲームからの読出要求がない場合であっても、ファイル管理部108が、バックグランドでROM媒体44から補助記憶装置2にゲームデータをコピーしてもよい。この場合、補助記憶装置2には、読出要求を受けたゲームデータだけでなく、それ以外のゲームデータも記憶されることになる。このようなコピー処理により、補助記憶装置2は、ROM媒体44に記録されているゲームソフトウェアの全部または一部を記録している。ファイル管理部108は、補助記憶装置2における記憶状況をブロックビットマップによって管理し、どのブロックのデータが記憶されているかを把握している。
(3)ROM媒体44における記憶状況
ROM媒体44には、全てのメタデータおよびゲームファイルが記憶されている。
ROM媒体44には、全てのメタデータおよびゲームファイルが記憶されている。
以上のコピー処理が行われている前提のもとで、ファイルアクセス部106は、ゲームからの読出要求に応じて、所定の優先順位にしたがって、ROM媒体44、補助記憶装置2またはメモリ110のいずれかからゲームデータをゲームに提供する。既述したようにファイル管理部108は、メモリ110および補助記憶装置2のゲームデータの記憶状況を管理しており、具体的にはファイル単位またはブロック単位で記憶状況を管理している。特に補助記憶装置2の記憶状況に関しては、各ブロックまたはファイルごとにコピー済みであるか否かを示す情報を設定したビットマップを用いて管理している。
所定の優先順位は、データ読出の速いデバイスが優先的に選択されるように設定される。具体的にファイルアクセス部106は、読出要求されたゲームデータがメモリ110に記憶されていれば、メモリ110からゲームデータをゲームに提供する。このときファイル管理部108は、補助記憶装置2の記憶状況を示すビットマップを参照する必要がない。
読出要求されたゲームデータがメモリ110に記憶されていない場合、ファイル管理部108は、ビットマップを参照して、当該ゲームデータが補助記憶装置2に記憶されているか確認する。当該ゲームデータが補助記憶装置2に記憶されていれば、ファイルアクセス部106は、補助記憶装置2からゲームデータをメモリ110に読み出して、ゲームに提供する。このようにファイルアクセス部106は、読出要求されたゲームデータがメモリ110に記憶されておらず、補助記憶装置2に記憶されていれば、補助記憶装置2からゲームデータをゲームに提供する。
ファイル管理部108によって、読出要求されたゲームデータがメモリ110および補助記憶装置2に記憶されていないことが判定されると、ファイルアクセス部106は、メディアドライブ32に装着されたROM媒体44からゲームデータをメモリ110に読み出して、ゲームに提供する。なお、このときファイル管理部108は、ROM媒体44からメモリ110に読み出したゲームデータを補助記憶装置2にコピーし、ビットマップを更新する。これにより、次回、この同じゲームデータをゲームに提供する際には、ROM媒体44からではなく補助記憶装置2から提供することが可能となる。なお、このときメモリ110に当該ゲームデータが記憶されていれば、メモリ110からゲームに提供される。
このように、記憶部120における各記憶部を速度順に優先順位を定め、優先順位の高い記憶部に記憶されているゲームデータをゲームに対して提供することで、より高速なファイルアクセスが実現できる。
以上は、ROM媒体44のゲームデータを補助記憶装置2にコピーした場合のファイルアクセスについて説明した。次に、コンテンツサーバ12やストアサーバ16から、ゲームソフトウェアをダウンロードしたときのファイルアクセスについて説明する。
ゲームソフトウェアのダウンロード処理において、補助記憶装置2は、ゲームソフトウェアを構成する複数のファイルを格納するための記憶装置として利用される。図3〜図6に関して説明したように、ゲームソフトウェアにおいて、各ファイルは少なくとも1つのグループに所属しており、また各グループには少なくとも1つのファイルが所属している。
ダウンロード処理はグループ単位で実行され、たとえば、ファイルX,Y,ZがグループSに属している場合、グループSのダウンロード要求が生成された場合には、ファイルX,Y,Zがコンテンツサーバ12からダウンロードされて、グループSに属する全てのファイルX,Y,Zが補助記憶装置2に記録されるようになる。なお既にファイルXがダウンロード済みである場合には、ファイルY,Zがコンテンツサーバ12からダウンロードされて、これによりグループSに属する全てのファイルX,Y,Zが補助記憶装置2に記録されるようになる。
図3に示すように、ゲームソフトウェアのグループはグループ番号で特定することができる。グループ番号は1から降順に設定されており、ダウンロード処理部(図示せず)は、グループの1つの決定手法として、ダウンロードするグループの順番を、グループ番号順と同じく定めてもよい。つまりダウンロード処理部は、より番号の小さいグループを、より早い順番でダウンロードする対象として決定し、したがって第1グループ72a、第2グループ72b、第3グループ72c・・・と、グループ番号順にダウンロードすることを決定し、その順番にしたがってグループに含まれるファイルをダウンロードする。
ダウンロード処理部は、グループ単位でダウンロード要求をコンテンツサーバ12に送信し、コンテンツサーバ12から送信されるゲームデータを補助記憶装置2に記録する。このときファイル管理部108は、グループ単位で、ファイルまたはブロックの記憶状況を管理する。ダウンロードするファイルは、圧縮且つ暗号化されたパッケージファイル214であるため、ファイル管理部108は、パッケージファイル214におけるゲームデータの記憶状況を示す第1ビットマップと、パッケージファイル214を復号して、圧縮解凍したときのゲームデータの記憶状況を示す第2ビットマップとを生成する。なお、この第2ビットマップは、ROM媒体44から補助記憶装置2へのゲームデータコピーに関して説明したビットマップと同じものである。ゲームデータコピーに関して説明したように、ファイル管理部108が、第2ビットマップを管理することで、ファイルアクセス部106は、効率的にファイルアクセスすることが可能になる。なおファイルアクセス部106が、第1ビットマップを管理することで、たとえばマウントされないファイルをダウンロードするような場合に、ファイル管理を適切に行うことが可能となる。
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。実施例では、アプリケーションの例としてゲームを示したが、それ以外のアプリケーションであってもよい。
1・・・情報処理システム、2・・・補助記憶装置、10・・・情報処理装置、32・・・メディアドライブ、44・・・ROM媒体、70・・・ゲームソフトウェア、100・・・受付部、102・・・ハッシュ値導出部、104・・・iノード番号取得部、106・・・ファイルアクセス部、108・・・ファイル管理部、110・・・メモリ、120・・・記憶部、200・・・メタデータ領域、202・・・ゲームデータ領域、204・・・メタデータ領域、206・・・ゲームデータ領域、208・・・メタデータ領域、210,212・・・イメージファイル、214・・・パッケージファイル、220・・・フラットパステーブル、222・・・衝突ファイル。
Claims (6)
- ゲームデータに含まれるファイルにアクセスする情報処理装置であって、ゲームデータは、ファイルのフルパス情報のハッシュ値と、ファイルの記録位置を特定するための情報とを対応付けた対応ファイルを有しており、
ゲームからファイルのフルパス情報を含む読出要求を受け付ける受付部と、
フルパス情報のハッシュ値を導出する導出部と、
対応ファイルを参照して、ハッシュ値を用いて、ファイルの記録位置を特定するための情報を取得する取得部と、
取得した情報をもとに、ファイルにアクセスするファイルアクセス部と、
を備えることを特徴とする情報処理装置。 - ゲームデータは、ハッシュ値が衝突するフルパスに対して、ファイル名とファイルの記録位置を特定するための情報とを対応付けた衝突ファイルをさらに有しており、
取得部は、導出部が導出したハッシュ値が衝突するものである場合に、衝突ファイルを参照して、ファイル名から、ファイルの記録位置を特定するための情報を取得することを特徴とする請求項1に記載の情報処理装置。 - コンピュータにより実行されるプログラムファイルを含むゲームデータのデータ構造であって、ゲームデータは、1または複数のブロックを割り当てられたファイルを複数含み且つ各ファイルのメタデータを含んで構成されており、
ファイルのフルパス情報のハッシュ値と、ファイルの記録位置を特定するための情報とを対応付けた対応ファイルと、
ハッシュ値が衝突するフルパス情報に対して、ファイル名とファイルの記録位置を特定するための情報とを対応付けた衝突ファイルと、
を備えたことを特徴とするゲームデータのデータ構造。 - 対応ファイルには、ハッシュ値が衝突しているか否かを示す情報が含まれていることを特徴とする請求項3に記載のゲームデータのデータ構造。
- コンピュータに、
ゲームからファイルのフルパス情報を含む読出要求を受け付ける機能と、
フルパス情報のハッシュ値を導出する機能と、
ファイルのフルパス情報のハッシュ値と、ファイルの記録位置を特定するための情報とを対応付けた対応ファイルを参照して、ハッシュ値を用いて、ファイルの記録位置を特定するための情報を取得する機能と、
取得した情報をもとに、ファイルにアクセスする機能と、
を実現させるためのプログラム。 - 請求項5に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013228809A JP2015088144A (ja) | 2013-11-01 | 2013-11-01 | 情報処理装置およびゲームデータのデータ構造 |
EP14003112.1A EP2878348B1 (en) | 2013-11-01 | 2014-09-09 | Information processing device, data structure of game data, program, and recording medium |
US14/510,438 US10052555B2 (en) | 2013-11-01 | 2014-10-09 | Information processing device, data structure of game data, and recording medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013228809A JP2015088144A (ja) | 2013-11-01 | 2013-11-01 | 情報処理装置およびゲームデータのデータ構造 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2015088144A true JP2015088144A (ja) | 2015-05-07 |
Family
ID=53050801
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013228809A Pending JP2015088144A (ja) | 2013-11-01 | 2013-11-01 | 情報処理装置およびゲームデータのデータ構造 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2015088144A (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021081785A (ja) * | 2019-11-14 | 2021-05-27 | 株式会社ソニー・インタラクティブエンタテインメント | 情報処理装置およびファイル記録方法 |
JP2021096594A (ja) * | 2019-12-16 | 2021-06-24 | 株式会社ソニー・インタラクティブエンタテインメント | 情報処理装置およびファイルアクセス方法 |
US11836367B2 (en) | 2019-12-16 | 2023-12-05 | Sony Interactive Entertainment Inc. | Information processing device and file access method |
US12013821B2 (en) | 2019-12-16 | 2024-06-18 | Sony Interactive Entertainment Inc. | Information processing apparatus and file recording method |
-
2013
- 2013-11-01 JP JP2013228809A patent/JP2015088144A/ja active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021081785A (ja) * | 2019-11-14 | 2021-05-27 | 株式会社ソニー・インタラクティブエンタテインメント | 情報処理装置およびファイル記録方法 |
JP7348815B2 (ja) | 2019-11-14 | 2023-09-21 | 株式会社ソニー・インタラクティブエンタテインメント | 情報処理装置およびファイル記録方法 |
US11848033B2 (en) | 2019-11-14 | 2023-12-19 | Sony Interactive Entertainment Inc. | Information processing device and file recording method |
JP2021096594A (ja) * | 2019-12-16 | 2021-06-24 | 株式会社ソニー・インタラクティブエンタテインメント | 情報処理装置およびファイルアクセス方法 |
WO2021124634A1 (ja) * | 2019-12-16 | 2021-06-24 | 株式会社ソニー・インタラクティブエンタテインメント | 情報処理装置およびファイルアクセス方法 |
JP7321917B2 (ja) | 2019-12-16 | 2023-08-07 | 株式会社ソニー・インタラクティブエンタテインメント | 情報処理装置およびファイルアクセス方法 |
US11836367B2 (en) | 2019-12-16 | 2023-12-05 | Sony Interactive Entertainment Inc. | Information processing device and file access method |
US11983177B2 (en) | 2019-12-16 | 2024-05-14 | Sony Interactive Entertainment Inc. | Information processing device and file access method |
US12013821B2 (en) | 2019-12-16 | 2024-06-18 | Sony Interactive Entertainment Inc. | Information processing apparatus and file recording method |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9286059B2 (en) | Information processing device and difference generating for software patching system | |
JP2015088146A (ja) | 情報処理装置 | |
US9529725B2 (en) | Information processing device and method for managing file | |
JP2015088143A (ja) | 情報処理装置およびゲームデータのデータ構造 | |
JP4342596B1 (ja) | 電子装置およびコンテンツデータ提供方法 | |
EP2878348B1 (en) | Information processing device, data structure of game data, program, and recording medium | |
JP2015088144A (ja) | 情報処理装置およびゲームデータのデータ構造 | |
JP5877186B2 (ja) | 情報処理装置 | |
JP2009282617A (ja) | 電子装置およびコンテンツデータ提供方法 | |
JP2009282624A (ja) | 電子装置およびコンテンツデータ提供方法 | |
JP6855348B2 (ja) | 情報処理装置およびダウンロード処理方法 | |
JP6767319B2 (ja) | 情報処理装置およびファイルコピー方法 | |
WO2021124634A1 (ja) | 情報処理装置およびファイルアクセス方法 | |
JP7271410B2 (ja) | 情報処理装置およびファイル記録方法 | |
JP2009282623A (ja) | 電子装置およびコンテンツデータ提供方法 | |
JP2009282615A (ja) | 電子装置およびコンテンツデータ提供方法 | |
JP2009282616A (ja) | 電子装置およびコンテンツデータ提供方法 |