JP7170006B2 - 情報処理装置、情報処理システム、情報処理プログラム、および情報処理方法 - Google Patents

Description

本発明は、ロムデータに基づくゲーム処理を実行するエミュレータプログラムが動作する情報処理装置、情報処理システム、情報処理プログラム、情報処理方法に関する。

従来から、エミュレータプログラムと、ゲームのロムが複数記憶されている情報処理装置が知られている（例えば特許文献１）。この装置では、過去に発売されていたゲーム装置の動作をエミュレータプログラムで再現でき、インストールされている複数のゲームをプレイすることが可能となっている。

特開２００７－７５４６６号公報

上記のような情報処理装置は、単にエミュレータを使ったゲームをプレイ可能とするだけであった。そのため、当該ゲームに含まれる各種コンテンツ（プレイヤキャラクタ等）をさらに活用するようなことは考慮されていなかった。

それ故に、本発明の目的は、単にエミュレータを使ったゲームがプレイできることに加え、当該ゲームのコンテンツを活用する別のアプリをも実行可能な情報処理装置等を提供することである。

上記目的を達成するために、例えば以下のような構成例が挙げられる。

構成例の一例は、記憶媒体と、プロセッサとを備える情報処理装置である。記憶媒体は、ゲームのロムデータと、当該ロムデータに基づいてゲームを実行するエミュレータプログラムを少なくとも記憶する。プロセッサは、第１のモードにおいて、エミュレータプログラムによってロムデータに基づくゲーム処理を実行し、第２のモードにおいて、エミュレータプログラムにロムデータに基づくゲーム処理を実行させながら、更に実行中のエミュレータプログラムが処理するデータに変更を加えることにより、ゲーム処理とは異なり、かつロムデータに含まれるゲーム画像の少なくとも一部が表示されるアプリケーションを実行する。

上記構成例によれば、エミュレータを使ったゲームがプレイできることに加えて、ゲームのロムデータを利用することで当該ゲームに関連した別のアプリケーションを更に実行可能な情報処理装置を提供できる。アプリケーションを１から全て作るのではなく、ロムデータとエミュレータの挙動を利用することで、データ量を削減することが可能となる。また、開発コストを抑えながら、オリジナルのゲームの動作の再現性を高めることができる。

他の構成例として、ロムデータは、背景画像データとキャラクタ画像データを少なくとも含み、エミュレータプログラムは、ロムデータに基づいて背景画像とキャラクタ画像を生成し、キャラクタ画像に関連付けられたキャラクタを制御し、背景画像とキャラクタ画像を少なくとも含むゲーム画面を表示させることでゲームを実行してもよい。

他の構成例として、プロセッサは、第１のモードにおいて、エミュレータプログラムにキャラクタのうちプレイヤキャラクタを少なくとも制御させ、第２のモードにおいて、プレイヤキャラクタに関連付けられるキャラクタ画像が少なくとも表示されるアプリケーションを実行させてもよい。

上記構成例によれば、第１のモードでは、プレイヤキャラクタをユーザが操作するゲームを楽しませることができ、第２のモードでは、このプレイヤキャラクタが登場する他のアプリケーションをユーザに提供できる。これにより、オリジナルのゲームに登場するプレイヤキャラクタを活用したアプリケーションを提供できる。

他の構成例として、プロセッサは、第２のモードにおいて、プレイヤキャラクタを所定の位置に配置する変更を行った上で、エミュレータプログラムにプレイヤキャラクタを制御させてもよい。

上記構成例によれば、第２モードにおいて、プレイヤキャラクタの表示・配置位置の自由度を高めると共に、当該プレイヤキャラクタの挙動の再現性を高めることができる。

他の構成例として、プロセッサは、第１のモードにおいて、エミュレータプログラムに、操作部から入力されるキーデータに基づいてプレイヤキャラクタを制御させてもよい。更に、第２のモードにおいて、キーデータを疑似的に入力する変更を行った上で、エミュレータプログラムにプレイヤキャラクタを制御させてもよい。

上記構成例によれば、疑似的にプレイヤキャラクタの操作入力を行い、その動作制御自体はエミュレータプログラムに行わせる。これにより、第２のモードにおいて自動的にプレイヤキャラクタを動作させつつも、ロムデータに基づくゲーム処理における挙動の再現度を高めることができ、ユーザに違和感を与えない表現が可能となる。

他の構成例として、プロセッサは、第２のモードにおいて、キャラクタのうち、プレイヤキャラクタ以外の少なくとも１つのノンプレイヤキャラクタを所定の位置に配置する変更を行った上でエミュレータプログラムに当該プレイヤキャラクタおよび当該ノンプレイヤキャラクタを制御させてもよい。

上記構成例によれば、第２のモードにおいて、ノンプレイヤキャラクタの配置位置に自由度を与えつつ、ノンプレイヤキャラクタの挙動について、ロムデータに基づくゲーム処理における挙動の再現度が高い挙動を行わせることができる。

他の構成例として、エミュレータプログラムが実行する処理は、キャラクタ同士の当たり判定処理を含んでいてもよい。

上記構成例によれば、第２のモードにおいて、キャラクタ同士の衝突に伴う各種の挙動の再現度を高めることができる。

他の構成例として、記憶媒体は、ロムデータに含まれるキャラクタ画像とは別に追加キャラクタ画像を更に記憶していてもよい。更に、プロセッサは、第２のモードにおいて、エミュレータプログラムがゲーム処理の実行中に制御するキャラクタのキャラクタ画像を追加キャラクタ画像に変更して表示してもよい。

上記構成例によれば、第２のモードにおいて、キャラクタの動作制御自体はエミュレータプログラムの処理を利用し、この処理結果に基づく表示の際にキャラクタの画像を追加キャラクタの画像に差し替える。これにより、エミュレータの処理を活用しつつ、オリジナルのゲームには存在しない新たなキャラクタを用いた表現が可能になり、ユーザを飽きさせないアプリケーションを提供できる。

他の構成例として、記憶媒体は、ロムデータに含まれる背景画像データとは別に追加背景画像データを更に記憶していてもよい。更に、プロセッサは、第２のモードにおいて表示する背景画像の少なくとも一部に、上記追加背景画像データを用いた画像を表示してもよい。

上記構成例によれば、第２のモードにおいて、エミュレータの処理を活用しつつ、オリジナルのゲームには存在しない背景画像を用いた表現が可能になり、ユーザを飽きさせないアプリケーションを提供できる。

他の構成例として、第２のモードにおけるアプリケーションは、時計アプリケーションであってもよい。

他の構成例として、第２のモードにおけるアプリケーションは、時計アプリケーションであり、プロセッサは、第２のモードにおいて、複数のノンプレイヤキャラクタを、時刻を表す形状に配置してもよい。

他の構成例として、第２のモードにおけるアプリケーションは、時計アプリケーションであり、プロセッサは、第２のモードにおいて、追加背景画像データによって時刻を表す画像を表示してもよい。

他の構成例として、プロセッサは更に、第２のモードにおいて、特定の時刻になったことに応じて所定のイベントを発生させてもよい。

上記構成例によれば、第２のモードにおいて、時刻に応じて様々なイベントを実行し、ユーザを楽しませることができる。

他の構成例として、情報処理装置は、モード切替の指示を行うための切替操作部を更に備えていてもよい。更に、プロセッサは、切替操作部への操作に応じてモード切替を行い、第１のモードから別のモードに移行する場合には、プレイ中の前記ゲームの状態を保存し、別のモードから第１のモードに移行した場合に、保存された状態からゲーム処理を再開させてもよい。

上記構成例によれば、第１モードのゲームをプレイ中、別のモードに切り替えた後、第１のモードに戻した場合、前回切り替えたときのゲーム状態からプレイを再開することができる。これにより、第１のモードにおけるゲームプレイの際のユーザの利便性を高めることができる。

他の構成例として、情報処理装置は、画像を表示するディスプレイと、ゲームをプレイするための操作部を更に備える携帯型の装置であってもよい。

本実施形態によれば、エミュレータを使ったゲームがプレイできることに加え、更に、当該ゲームのロムデータを利用することで当該ゲームに関連した別のアプリケーションを実行可能な情報処理装置を提供することができる。

本実施形態の情報処理装置１０の外観を示す模式図 情報処理装置１０のハードウェア構成を示すブロック図 第１のモードの画面例 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例 画像処理に関して説明するための図 第２のモードの処理概要を説明するための図 フラッシュメモリ１０２に記憶されるデータの一例 ゲームロムデータ４０４のデータ構成の一例 登場キャラクタ画像データ４２３のデータ構成の一例 登場キャラクタ画像データ４２３の一部のデータ内容の一例 イベント定義データ４０８のデータ構成の一例 ＤＲＡＭ１０３に記憶されるデータの一例 第１モード用エミュレータメモリ領域４７１に記憶されるデータの一例 カスタムロムデータ５０４のデータ構成の一例 第２モード用エミュレータメモリ領域５０５に記憶されるデータの一例 第２モード処理作業用データ４１５のデータ構成の一例 全体制御処理の詳細を示すフローチャート 第１モードの処理の詳細を示すフローチャート ゲームプログラムの実行処理の詳細を示すフローチャート 時計アプリ処理の詳細を示すフローチャート 時計アプリ処理の詳細を示すフローチャート 開始処理の詳細を示すフローチャート 第２モード用エミュレータ処理の詳細を示すフローチャート 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例 第２のモードの画面例

［情報処理端末のハードウェア構成］
以下、本発明の一実施形態について説明する。図１は、本実施形態に係る処理が実行される情報処理装置１０の外観を示す図である。情報処理装置１０は、略板状のハウジング１１を備える。本実施形態において、ハウジング１１の主面（換言すれば、表側の面、すなわち、ディスプレイ１２が設けられる面）は、大略的には矩形形状である。なお、ハウジング１１の形状および大きさは、任意である。一例として、ハウジング１１は、携帯可能な大きさであってよい。

図１に示すように、情報処理装置１０は、ハウジング１１の主面に設けられるディスプレイ１２を備える。ディスプレイ１２は、情報処理装置１０が生成した画像を表示する。本実施形態においては、ディスプレイ１２は、液晶表示装置（ＬＣＤ）とする。ただし、ディスプレイ１２は任意の種類の表示装置であってよい。

また、ハウジング１１の主面には、複数の操作キー（後述の操作部１０４）が設けられている。具体的には、十字キー１３、Ａボタン１４、Ｂボタン１５、第１モード切り替えボタン１６、第２モード切り替えボタン１７が設けられている。

次に、情報処理装置１０のハードウェア構成について説明する。図２は、情報処理装置１０のハードウェア構成を示すブロック図である。図２において、情報処理装置１０は、プロセッサ１０１と、フラッシュメモリ１０２と、ＤＲＡＭ１０３と、操作部１０４と、上記ディスプレイ１２と、リアルタイムクロック（以下ＲＴＣ）１０６とを備えている。プロセッサ１０１は、後述するような各種処理を実行する。なお、プロセッサ１０１は、単一のプロセッサを搭載してもよいし、複数のプロセッサを搭載するようにしてもよい。フラッシュメモリ１０２は、プロセッサ１０１によって実行される各種プログラムおよび当該プログラムで利用される各種データが格納される。ＤＲＡＭ１０３は、ゲーム処理の過程で生成されたゲームデータを必要に応じて記憶するためのメモリである。また、本例では、実際に本実施形態の処理を実行するに際して、フラッシュメモリ１０２内の各種プログラム及びデータが当該ＤＲＡＭ１０３にコピー（ロード）される。そして、以下に説明する処理の実行においては、基本的には当該ＤＲＡＭ１０３にコピーされたプログラムやデータが用いられる。また、ＤＲＡＭ１０３の領域の一部は、ＶＲＡＭとしても用いられる。

次に、操作部１０４は、ユーザからの操作を受け付けるための入力装置であり、上述した複数の操作キーに対応する。ＲＴＣ１０６は、時計機能や計時機能を提供するものであり、プロセッサ１０１は、ＲＴＣ１０６から現在時刻等を取得することができる。

［本実施形態の処理の概要］
次に、本実施形態で想定する処理の概要について説明する。本実施形態では、情報処理装置１０は、複数の動作モードを有しており、ユーザの操作に基づき切り替え可能に構成されている。具体的には、少なくとも以下の２つの動作モードを有している。

［第１の動作モードについて］
まず、第１の動作モード（以下、単に第１のモードと呼ぶ）として、エミュレータプログラムを実行して、所定のゲーム装置で実行される所定のゲーム処理をエミュレーションする動作モードがある。所定のゲーム装置は情報処理装置１０とは別のゲーム装置であって、本実施形態では、この所定のゲーム装置の一例として、８ビットＣＰＵのゲーム装置を想定する。以下、当該ゲーム装置のことを、エミュレーション対象ゲーム機と呼ぶ。ここで、本実施形態で想定する情報処理装置１０は、エミュレーション対象ゲーム機よりもプロセッサの性能や画像処理の性能（処理能力）は高いものとする。また、本実施形態における情報処理装置１０では、当該エミュレーション対象ゲーム機よりも表示可能な色数が多いものとする。また、上記エミュレーションするゲームのことを、以下の説明ではエミュレーション対象ゲームと呼ぶ。そして、エミュレーション対象ゲームの一例として、２Ｄ画面での処理による、画面スクロールが可能なジャンプアクションゲームを想定する。当該エミュレーション対象ゲームは、本来は、エミュレーション対象ゲーム機用のゲームカートリッジとして提供されていたものである。本実施形態では、このゲームカートリッジに記憶されているデータを後述するゲームロムデータ４０４として上記フラッシュメモリ１０２に記憶している。そして、当該ゲームロムデータ４０４を上記エミュレータプログラムに読み込ませ、当該ゲームロムデータ４０４内に含まれるゲームプログラムを実行（エミュレーション）することで、エミュレーション対象ゲームを実行する。

図３に、第１のモードにおける画面例を示す。図３では、プレイヤキャラクタ２０１、敵キャラクタ２０２、複数のブロックキャラクタ２０３、土管２０５等が表示されている。また、図３では、プレイヤキャラクタ２０１と敵キャラクタ２０２は、地形部分２０４の上に乗っている状態である。ユーザは、十字キー１３、Ａボタン１４、Ｂボタン１５をそれぞれ操作することで、プレイヤキャラクタ２０１を移動させたり、ジャンプさせたりすることができる。当該ゲームは、プレイヤキャラクタ２０１を操作して、各種障害物を避けたり、敵キャラクタ２０２を踏みつけたり、ブロックキャラクタ２０３を破壊したりしながら、ゴール地点を目指して進んでいくジャンプアクションゲームとなっている。以下の説明では、第１のモードにおけるゲーム画面を「第１モード画面」と呼ぶ。

［第２の動作モードについて］
次に、第２の動作モード（以下、単に第２のモードと呼ぶ）について説明する。本実施形態では、第２のモードとして、時計アプリケーション（以下、時計アプリ）をユーザに提供する。図４に、第２のモードにおける画面例を示す。図４では、上記ブロックキャラクタ２０３を用いて、ＨＨ：ＭＭ形式で現在時刻が表示されている。以下、第２のモードにおいてこのような時刻表示に用いている複数のブロックキャラクタ２０３のことを総称して時刻ブロック２０６と呼ぶ。また、その他、地形部分２０４や山、そして、土管２０５の画像も表示されている。第２のモードは、基本的には、このように現在時刻をディスプレイ１２に表示して、情報処理装置１０を時計として機能させるものである。以下の説明では、第２のモードにおける画面を「第２モード画面」と呼ぶ。

ここで、本実施形態では、この第２モード画面において、上記のプレイヤキャラクタ２０１や敵キャラクタ２０２が登場し、自動的に各種アクションを行う。一例として、図５に、第２モード画面の別の画面例を示し、第２モード画面におけるプレイヤキャラクタ２０１の基本的な動作例を説明する。図５において、プレイヤキャラクタ２０１は、画面左端から（地形部分２０４に乗った状態で）出現し、画面右端に向けて地形部分２０４の上を走って行く動作を自動的に行う。また、途中にある土管２０５に関しては、ジャンプして避ける動作を行う（後述するが、土管２０５の表示位置には当たり判定が設定されている）。そして、画面右端まで到達すれば、そのまま画面外に移動する。その後、再度画面左端から出現して、同じ動作を繰り返す。内部処理的には、例えば画面外の丸印１番の位置にプレイヤキャラクタ２０１が到達すれば、画面外の丸印２番の位置にプレイヤキャラクタ２０１を配置するような処理が行われることになる（例えばディスプレイ１２よりも広い領域の内部画面を用いて処理する）。このように、第２モード画面においては、プレイヤキャラクタ２０１が画面左端から出現して右端に向けて走って行く、という動作が繰り返し行われる。

更に、図６に、第２モード画面の別の画面例を示す。この画面では、更に敵キャラクタ２０２が出現する例を示している。この例では、敵キャラクタ２０２は図６の黒丸で示す出現位置から降ってくるようにして出現し、画面左端に向けて移動するように制御される。その結果、図６の点線で示すような経路で移動することになる。最初は時刻ブロック２０６の上に乗るように出現し、左方向に移動した結果、時刻ブロック２０６の足場がなくなるため下方に垂直に落下していき、地形部分２０４に到達すれば、当該地形部分２０４の上を左方向に移動していく。敵キャラクタ２０２が画面外まで移動すれば、再度、図６の黒丸の出現位置から出現し、同様の動作制御が繰り返される。また、この動作の過程で、プレイヤキャラクタ２０１と敵キャラクタ２０２が互いに接近した場合、例えばプレイヤキャラクタ２０１が敵キャラクタ２０２をジャンプして避ける動作も行われる。

このように、第２のモードでは、時刻ブロック２０６によって現在時刻を表示しつつ、プレイヤキャラクタ２０１や敵キャラクタ２０２が自動的に動くものとなっている。そして、本実施形態では、時刻に応じて発生するイベントが複数用意されている。各イベントでは、プレイヤキャラクタ等について、上記に例示した基本動作とは異なる動作が行われ得る。例えば、特定の時刻になると、プレイヤキャラクタ２０１が上述した動き以外の特定の動きを行うことがある。また、イベント内容によっては、背景画像が変化することもある。例えば、朝、昼、夕方、夜という時間帯に応じて、背景画像の色が変化する。また、イベント内容によっては、元々のエミュレーション対象ゲームには登場しないキャラクタ（以下、未登場キャラクタ）が登場することもある。例えば、特定に時刻になると、未登場キャラクタが画面に出現したりする（なお、イベント内容の具体例は、後にいくつか例示する）。

また、第２のモードから第１のモードへの切り替えは、上記第１モード切り替えボタン１６を押下することによって実現される。逆に、第１モードから第２のモードへの切り替えは、上記第２モード切り替えボタン１７を押下することによって実現される。ここで、第１のモードから第２のモードへの切り替えが行われる際、その時点の第１モードでのエミュレーション対象ゲームのゲーム実行状態は保存される。そして、その後第２のモードから第１のモードへの切り替えが行われたときは、保存した状態からエミュレーション対象ゲームのプレイを再開できる。つまり、第１のモードについては、他のモードへの切り替え操作が発生した際、ゲームプレイが一時停止したような状態となり、再度第１のモードに切り替えられた際に、ゲームプレイが再開されるという制御が行われている。

また、本実施形態では、説明の便宜上、動作モードが２つである場合を例示しているが、動作モードを３つ以上用意してもよい。例えば、第３の動作モードとして、更に他のゲーム処理が実行可能な構成とし、情報処理装置１０が、第３の動作モードに切り替え可能な操作部を更に備える構成としてもよい。または、いずれかのボタンを再度操作することで第３の動作モードに切り替わるようにし、順番にモードが切り替わるようにしてもよい。

ここで、本実施形態では、第２モード画面において描画する各種画像のうち、一部の画像については、上記エミュレーション対象ゲームのゲームロムデータ４０４に含まれている画像データをそのまま流用している。上記の例では、プレイヤキャラクタ２０１および敵キャラクタ２０２の画像データは、上記ゲームロムデータ４０４に含まれているデータをそのまま流用している。一方、これらキャラクタ以外の画像については、上記ゲームロムデータ４０４のものとは別に用意された、第２のモード専用の画像データ（以下、追加画像データと呼ぶ）を用いて表示している。また、第２のモードにおけるプレイヤキャラクタ２０１や敵キャラクタ２０２の動作の制御そのものについては、エミュレータプログラムによる処理結果を流用している。この点に関しては、後ほど説明する。

なお、このような追加背景画像データを用いる理由について補足説明する。本実施形態では、上記情報処理装置１０が表示可能（利用可能）な色数が、エミュレーション対象ゲーム機で表示可能な色数よりも多いものとなっている。すなわち、上記追加画像データに基づく画像については、エミュレーション対象ゲーム機よりも多くの色数を利用した表現が可能となっている。また、エミュレーション対象ゲーム機ではできなかったような画像効果を加えることも可能である（情報処理装置１０自体がそのような画像処理機能を有していることが前提となる）。そのため、上記第２モード画面としては、第１モード画面よりも豊かな表現が可能である。その一方で、キャラクタ画像についてはエミュレーション対象ゲーム機の処理結果をそのまま流用している、これは、キャラクタの動作の再現性を高めるという観点等によるものである。つまり、第２のモードでは、プレイヤキャラクタ２０１等の外観や動き方はオリジナルのゲームのものを再現しつつ、背景画像についてはより豊かな表現とした時計アプリを提供している。

以下、本実施形態における処理についてより詳細に説明するが、この説明に先立って、本実施形態で想定する上記エミュレーション対象ゲーム機における画像処理の概要について簡単に説明する。

［エミュレーション対象ゲーム機における画像処理の概要］
本実施形態で想定するエミュレーション対象ゲーム機では、大きく分けて、「背景画像」と「キャラクタ画像」を用いてゲーム画像を生成している。背景画像、キャラクタ画像のいずれも、８×８ピクセルからなるピクセルパターンを最小単位としている。以下、説明の便宜上、この８×８ピクセルのピクセルパターンのことを「タイル」と呼ぶ。なお、このタイルはピクセルパターンを定義したものであり、これとは別に、各タイルで使用する色情報を定義した「パレット」と呼ばれるデータもある。各タイルで使用できる色の数は、５２色中４色であるものとする。また、パレットは複数定義可能であり、本例のエミュレーション対象ゲーム機では、背景画像用に４つ、キャラクタ画像用に４つのパレットが定義可能である。このタイルと、各タイルで用いるパレットを指定することで、ゲーム画像が生成される。

上記背景画像は、上記タイルを複数組み合わせることで表現される。キャラクタ画像は、このタイルを単体で用いる、あるいは複数組み合わせることで表現される。例えば、当該タイルを４つ組み合わせることで、１６×１６ピクセルの大きさのプレイヤキャラクタ２０１を表現することができる。図７に、このような４つのタイルの組み合わせで構成されるプレイヤキャラクタ画像の一例を示す。図７の例では、プレイヤキャラクタ２０１の左上部分、右上部分、左下部分、右下部分のピクセルパターンを定義した４つのタイルを２×２の配置で組み合わせて、１体のプレイヤキャラクタ２０１のキャラクタ画像を表現していることを示している。換言すれば、プレイヤキャラクタ２０１という仮想キャラクタとこれら４つのタイルとが関連付けられているといえる。なお、図７の左側の図では、１マスが１ピクセルに相当する。また、図７では、プレイヤキャラクタ２０１が描画される部分のピクセルを黒色で表現している（白色部分は透明色とする）が、実際は、上記パレットの指定によって、所定の色で描画されることになる。

ここで、上記「キャラクタ」に関して、上記エミュレーション対象ゲームでは、プレイヤキャラクタ２０１、敵キャラクタ２０２、上記ブロックキャラクタ２０３等のその他のキャラクタ（プレイヤキャラクタ２０１との当たり判定が行われるキャラクタ）、という複数種類のキャラクタが登場する。以下の説明では、プレイヤキャラクタ２０１との当たり判定が行われ得るキャラクタや敵キャラクタ２０２等の、プレイヤキャラクタ２０１以外のキャラクタのことを「ＮＰＣ（ノンプレイヤキャラクタ）」と呼ぶ。また、プレイヤキャラクタ２０１およびＮＰＣを総称して、「登場キャラクタ」と呼ぶ。

上記ゲームロムデータには、背景画像データと登場キャラクタ画像データとが含まれている。背景画像データとしては、最大で２５６個分のタイルが定義可能である。また、登場キャラクタ画像データも同様に、最大で２５６個分のタイルのデータが定義可能である。換言すれば、背景画像データ、登場キャラクタ画像データはそれぞれ、（最大で）２５６個分のタイルのデータを有している。そして、上記エミュレーション対象ゲーム機では、背景画像データに含まれる所定のタイルを、例えば３２×３０個並べることで、１画面分の背景画像を作成する。更に、上記エミュレーション対象ゲーム機では、この背景画像上の所定の位置に、上記登場キャラクタのタイル（これは、スプライトと呼ばれることもある）を合成することで、ディスプレイ１２に出力されるゲーム画像を生成する。このように、上記エミュレーション対象ゲーム機では、タイルを並べて構成される背景画像に上記登場キャラクタ画像を合成することでゲーム画像を生成し、出力するという処理が行われている。

エミュレーション対象ゲーム機では上記のような画像処理が行われることを前提として、本実施形態では、各動作モードで、次のような処理が行われる。まず、第１のモードでは、上記のようにエミュレータプログラムによるゲーム処理が行われる。つまり、エミュレーション対象ゲーム機と同様の画像処理が行われ、第１モード画面として出力されるゲーム画像も、上記ゲームロムデータに含まれる背景画像データと登場キャラクタ画像データとに基づいた画像となる。

一方、第２のモードでは、上記のような第２モード画面を表示するが、プレイヤキャラクタ２０１、敵キャラクタ２０２の画像データおよびその動作制御に関しては、ゲームロムデータの内容を流用する。そして、空の部分や地形部分２０４等の背景画像に関しては、上記追加画像データを用いる。但し、上記時刻ブロック２０６に関しては、処理の内部的には上記ＮＰＣ扱いではあるが、第２モード画面として表示する際は、上記追加画像データに基づく画像を用いる。時刻ブロック２０６については、より豊かな表現を行いたいためである。なお、他の実施形態では、時刻ブロック２０６として、エミュレーション対象ゲームにおけるブロックキャラクタ２０３の画像データをそのまま用いるようにしてもよい。

第２のモードにおける処理の詳細については後述するが、一旦、第２のモードにおける処理概要を、図８を用いて説明する。第２のモードでは、時計アプリのプロセス（以下、時計アプリプロセス）と、エミュレータプログラムによるプロセス（以下、エミュレータプロセス）とが並列的に実行される。時計アプリプロセスが、上記第２モード画面を生成するための主となるプロセスであり、その裏で（バックグラウンドプロセスとして）、エミュレータプロセス（いわば、画面出力を行わないゲーム処理）も同時実行されている。また、詳細は後述するが、エミュレータプロセスで実行されるゲームプログラムは、ゲームロムデータ４０４に含まれているゲームプログラムをそのまま用いるのではなく、上記第２モード処理との連携機能を追加するようにカスタマイズされたゲームプログラムが用いられる。

典型的な処理の流れを説明すると、図８において、まず、エミュレータプロセスから時計アプリプロセスに対して、動作制御パラメータの要求が行われる（Ｐ１）。これに応じて、時計アプリプロセスから、動作制御パラメータがエミュレータプロセスに渡される（Ｐ２：より正確には、エミュレータプロセスで用いられるメモリ空間内の所定アドレスの値が書き換えられる）。この動作制御パラメータは、例えばプレイヤキャラクタ２０１を擬似的に操作するための操作キーデータ等である(パラメータの具体的内容については後述する)。次に、エミュレータプロセスにおいて、上記動作制御パラメータに基づいてプレイヤキャラクタ２０１やＮＰＣの動作を制御し、更に、当たり判定処理も行う（Ｐ３）。また、これらの処理結果は、エミュレータプロセスで用いられるメモリ空間内の所定アドレスに格納される。その後、エミュレータプロセスにおいて、このような処理結果の更新が発生したことを時計アプリプロセスに通知する（Ｐ４）。これに応じて、時計アプリプロセスでは、移動制御と当たり判定の処理結果を取得する（Ｐ５）。そして、この結果に基づいて、上記第２モード画面を生成して表示する（Ｐ６）。より具体的には、当該処理結果に基づき、プレイヤキャラクタ２０１、敵キャラクタ２０２、時刻ブロック２０６の表示位置を決定する。更に、上記追加画像データを用いて背景画像を生成する。これに、ゲームロムデータに含まれる登場キャラクタ画像データを用いたプレイヤキャラクタ画像等を合成する。これにより、上記第２モード画面が生成される。このような一連の流れが繰り返されることで、本実施形態にかかる時計アプリの処理が実現される。

ここで、上記時刻ブロック２０６の扱いについて補足する。本実施形態では、上記時刻ブロック２０６については、当たり判定が行われ得る上記ＮＰＣとして扱う。そのため、エミュレータプロセス側では、時刻ブロック２０６は例えばエミュレーション対象ゲームに元々存在するブロックキャラクタ２０３として処理される。そして、時計アプリプロセス側で第２モード画面を生成する際に、このブロックキャラクタ２０３の画像を追加画像データによる画像に置き換えるような制御が行われる。但し、他の実施形態では、例えば時刻ブロック２０６についての当たり判定を行う必要がない場合は、上記背景画像として扱うようにしてもよい（その結果、追加画像データによる描画が行われることになる）。また、時刻ブロック２０６を上記背景画像として扱いつつ、当たり判定も行わせたい場合は、時刻ブロック２０６の配置上に当たり判定用の位置を設定するようにしてもよい（例えば、後述する当たり判定用ブロック配置情報４８６）。

このように、本実施形態では、第１のモードでは、ユーザは、エミュレータプログラムによるエミュレーション対象ゲームがプレイできる。一方、第２のモードでは、エミュレーション対象ゲームのコンテンツを活用した別のアプリケーション（本例では時計アプリ）がユーザに提供できる。本実施形態によれば、このような２つの動作モードが実行可能な情報処理装置を提供できる。

［本実施形態のゲーム処理の詳細］
次に、図９～図３５を参照して、本実施形態における情報処理装置１０の処理についてより詳細に説明する。

［フラッシュメモリのデータについて］
まず、本処理にて用いられる各種データに関して説明する。まず、フラッシュメモリ１０２に記憶されている各種データに関して説明する。図９は、上記フラッシュメモリ１０２に記憶される各種データの一例を示すメモリマップである。フラッシュメモリ１０２には、制御用プログラム４０１、エミュレータプログラム４０２、時計アプリプログラム４０３、ゲームロムデータ４０４、追加背景画像データ４０５、追加キャラ画像データ４０６、カスタマイズ用データ４０７、イベント定義データ４０８等が記憶されている。

制御用プログラム４０１は、情報処理装置１０の基本的な動作を制御するためのプログラムである。具体的には、上述した第１のモードと第２のモードとの切り替え制御等を行うためのプログラムである。

エミュレータプログラム４０２は、上記エミュレーション対象ゲーム機の動作をエミュレーションするプログラムである。

時計アプリプログラム４０３は、上記第２のモードにおける動作を実現するためのプログラムである。

ゲームロムデータ４０４は、上記エミュレーション対象ゲームのロムデータである。図１０に、当該ゲームロムデータ４０４のデータ構成の一例を示す。ゲームロムデータ４０４には、ゲームプログラム４２１と、ゲーム画像データ４２２とが含まれている。ゲームプログラム４２１は、エミュレーション対象ゲームにかかるゲーム処理を実行するためのプログラムである。上記エミュレータプログラム４０２の実行で実現される仮想的な上記エミュレーション対象ゲーム機上で動作するものである。

ゲーム画像データ４２２は、エミュレーション対象ゲームで用いられる各種画像データである。上記のように、エミュレーション対象ゲーム機では、背景画像に登場キャラクタ画像を合成してゲーム画像する。そのため、ゲーム画像データ４２２には、登場キャラクタ画像データ４２３と背景画像データ４２４とが含まれている。登場キャラクタ画像データ４２３は、登場キャラクタの画像の素になる画像のデータが記憶されたデータである。図１１に、登場キャラクタ画像データ４２３の内容の模式図を示す。登場キャラクタ画像データ４２３には、８×８ピクセルの上記タイルが２５６個含まれている。図１１では、１タイルを１マスとした、１６×１６のテーブルとして示している。なお、図１１では、各タイルには説明の便宜上、タイル番号を示している。更に、各タイルの内容の具体的な一例として、図１２に、タイル番号１番～９番の内容例を示す。図１２において、タイル番号１～４番は上記プレイヤキャラクタ２０１の画像データ例である。この４つのタイルが組み合わされて、１体のプレイヤキャラクタ２０１の画像が表現される。タイル番号５～８番は、敵キャラクタ２０２の画像データ例である。こちらも、これら４つのタイルが組み合わされることで、１体の敵キャラクタ２０２の画像が表現される。また、タイル番号９番は、上記ブロックキャラクタ２０３の画像データ例である。この９番のタイルが４つ組み合わされて、１個分のブロックキャラクタ２０３が表現される。このように、登場キャラクタ画像データ４２３は、上記登場キャラクタの画像を（タイル単位で）定義した画像データである。なお、このデータには、各タイル毎に使用するパレットを指定するための情報も適宜含まれている。

図１０に戻り、背景画像データ４２４は、背景画像の素になる画像のデータが記憶されたデータである。そのデータ構造は、上記登場キャラクタ画像データ４２３と同様であるため、詳細説明は割愛するが、背景画像として利用可能な上記タイルが２５６個分定義されている。

図９に戻り、追加背景画像データ４０５および追加キャラ画像データ４０６は、上記追加画像データに相当するデータである。追加背景画像データ４０５は、上記第２モード画面における背景画像の素になるデータである。そのテータ構成は、基本的には、上記背景画像データと同じであり、上記タイルを最小単位としたピクセルパターンが定義されている。追加キャラ画像データ４０６は、第２のモードにおける上記未登場キャラクタの画像を定義したデータである。更に、元のエミュレーション対象ゲームには登場するＮＰＣの一部について、それを描き直した画像を定義したデータも含まれる。具体的には、第２のモードにおける上記時刻ブロック２０６の画像データ等である。こちらも、上記タイルを最小単位としたピクセルパターンが定義されている。また、これらのデータには、上記パレットの情報（各タイルで使用する色の指定情報）も適宜含まれている。

なお、本実施形態では、第２のモードにおける上記時刻ブロック２０６の画像データは、追加キャラ画像データ４０６として含まれる例を挙げたが、他の実施形態で時刻ブロック２０６を背景画像として扱う場合は、追加背景画像データ４０５に含めるようにすればよい。

次に、カスタマイズ用データ４０７は、上記ゲームロムデータ４０４に含まれるゲームプログラム４２１の一部を変更する(書き換える)ために用いるデータである。詳細は後述するが、本実施形態では、第２のモードにおいて、時計アプリプログラムの実行プロセスと、エミュレータプログラムの実行プロセスとでデータの受け渡しを行う必要がある。そのため、本実施形態では、元々のゲームプログラム４２１の一部を変更して、当該データの受け渡しを実現が可能なようにゲームプログラム４２１をカスタマイズする。カスタマイズ用データ４０７は、このようなゲームプログラム４２１の変更内容が定義されているデータである。

イベント定義データ４０８は、第２のモードにおいて発生させるイベントについて定義したデータである。図１３に、イベント定義データ４０８のデータ構成の一例を示す。イベント定義データ４０８は、イベント番号４５１、発生条件情報４５２、イベント内容情報４５３、動作制御用データ４５４、という項目を有するテーブル形式のデータである。イベント番号４５１は、各イベントを識別するための番号である。発生条件情報４５２は、そのイベントを実行するための条件を定義した情報である。具体的には、イベントを開始する時刻（あるいは時間帯）が定義されている。また、イベント内容によっては、プレイヤキャラクタ２０１の現在位置を発生条件とするものもある。このようなイベントについては、時刻情報に加えて、あるいは単独で、位置情報も定義される。また、このような特定の時刻や特定の位置に対応づけられたイベントの他、上記図５～図６を用いて説明したような「基本的な動作」についても、「基本イベント」として、その動作制御の内容が定義されているものとする。つまり、普段は「基本イベント」が実行され、特定の時刻になれば、その時刻に応じた特定のイベントの実行が開始され、この特定のイベントが終了すればまた「基本イベント」が実行される。

イベント内容情報４５３は、そのイベントの内容を定義した情報である。例えば、背景画像を変更するイベントの場合は、変更する背景を指定する情報が含まれる。プレイヤキャラクタ２０１や未登場キャラクタに特定の動作を行わせるイベントであれば、そのモーションを定義する情報が含まれる。また、上記「基本イベント」であれば、上述したようなプレイヤキャラクタ２０１や敵キャラクタ２０２の基本的な動作内容等を定義した情報が含まれる。

動作制御用データ４５４は、エミュレータプログラムのプロセスに渡すためのデータについて定義した情報である。具体的には、プレイヤキャラクタ２０１や敵キャラクタ２０２の出現位置や、当たり判定を行う位置を指定する情報、プレイヤキャラクタ２０１の操作を擬似的に入力するための操作キーデータ、等である。エミュレータプログラムのプロセスでは、このデータに基づいてプレイヤキャラクタ２０１を動作制御させたり、当たり判定を行ったりすることになる。

［ＤＲＡＭのデータについて］
次に、図１４を用いて、ＤＲＡＭ１０３に記憶されるデータについて説明する。本実施形態では、例えば情報処理装置１０の電源がオンにされたときに、フラッシュメモリ１０２に記憶されているプログラムやデータがＤＲＡＭ１０３内の所定の領域（アドレス）にコピー等される。

図１４は、ＤＲＡＭ１０３に記憶される各種データの一例を示すメモリマップである。図１４において、ＤＲＡＭ１０３のメモリ空間は、制御処理用領域４１１、第１モード用領域４１２、第２モード用領域４１３に区分けされている。まず、制御処理用領域４１１には、制御用プログラム４０１および現在動作モード４６１が記憶される。制御用プログラム４０１はフラッシュメモリ１０２からコピーされたものである。現在動作モード４６１は、現在の動作モードを示す情報である。本例では、第１のモードと第２のモードのいずれかを示す情報が設定される。

第１モード用領域４１２には、エミュレータプログラム４０２が記憶される。また、第１モード用領域４１２には、第１モード用エミュレータメモリ領域４７１が含まれる。これは、上記エミュレータ対象ゲーム機に搭載されているメモリに対応する（このメモリをエミュレーションした）メモリ空間である。図１５に、第１モード用エミュレータメモリ領域４７１に記憶されるデータの一例を示す。第１モード用エミュレータメモリ領域４７１には、ゲームプログラム４２１、ゲーム画像データ４２２、ゲーム処理作業用データ４８１が記憶される。ゲームプログラム４２１およびゲーム画像データ４２２は、ゲームロムデータ４０４の内容がそのままコピーされたものである。より具体的には、本実施形態では、エミュレータプログラムの実行開始時に、ゲームロムデータ４０４をロードする処理を行うことで、ゲームプログラム４２１およびゲーム画像データ４２２が第１モード用エミュレータメモリ領域４７１に読み込まれる。

ゲーム処理作業用データ４８１は、ゲーム処理の過程で適宜生成される各種のゲームデータである。ゲーム処理作業用データ４８１には、キー操作データ４８２、プレイヤキャラクタ移動制御用パラメータ４８３、ＮＰＣ出現フラグ４８４、ＮＰＣ出現位置指定パラメータ４８５、当たり判定用ブロック配置情報４８６、ＮＰＣ移動制御用パラメータ４８７、ゲーム処理後の配置・位置情報４８８、当たり判定結果情報４８９、等が含まれる。

キー操作データ４８２は、各操作キーに対する入力（押下）状態を示すデータである。プレイヤキャラクタ移動制御用パラメータ４８３は、プレイヤキャラクタ２０１の移動を制御するためのパラメータである。具体的には、プレイヤキャラクタ２０１の移動方向、移動速度、加速度等を指定するパラメータが含まれる。また、当該パラメータは、キー操作データ４８２に基づいてその内容が算出・決定される。ＮＰＣ出現フラグ４８４は、例えば、ゲーム処理が１／６０秒単位で繰り返されるとすると（１フレーム分の処理ループの場合）、今回のフレームにかかる処理において、新たに出現するＮＰＣが存在するか否かを示すフラグである。また、ＮＰＣ出現位置指定パラメータ４８５は、当該新たに出現するＮＰＣの出現位置を指定するためのパラメータである。

当たり判定用ブロック配置情報４８６は、仮想ゲーム空間内において、プレイヤキャラクタ２０１や敵キャラクタ２０２との当たり判定処理を実行する位置を定義した情報である。概念的には、当たり判定を有する透明なブロックが仮想ゲーム空間内に配置されることになり、当該情報はこの配置位置を示す情報であるともいえる。例えば、背景画像の一部に当たり判定を設定したい場合等に用いられる。一例を挙げると、上記図４における地形部分２０４や土管２０５については、上記背景画像として扱われるが、これらの位置に重畳するようにして、当たり判定用の位置情報が当該当たり判定用ブロック配置情報４８６として設定される。これにより、実質的に、地形部分２０４や土管２０５と、プレイヤキャラクタ２０１等との当たり判定が行われ得る。また、上記時刻ブロック２０６を背景画像として扱う場合、この時刻ブロック２０６の全ての位置に当たり判定用の位置情報を設定してもよいし、時刻ブロック２０６のうちの任意のブロックにのみ当たり判定用の位置情報を設定してもよい。例えば、時刻ブロック２０６のうち、一番上と一番下のブロック部分だけ敵キャラクタ２０２等との当たり判定を行いたいような場合は、これらのブロックの位置にのみ当たり判定用の位置情報を設定するようにしてもよい。

ＮＰＣ移動制御用パラメータ４８７は、ＮＰＣ（主に敵キャラクタ）の移動を制御するためのパラメータであり、各ＮＰＣの移動方向や移動速度等の情報が含まれる。

ゲーム処理後の配置・位置情報４８８は、今回フレームの処理において移動制御を行った後のプレイヤキャラクタ２０１や敵キャラクタ２０２の配置・現在位置を示す情報である。つまり、ユーザの入力内容を反映させた後のプレイヤキャラクタ２０１等のゲーム空間内での位置を示す情報である。当たり判定結果情報４８９は、当たり判定処理の結果を示す情報である。当該情報に基づいて、当たり判定の結果を反映したゲーム処理（点数加算やキャラクタ画像の変更指示等）が更に行われ得る。

なお、上記キー操作データ４８２～ＮＰＣ移動制御用パラメータ４８７までのデータは、いわば、移動制御および当たり判定処理に関する「入力パラメータ」という性格を有し、ゲーム処理後の配置・位置情報４８８、および当たり判定結果情報４８９は、移動制御および当たり判定処理の結果を示す「出力パラメータ」という性格を有するものともいえる。

また、図示は省略するが、第１モード用エミュレータメモリ領域４７１には、ゲーム処理に必要なその他の各種データが必要に応じて適宜生成され、格納される。

図１４に戻り、次に、第２モード用領域４１３に記憶されるデータについて説明する。第２モード用領域４１３には、時計アプリプログラム４０３、エミュレータプログラム４０２、カスタムロムデータ５０４、第２モード用エミュレータメモリ領域５０５、追加背景画像データ４０５、追加キャラ画像データ４０６、イベント定義データ４０８、第２モード処理作業用データ４１５等が記憶される。これら記憶されるデータのうち、カスタムロムデータ５０４、第２モード用エミュレータメモリ領域５０５、および第２モード処理作業用データ４１５以外は、上記フラッシュメモリ１０２に記憶されている各データがそのままコピーされたものである。そのため、説明は割愛する。

カスタムロムデータ５０４は、第２のモードにおける処理で用いられるロムデータである。図１６に、カスタムロムデータ５０４のデータ構成の一例を示す。カスタムロムデータ５０４には、カスタムゲームプログラム５２１と、ゲーム画像データ４２２が含まれている。カスタムゲームプログラム５２１は、上記ゲームロムデータ４０４に含まれるゲームプログラム４２１を、第２のモードにおける処理に適合するように一部変更したものである。より具体的には、第２のモードの処理において、時計アプリプログラムの実行プロセスと連携するための機能が追加されたものとなっている。なお、この変更は、上記カスタマイズ用データ４０７を用いて行われる。

図１４に戻り、第２モード用エミュレータメモリ領域５０５は、上記同様、上記エミュレータ対象ゲーム機に搭載されているメモリに対応するメモリ空間であるが、第２モードにおける処理のために上記とは別に設けられているものである。図１７に、第２モード用エミュレータメモリ領域５０５に記憶されるデータの一例を示す。第２モード用エミュレータメモリ領域５０５には、カスタムゲームプログラム５２１、ゲーム画像データ４２２、ゲーム処理作業用データ４８１が記憶される。このうち、ゲーム画像データ４２２、ゲーム処理作業用データ４８１については、上述したものと同様の内容であるため、説明は割愛する。カスタムゲームプログラム５２１は、上記カスタムロムデータ５０４に含まれるカスタムゲームプログラム５２１が第２モードにおけるエミュレータの実行に際して読み込まれたものである。

図１４に戻り、次に、第２モード処理作業用データ４１５に記憶されるデータについて説明する。当該データは、第２のモードにかかる処理の過程で適宜生成される各種のデータである。図１８は、第２モード処理作業用データ４１５のデータ構成の一例を示す図である。第２モード処理作業用データ４１５には、操作データ５３１、現在イベント情報５３２、動作制御入力用パラメータ５３３、追加キャラ対応指定情報５３４、等が含まれる。

操作データ５３１は、（第２のモード中における）ユーザの操作キーへの入力状況を示すデータである。現在イベント情報５３２は、現在実行するイベント（現在実行中のイベント）を特定するための情報である。動作制御入力用パラメータ５３３は、後述する処理において、エミュレータプログラムにかかるプロセスに渡すためのデータである。具体的には、上述したキー操作データ４８２、プレイヤキャラクタ移動制御用パラメータ４８３、ＮＰＣ出現フラグ４８４、ＮＰＣ出現位置指定パラメータ４８５、当たり判定用ブロック配置情報４８６、および、ＮＰＣ移動制御用パラメータ４８７の内容を設定したデータである。第２のモードにおけるエミュレータプログラムは、これらデータに基づいて、各種キャラクタの移動制御と当たり判定処理を行うことになる。

追加キャラ対応指定情報５３４は、所定のイベントにおいて上記未登場キャラクタを用いる場合に設定される情報である。本実施形態では、未登場キャラクタを用いる場合、エミュレータプログラムには、当該未登場キャラクタを既存のキャラクタに置き換えてエミュレーションさせる。例えば、未登場キャラクタＡを使いたい場合、これをエミュレーション対象ゲームに元々含まれている既存キャラクタＢとして、エミュレーションさせる。そして、既存キャラクタＢとしての処理結果を取得し、その画像を未登場キャラクタＡの画像のものにして、上記第２モード画面に表示するという処理を行っている。追加キャラ対応指定情報５３４は、このような未登場キャラクタＡと既存キャラクタＢとの対応付けを一時的に記憶しておくための情報である。

［プロセッサ１０１が実行する処理の詳細］
次に、図１９～図２５のフローチャートを用いて、本実施形態にかかる処理の詳細を説明する。なお、ここで説明する処理は、汎用的な処理の例示であり、本実施形態の趣旨を逸脱しない範囲で、適宜別の処理が追加されてもよい。

まず、制御用プログラム４０１により処理される全体制御処理について説明する。図１９は、当該全体制御処理の詳細を示すフローチャートである。この処理は、情報処理装置１０の電源がオンにされたときに、（フラッシュメモリ１０２からＤＲＡＭ１０３に制御用プログラム４０１がコピーされた上で）自動的に開始され、電源がオフにされるまで繰り返し実行される。

図１９において、まず、ステップＳ１で、プロセッサ１０１は、フラッシュメモリ１０２から、エミュレータプログラム４０２を読み込み、第１モード用領域４１２に配置する。続くステップＳ２で、プロセッサ１０１は、フラッシュメモリ１０２から、時計アプリプログラム４０３およびエミュレータプログラム４０２を読み込み、第２モード用領域４１３に配置する。

次に、ステップＳ３で、プロセッサ１０１は、フラッシュメモリ１０２からゲームロムデータ４０４を読み込み、第１モード用エミュレータメモリ領域４７１に配置する。これは例えば、第１モード用領域４１２に配置したエミュレータプログラム４０２に当該ゲームロムデータ４０４をロードさせる処理を実行させることで実現される。

次にステップＳ４で、プロセッサ１０１は、フラッシュメモリ１０２からゲームロムデータ４０４およびカスタマイズ用データ４０７を読み込む。更に、プロセッサ１０１は、当該読み込んだゲームロムデータ４０４に含まれるゲームプログラム４２１の一部をカスタマイズ用データ４０７に基づいて変更することで、カスタムゲームプログラム５２１を含むカスタムロムデータ５０４を生成する。そして、プロセッサ１０１は、当該カスタムロムデータ５０４を第２モード用領域４１３に記憶する。

次に、ステップＳ５で、プロセッサ１０１は、初期の動作モードとして、現在動作モード４６１に「第２モード」を設定する。

次に、ステップＳ６で、プロセッサ１０１は、現在の動作モードが第１モードか否かを判定する。当該判定の結果、第１モードの場合は（ステップＳ６でＹＥＳ）、ステップＳ７で、プロセッサ１０１は、第１モードの処理を実行する。一方、第２モードの場合は（ステップＳ６でＮＯ）、ステップＳ８で、プロセッサ１０１は、第２モードの処理を実行する。その後、ステップＳ６に戻り、処理が繰り返される。

なお、図示は省略するが、全体制御処理としては、上記のような制御の他、例えば、いわゆるスリープモードへの移行制御等も適宜実行される。すなわち、一定時間以上操作が行わなければ、画面出力をオフにする処理等も適宜実行される。またこの際、実行中の第１のモードの処理あるいは第２のモードの処理を一時停止状態とする制御が行われてもよい。

［第１のモードの処理］
次に、第１モードの処理の詳細について説明する。図２０は、第１モードの処理の詳細を示すフローチャートである。図２０において、まず、ステップＳ１１で、プロセッサ１０１は、第２のモードへの切り替え操作が行われたか否かを判定する。すなわち、上記第２モード切り替えボタン１７が押下されたか否かを判定する。その結果、切り替え操作が行われていない場合は（ステップＳ１１でＮＯ）、ステップＳ１２で、プロセッサ１０１は、ゲームプログラムの実行処理を行い、ステップＳ１１に戻る。なお、ステップＳ１１～Ｓ１２にかかる処理ループは、例えば１フレーム毎に繰り返し実行されるものとする。一方、切り替え操作が行われていた場合は（ステップＳ１１でＹＥＳ）、ステップＳ１３で、プロセッサ１０１は、現在動作モード４６１に「第２モード」を設定し、第１モードの処理を終了する。この際、次に第１モードに移行したときに前回中断した状態からゲームプレイが再開できるように、プロセッサ１０１は、ゲーム状態を保存する。具体的には、第１モード用エミュレータメモリ領域４７１の状態を保持した状態のまま、第２モード処理が開始されるように制御する。これにより、次に第２のモードから第１のモードに切り替えられた際、中断した状態から再開することができる。なお、当該処理に関して、他の実施形態では、第１のモードから第２のモードへの切り替え操作が発生した際、例えばそのときの第１モード用エミュレータメモリ領域４７１の状態を保存したゲーム状態保存データを別途生成・記憶してもよい。そして、第１のモードの再開時にこのデータを読み込むような構成としてもよい。

次に、上記ステップＳ１２のゲームプログラムの実行処理の詳細を説明する。この処理では、エミュレータプログラムの実行によって、エミュレータ対象ゲームのゲーム処理をエミュレーションする処理が行われる。そのため、概念的には、この処理の主体はエミュレータであるともいえる。図２１は、当該処理の詳細を示すフローチャートである。図２１において、まず、ステップＳ２１で、プロセッサ１０１は、エミュレータに、ユーザが行った操作内容、すなわち、キー操作データ４８２に基づいたプレイヤキャラクタ２０１の動作制御を行わせる。

次に、ステップＳ２２で、プロセッサ１０１は、エミュレータに、各種ＮＰＣの配置やその動作制御を行わせる。続くステップＳ２３で、プロセッサ１０１は、エミュレータに各種の当たり判定処理を実行させ、その結果を当たり判定結果情報４８９に格納させる。

次に、ステップＳ２４で、プロセッサ１０１は、エミュレータに、当たり判定結果情報４８９に基づく各種ゲーム処理を実行させる。更に、ステップＳ２５で、プロセッサ１０１は、エミュレータに、その他の各種ゲーム処理を実行させる。

次に、ステップＳ２６で、プロセッサ１０１は、エミュレータに、上記ゲーム処理の結果を反映するようにして、背景画像データ４２４を用いた背景画像を生成させる。更に、ステップＳ２７で、登場キャラクタ画像データ４２３を用いて各種登場キャラクタの画像を生成する。そして、背景画像に登場キャラクタの画像を合成することで、上記第１モード画面として表示するゲーム画像（以下、第１モード用画像と呼ぶ）を生成する。

次に、ステップＳ２８で、プロセッサ１０１は、エミュレータに、第１モード用画像をディスプレイ１２に出力する処理を行わせる。以上で、当該ゲームプログラムの実行処理は終了する。

［第２のモードの処理］
次に、上記ステップＳ８にかかる第２モードの処理の詳細について説明する。上記のように、第２のモードでは、時計アプリプログラムの実行による時計アプリプロセスと、第２モード用のエミュレータ処理の実行によるエミュレータプロセスとが並列的に実行される（上記図８参照）。ここではまず、時計アプリプロセス側の処理を説明し、その後、エミュレータプロセス側の処理について説明する。

図２２～図２３は、時計アプリプロセス側の処理となる時計アプリ処理の詳細を示すフローチャートである。図２２において、まず、ステップＳ３１で、開始処理が実行される。この処理は、第２モードの処理の実行に際しての準備や初期設定を行う処理である。

図２４は、当該開始処理の詳細を示すフローチャートである。まず、ステップＳ５１で、プロセッサ１０１は、第２モード用エミュレータメモリ領域５０５を初期化し、第２モード用のエミュレータに、カスタムゲームプログラム５２１を用いたエミュレーション処理の実行開始指示を行う（その結果、後述する第２モード用エミュレータ処理が開始される）。

次に、ステップＳ５２で、プロセッサ１０１は、初期準備用のキー操作データ４８２を生成して第２モード用のエミュレータに渡す処理を実行する。このキー操作データ４８２の内容は、例えば、エミュレーション対象ゲームのタイトル画面における操作内容を示すデータである。本例の場合、タイトル画面においてゲームをスタートするためのキー操作が第２モード用のエミュレータに渡される。より正確には、第２モード用エミュレータメモリ領域５０５のキー操作データ４８２に上記のような操作を示す内容を順次書き込んでいく処理が実行される。これにより、エミュレータプロセス側では、エミュレーション対象ゲームの開始後、最初のステージの開始時点までゲーム処理が進められ、更なる入力を待機する形となる。

次に、ステップＳ５３で、プロセッサ１０１は、ＲＴＣ１０６から、現在の時刻を取得する。次に、ステップＳ５４で、プロセッサ１０１は、現在時刻とイベント定義データ４０８とに基づいて、実行するイベント内容を決定する。そして、そのイベントを示すイベント番号４５１を現在イベント情報５３２に設定する。以上で、開始処理は終了する。

なお、他の実施形態では、上記ステップＳ５４の処理の次に、現在時刻を示すように時刻ブロック２０６が配置された第２モード画面を生成して、一旦この時点で表示する処理を行ってもよい。

図２２に戻り、次に、ステップＳ３２で、プロセッサ１０１は、操作データ５３１に基づき、第１のモードへの切り替え操作が行われたか否かを判定する。すなわち、上記第１モード切り替えボタン１６が押下されたか否かを判定する。その結果、切り替え操作が行われていた場合は（ステップＳ３２でＹＥＳ）、ステップＳ３３で、プロセッサ１０１は、現在動作モード４６１に「第１モード」を設定し、時計アプリ処理を終了する。

一方、切り替え操作が行われていない場合は（ステップＳ３２でＮＯ）、ステップＳ３４で、プロセッサ１０１は、ＲＴＣ１０６から現在時刻を取得する。次に、ステップＳ３５で、プロセッサ１０１は、現在時刻とイベント定義データ４０８とに基づいて、所定のイベントの実行開始条件が満たされているか否かを判定する。当該判定の結果、所定イベントの実行開始条件が満たされている場合は（ステップＳ３５でＹＥＳ）、ステップＳ３６で、プロセッサ１０１は、イベント定義データ４０８に基づき、現在時刻に応じた実行すべきイベント内容を決定する。なお、イベント内容によっては更にプレイヤキャラクタ２０１の位置に応じて実行するイベントを決定してもよい。そして、決定したイベント内容に対応するイベント番号４５１を現在イベント情報５３２に設定する。なお、特定の時刻に開始された所定のイベントが終了した場合は、上記「基本イベント」の開始条件が満たされたと判定され、「基本イベント」を実行することが決定される。

一方、上記ステップＳ３５の判定の結果、所定イベントの実行開始条件が満たされていない場合は（ステップＳ３５でＮＯ）、上記ステップＳ３６の処理はスキップされる。

次に、ステップＳ３７で、プロセッサ１０１は、実行するイベント内容に応じて、エミュレータプロセスに渡す動作制御用パラメータを準備する処理を実行する。具体的には、実行するイベント内容やプレイヤキャラクタ２０１の現在位置等に基づき、上述したキー操作データ４８２、プレイヤキャラクタ移動制御用パラメータ４８３、ＮＰＣ出現フラグ４８４、ＮＰＣ出現位置指定パラメータ４８５、当たり判定用ブロック配置情報４８６、ＮＰＣ移動制御用パラメータ４８７の内容を決定する。例えば、プロセッサ１０１は、（前回フレームの処理結果として）プレイヤキャラクタ２０１と敵キャラクタ２０２との位置関係を判定する。そして、プレイヤキャラクタ２０１の移動方向側に敵キャラクタ２０２が位置している場合は、プレイヤキャラクタ２０１をジャンプさせるようにキー操作データ４８２の内容を決定する。また、新たに敵キャラクタ２０２を出現させる場合は、プロセッサ１０１は、ＮＰＣ出現フラグ４８４をオンにして、ＮＰＣ出現位置指定パラメータ４８５で時刻ブロック２０６を含む各種ＮＰＣの出現位置または表示位置を指定するようにその内容を決定する。特定のイベントに応じた特定の動きをプレイヤキャラクタ２０１等に行わせる場合は、その動作内容に基づいて、キー操作データ４８２やプレイヤキャラクタ移動制御用パラメータ４８３の内容が決定される。

ここで、上記のような、エミュレータ対象ゲームでは登場しない未登場キャラクタを用いるイベントの場合について補足する。このようなイベントの場合、上記のようにエミュレータプロセス側では、未登場キャラクタの代替として既存のキャラクタを用いて処理される。そのため、この場合は、上記未登場キャラ対応指定情報５３４として、時計アプリ側で用いる未登場キャラクタとエミュレータプロセス側で代替キャラとして扱うＮＰＣとの対応付けを示す情報が生成される。そして、この代替となるＮＰＣに関してのＮＰＣ出現フラグ４８４、ＮＰＣ出現位置指定パラメータ４８５、ＮＰＣ移動制御用パラメータ４８７が決定されることになる。

次に、ステップＳ３８で、プロセッサ１０１は、エミュレータプロセスから「動作制御用パラメータ」の入力要求が来ているか否かを判定する。当該入力要求が来ていない場合は（ステップＳ３８でＮＯ）、入力要求が来るまで待機する。入力要求が来た場合は（ステップＳ３８でＹＥＳ）、ステップＳ３９で、プロセッサ１０１は、上記ステップＳ３７で決定した動作制御用の各パラメータを第２モード用エミュレータメモリ領域５０５に書き込む。つまり、第２モード用エミュレータメモリ領域５０５におけるゲーム処理作業用データ４８１（すなわち、エミュレータ処理で用いるデータ）の内容を変更する処理が行われる。

次に、図２３のステップＳ４０で、プロセッサ１０１は、エミュレータプロセスから「処理結果の更新通知」が届いているか否かを判定する。届いていない場合は（ステップＳ４０でＮＯ）、プロセッサ１０１は、「処理結果の更新通知」が届くまで待機する。当該通知が届いていれば（ステップＳ４０でＹＥＳ）、次に、ステップＳ４１で、プロセッサ１０１は、エミュレータプロセスにおける処理結果のデータを取得する。すなわち、プロセッサ１０１は、第２モード用エミュレータメモリ領域５０５からゲーム処理後の配置・位置情報４８８および当たり判定結果情報４８９を取得する。

次に、ステップＳ４２で、プロセッサ１０１は、上記処理結果のデータに基づき、第２モード用エミュレータメモリ領域５０５のキャラクタ画像データから、必要となる登場キャラクタの画像データを取得する。

次に、ステップＳ４３で、プロセッサ１０１は、現在時刻、上記処理結果のデータ、および、現在イベント情報５３２で示されるイベント内容に基づき、追加背景画像データ４０５を用いて背景画像を生成する。また、現在イベント情報５３２で示されるイベント内容に基づいて、用いる背景画像の決定やその色を設定する。例えば、時刻Ａと時刻Ｂとで、上述した地形部分２０４の画像を異ならせたり、時間帯に応じて空の部分の色を変化させたりする。上記のように、追加背景画像データ４０５のほうが使用色数が多いため、背景画像に関しては、エミュレータ対象ゲームよりも豊かな表現が可能となる。

次に、ステップＳ４４で、プロセッサ１０１は、上記処理結果のデータに基づき、上記登場キャラクタの表示位置を特定する。すなわち、プレイヤキャラクタ２０１、敵キャラクタ２０２、時刻ブロック２０６等の表示位置を特定する。そして、プロセッサ１０１は、上記背景画像における当該位置に、上記取得した登場キャラクタの画像を合成する。ここで、時刻ブロック２０６に関しては、追加キャラ画像データ４０６に含まれる画像データを用いて、背景画像に合成する。そのため、時刻ブロック２０６に関しては、元のエミュレータ対象ゲームに登場するキャラクタ(ブロックキャラクタ２０３)の画像データを追加キャラ画像データ４０６のものに置き換える、という制御が行われる。

次に、ステップＳ４５で、プロセッサ１０１は、現在実行中のイベントが上記未登場キャラクタを利用するイベントであるか否かを判定する。その結果、利用するイベントである場合は（ステップＳ４５でＹＥＳ）、ステップＳ４６で、プロセッサ１０１は、追加キャラ対応指定情報５３４を参照して、取得すべき未登場キャラクタのデータを特定する。更に、当該未登場キャラクタの画像データを追加キャラ画像データ４０６から取得する。そして、上記処理結果のデータに基づき、代替ＮＰＣの表示位置を特定し、上記背景画像におけるこの特定した位置に当該未登場キャラクタの画像を合成する。これにより、エミュレータプロセスで処理された代替ＮＰＣを未登場キャラクタに置き換えて表示することができる。一方、上記判定の結果、未登場キャラクタを利用するイベントではない場合は（ステップＳ４５でＮＯ）、当該ステップＳ４６の処理はスキップされる。

次に、ステップＳ４７で、プロセッサ１０１は、上記のような背景画像に登場キャラクタや未登場キャラクタの画像が合成された第２モード用画像をディスプレイ１２に表示する。その後、上記ステップＳ３２に戻り、処理が繰り返される。

［第２のモードにおけるエミュレータ処理］
次に、第２のモードにおけるエミュレータプロセス側の処理（以下、第２モード用エミュレータ処理）について説明する。図２５は、当該第２モード用エミュレータ処理の詳細を示すフローチャートである。この処理の開始タイミングについては、上記図２４のステップＳ５１で、時計アプリプロセス側から実行開始指示が行われたときに、別プロセスとしてその実行が開始する。なお、上記第１のモードの場合と同様に、概念的には、この処理の主体はエミュレータであるともいえる。

まず、ステップＳ８１で、プロセッサ１０１は、エミュレータに開始処理を実行させる。この処理は、時計アプリプロセスとの連携の準備を行うための処理である。具体的には以下の処理が実行される。まず、エミュレータは、上記カスタムロムデータ５０４をロードし、カスタムゲームプログラム５２１に基づくゲーム処理の実行を開始する。その結果、内部的には例えばゲームのタイトル画面が表示される。エミュレータは、時計アプリプロセス側から送られた、上記準備用の動作制御パラメータ（擬似的な入力操作）に基づくゲーム処理を行う。当該準備用の動作制御パラメータには、エミュレーション対象ゲームの開始後、最初のステージの開始時点までゲーム処理を進めるための操作キーのデータが含まれる。そのため、当該開始処理により、エミュレータプロセス側では、擬似的な入力操作によって、最初のステージの開始時点までゲーム処理が自動的に進められることになる。

次に、ステップＳ８２で、プロセッサ１０１は、エミュレータに、時計アプリプロセス側への上記動作制御用パラメータの入力要求を行わせる。これに応じて時計アプリプロセス側では動作制御用パラメータの書き込み処理が行われる（上記ステップＳ３９）。

次のステップＳ８３で、プロセッサ１０１は、エミュレータに上記書き込まれた動作制御用パラメータを取得させる。更に、続くステップＳ８４で、プロセッサ１０１は、エミュレータに、当該動作制御用パラメータに基づいたプレイヤキャラクタ２０１および各種ＮＰＣの配置や動作制御を行わせる。上記のように、当該動作制御用パラメータには、プレイヤキャラクタ２０１の擬似的な操作内容や、時刻ブロック２０６の配置に対応する当たり判定用ブロックの配置位置や、敵キャラクタ（未登場キャラクタに対応づけられたものも含む）の出現位置等が含まれている。すなわち、上記第２モード画面として表示したい内容に対応するような各キャラクタの位置・配置情報が示されるものである。そのため、ここでの動作制御は、実質的には、上記第２モード画面の画面レイアウト（仮想ゲーム空間）においてプレイヤキャラクタ２０１や敵キャラクタ２０２を動作させる処理に相当する。そして、この動作制御処理の結果は、ゲーム処理後の配置・位置情報４８８して第２モード用エミュレータメモリ領域５０５に格納される。

更に、ステップＳ８５で、プロセッサ１０１は、エミュレータに、上記動作制御を踏まえた当たり判定処理を行わせる。プレイヤキャラクタ２０１と敵キャラクタ２０２当たり判定や、上記時刻ブロック２０６とプレイヤキャラクタ２０１・敵キャラクタ２０２との当たり判定がここで行われることになる。この結果は、当たり判定結果情報４８９として第２モード用エミュレータメモリ領域５０５に格納される。

次に、ステップＳ８６で、プロセッサ１０１は、エミュレータに、時計アプリプロセス側に判定処理結果が更新された旨を通知させる。これに応じて、時計アプリプロセス側では、上記ステップＳ４１以降の処理が行われることになる。なお、図示は省略しているが、エミュレータプロセス側では、内部的にはこの後もゲーム画面の生成処理等のゲーム処理（上記図２１のステップＳ２４～Ｓ２８相当の処理）も行われるが、実際の画面出力は行われないことになる。このように内部的に１フレーム分のゲーム処理が行われた後、上記ステップＳ８２に戻り、処理が繰り返される。

このように、第２のモードにおけるエミュレータの役割は、主に、時計アプリプロセス側から入力された動作制御用パラメータに基づく各種キャラクタの移動制御と当たり判定処理の実行となる。時計アプリプロセス側では、この処理結果を用いて、上記のような第２モード画面の生成が行われることになる。

［処理の適用例］
次に、上記のような第２のモードの処理の適用例を、適宜画面例を交えながらいくつか例示する。

［地形・背景を変更する例］
適用例の１つとして、まず、第２モード画面における地形の画像を変更する例がある。図２６に、地形部分２０４の画像を変更した例を示す。上記図４で示した第２モード画面と比べると、地形部分２０４の画像がブロック状の地形から「きのこ」を模したような地形に変化している。これは例えば、次のようなタイミングで変化させればよい。例えば、動作モードが切り替えられたタイミング（第１のモードから第２のモードに切り替えられたタイミング）である。その他、第２のモードにおいて、スリープモードから復帰したタイミングで、第２モード画面で使用する地形画像をランダムで他の地形画像に変更するようにしてもよい。

また、第２モード画面の背景、具体的には「空」の部分の色を、時間帯に応じて変化させるようにしてもよい。すなわち、朝、昼、夕方、夜、深夜、といった時間帯に応じて、「空」の色を変化させるようにしてもよい。追加背景画像データ４０５のほうが使用色数が多いことから、このような時間帯毎に変化する「空」の色の表現について、エミュレータ対象ゲームにおける表現よりも豊かな表現ができる。

また、その他、特定の時刻において、時刻ブロック２０６の画像をコインの画像に変化させる等、時刻ブロック２０６の画像を時刻に応じて変化させてもよい。なお、このコインの画像データは、上記エミュレータ対象ゲームに元々含まれている画像データである。またこの際、プレイヤキャラクタ２０１にコインを取得させる動作を行わせてもよい。また、この取得動作にかかる制御自体は、エミュレータにおける処理結果を流用すればよい。

また、上記時刻ブロック２０６として描画する画像データについては、上記追加画像データを用意して、これを用いるようにしてもよいし、上記エミュレータ対象ゲームに含まれている（元の）画像データを流用するようにしてもよい。

［プレイヤキャラクタを変更する例］
また、他の適用例として、ランダム、あるいは特定の時間帯に、プレイヤキャラクタ２０１を他のプレイヤキャラクタの画像に変更するような処理を行ってもよい。例えば、エミュレータ対象ゲームが２人以上の同時プレイが可能なゲームである場合に、２人目以降のプレイヤが操作するキャラクタの画像（外観が明らかに異なるキャラクタの他、単なる「色変え」の場合のキャラクタも含む）に変更するようにしてもよい。なお、この場合も、これらキャラクタの画像データは、エミュレータ対象ゲームの画像データを流用することになる。

［ユーザ入力を利用する例］
また、他の適用例として、上記のような背景画像を変更するトリガーとして、ユーザの入力をトリガーとする処理を行ってもよい。例えば、第２のモードにおいて、プレイヤがＡボタン１４とＢボタン１５とを同時押しする度に、時刻ブロック２０６の色を他の色に変化させるような処理を行ってもよい。一例として、上記図２３のステップＳ４４とＳ４５の間に、このような同時押しが行われたか否かの判定を行い、行われていた場合は時刻ブロック２０６の表示色設定を変更する処理を行うようにしてもよい。また、時刻ブロック２０６の画像について追加画像データを用いるように構成しておくことで、より多彩な色彩表現を行うことも可能となる。

［プレイヤキャラクタ画像を一時的に変更する例］
また、他の適用例として、プレイヤキャラクタ２０１について、元のエミュレータ対象ゲームにはなかった動きを行わせる処理を行ってもよい。例えば、プレイヤキャラクタ２０１が所定の位置に来たときに一旦立ち止まらせ、元のエミュレータ対象ゲームにはなかった画像に一時的にプレイヤキャラクタ２０１の画像を変更し、その後、元の画像に戻して移動を再開させる、等の処理をおこなってもよい。より具体的には、所定の位置でプレイヤキャラクタ２０１が時々立ち止まり、元のエミュレータ対象ゲームにはなかったプレイヤキャラクタ２０１の「正面画像」や、「休憩している画像」を描画する、等である。なお、この立ち止まりの発生については、例えばランダムで発生させてもよいし、特定の条件を満たした際に（上記イベントの１つとして）発生させるようにしてもよい。

［敵キャラクタの動作例］
次に、第２のモードにおける敵キャラクタに関して、いくつか例示する。まず、基本的な動作としては、図６を用いて上述したように、画面上方から敵キャラクタ２０２が出現し、画面左端に向けて移動していくという動作を行っている。この際、例えば、図２７に示すように分表示が「４０分」台の場合、画面上方から出現した敵キャラクタ２０２は、時刻ブロック２０６のくぼみ（凹部分）に挟まり、結果的に身動きがとれないような状態で表示されることになる。

［未登場キャラクタの利用例］
次に、敵キャラクタとして、元のエミュレータ対象ゲームには存在しない上記未登場キャラクタを用いる例を示す。図２８に、第２のモード専用の敵キャラクタが登場する場合の画面例を示す。図２８では、特定の時刻（１時１１分）のときに、３体の未登場キャラクタ３３１が出現している例を示している。この例では、３体の未登場キャラクタ３３１はそれぞれ画面下方から出現して、真上方向に移動していく。これら未登場キャラクタ３３１の画像データは、追加キャラ画像データ４０６に含まれるものであって、エミュレータ対象ゲームには含まれていないデータである。処理としては、エミュレータ対象ゲームに登場する所定の敵キャラクタを代替キャラクタとして、当該未登場キャラクタと対応づけておく（追加キャラ対応指定情報５３４）。そして、エミュレータの処理において、その出現位置や移動経路を指定してこの代替キャラクタの動作制御を行わせ、その処理結果を受けて、この代替キャラクタの画像を未登場キャラクタの画像に変更して表示する、という処理となる。

このような未登場キャラクタを用いる他の適用例を示す。次に説明する例では、「時報」としての演出で、これら未登場キャラクタを用いた特殊な演出を行っている。ここでは、１２：００の時報を例にする。図２９に、１２：００の数秒前の第２モード画面の例を示す。図２９では、未登場キャラクタ３３２が４体登場している。これら未登場キャラクタ３３２は、画面左端から順次出現し、それぞれ、時刻ブロック２０６の各桁の真下となる位置まで移動する。そして、１２：００になると、これらの未登場キャラクタ３３２がジャンプして時刻ブロック２０６にぶつかることで、当該時刻ブロック２０６を破壊する（なお、ブロックの破片の画像データはエミュレーション対象ゲームのロムデータのものを利用しているとする）。その結果、図３０に示すように、時刻ブロック２０６は一旦粉々になった後、更に、破片が寄せ集まるような演出が行われ、図３１に示すように、「１２：００」の形状に配置される。その後、未登場キャラクタ３３２は画面外に移動していく。なお、この一連の演出の間、プレイヤキャラクタ２０１は、地形部分２０４上の、ほぼ画面中央となる位置で停止している。このような処理の場合も、第２モード用エミュレータメモリ領域５０５のゲーム処理作業用データ４８１の内容を、未登場キャラクタに対応する代替キャラクタが出現するように変更して各種の動作制御を行わせている。そして、この処理結果に基づき、代替キャラクタの画像を未登場キャラクタの画像に変更して、上記のような時報の演出を行う。

［ゲームシーンが変化する例］
また、更に他の適用例として、ゲーム場面が変化するような処理について説明する。一例として、上記１２：００のような特定の時刻になると、ゲームステージのゴール地点に到達するような演出（ゴールシーン演出）を行う例を挙げる。この例では、上記のような時報演出が終わると、プレイヤキャラクタ２０１は、図３２に示すように、画面右端に向けて移動を開始する。この移動に伴い、図３３に示すように画面がスクロールし、山積みとなっているブロックが表示されてくる。プレイヤキャラクタ２０１はこのブロックを駆け上っていき、図３４に示すように、頂上からジャンプして着地した後、更に右方向に進んで図３５に示すようなゴール地点となる「城オブジェクト」に到着する、という演出が行われる。この処理の場合、上記動作制御パラメータの決定の際に、仮想ゲーム空間内におけるプレイヤキャラクタ２０１の位置としてゴール地点手前の地点を指定すればよい。そして、ゴールシーンの演出部分にかかる処理はエミュレータの処理結果をそのまま反映しつつ、背景画像だけを変更する、というような処理を行えばよい。

この他、例えば、所定の時刻や時間帯になると、プレイヤキャラクタ２０１が上記土管２０５の中に入り、異なるゲームステージに移動するようにしてもよい。例えば、ある時刻になると、プレイヤキャラクタ２０１が土管２０５の中に入り、ゲームステージが遷移して、第２モード画面の内容が「水中ステージ」のものに切り替わるようにしてもよい。この場合は、仮想ゲーム空間内におけるプレイヤキャラクタ２０１の位置がこの水中ステージのスタート地点になるように、ゲーム処理作業用データ４８１の内容を変更して、エミュレータに処理させればよい。特に、地上ステージでは「走る」ところ、水中ステージでは「泳ぐ」というように、水中ステージでは地上ステージとでプレイヤキャラクタ２０１の挙動が異なる場合でも、動作制御自体はエミュレータ側に処理させているため、その挙動の再現度を高めることができる。

以上で、本実施形態にかかる処理の詳細説明を終了する。

このように、本実施形態では、エミュレータが処理するデータに変更を加えたうえで、プレイヤキャラクタ２０１やＮＰＣの動作制御、および当たり判定処理自体は当該エミュレータに処理させている。そして、この処理結果に基づいて上記第２モード画面を生成するが、この際、登場キャラクタの画像データはエミュレーション対象ゲームのロムデータのものをそのまま流用している。その一方で、背景画像については、第２のモード専用の画像データを用いて描画している。これにより、エミュレーション対象ゲームのコンテンツを活用した別のアプリケーション（本例では時計アプリ）を実行することができる。また、その画面についても、より表現力が豊かな画面で表現できる。また、プレイヤキャラクタ２０１等の動作制御はエミュレータに行わせるため、時計アプリにおけるプレイヤキャラクタ２０１等の動きのエミュレーション対象ゲームに対する再現度をより高めることができる。換言すれば、プレイヤキャラクタ２０１の動作制御等に関して、時計アプリ側で新たにその制御用の処理を作り込む必要を省くことができ、開発コストの削減を図ることができる。特に、エミュレーション対象ゲームが過去のゲームであり、コンテンツを活用したアプリケーションにおいても原作再現度が求められる場合において、当時のハードウェアにおける当時のプログラムの挙動を現在の環境でも忠実に再現するということは必ずしも容易ではないが、その手間を省くことができる。また、エミュレーション対象ゲームのロムデータを第２モードでも利用することで、フラッシュメモリ１０２に記憶されるデータ量を節約することができる。

［変形例］
なお、上記エミュレーション対象ゲームは、上記のようなジャンプアクションゲームに限らず、所定のキャラクタが登場する他のジャンルのゲームであってもよい。そして、プレイヤキャラクタ２０１やＮＰＣの画像データについてはエミュレーション対象ゲームのロムデータのものを用いて、背景画像については時計アプリ専用に用意された画像を用いればよい。

また、上記実施形態では、時計アプリにおける背景画像については全て追加背景画像データ４０５を用いる例を示した。他の実施形態では、背景画像についても、少なくとも一部は追加背景画像データ４０５を用い、残りの部分はエミュレーション対象ゲームにおける画像データをそのまま流用するような構成にしてもよい。

また、上記の実施形態では、第２のモードにおいて、エミュレータプロセス側から取得する処理結果として、各キャラクタの移動制御の結果と当たり判定結果を取得する例を示した。そして、この処理結果を用いて時計アプリプロセス側で上記第２モード画面を生成していた。この他、他の実施形態では、背景画像と登場キャラクタ画像とを用いたゲーム画面の生成処理まで一旦エミュレータプロセス側に行わせ、出力結果としてのゲーム画像を時計アプリプロセス側で取得するようにしてもよい。そして、時計アプリ側でこのゲーム画像を解析し、背景画像を構成する各タイルを追加背景画像データ４０５に基づく画像に変更してからディスプレイ１２に出力するような構成にしてもよい。例えば、エミュレータ対象ゲーム機がフレームバッファにゲーム画像を書き込むような処理を行うものであれば、エミュレータにおけるフレームバッファの内容を取得して、追加背景画像データ４０５を用いてその内容を変更してからディスプレイ１２に出力するような構成としてもよい。

また、上記の例では、第２のモードとしてエミュレーション処理を活用するアプリの例として時計アプリの例を挙げた。他の実施形態では、時計アプリ以外の所定のアプリケーションを実行してもよい。例えば、天気予報アプリ、歩数計アプリ、電卓アプリ等でもよい。これらのアプリケーションで表示するアプリケーション画像においても、登場するキャラクタの画像やその動作はエミュレーション対象ゲームのものをそのまま用い、背景画像は各アプリケーション専用の画像を用いるようにすればよい。

また、上記のような処理を実行する主体に関しても、上記のような構成に限らない。例えば、単体の情報処理装置ではなく、本体装置、コントローラ、表示部とが別のコンポーネントとして構成される情報処理システムについても上記のような処理は適用可能である。更には、本体装置が所定のサーバと通信可能な構成として、情報処理装置１０で実行される上記一連の処理のうちの主要な処理がサーバ側装置によって実行され、当該情報処理装置１０では一部の処理が実行されてもよい。

また、その他、スマートフォン等の汎用的な情報処理装置において、上記のような第１のモードと第２のモードの２つの動作モードを有する（スマートフォン向け）アプリケーションとして、上記のような機能が提供されてもよい。

１０ 情報処理装置
１０１ プロセッサ
１０２ フラッシュメモリ
１０３ ＤＲＡＭ
１０４ 操作部
１２ ディスプレイ
１０６ ＲＴＣ

Claims (28)

1. 記憶媒体と、
   プロセッサを備え、
   前記記憶媒体は、ゲームのロムデータと、当該ロムデータに基づいてゲームを実行するエミュレータプログラムを少なくとも記憶し、
   前記プロセッサは、
   第１のモードにおいて、前記エミュレータプログラムによって前記ロムデータに基づくゲーム処理を実行し、
   第２のモードにおいて、前記エミュレータプログラムに前記ロムデータに基づくゲーム処理を実行させながら、更に実行中の当該エミュレータプログラムが処理するデータに変更を加えることにより、前記ゲーム処理とは異なり、かつ前記ロムデータに含まれるゲーム画像の少なくとも一部が表示されるアプリケーションを実行する、情報処理装置。
2. 前記ロムデータは、背景画像データとキャラクタ画像データを少なくとも含み、
   前記エミュレータプログラムは、前記ロムデータに基づいて背景画像およびキャラクタ画像を生成し、当該キャラクタ画像に関連付けられたキャラクタを制御し、当該背景画像およびキャラクタ画像を少なくとも含むゲーム画面を表示させることで前記ゲームを実行する、請求項１に記載の情報処理装置。
3. 前記プロセッサは、
   前記第１のモードにおいて、前記エミュレータプログラムに前記キャラクタのうちプレイヤキャラクタを少なくとも制御させ、
   前記第２のモードにおいて、前記プレイヤキャラクタに関連付けられる前記キャラクタ画像が少なくとも表示される前記アプリケーションを実行する、請求項２に記載の情報処理装置。
4. 前記プロセッサは、前記第２のモードにおいて、前記プレイヤキャラクタを所定の位置に配置する変更を行った上で、前記エミュレータプログラムに前記プレイヤキャラクタを制御させる、請求項３に記載の情報処理装置。
5. 前記プロセッサは、
   前記第１のモードにおいて、前記エミュレータプログラムに、操作部から入力されるキーデータに基づいて前記プレイヤキャラクタを制御させ、
   前記第２のモードにおいて、前記キーデータを疑似的に入力する変更を行った上で、前記エミュレータプログラムに前記プレイヤキャラクタを制御させる、請求項３または４に記載の情報処理装置。
6. 前記プロセッサは、前記第２のモードにおいて、前記キャラクタのうち、前記プレイヤキャラクタ以外の少なくとも１つのノンプレイヤキャラクタを所定の位置に配置する変更を行った上で前記エミュレータプログラムに当該プレイヤキャラクタおよび当該ノンプレイヤキャラクタを制御させる、請求項３から５のいずれかに記載の情報処理装置。
7. 前記エミュレータプログラムが実行する処理は、前記キャラクタ同士の当たり判定処理を含む、請求項３から６のいずれかに記載の情報処理装置。
8. 前記記憶媒体は、前記ロムデータに含まれる前記キャラクタ画像とは別に追加キャラクタ画像を更に記憶し、
   前記プロセッサは、前記第２のモードにおいて、前記エミュレータプログラムが前記ゲーム処理の実行中に制御する前記キャラクタの前記キャラクタ画像を、前記追加キャラク
   タ画像に変更して表示する、請求項２から７のいずれかに記載の情報処理装置。
9. 前記記憶媒体は、前記ロムデータに含まれる前記背景画像データとは別に追加背景画像データを更に記憶し、
   前記プロセッサは、前記第２のモードにおいて表示する前記背景画像の少なくとも一部に、前記追加背景画像データを用いた画像を表示させる、請求項２から８のいずれか記載の情報処理装置。
10. 前記第２のモードにおけるアプリケーションは、時計アプリケーションである、請求項１から９のいずれか記載の情報処理装置。
11. 前記第２のモードにおけるアプリケーションは、時計アプリケーションであり、
    前記プロセッサは、前記第２のモードにおいて、複数の前記ノンプレイヤキャラクタを、時刻を表す形状に配置する、請求項６に記載の情報処理装置。
12. 前記第２のモードにおけるアプリケーションは、時計アプリケーションであり、
    前記プロセッサは、前記第２のモードにおいて、前記追加背景画像データによって時刻を表す画像を表示させる、請求項９に記載の情報処理装置。
13. 前記プロセッサは更に、前記第２のモードにおいて、特定の時刻になったことに応じて、所定のイベントを発生させる、請求項１０から１２のいずれかに記載の情報処理装置。
14. 前記情報処理装置は、モード切替の指示を行うための切替操作部を更に備え、
    前記プロセッサは更に、
    前記切替操作部への操作に応じて前記モードの切替を行い、
    前記第１のモードから別のモードに移行する場合には、プレイ中の前記ゲーム処理の状態を保存し、
    前記別のモードから前記第１のモードに移行した場合に、保存された状態から前記ゲーム処理を再開させる、請求項１から１３のいずれかに記載の情報処理装置。
15. 前記情報処理装置は、画像を表示するディスプレイと、前記ゲームをプレイするための操作部を更に備える携帯型の装置である、請求項１から１４のいずれか記載の情報処理装置。
16. 記憶媒体と、
    プロセッサを備え、
    前記記憶媒体は、ゲームのロムデータと、当該ロムデータに基づいてゲームを実行するエミュレータプログラムを少なくとも記憶し、
    前記プロセッサは、
    第１のモードにおいて、前記エミュレータプログラムによって前記ロムデータに基づくゲーム処理を実行し、
    第２のモードにおいて、前記エミュレータプログラムに前記ロムデータに基づくゲーム処理を実行させながら、更に実行中のエミュレータプログラムが処理するデータに変更を加えることにより、前記ゲーム処理とは異なり、かつ前記ロムデータに含まれるゲーム画像の少なくとも一部が表示されるアプリケーションを実行する、情報処理システム。
17. ゲームのロムデータと、当該ロムデータに基づいてゲームを実行するエミュレータプログラムを少なくとも記憶した記憶媒体を備える情報処理装置のプロセッサに、
    第１のモードにおいて、前記エミュレータプログラムによって前記ロムデータに基づくゲーム処理を実行させ、
    第２のモードにおいて、前記エミュレータプログラムに前記ロムデータに基づくゲーム処理を実行させながら、更に実行中の当該エミュレータプログラムが処理するデータに変更を加えることにより、前記ゲーム処理とは異なり、かつ前記ロムデータに含まれるゲーム画像の少なくとも一部が表示されるアプリケーションを実行させる、情報処理プログラム。
18. 前記ロムデータは、背景画像データとキャラクタ画像データを少なくとも含み、
    前記エミュレータプログラムは、前記ロムデータに基づいて背景画像とキャラクタ画像を生成し、前記キャラクタ画像に関連付けられたキャラクタを制御し、背景画像とキャラクタ画像を少なくとも含むゲーム画面を表示させることで前記ゲームを実行する、請求項１７に記載の情報処理プログラム。
19. 前記プロセッサに、
    前記第１のモードにおいて、前記エミュレータプログラムによって前記キャラクタのうちプレイヤキャラクタを少なくとも制御させ、
    前記第２のモードにおいて、前記プレイヤキャラクタに関連付けられる前記キャラクタ画像が少なくとも表示される前記アプリケーションを実行させる、請求項１８に記載の情報処理プログラム。
20. 前記プロセッサに、前記第２のモードにおいて、前記プレイヤキャラクタを所定の位置に配置する変更を行った上で、前記エミュレータプログラムによる前記プレイヤキャラクタの制御を行わせる、請求項１９に記載の情報処理プログラム。
21. 前記プロセッサに、
    前記第１のモードにおいて、操作部から入力されるキーデータに基づいて前記エミュレータプログラムによる前記プレイヤキャラクタの制御を行わせ、
    前記第２のモードにおいて、前記キーデータを疑似的に入力する変更を行った上で、前記エミュレータプログラムによる前記プレイヤキャラクタの制御を行わせる、請求項１９または２０に記載の情報処理プログラム。
22. 前記プロセッサに、前記第２のモードにおいて、前記キャラクタのうち、前記プレイヤキャラクタ以外の少なくとも１つのノンプレイヤキャラクタを所定の位置に配置する変更を行った上で前記エミュレータプログラムによる当該プレイヤキャラクタおよび当該ノンプレイヤキャラクタの制御を行わせる、請求項１９から２１のいずれかに記載の情報処理プログラム。
23. 前記記憶媒体には、前記ロムデータに含まれる前記キャラクタ画像とは別に追加キャラクタ画像が更に記憶されており、
    前記プロセッサに、前記第２のモードにおいて、前記エミュレータプログラムが前記ゲーム実行中に制御する前記キャラクタの前記キャラクタ画像を、前記追加キャラクタ画像に変更して表示させる、請求項１８から２２のいずれかに記載の情報処理プログラム。
24. 前記記憶媒体には、前記ロムデータに含まれる前記背景画像データとは別に追加背景画像データを更に記憶されており、
    前記プロセッサに、前記第２のモードにおいて表示する前記背景画像の少なくとも一部に、前記追加背景画像データを用いた画像を表示させる、請求項１８から２３のいずれか記載の情報処理プログラム。
25. 前記第２のモードにおけるアプリケーションは、時計アプリケーションであり、
    前記プロセッサに、前記第２のモードにおいて、複数の前記ノンプレイヤキャラクタを
    、時刻を表す形状に配置させる、請求項２２に記載の情報処理プログラム。
26. 前記第２のモードにおけるアプリケーションは、時計アプリケーションであり、
    前記プロセッサに、前記第２のモードにおいて、前記追加背景画像データによって時刻を表す画像を表示させる、請求項２４に記載の情報処理プログラム。
27. 前記プロセッサに更に、前記第２のモードにおいて、特定の時刻になったことに応じて、所定のイベントを発生させる、請求項２５または２６に記載の情報処理プログラム。
28. ゲームのロムデータと、当該ロムデータに基づいてゲームを実行するエミュレータプログラムを少なくとも記憶した記憶媒体を備える情報処理装置のプロセッサが実行する情報処理方法であって、
    前記プロセッサに、
    第１のモードにおいては、前記ロムデータに基づいたゲーム処理を前記エミュレータプログラムが実行するように制御させ、
    第２のモードにおいては、前記ロムデータに基づくゲーム処理を前記エミュレータプログラムに実行させながら、更に実行中の当該エミュレータプログラムが処理するデータに変更を加えることにより、当該ゲーム処理とは異なり、かつ前記ロムデータに含れるゲーム画像の少なくとも一部が表示されるアプリケーションを実行するように制御させる、情報処理方法。

Images