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

Abstract

【課題】既存のゲームプログラムを活用し、より手軽にゲームを楽しめる情報処理プログラム、情報処理装置、情報処理システム、及び情報処理方法を提供すること。【解決手段】情報処理ログムラムにおいて、情報処理装置を、前記情報処理装置の構成とは異なる構成を持つ他の情報で実行可能なゲームプログラム及びゲームプログラムの所定の実行箇所における実行状況を表す実行状況情報を読み込む読込手段と、前記実行状況情報を用いて、前記ゲームプログラムを所定の実行箇所からエミュレートするエミュレート手段と、前記エミュレートするゲームプログラムの実行状況を判定する判定手段と、前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記エミュレート手段の実行状態を変更する変更手段として動作させる。【選択図】図１

Description

本発明は、ゲームプログラムのエミュレーションを行う情報処理プログラム、情報処理装置、情報処理システム、及び情報処理方法に関する。

近年、コンピュータ技術の進歩により、ＣＰＵ（Central Processing Unit）の処理速度、処理能力が向上している。それに伴い、新たなＣＰＵを用いたゲーム機が開発されている。このような新タイプのゲーム機は、旧タイプと構成が異なるため、旧タイプ用のゲームプログラムを動作させることは出来ない。そこで、新タイプのゲーム機において、旧タイプのゲーム機用のゲームプログラムを利用可能とするエミュレータが提案されている（特許文献１）。

特開２００１−３４０６４０号公報

上記提案されているエミュレータは、単に旧タイプのゲーム機用プログラムを新タイプのゲーム機で利用可能とするものであり、場面をクリアする条件など、ゲーム内容には変化がなかった。そのため、ゲームの一場面をクリアするためには、ある一定以上の時間が必要であった。
しかし、ユーザの生活が多様化する中、より手軽にゲームを楽しめることが望まれている。また、旧タイプのゲーム機用プログラムといった既存のゲームプログラムを活用し新たな楽しみをユーザに提供することが望まれている。

本発明の目的とするところは、既存のゲームプログラムを活用し、より手軽にゲームを楽しめる情報処理プログラム、情報処理装置、情報処理システム、及び情報処理方法を提供することにある。

本発明に係る情報処理プログラムは、情報処理装置を、前記情報処理装置の構成とは異なる構成を持つ他の情報処理装置で実行可能なゲームプログラム及び前記ゲームプログラムの所定の実行箇所における実行状況を表す実行状況情報を読み込む読込手段と、前記実行状況情報を用いて、前記ゲームプログラムを前記所定の実行箇所からエミュレートするエミュレート手段と、前記エミュレートするゲームプログラムの実行状況を判定する判定手段と、前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記エミュレート手段の実行状態を変更する変更手段として前記情報処理装置を動作させる。

本発明に係る情報処理プログラムにおいて、前記ゲームプログラムによるゲームは複数の場面を含み、前記実行状況情報は、所定の場面における状態を示す情報であり、前記エミュレート手段は、前記所定の場面から処理を実行する。

本発明に係る情報処理プログラムにおいて、前記変更手段は、前記条件を満たすと判定した場合に、前記エミュレートしている場面についての処理を停止させる。

本発明に係る情報処理プログラムにおいて、前記読込手段は前記ゲームプログラムの複数の場面それぞれに対応する実行箇所における実行状況情報の中から前記エミュレートしている場面とは異なる一の場面に対応した実行状況情報を更に読み込み、前記変更手段は、前記エミュレート手段が実行中の場面についての処理を停止させ、前記エミュレートしている場面とは異なる一の場面についての処理を前記エミュレート手段に実行させる。

本発明に係る情報処理プログラムにおいて、前記読込手段は複数のゲームプログラムについての実行状況情報の中から一の場面に対応した実行状況情報を読み込む。

本発明に係る情報処理プログラムにおいて、前記実行状況情報は、ゲームプログラムがエミュレートされる際に使用される仮想メモリ全体のメモリイメージである。

本発明に係る情報処理プログラムにおいて、前記予め定めた条件は、ゲームが予め定めた状況まで進行したか否かであり、前記判定手段は、前記エミュレート手段で実行するゲームプログラムが出力する出力画像及び予め定めた判定用画像のマッチングを行うマッチング手段、並びにマッチング手段によるマッチング結果から、前記ゲームプログラムに係るゲームが予め定めた状況まで進行したか否かを判定する画像判定手段を含む。

本発明に係る情報処理プログラムにおいて、前記画像判定手段は、前記マッチング結果より前記出力画像に前記判定用画像が出現している場合に、前記ゲームプログラムの実行状況が条件を満たしたと判定する。

本発明に係る情報処理プログラムにおいて、前記画像判定手段は、前記出力画像における前記判定用画像の出現位置が所定範囲内である場合に、前記ゲームプログラムの実行状況が条件を満たしたと判定する。

本発明に係る情報処理プログラムにおいて、前記マッチング手段は、前記出力画像及び前記判定用画像のマッチングを繰り返し実行し、前記画像判定手段は、前記出力画像における前記判定用画像の出現位置が、予め定めた遷移をした場合に、前記ゲームプログラムの実行状況が条件を満たしたと判定する。

本発明に係る情報処理プログラムにおいて、前記マッチング手段は、前記出力画像及び前記判定用画像のマッチングを繰り返し実行し、マッチングを行う都度、前記出力画像における前記判定用画像の出現個数又は前記出力画像に含まれる数値を取得し、前記画像判定手段は、前記出力画像における前記判定用画像の出現個数又は数値が所定の条件を満たした場合に、前記ゲームプログラムの実行状況が条件を満たしたと判定する。

本発明に係る情報処理プログラムにおいて、前記所定の条件を満たした場合とは、前記出現個数又は前記出力画像に含まれる数値が、先行するマッチングにより取得した出現個数又は数値から所定の変化をした場合である。

本発明に係る情報処理装置は、自らとは構成の異なる構成を持つ他の情報処理装置で実行可能なゲームプログラム及び前記ゲームプログラムの所定の実行箇所における実行状況を表す実行状況情報を読み込む読込部と、前記実行状況情報を用いて、前記ゲームプログラムを前記所定の実行箇所からエミュレートするエミュレート部と、前記エミュレートするゲームプログラムの実行状況を判定する判定部と、前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記エミュレート部の実行状態を変更する変更部とを備える。

本発明に係る情報処理システムは、自らとは構成の異なる構成を持つ他の情報処理システムで実行可能なゲームプログラム及び前記ゲームプログラムの所定の実行箇所における実行状況を表す実行状況情報を読み込む読込部と、前記実行状況情報を用いて、前記ゲームプログラムを前記所定の実行箇所からエミュレートするエミュレート部と、前記エミュレートするゲームプログラムの実行状況を判定する判定部と、前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記エミュレート部の実行状態を変更する変更部とを備える。

本発明に係る情報処理方法は、情報処理装置で実行される情報処理方法であって、自らとは構成の異なる構成を持つ他の情報処理装置で実行可能なゲームプログラム及び前記ゲームプログラムの所定の実行箇所における実行状況情報を読み込む読込ステップと、前記実行状況情報を用いて、前記ゲームプログラムを前記所定の実行箇所からエミュレートするエミュレートステップと、前記ゲームプログラムの実行状況を判定する判定ステップと、前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記ゲームプログラムの実行状態を変更する変更ステップを含む。

本発明は、ゲーム機により実行されているゲームプログラムをプログラム内部で定めた終了条件ではなく、プログラム外部で定めた条件により終了させるので、既存のゲームプログラムとは異なる楽しみ方を提供可能であり、ユーザが手軽に楽しめるゲームを提供することが可能となる。

本実施の形態に係るゲームシステムの構成を示す説明図である。 本実施の形態に係るゲーム機のハードウェア構成を示すブロック図である。 本実施の形態に係るゲーム機のハードウェアとソフトウェアとの関係を示す説明図である。 ゲーム機で行われる処理の概要を示すフローチャートである。 実行フローのデータ構造を示す説明図である。 クリア条件の条件タイプ別のデータ構造を示す説明図である。 プレイヤキャラクタが敵キャラクタをかわす場合についての説明図である。 レースゲームにおいて、プレイヤキャラクタがゴールした場合についての説明図である。 種々のゲームにおいて、壁を規定数破壊した場合をクリア条件とする場合の説明図である。 種々のゲームにおいて、プレイヤキャラクタの残機数の変化を検出する場合についての説明図である。 スコアが所定の値になったら、クリアとする場合の説明である。 本実施の形態に係るゲーム機で行われる処理を説明するためのフローチャートである。 停止条件判定処理の処理手順を示すフローチャートである。 停止条件判定処理の処理手順を示すフローチャートである。 停止条件判定処理の処理手順を示すフローチャートである。

図１は本実施の形態に係るゲームシステム（情報処理システム）の構成を示す説明図である。ゲームシステムは、ゲーム機１（情報処理装置）、記録媒体２、テレビジョン受像機などのディスプレイ３、コントローラ４を含む。ゲーム機１は記録媒体２などに記憶されている情報処理プログラムを読み出して実行することにより、ゲーム処理を実行する。本実施の形態において、情報処理プログラムは管理プログラム、エミュレーションプログラム、ゲームプログラムなどである。また、ゲーム処理とはゲームプログラムで行われる処理のことを示す。

ゲーム機１は接続コードを介してディスプレイ３に接続される。ディスプレイ３はゲーム機１において実行されるゲーム処理によって得られるゲーム画像を表示する。また、ディスプレイ３はスピーカを内蔵しており、スピーカはゲーム処理の結果得られるゲーム音声を出力する。

コントローラ４はユーザが用いる操作装置である。コントローラ４は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）といった近距離無線通信技術を用いて、ゲーム機１と通信を行う。コントローラ４は、十字キー、アナログスティック、プッシュボタン又はタッチパネル等により、プレイヤの操作入力を受け付けて、それらの操作情報をゲーム機１に送信する。また、コントローラ４は表示部やスピーカ、マイクを備えていても良く、ディスプレイ３に表示される画像を表示したり、ディスプレイ３とは異なる画像を表示したりしても良い。音声についても同様にディスプレイ３の内蔵スピーカと同じ音声を、コントローラ４のスピーカから出力しても良いし、コントローラ４向けの独自の音声を出力しても良い。マイクはコントローラ４の周辺の音声、例えばプレイヤの発話音声などを集音し、ゲーム機１へ送信する。

図２は本実施の形態に係るゲーム機１のハードウェア構成を示すブロック図である。ゲーム機１は、処理部１０、出力部１１、記録媒体装着部１２、一次記憶部１３、二次記憶部１４、近距離無線通信部１５、無線通信部１６等を含む。

ゲーム機１の処理部１０は、ＣＰＵ（Central Processing Unit）などの演算処理装置を用いて構成されている。処理部１０は、二次記憶部１４に記憶された後述する管理プログラムＰ１、エミュレータ、ゲームプログラムＰ３を一次記憶部１３に読み出して実行することにより、ゲーム処理を行う。管理プログラムＰ１、エミュレーションプログラムＰ２、ゲームプログラムＰ３の全部又は一部を記録媒体装着部１２に装着された記録媒体２より、読み出しても良い。

出力部１１は、処理部１０から与えられた画像、音声を出力し、ディスプレイ３に画像を表示させ、ディスプレイ３内臓のスピーカより音声を出力させる。記録媒体装着部１２は、ＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）等の記録媒体２を着脱できるように構成されている。なお、記録媒体装着部１２は従来のゲーム機で使用されていたカセットを装着可能とし、ゲームプログラムＰ３等をカセットから読み込むこととしても良い。一次記憶部１３は、半導体メモリ素子などを用いて構成されている。一次記憶部１３は、処理部１０の演算処理に伴って生成される各種のデータが一時的に記憶される。二次記憶部１４は、一次記憶部１３と比較して大容量の不揮発性記憶装置を用いて構成されている。二次記憶部１４は、ゲームプログラムＰ３及びその他のデータ等を記憶する。

近距離無線通信部１５は上述したように、コントローラ４と通信を行う。コントローラ４から操作入力、マイクによる集音データを受信し、それを処理部１０に出力する。また、処理部１０又は出力部１１より入力された画像又は音声をコントローラ４に送信する。

無線通信部１６は、無線ＬＡＮ（Local Area Network）又は携帯電話網等のネットワーク５を介して、サーバ装置等との間で情報の送受信を行う。例えばゲーム装置１は、無線通信部１６にてサーバ装置との通信を行ってゲームプログラムＰ３をダウンロードし、二次記憶部１４に記憶することができる。管理プログラムＰ１、エミュレータなども、サーバ装置からダウンロードしても良い。

図３は、本実施の形態に係るゲーム機１のハードウェアとソフトウェアとの関係を示す説明図である。ゲーム機１のハードウェア上で管理プログラムＰ１が実行される。管理プログラムＰ１上でエミュレータが動作し、さらにエミュレータ上でゲームプログラムＰ３が動作する。

エミュレータ（エミュレート実行部）はゲーム機１と異なるハードウェア構成を持つ他のゲーム機のハードウェアをエミュレートする。エミュレータは仮想ＣＰＵ１０ｇ、仮想メモリ１０ｈを含む。エミュレータにより、他のゲーム機でしか動作できないゲームプログラムを動作させることが可能となる。例えば、他のゲーム機は、以前の世代のゲーム機である。

管理プログラムＰ１は機能部として、読込部１０ａ、判定部１０ｂ及び変更部１０ｆを含む。読込部１０ａはエミュレータの動作に必要な実行状況情報を読み込む。

判定部１０ｂは、エミュレータで動作しているゲームプログラムの実行状態を監視し、実行状態が予め定めた条件を満たしたか否かを判定する。
本実施の形態において、判定部１０ｂはディスプレイ３に表示されるゲーム画像の表示内容から判定を行う。判定部１０ｂは、画像取込部１０ｃ、マッチング部１０ｄ、画像判定部１０ｅを含む。画像取込部１０ｃはゲーム画像を取り込む。マッチング部１０ｄは画像取込部１０ｃが取り込んだ画像と予め取得してある判定用画像とのマッチングを行う。画像判定部１０ｅはマッチング部１０ｄによるマッチング結果から、ゲーム画像が予め定めた条件を満たしているか否かを判定する。

変更部１０ｆは、判定部１０ｂにより実行状態が予め定めた条件を検知した場合、エミュレータで実行中のゲームプログラムの実行状態を変更する。例えば、実行中のゲームプログラムの実行を停止し、予め定めた実行箇所から実行を再開する。または、他のゲームプログラムを読み込み、当該プログラムを所定の実行箇所から実行する。

ゲーム機１は、処理部１０が管理プログラムＰ１を実行することによって、読込部１０ａ、判定部１０ｂ、変更部１０ｆがソフトウェア的な機能手段として実現される。

本実施の形態に係るゲーム機は、ゲームプログラムを部分実行することが可能である。ここで、部分実行とは、ゲームプログラムを部分的に実行することを示す。部分実行は、１つのゲームプログラムの一部分を１回のみ行うものでも良いし、複数回、実行するのでも良い。また、１つのプログラムの異なる一部分を、それぞれ１回又は複数回実行しても良い。さらにまた、複数のプログラムの部分実行を組み合わせても良い。このような部分実行を実現するために、実行フローを用いる。実行フローは、ゲームプログラムの実行順、各実行におけるゲームプログラムの実行箇所、実行するゲームプログラムを停止する条件などが記載されたものである。

図４は、ゲーム機で行われる処理の概要を示すフローチャートである。ゲーム機はまず、実行フローを読み込む。読み込んだ実行フローに従い、ゲームプログラムを実行する。ゲーム機はゲームプログラムの実行状態を監視し、実行状態が停止条件を満たしているか否かを判定する。実行状態が停止条件を満たしていない場合、ゲーム機はゲームプログラムの実行を継続する。実行状態が停止条件を満たした場合、ゲーム機は実行フローを参照し、次に実行すべきゲームプログラムが有るか否か判定する。次に実行すべきプログラムが有る場合、ゲーム機は次のゲームプログラムを実行する。実行すべきプログラムがない場合は、ゲーム機は処理を終了する。

次に、本実施の形態において用いられる各種データについて説明する。図５は実行フローＦのデータ構造を示す説明図である。実行フローＦはゲームプログラムの実行手順を定義する。実行フローＦは複数のフローｆ１、フローｆ２、…から構成される。図５にｆ１１、ｆ２１はフローのＩＤが格納され、ＩＤに含まれる数値の順にフローが実行される。フローｆ１を例として、各フローのデータ構造を説明する。フローｆ１は、ゲームＩＤｆ１２、実行状況情報ｆ１３、クリア条件ｆ１４を含む。ゲームＩＤｆ１２はゲームを特定するための情報である。

実行状況情報ｆ１３はゲームＩＤｆ１２で特定されたゲームに対応するゲームプログラムを所定の箇所から実行開始するための情報である。実行状況情報ｆ１３はゲームプログラム実行中の所定の箇所でのレジスタ情報ｆ１３１、メモリ情報ｆ１３２を含む。レジスタ情報ｆ１３１、メモリ情報ｆ１３２を用いることにより、所定の箇所での状態を再現し、当該ゲームプログラムをプログラムの冒頭からではなく、所定の箇所から実行することが可能となる。実行状況情報ｆ１３には、スタック、フラグレジスタ、割り込みベクタ、インタバールタイマ等のタイマ値などの情報を含んでも良い。
上述したように、実行状況情報ｆ１３はゲームプログラムを所定の箇所で止めた場合の、レジスタ情報ｆ１３１、メモリ情報ｆ１３２等であり、いわゆるスナップショットとも言われる、静的情報を示す。
それに対して、実行状態は、動作しているゲームプログラムの状態であり、変化することが前提の動的な情報である。複数の実行状況情報ｆ１３を時系列に並べた場合、最新なものが実行状態である。

本実施の形態において、実行状況情報ｆ１３はゲームの途中の状況を示す情報である。例えば、複数の場面からなるゲームにおいて、第３面の冒頭の状況を実行状況情報ｆ１３として用意しておけば、プレイヤは第１面、第２面をクリアせずとも、第１面、第２面をクリアしたものとして、第３面の冒頭からゲームを開始することが可能となる。また、場面の途中での実行状況情報ｆ１３を取得していれば、場面の途中からゲームを開始することも可能となる。例えば、最終面において、ボスキャラクタが登場する条件が揃った状況における実行状況情報ｆ１３を取得しておけば、プレイヤは他の面をクリアすることなく、ボスキャラクタと戦うことが可能となる。

クリア条件ｆ１４とはゲームプログラムを停止する条件（停止条件）を定義する。クリア条件ｆ１４を用いることにより、ゲームプログラムの動作を任意の時点で停止することが可能なる。すなわち、ゲームプログラム自体とは異なる条件で、ゲームをクリアしたものとできる。図５のフロー１ｆ１を例とすすると、クリア条件ｆ１４は条件タイプｆ１４１と条件データｆ１４２を含む。条件データｆ１４２は条件タイプ毎に内容が異なる。
なお、停止条件はゲームをクリアとするクリア条件ｆ１４のみならず、ゲームオーバーを判定する条件としても良い。

次にクリア条件ｆ１４について説明する。以下、クリア条件ｆ１４の一例として、ゲームプログラムが表示出力する画像（以下、「ゲーム画像」と記す。）を用いて、条件判定を行う場合について説明する。図６はクリア条件ｆ１４の条件タイプ別のデータ構造を示す説明図である。図６には３つの条件タイプを例示している。図６Ａは「出現回数」タイプの場合のクリア条件ｆ１４である。この条件はゲーム画像に所定の画像が複数回出現した場合に、条件を満たしたと判定する。この場合のクリア条件ｆ１４は検索範囲ｃ１、判定用画像ｃ２、回数ｃ４、出現位置ｃ５を含む。検索範囲ｃ１はゲーム画像のうち、どの範囲を処理対象とするかを定める。判定用画像ｃ２はクリア条件ｆ１４を判定するのに用いる画像を抽出するための画像である。回数ｃ４はクリア条件を満たす出現回数である。出現位置ｃ５は所定の画像が出現すべき位置を定義する。定義した位置を基準とする一定範囲内に所定画像が表示された場合に、出現回数をカウントする。検索範囲内であれば、どこの位置でも良い場合は、定義しなくても良い。また、回数に対応した数の位置を定義することにより、異なる位置に複数回出現する場合も条件として定義が可能となる。

図６Ｂは「出現数」タイプの場合のクリア条件ｆ１４である。この条件はゲーム画像中に同時に複数の所定画像が出現している場合に条件を満たしたと判定する。この場合のクリア条件は検索範囲ｃ１、判定用画像ｃ２、個数ｃ６を含む。検索範囲ｃ１、判定用画像ｃ２は上記と同様である。個数ｃ６はクリア条件を満たす所定画像の個数である。

図６Ｃは「カウンタ」タイプの場合のクリア条件ｆ１４である。この条件はゲーム画像中に出現する数値を抽出し、その値と閾値との大小関係で条件関係を満たしたかを判定するものである。この場合のクリア条件ｆ１４は検索範囲ｃ１、判定用画像ｃ２、値ｃ７、不等号ｃ８を含む。検索範囲ｃ１は上記と同様である。判定用画像ｃ２も上記と同様であるが、ここでは数字を表す画像を抽出する必要が有るため、少なくとも０から９を表す９枚の画像が定義されている。値ｃ７は条件判定の基準となる閾値である。不等号ｃ８は条件を満たす場合の画面上の数値としきい値との関係を示す。不等号ｃ８が大なり記号「＞」場合、画面上の数値が閾値より大きい場合に条件を満たしたと判定する。

次にクリア条件ｆ１４の具体例を示す。図７はプレイヤキャラクタ７１が敵キャラクタ７２をかわす場合についての説明図である。すなわち、プレイヤキャラクタ７１が敵キャラクタ７２をかわせたら、ゲームをクリアしたとする。図７Ａに示すように、敵キャラクタ７２は画面の右から現れる。図７Ｂに示すように、プレイヤキャラクタ７１はジャンプして、敵キャラクタ７２をよける。図７Ｃに示すように、敵キャラクタは画面の左へ消えていく。この場合、敵キャラクタ７２が現れた画像と、敵キャラクタ７２が消えていく画像とを捉える。

図７において、画像の左上が原点Ｏである。左右の軸がｘ軸、上下の軸がｙ軸である。画面右端のｘ座標をｘ１、敵キャラクタ７２が右端にいる場合のｘ座標をｘ２、左端にいる場合はのｘ座標をｘ３とする。
この場合、敵キャラクタ７２がｘ２の付近に現れた後に、ｘ３まで移動し、表示されなくなったとき、プレイヤキャラクタ７１は敵キャラクタ７２をかわしたものと判断できるから、クリア条件ｆ１４は、例えば、以下のように設定する。
タイプｔ：出現回数
検索範囲ｃ１：画面全体
判定用画像ｃ２：敵キャラ画像
回数ｃ４：２回
出現位置ｃ５：一回目ｘ＝ｘ２、ｙ＝任意、二回目ｘ＝ｘ３、ｙ＝任意

ここで、出現位置ｃ５の座標に幅を設けていないが、位置の判定を行う際に幅を設けても良い。ｙ座標については「任意」としたが、該当する敵キャラクタ７２が上下には移動しないものであれば、ｙ座標を指定しても良い。
また、より正確に敵キャラクタ７２の動きを検出するため、回数ｃ４を増やしても良い。

上述と同様な条件設定により、プレイヤキャラクタがスタートから出発してゴールに到達したこと、プレイヤキャラクタがスタートから出発して何かしらのタスクを果たしてスタートに戻ってきたことを検出することが可能となる。
また、レーシングゲームにおいて、コースのショートカットが行える場合に、ショートカットが行える地点の背景画像に含まれる特徴的な画像と、ショートカットが成功した後の地点の背景画像に含まれる特徴的な画像を判定用画像とすることにより、ショートカットに成功したことを検知することが可能となる。

図８はレースゲームにおいて、プレイヤキャラクタ８１がゴールした場合についての説明図である。プレイヤキャラクタ８１が乗ったカート８２がゴールしたので、「ＧＯＡＬ！」というメッセージが画面に表示されている。このメッセージを検知することにより、プレイヤキャラクタ８１がゴールしたことを検知可能となる。
この場合は、クリア条件ｆ１４は、例えば、以下のように設定する。
タイプｔ：出現回数
検索範囲ｃ１：所定範囲
判定用画像ｃ２：「ＧＯＡＬ！」のメッセージ画像
回数ｃ４：１回
出現位置ｃ５：任意

上述の場合、メッセージの表示箇所は一定であるとの前提で、処理量軽減のため、検索範囲を「所定範囲」とした。しかし、メッセージ画像が表示される位置が場面により異なり、予め設定が困難な場合は、検索範囲を画面全体とすれば良い。

上述と同様な条件設定により、場面をクリアした場合の「Ｃｌｅａｒ！」などのメッセージ画像や、格闘ゲームで相手キャラクタに勝利した場合の「Ｗｉｎ！」などのメッセージを検出することが可能である。
また、プレイヤキャラクタが取る特殊なポーズを検出することにより、ゴールや、敵キャラクタを倒したことを検出可能である。
さらにまた、敵キャラクタが倒された時に表示される効果画像を検知することにより、プレイヤキャラクタが敵キャラクタを倒したことを検出することが可能となる。

図９は種々のゲームにおいて、壁を規定数破壊した場合をクリア条件とする場合の説明図である。図９Ａは壁を破壊する前の状況であり、プレイヤキャラクタ９１が壁９２を壊そうとしている。図９Ｂは壁を破壊した直後の状況であり、破壊された壁９３が表示されている。破壊された壁９３の上に、破壊によって得たポイント９４が表示されている。図９Ｂの例では、得たポイント９４は、１００ポイントである。プレイヤキャラクタ９１が規定数の壁を破壊したらクリアとする。
この場合、クリア条件ｆ１４は、例えば、以下のように設定する。
タイプｔ：出現回数
検索範囲ｃ１：画像全体
判定用画像ｃ２：壁が破壊された直後の画像
回数ｃ４：規定数
出現位置ｃ５：任意

上述と同様な条件設定により、壁を規定数破壊した場合にクリアにする条件も設定可能である。また、敵キャラクタを規定数倒した場合に、クリアとする条件も同様である。

図１０は種々のゲームにおいて、プレイヤキャラクタの残機数の変化を検出する場合についての説明図である。図１０に示す例では、プレイヤキャラクタ１０１の残機数が画面左上の領域１０３に、アイコン１０２の表示数で示されている。アイコン１０２が３個表示されているから、残機数は３である。ここで、残機数が１増加し、残機数が４となったらクリアするものとする。
この場合、クリア条件ｆ１４は、例えば、以下のように設定する。
タイプｔ：出現数
検索範囲ｃ１：所定範囲（図１０では領域１０３）
判定用画像ｃ２：残機を示すアイコン画像（図１０ではアイコン１０２の画像）
個数ｃ６：増加と判定する個数（今回の例では４）

なお、上記の例では、クリアとする残機数を４と設定したが、開始時の残機数が不確定の場合は、開始時に残機数を取得し、その後、残機数が１増加することを検出すれば良い。そのような場合、個数の設定を符号付きの「＋１」などし、上記の場合との区別が行えるようにすれば良い。

また、プレイヤキャラクタ１０１がアイテムを取得したら、クリアとする場合も上記と同様である。図１０の画面右下には、アイテム表示領域１０４が３つ表示されている。一番左のアイテム表示領域１０４にはアイテム１０５が表示されている。これは、アイテム１０５をプレイヤキャラクタ１０１が取得したことを示している。アイテムが何も取得されていない状態から、アイテム１０５を取得した場合にクリアとする条件は、例えば、以下のように設定する。
タイプｔ：出現数
検索範囲ｃ１：所定範囲（図１０の例では全てのアイテム表示領域１０４）
判定用画像ｃ２：対象とするアイテムのアイコン画像（図１０では、アイテム１０５の画像）
個数ｃ６：取得したとみなす個数（図１０では１）

なお、特定のアイテムを取得した場合ではなく、任意のアイテムを取得した場合にクリアとするには、判定用画像ｃ２を全アイテムの数と設定すれば良い。

図１１はスコアが所定の値になったら、クリアとする場合の説明である。画面の所定領域１１２に、スコア１１３が表示されている。図１１の例ではスコア１１３は１００点である。ここで、スコア１１３が１５０点になったら、クリアとする条件は、例えば、以下の様に設定する。

タイプｔ：カウンタ
検索範囲ｃ１：所定範囲（図１１では領域１１２）
判定用画像ｃ２：数字を示す画像（「０」から「９」までの画像）
値ｃ７：増減と判定する値（図１１では１５０）
不等号ｃ８：＞、＜など（図１１では＝又は≧）

なお、残機数の変化を検知する場合において、残機数の表示がアイコンの個数ではない場合は、上記と同様な設定により、条件設定が可能である。床や壁を規定数破壊したことをクリア条件とする場合も、破壊数が数字で画面表示される場合は、上記と同様な設定により、条件設定が可能である。
また、判定用画像を「０」から「９」までの各数字の画像としたが、クリアとするスコア、残機数、破壊数の値が一定値であるならば、その一定値を表示されている画像のみを判定用画像として、条件タイプｔ「出現回数」で回数ｃ４を１と設定をすれば良い。

上述のように、様々なクリア条件ｆ１４を設定することが可能であるので、ゲームプログラム本来の条件とは異なるクリア条件ｆ４１で、ゲームをクリアすることが可能となる。例えば、野球ゲームにおいて、アウトを１つ取っただけでクリアとしたり、レーシングゲームにおいて、コースのショートカットに成功したらクリアとしたりすることが可能となる。

次に、本実施の形態に係るゲーム機１で行われる処理について説明する。図１２は本実施の形態に係るゲーム機１で行われる処理を説明するためのフローチャートである。プレイヤはゲーム機１の起動後、メニュー画面等から実行する機能を選択する。ゲーム機１の処理部１０は選択された機能から、従来動作を行うか否かを判定する（ステップＳ１）。ここで言う従来動作とは、従来技術のゲーム機が備えている機能を提供するための動作である。

従来動作を指示されていない場合（ステップＳ１でＮＯ）、処理部１０（読込部１０ａ）は二次記憶部１４より実行フローを読み込む（ステップＳ２）。処理部１０は実行フローに含まれるフローの数を変数ｎに設定し、ループカウンタｉを１に設定する（ステップＳ３）。

次に、処理部１０はエミュレータを起動する（ステップＳ４）。すなわち、二次記憶部１４に記憶してあるエミュレーションプログラムＰ２起動する。処理部１０はエミュレーションプログラムＰ２を実行することにより、エミュレート部として機能する。

続いて、処理部１０（読込部１０ａ）は実行フローからｉ番目のフローを読み込み、指定されているゲームプログラムを二次記憶部１４より読み込む（ステップＳ５）。処理部１０は実行状況情報を設定する（ステップＳ６）。処理部１０は実行状況情報に含まれる各種レジスタの値、メモリの状態を、それぞれエミュレータのレジスタ、メモリに設定する。

そして、処理部１０はエミュレータ上でゲームプログラムを実行する（ステップＳ７）。処理部１０（判定部１０ｂ）は停止条件判定を行う（ステップＳ８）。

図１３から図１５は、停止条件判定処理の処理手順を示すフローチャートである。制御部１０は実行中のフローであるｉ番目のフローのクリア条件を取得し、さらにクリア条件に含まれる検索範囲を取得する。制御部１０（画像取込部１０ｃ）は、取得した検索範囲に基づき、ゲームプログラムの出力画像から、マッチングに用いる部分画像を作成する（ステップＳ２１）。出力画像は一次記憶部１３に記憶されている。次に、制御部１０はクリア条件に含まれる判定用画像を取得する（ステップＳ２２）。制御部１０（マッチング部１０ｄ）は部分画像と判定用画像とによるマッチングを行う（ステップＳ２３）。制御部１０はマッチングを行ってない判定用画像が有るか否かを判定する（ステップＳ２４）。マッチングを行ってない判定用画像がある場合（ステップＳ２４でＹＥＳ）、制御部１０は処理をステップＳ２２に戻す。マッチングを行ってない判定用画像がない場合（ステップＳ２４でＮＯ）、制御部１０（画像判定部１０ｅ）はクリア条件の条件タイプを取得し、「出現回数」であるか否か判定する（ステップＳ２５）。条件タイプが「出現回数」である場合（ステップＳ２５でＹＥＳ）、フローチャートは図１４に進み、制御部１０はマッチング画像の出現位置が指定範囲内であるか否かを判定する（ステップＳ２６）。すなわち、検索範囲内にマッチング画像が出現し、なおかつ、そのマッチング画像がクリア条件に記載されている出現位置を含む所定範囲内に、位置しているか否かを判定する。指定範囲内にマッチング画像が位置していた場合（ステップＳ２６でＹＥＳ）、制御部１０は、クリア条件の回数が１であるか否か判定する（ステップＳ２７）。１である場合（ステップＳ２７でＹＥＳ）、制御部１０は戻り値に条件を満たす旨の値を設定し（ステップＳ２８）、処理を呼び出し元に戻す。

クリア条件の回数が１ではない場合（ステップＳ２７でＮＯ）、制御部１０は一次記憶部１３等に記憶してある出現回数を増加させる（ステップＳ２９）。制御部１０は出現回数が、クリア条件に指定されている所定回数に達したかを判定する（ステップＳ３０）。所定回数に達している場合（ステップＳ３０でＹＥＳ）、制御部１０は一次記憶部１３等に記憶してある出現回数を含むマッチングの履歴をクリアする（ステップＳ３１）。制御部１０は戻り値に条件を満たす旨の値を設定し（ステップＳ２８）、処理を呼び出し元に戻す。

所定回数に達していない場合（ステップＳ３０でＮＯ）、制御部１０は、二次記憶部１４等に既にマッチングの履歴があれば更新し、なければ、出現回数を含む履歴を新たに作成し記録する（ステップＳ３２）。履歴は出現回数以外に、マッチング画像の出現位置、現在時刻などのタイムスタンプ等を含めても良い。

そして、制御部１０は、戻り値に条件を満たさない旨の値を設定し（ステップＳ３３）、処理を呼び出し元に戻す。

指定範囲内にマッチング画像が位置していない場合（ステップＳ２６でＮＯ）、制御部１０は、戻り値に条件を満たさない旨の値を設定し（ステップＳ３３）、処理を呼び出し元に戻す。

図１３において、条件タイプが「出現回数」でない場合（ステップＳ２５でＮＯ）、制御部１０は条件タイプが「出現数」であるか否かを判定する（ステップＳ３４）。条件タイプが「出現数」である場合（ステップＳ３４でＹＥＳ）、制御部１０はマッチング結果より、判定用画像の出現数をカウントする（ステップＳ３５）。制御部１０は、出現数がクリア条件に設定されている個数以上であるか否かを判定する（ステップＳ３６）。設定されている個数以上である場合（ステップＳ３６でＹＥＳ）、フローチャートは図１４に進み、制御部１０は戻り値に条件を満たす旨の値を設定し（ステップＳ２８）、処理を呼び出し元に戻す。図１３に戻り、設定されている個数未満である場合（ステップＳ３６でＮＯ）、図１４に進み、制御部１０は、戻り値に条件を満たさない旨の値を設定し（ステップＳ３３）、処理を呼び出し元に戻す。

図１３において、条件タイプが「出現数」でない場合（ステップＳ３４でＮＯ）、フローチャートは図１５に進む。この場合、条件タイプは残りの「カウンタ」ということになる。制御部１０はマッチング結果より、対象となるカウンタ値を取得する（ステップＳ３７）。制御部１０はクリア条件に設定されている不等号を取得する（ステップＳ３８）。制御部１０はカウンタ値とクリア条件１４に設定してある閾値ｃ７とが取得した不等号の関係を満たすか否かを判定する（ステップＳ３９）。例えば、不等号が大なり記号「＞」であれば、カウンタ値が閾値ｃ７より大きいか否かを判定する。不等号の関係を満たす場合（ステップＳ３９でＹＥＳ）、制御部１０は戻り値に条件を満たす旨の値を設定し（ステップＳ２８）、処理を呼び出し元に戻す。不等号の関係を満たさない場合（ステップＳ３９でＮＯ）、制御部１０は、戻り値に条件を満たさない旨の値を設定し（ステップＳ３３）、処理を呼び出し元に戻す。

なお、制御部１０に、画像処理を高速に行えるＤＳＰ（Digital Signal Processor）やＧＰＵ(Graphics Processing Unit)を含めておき、部分画像の作成（ステップＳ２１）からマッチング（ステップＳ２３）までの処理を、ＤＳＰやＧＰＵに行わせることとしても良い。
また、上述したマッチング処理では、検索範囲が指定されている場合、出力画像からマッチングに用いる部分画像を作成することとしたが、部分画像の作成は必須ではない。検索範囲で判定用画像とのマッチングを行えば良い。

図１２に戻り、処理部１０は、停止条件判定処理の戻り値より、判定結果が停止条件を満たすものであったか否かを判定する（ステップＳ９）。停止条件を満たしていない場合（ステップＳ９でＮＯ）、処理部１０は処理をステップＳ７に戻す。停止条件を満たしている場合（ステップＳ９でＹＥＳ）、処理部１０（変更部１０ｆ）はエミュレータで実行中のゲームプログラムの実行状態を実行から停止に変更させる（ステップＳ１０）。処理部１０はループカウンタを１インクリメントする（ステップＳ１１）。処理部１０はループカウンタｉがフロー数ｎより大きいか判定する（ステップＳ１２）。ループカウンタｉがフロー数ｎより大きくない場合（ステップＳ１２でＮＯ）、処理部１０は、ｉ番目のフローで指定されているゲームプログラムが実行停止中のプログラムと同一であるか否かを判定する（ステップＳ１３）。同一である場合（ステップＳ１３でＹＥＳ）、処理部１０は処理をステップＳ６に戻す。同一でない場合（ステップＳ１３でＮＯ）、処理部１０は処理をステップＳ５に戻す。

ループカウンタｉがフロー数ｎより大きい場合（ステップＳ１２でＹＥＳ）、すなわち、実行フローに含まれる全てのフローについての処理が終了したので、処理部１０は、処理を終了する。また、ステップＳ１で従来動作であると判定された場合（ステップＳ１でＹＥＳ）、処理部１０は従来動作を行い（ステップＳ１４）、処理を終了する。

以上のように、本実施の形態に係るゲーム機１は、ゲームプログラムの動作途中におけるＣＰＵのレジスタ状態、メモの内容を読み込むことにより、ゲームプログラムを途中から動作させることが可能となる。また、予め定めたクリア条件が満たされたか否かを検知し、ゲームプログラムの実行状態の変更を行うので、実行中のゲームプログラムが本来のクリア条件を満たしていない場合でも、実行を停止し、他の箇所から再開することが可能である。それにより、既存ゲームプログラムの一部分を異なったクリア条件で、ユーザは楽しむことが可能となる。また、複数のゲームプログラムを組み合わせることにより、ユーザは様々なゲームを手軽に楽しむことが可能となる。

なお、実行フロー、ゲームプログラムは記録媒体装着部１２を介して記録媒体２又は無線通信部１６を介してネットワーク上のサーバ等から読み込んでも良い。
また、クリア条件の判定は、出力される画像を用いたが、エミュレータのメモリ等を調べて判定しても良い。例えば、スコア値、残機数などは所定の変数で保持しているのが通常であるからである。本発明おいて画像を用いているのは、複数のゲームプログラムに汎用的に対応可能とするためである。変数を調べる場合には、ゲームプログラムごとに変数定義を調査し、それらの変数がどのメモリ番地に記憶されているかを調べて、設定する必要がある。一方、画像を用いる場合は、画面イメージを取得できれば、容易に条件設定が可能である。

上述の実施の形態では、ゲームプログラムの実行開始箇所及びゲームのクリア条件を変えることにより、ゲームの新たな楽しみ方を提供した。さらに画面表示について、制御を加えて、新たな楽しみ方を提供する事が可能である。

＜色の変更＞
カラー表示を、グレースケール表示、セピアカラー表示に変更する。このことより、プレイヤが画面から受ける印象が変わり、従前のゲームとは違った楽しみ方を提供可能となる。
具体的な実現方法は、周知の技術により実現可能であるが、例えば、以下のようにして実現する。エミュレータがエミュレートしているＶＲＡＭに描画されている画像を書き換える。また、エミュレータのカラーパレットを書き換えることにより、カラー情報が書き変わった画像をエミュレータのＶＲＡＭに描画させる。

または、ゲーム機１のＶＲＡＭに描画されている画像を書き換える、ゲーム機１のカラーパレットを書き換えるという方法も実現可能である。

＜プレイヤキャラクタの行動範囲制限＞
ロールプレイングゲームやアドベンチャーゲームでは、１つの場面において、プレイヤキャラクタの行動可能な範囲が広いため、その行動範囲の制限することにより、より手軽にゲームを楽しむことが可能となる。
具体的な実現方法としては、以下の様なものが考えうる。ゲームプログラムにおいて、メインキャラクタの位置座標が、如何なる変数に保持されているかを解析する。また、行動範囲を制限した場合に、メインキャラクタが行動可能な位置座標の範囲を決定する。そして、エミュレータでゲームプログラムが実行されている場合に、管理プログラムは、メインキャラクタの位置座標を常に取得する。取得した値より、メインキャラクタが行動範囲を逸脱しそうな場合には、管理プログラムは、プレイヤが入力したメインキャラクタについての移動命令を、エミュレータに伝達しないようする。または、エミュレータを制御し、プレイヤが入力したメインキャラクタについての移動命令を、ゲームプログラムが取得できないようにする。
また、扉や抜け穴等により、別の場所に移動するのを制限する場合には、プレイヤキャラクタの位置に加えて、例えば、次のような処理を行うことが考えられる。別の場所に移動するのに伴い、背景となる画像データや、新たな場面の設定データ等が読み込まれるはずである。これらの別の場所に移動する際の処理は、一又は複数のサブルーチンで実現されているはずである。そこで、管理プログラムがエミュレータのメモリ等に展開されているプログラムを書き換え、別の場所に移動する際の処理を行うサブルーチンが呼ばれても、何らの処理をせずに、リターンするようにする。
以上のように、プレイヤキャラクタの行動範囲制限を行うことで、１つの場面のクリアに比較的長い時間を要するロールプレイングやアドベンチャーゲームであっても、より短い時間で、より手軽に楽しめるゲームとして、プレイヤに提供することが可能となる。

＜表示マスク処理＞
ゲーム画面の一部のみを表示させたり、一部のみを表示させないという処理を行うことにより、新たな楽しみ方を提供できる。
例えば、以下のようにして実現する。エミュレータがエミュレートしているＶＲＡＭに描画されている出力画像を書き換える。出力画像の画素数と同様なビットパターンを用意する。表示させる部分に１、表示させない部分０とする。出力画像とビットパターンとを論理積演算する。それにより、表示させる部分は変化がなく、表示させない部分は黒となり、所望の出力画像が得られる。

＜オブジェクトの輪郭強調表示＞
メインキャラクタ、敵キャラクタ、アイテム等のオブジェクトの輪郭を強調表示することで、新たな楽しみ方を提供できる。キャラクタの輪郭を強調表示することで、外観の印象を変えることが可能となる。また、敵キャラクタの輪郭を強調表示することで、プレイヤが敵キャラクタの登場に気づきやすくなり、ゲームの難易度を下げることが可能となる。また、アイテムが強調表示されていれば、プレイヤは見つけやすくなる。秘密の扉や、抜け穴も強調表示することでプレイヤが見つけやすくなる。それにより、ゲームの難易度を下げることが可能となる。このように、強調表示を用いてゲームの難易度を下げることにより、プレイヤは手軽にゲームを楽しむことが可能となる。
例えば、以下のようにして実現する。ゲームプログラムに含まれているキャラクタやアイテム等の画像データを輪郭強調表示された画像に書き換えれば、常に輪郭強調表示されることとなる。または、輪郭強調表示された画像を用意し、ゲームプログラムから読み出す際に用いられる画像へのポインタを書き換えることにより、通常表示の画像に変わって、輪郭強調表示された画像が表示されることとなる。

＜画面全体を拡大縮小＞
ゲーム画面全体を拡大又は縮小表示することで新たな楽しみ方を提供可能となる。拡大表示をした場合においては、キャラクタの表示が拡大されて迫力を増す一方で、表示される範囲は狭くなる。また、縮小した場合においては、キャラクタが見にくくなるおそれもがあるが、画面表示される範囲が広くなるので、ゲーム全体を見通し易くなる。
例えば、以下のように実現する。エミュレータがエミュレートしているＶＲＡＭに描画されている出力画像を書き換える。ＶＲＡＭに出力画像が格納される都度、当該出力画像を拡大又は縮小した画像に書き換え、ＶＲＡＭに格納し直す。

＜画面全体を左右反転＞
ゲーム画像全体を左右反転表示することで新たな楽しみ方を提供可能となる。例えば、シューティングゲームにおいて、キャラクタが右から左に進むことが基本となっているゲームであれば、左から右に進むことが基本となる。それにより、プレイヤの操作感は違ったものとなり、異なる楽しみ方が提供可能となる。
実現方法の一例は拡大縮小の場合と同様に、ＶＲＡＭに出力画像が格納される都度、当該出力画像を左右反転した画像に書き換え、ＶＲＡＭに格納し直す。

＜画像にモザイク＞
画面に表示される画像にモザイクを書けることにより、外観が異なった表示となる。それにより、敵キャラクタが把握しにくくなり、アイテムが区別しにくくなれば、ゲーム難易度を上げることが可能となる。
実現方法は上述の輪郭強調表示と同様で、ゲームプログラムに含まれているキャラクタやアイテム等の画像データをモザイク処理画像に書き換えれば、常にモザイク表示されることとなる。または、モザイク処理された画像を用意し、ゲームプログラムから読み出す際に用いられる画像へのポインタを書き換えることにより、通常表示の画像に変わって、モザイク処理された画像が表示されることとなる。

＜背景を周期的に非表示＞
ゲーム画面の背景を、周期的非表示にしたり、再表示したりするようにする。それにより、プレイヤはゲーム場面において、メインキャラクタの位置がわかり難くなる。場面によっては、プレイヤはメインキャラクタが進むべき方向を見失うこともあるから、ゲームの難易度を上げることが可能となる。
実現方法の一例は、輪郭強調表示と同様で、ゲームプログラムに含まれている背景画像の画像データを同一サイズの透過画像に書き換えれば、背景が非表示となる。背景画像を元に戻せば、再び、背景が表示されることとなる。または、背景画像と同一サイズの透過画像を用意し、ゲームプログラムから読み出す際に用いられる画像へのポインタを書き換えたり、書き戻したりすることにより、背景を非表示にしたり、再表示したりすることが可能となる。

＜一部キャラクタを非表示＞
一部のキャラクタを非表示にする。例えば、敵キャラクタの一部を非表示にすることにより、プレイヤはその存在に気付かず、非表示の敵キャラクタにより、メインキャラクタを失うこととなる。そのことにより、ゲームの難易度を上げることが可能となる。
実現方法の一例は、背景を非表示にする場合と同様であり、非表示にするキャラクタの画像と同一サイズの透過画像を用意し、画像データそのものを書き換えるか、ゲームプログラムから読み出す際に用いられる画像へのポインタを書き換えるかにより、実現される。

＜一部キャラクタの画像の変更＞
一部キャラクタの画像を変更する。例えば、敵キャラクタ画像をプレイヤが操作するメインキャラクタ画像と同じにする。戦っている場合などに、プレイヤはいずれが自分の操作する真のメインキャラクタであるのかという混乱を生じ、ゲームの難易度を上げることが可能となる。
実現方法の一例は、一部キャラクタを非表示にする場合と同様であり、変更するキャラクタの画像を、変更後の画像データに書き換えるか、ゲームプログラムから読み出す際に用いられる画像へのポインタを書き換えるかにより、実現される。

＜メインキャラクタの無敵化＞
プレイヤが操作するメインキャラクタを無敵化し、敵キャラクタから攻撃を受けたとしても、メインキャラクタが死なないようにする。それにより、プレイヤはクリアするまで、ゲームを継続して楽しむことが可能となる。 実現方法の一例は、次の通りである。ゲームプログラムが使用する仮想メモリから、メインキャラクタのダメージや受けた攻撃の度合いを示すＨＰ（Hit Point）、ダメージポイントといった値を保持する変数を監視し、攻撃を受けたことにより値が変化しても、その値をすぐに回復するような処理を行えば良い。

＜所定キーを入力固定＞
所定キーが常に入力された状態とする。そのことにより、プレイヤが操作せずともキー入力されている状態となる。例えば、所定キーが入力されていないとき、メインキャラクタは歩く速度で移動するが、所定キーが入力されているときは、歩くのではなくダッシュで移動するようになる場合において、当該所定キーを常に入力している状態を作り出す。そのことにより、メインキャラクタは常にダッシュでしか移動ができないため、ゲームの難易度を上げることが可能となる。
実現方法の一例は、次の通りである。エミュレータで所定のキーが入力されている状態をソフトウェア的に作り出することにより、エミュレータ上で実行されるゲームプログラムは所定キーが入力されているものとして動作することとなる。

以上のように、本実施の形態においては、ゲームプログラムをエミュレータ上で動作させていることから、エミュレータの仮想メモリを操作することにより、ゲームプログラムを多様な形態で動作させることが可能となり、プレイヤに新たなゲームの楽しみかたを提供することが可能となる。

なお、情報処理装置としてのゲーム機１は単一の装置として示したが、それに限らない。ゲーム機１の部分的な機能が複数の装置により提供され、それらの装置が協働することより、上述した機能を実現することとしても良い。

各実施例で記載されている技術的特徴（構成要件）はお互いに組合せ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものでは無いと考えられるべきである。本発明の範囲は、上記した意味では無く、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ ゲーム機（情報処理装置）
１０ 処理部
１０ａ 読込部
１０ｂ 判定部
１０ｃ 画像取込部
１０ｄ マッチング部
１０ｅ 画像判定部
１１ 出力部
１２ 記録媒体装着部
１３ 一次記憶部
１４ 二次記憶部
１５ 近距離無線通信部
１６ 無線通信部
２ 記録媒体
３ ディスプレイ
４ コントローラ

Claims (15)

1. 情報処理装置を、
   前記情報処理装置の構成とは異なる構成を持つ他の情報処理装置で実行可能なゲームプログラム及び前記ゲームプログラムの所定の実行箇所における実行状況を表す実行状況情報を読み込む読込手段と、
   前記実行状況情報を用いて、前記ゲームプログラムを前記所定の実行箇所からエミュレートするエミュレート手段と、
   前記エミュレートするゲームプログラムの実行状況を判定する判定手段と、
   前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記エミュレート手段の実行状態を変更する変更手段
   として前記情報処理装置を動作させる情報処理プログラム。
2. 前記ゲームプログラムによるゲームは複数の場面を含み、
   前記実行状況情報は、所定の場面における状態を示す情報であり、
   前記エミュレート手段は、前記所定の場面から処理を実行する
   請求項１に記載の情報処理プログラム。
3. 前記変更手段は、前記条件を満たすと判定した場合に、前記エミュレートしている場面についての処理を停止させる
   請求項２に記載の情報処理プログラム。
4. 前記読込手段は前記ゲームプログラムの複数の場面それぞれに対応する実行箇所における実行状況情報の中から前記エミュレートしている場面とは異なる一の場面に対応した実行状況情報を更に読み込み、
   前記変更手段は、前記エミュレート手段が実行中の場面についての処理を停止させ、前記エミュレートしている場面とは異なる一の場面についての処理を前記エミュレート手段に実行させる
   請求項３に記載の情報処理プログラム。
5. 前記読込手段は複数のゲームプログラムについての実行状況情報の中から一の場面に対応した実行状況情報を読み込む
   請求項４に記載の情報処理プログラム。
6. 前記実行状況情報は、ゲームプログラムがエミュレートされる際に使用される仮想メモリ全体のメモリイメージである
   請求項１乃至５のいずれか１項に記載の情報処理プログラム。
7. 前記予め定めた条件は、ゲームが予め定めた状況まで進行したか否かであり、
   前記判定手段は、
   前記エミュレート手段で実行するゲームプログラムが出力する出力画像及び予め定めた判定用画像のマッチングを行うマッチング手段、並びに
   マッチング手段によるマッチング結果から、前記ゲームプログラムに係るゲームが予め定めた状況まで進行したか否かを判定する画像判定手段を含む
   請求項１乃至６のいずれか１項に記載の情報処理プログラム。
8. 前記画像判定手段は、前記マッチング結果より前記出力画像に前記判定用画像が出現している場合に、前記ゲームプログラムの実行状況が条件を満たしたと判定する
   請求項７に記載の情報処理プログラム。
9. 前記画像判定手段は、前記出力画像における前記判定用画像の出現位置が所定範囲内である場合に、前記ゲームプログラムの実行状況が条件を満たしたと判定する
   請求項８に記載の情報処理プログラム。
10. 前記マッチング手段は、前記出力画像及び前記判定用画像のマッチングを繰り返し実行し、
    前記画像判定手段は、前記出力画像における前記判定用画像の出現位置が、予め定めた遷移をした場合に、前記ゲームプログラムの実行状況が条件を満たしたと判定する
    請求項８または９に記載の情報処理プログラム。
11. 前記マッチング手段は、前記出力画像及び前記判定用画像のマッチングを繰り返し実行し、マッチングを行う都度、前記出力画像における前記判定用画像の出現個数又は前記出力画像に含まれる数値を取得し、
    前記画像判定手段は、前記出力画像における前記判定用画像の出現個数又は数値が所定の条件を満たした場合に、前記ゲームプログラムの実行状況が条件を満たしたと判定する
    請求項８に記載の情報処理プログラム。
12. 前記所定の条件を満たした場合とは、前記出現個数又は前記出力画像に含まれる数値が、先行するマッチングにより取得した出現個数又は数値から所定の変化をした場合である
    請求項１１に記載の情報処理プログラム。
13. 自らとは構成の異なる構成を持つ他の情報処理装置で実行可能なゲームプログラム及び前記ゲームプログラムの所定の実行箇所における実行状況を表す実行状況情報を読み込む読込部と、
    前記実行状況情報を用いて、前記ゲームプログラムを前記所定の実行箇所からエミュレートするエミュレート部と、
    前記エミュレートするゲームプログラムの実行状況を判定する判定部と、
    前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記エミュレート部の実行状態を変更する変更部と
    を備える情報処理装置。
14. 自らとは構成の異なる構成を持つ他の情報処理システムで実行可能なゲームプログラム及び前記ゲームプログラムの所定の実行箇所における実行状況を表す実行状況情報を読み込む読込部と、
    前記実行状況情報を用いて、前記ゲームプログラムを前記所定の実行箇所からエミュレートするエミュレート部と、
    前記エミュレートするゲームプログラムの実行状況を判定する判定部と、
    前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記エミュレート部の実行状態を変更する変更部と
    を備える情報処理システム。
15. 情報処理装置で実行される情報処理方法であって、
    自らとは構成の異なる構成を持つ他の情報処理装置で実行可能なゲームプログラム及び前記ゲームプログラムの所定の実行箇所における実行状況情報を読み込む読込ステップと、
    前記実行状況情報を用いて、前記ゲームプログラムを前記所定の実行箇所からエミュレートするエミュレートステップと、
    前記ゲームプログラムの実行状況を判定する判定ステップと、
    前記ゲームプログラムの実行状況が予め定めた条件を満たすと判定した場合に、前記ゲームプログラムの実行状態を変更する変更ステップ
    を含む情報処理方法。

Images