JPH11319318A

JPH11319318A - ゲーム実行管理装置およびゲーム実行管理方法

Info

Publication number: JPH11319318A
Application number: JP10127629A
Authority: JP
Inventors: Atsushi Kamoki; 厚志鴨木
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1998-05-11
Filing date: 1998-05-11
Publication date: 1999-11-24

Abstract

(57)【要約】【課題】ゲームに必要なプログラムメモリ容量を大幅
に削減させるとともに一つのソフトで複数のプログラム
を同時に実行できるようにすること。【解決手段】ゲーム別に進行状態を記憶するためのゲ
ーム進行状態記憶部１Ｊを用意しておき、ゲーム実行の
際に、実行すべきゲームに対応させてゲーム別に記憶さ
れた進行状態を切替スイッチ１Ｋで切り替え、その切り
替えられたゲームの進行状態をプレーヤが操作できない
固定ゲーム場１Ａ／可動ゲーム場１Ｂとプレーヤが操作
できる固定プレーヤ場１Ｃ／可動プレーヤ場１Ｄとに分
けて管理し、ゲーム整合処理部１Ｅによりゲーム場とプ
レーヤ場間の整合をとりながら、その管理されるゲーム
場とプレーヤ場のゲームの進行状態を合成してゲーム表
示部１Ｆに表示する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、移動通信機器等
の電子機器に搭載されるゲームの実行を管理するゲーム
実行管理装置およびゲーム実行管理方法に関し、詳細に
は、複数のゲームを統合して処理する技術に関する。

【０００２】

【従来の技術】まず、ゲーム端末や移動物体通信端末に
搭載される従来のゲーム実行管理装置の構成について説
明する。図４５は従来のゲーム実行管理装置を機能的に
示すブロック図である。図４５において、２０Ａはあら
かじめ用意されたゲームＡプログラム〜ゲームＸプログ
ラムを記憶するゲーム記憶部、２０ＢはゲームＡプログ
ラム〜ゲームＸプログラムのいずれか一つを選択するゲ
ーム選択部、２０Ｃはゲーム選択部２０Ｂで選択された
ゲームプログラムの実行を制御するプログラム実行制御
部、２０Ｄはプログラム実行制御部２０Ｃによるゲーム
を操作したりゲーム実行状態を表示するゲーム表示／操
作部、２０Ｅはゲーム進行状況を記憶するゲーム進行状
況記憶部、そして、２１Ａ〜２１Ｘはそれぞれゲーム記
憶部２０Ａに記憶されるゲームＡプログラム〜ゲームＸ
プログラムを示している。

【０００３】つぎに上記ゲーム実行管理装置の動作につ
いて説明する。図４６は従来のゲーム実行管理装置の動
作を説明するフローチャートであり、図４７，図４８は
それぞれゲームＡ，ゲームＢの動作を説明するフローチ
ャートである。なお、図４６〜図４８の処理は、プログ
ラム実行制御部２０Ｃにより制御され、ここの動作は各
部で行われるものとする。

【０００４】図４６において、まず、ゲーム記憶部２０
Ａから所要のゲームが選択される（ステップＳ２０
１）。この場合、ゲーム表示／操作部２０Ｄの操作に応
じてゲーム選択部２０Ｂにより複数のゲームプログラム
の中から実行すべきゲームプログラムが一つだけ選択さ
れる。これは、ゲームＡ，ゲームＢ，ゲームＣ…ゲーム
Ｘがそれぞれ別個のゲームプログラムであるためであ
る。

【０００５】そして、ステップＳ２０１で選択されたゲ
ームだけが実行を開始する。それぞれのゲームは、ゲー
ム毎に独立の処理を実行する。例えば、ゲームＡが選択
されると、そのゲームＡプログラムだけが実行され（ス
テップＳ２０１Ａ１）、またはゲームＢが選択された場
合にはゲームＢプログラムだけが実行される（ステップ
Ｓ２０１Ａ２）。同様に、ゲームＣ，ゲームＤ…ゲーム
Ｘについても、それぞれのゲームプログラムだけが実行
される（ステップＳ２０１Ａ３，ステップＳ２０１Ａ４
…ステップＳ２０１ＡＸ）。このようにして選択した
ゲームプログラムだけが実行された後、処理は終了す
る。

【０００６】例えばゲームＡプログラムが実行される
と、ゲームＡだけの独立した動作が開始される。ここ
で、ゲームＡをテトリス（登録商標）などの移動物体を
処理するゲームとして説明する。図４７において、まず
ゲームＡが初期化される（ステップＳ３０１）。すなわ
ち、ゲームＡの選択で始めてそのゲームＡ単独の動作が
開始されることになる。ゲームＡ開始後、キー入力が行
われると（ステップＳ３０２）、そのキー入力の応じて
移動物体の移動処理（ステップＳ３０３）、移動物体の
着地処理が行われる（ステップＳ３０４）。

【０００７】その着地地点に移動物体が表示され（ステ
ップＳ３０５）、そのときの進行状況がゲーム進行状況
記憶部２０Ｅに記憶される（ステップＳ３０６）。以上
のステップＳ３０２〜ステップＳ３０６までの処理はゲ
ーム表示／操作部２０Ｄにより終了操作が行われるまで
繰り返し実行される（ステップＳ３０７）。

【０００８】また、ゲームＢについても移動物体を移動
制御するような内容であれば、例えば図４８のように処
理が実行される。すなわち、図４８において、まずゲー
ムＡのときと同様にゲームＢが初期化される（ステップ
Ｓ４０１）。これにより、ゲームＢの選択で始めてその
ゲームＢ単独の動作が開始されることになる。ゲームＢ
開始後、キー入力が行われると（ステップＳ４０２）、
そのキー入力の応じて移動物体の移動処理（ステップＳ
４０３）、移動物体の着地処理が行われる（ステップＳ
４０４）。

【０００９】その着地地点に移動物体が表示され（ステ
ップＳ４０５）、そのときの進行状況がゲーム進行状況
記憶部２０Ｅに記憶される（ステップＳ４０６）。以上
のステップＳ４０２〜ステップＳ４０６までの処理はゲ
ーム表示／操作部２０Ｄにより終了操作が行われるまで
繰り返し実行される（ステップＳ４０７）。

【００１０】

【発明が解決しようとする課題】従来のゲーム実行管理
装置は以上のように構成しているので、ゲーム製作者は
複数のゲームプログラムを開発する必要があった。これ
により、以下に示す問題点があった。すなわち、（１）複数のゲームＡ〜Ｘを別々のソフトウェアで実現
していたために、組み込むゲームの数が増えれば、それ
に比例して多くのプログラムメモリを必要としていた。

【００１１】（２）ゲームを実現するために、ゲームの
ルール（遊び方）をプログラム言語を使ってプログラム
する必要があったため、ゲーム毎に別々にソフトウェア
を開発する必要があった。（３）ゲームを実行できる装
置の状態（待ち受け中、スタンバイ中など）が制限され
ていた。すなわち、移動通信端末に組み込まれたゲーム
の場合には、通話中などの通信機能を使用している際に
ゲームを実行することができないとともに、ゲーム実行
中に着信などのゲーム以外のイベントが発生した場合に
は、現在実行中のゲームが中断または中止されていた。

【００１２】（４）従来のゲームエンジンはゲームプロ
グラムと明確に分離されていなかったため、複数／複数
種類のゲームを同時に実行することができなかった。
（５）ゲームを実現するために、ゲームのルール（遊び
方）をプログラム言語を使ってプログラムしていたた
め、ゲームの機能や構成を変更する場合には、再度プロ
グラムし直す必要があった。（６）プレーヤ（人）がゲ
ーム環境を作成することができず、また、従来の移動通
信端末のゲーム機能は、あらかじめ決められた表示デバ
イスや操作キーでしか実現できない場合が多かった。

【００１３】この発明は、上記のような問題を解消する
ためになされたもので、複数のゲームを統合化すること
で、ゲームに必要なプログラムメモリ容量を大幅に削減
させるとともに複数のプログラムを同時に実行させるこ
とが可能なプログラム実行管理装置およびプログラム実
行管理方法を得ることを目的とする。

【００１４】

【発明を解決するための手段】上述した課題を解決し、
目的を達成するため、この発明に係るゲーム実行管理装
置は、あらかじめ用意された複数のゲームについて各ゲ
ームの実行状態を管理するゲーム実行管理装置におい
て、前記複数のゲームについてゲーム別に進行状態を記
憶するゲーム別記憶手段と、ゲーム実行の際に、実行す
べきゲームに対応させて前記ゲーム別記憶手段に記憶さ
れたゲーム別の進行状態を切り替えるゲーム別進行状態
切替え手段と、ゲーム実行の際に、前記ゲーム別進行状
態切替え手段で切り替えられたゲームの進行状態をプレ
ーヤが操作できないゲーム場とプレーヤが操作できるプ
レーヤ場とに分けて管理する場管理手段と、ゲーム実行
の際に、前記場管理手段で管理されるゲーム場とプレー
ヤ場のゲームの進行状態を合成して表示するゲーム表示
手段と、を備えたことを特徴とする。

【００１５】この発明によれば、ゲーム実行の際に、実
行すべきゲームに対応させてゲーム別に記憶された進行
状態を切り替え、その切り替えられたゲームの進行状態
をプレーヤが操作できないゲーム場とプレーヤが操作で
きるプレーヤ場とに分けて管理し、その管理されるゲー
ム場とプレーヤ場のゲームの進行状態を合成して表示す
るようにしたので、複数のゲームが統合化されてゲーム
別にプログラムを用意する必要がなく、これにより、ゲ
ームに必要なプログラムメモリ容量を大幅に削減させる
とともに一つのソフトで複数のプログラムを同時に実行
させることが可能である。

【００１６】つぎの発明に係るゲーム実行管理装置は、
ゲーム実行の際に、前記場管理手段で管理されるゲーム
場とプレーヤ場との間でゲームの進行状態に矛盾があっ
た場合にゲームの整合をとるゲーム整合手段をさらに備
えたことを特徴とする。

【００１７】この発明によれば、ゲーム場とプレーヤ場
との間でゲームの進行状態に矛盾があった場合にゲーム
の整合をとるようにしたので、ゲーム場とプレーヤ場間
の矛盾が解消される。

【００１８】つぎの発明に係るゲーム実行管理装置は、
前記ゲーム別記憶手段には、ゲーム別に、部分的にゲー
ムルールが任意に記述されることを特徴とする。

【００１９】この発明によれば、ゲーム別に、部分的に
ゲームルールを任意に記述するようにしたので、ゲーム
毎に独立したソフトウェアを開発する必要がなく、大掛
かりな開発作業が不要となる。

【００２０】つぎの発明に係るゲーム実行管理装置は、
前記ゲーム別記憶手段には、ゲーム別に、前記ゲーム場
およびプレーヤー場の各構成要素が任意に設定されるこ
とを特徴とする。

【００２１】この発明によれば、ゲーム別に、ゲーム場
およびプレーヤー場の各構成要素を任意に設定するよう
にしたので、設定の応じてオリジナルのゲームを作成す
ることが可能である。

【００２２】つぎの発明に係るゲーム実行管理装置は、
前記ゲーム別記憶手段には、ゲーム別に、ゲーム画面形
状と任意のゲーム画面構成が任意に設定されることを特
徴とする。

【００２３】この発明によれば、ゲーム別に、ゲーム画
面形状と任意のゲーム画面構成を任意に設定するように
したので、ゲームの制御に影響を与えずに各ゲームに対
して独立して所望の環境を用意することができ、これに
より、ゲーム画面形状やゲーム画面構成に依存しないゲ
ーム実行管理を実現することが可能である。

【００２４】つぎの発明に係るゲーム実行管理装置は、
前記ゲーム別記憶手段には、ゲームの実行中にゲーム場
面形状およびゲーム作用が任意に変更されることを特徴
とする。

【００２５】この発明によれば、ゲームの実行中にゲー
ム場面形状およびゲーム作用を任意に変更するようにし
たので、ゲーム実行中のゲーム場面の変化に影響されな
いゲーム実行管理を実現することが可能である。

【００２６】つぎの発明に係るゲーム実行管理装置は、
ゲーム中断時には、当該ゲームの進行状態を前記ゲーム
別記憶手段に待避させ、ゲーム復元時には、中断によっ
て前記ゲーム別記憶手段に待避されたゲームの進行状態
を読み出して実行状態を復元することを特徴とする。

【００２７】この発明によれば、ゲーム中断時には、当
該ゲームの進行状態を待避させ、ゲーム復元時には、中
断によって待避されたゲームの進行状態を読み出して実
行状態を復元するようにしたので、中断があっても中断
時の進行状態でゲームを再開することができ、これによ
り、複数のゲームを同時に実行することが可能である。

【００２８】つぎの発明に係るゲーム実行管理装置は、
前記ゲーム実行管理装置は移動通信端末に適用され、ゲ
ーム実行中に前記移動通信端末でゲーム以外の処理が操
作された場合、ゲームを中断して実行する際に、当該ゲ
ームの進行状態を前記ゲーム別記憶手段に待避させ、前
記ゲーム以外の処理が終了した際に、中断によって前記
ゲーム別記憶手段に待避されたゲームの進行状態を読み
出してゲームを再開することを特徴とする。

【００２９】この発明によれば、ゲーム実行管理装置を
移動通信端末に適用して、ゲーム実行中に移動通信端末
でゲーム以外の処理が操作された場合、ゲームを中断し
て実行する際に、当該ゲームの進行状態を待避させ、ゲ
ーム以外の処理が終了した際に、中断によって待避され
たゲームの進行状態を読み出してゲームを再開するよう
にしたので、ゲーム以外の処理が割り込んでも、その後
に中断時の進行状態でゲームを再開することができ、こ
れにより、ゲームと他の処理とを同時に実行することが
可能である。

【００３０】つぎの発明に係るゲーム実行管理装置は、
ゲームの実行を操作するゲーム操作手段と、前記ゲーム
操作手段およびゲーム表示手段を接続するインタフェー
ス手段とをさらに有し、前記インタフェース手段は、前
記ゲーム操作手段と前記ゲーム表示手段との組を複数組
接続可能に設けられ、前記ゲーム別記憶手段は、ゲーム
別に、前記インタフェース手段に接続可能な組数分のゲ
ームの進行状態を記憶することを特徴とする。

【００３１】この発明によれば、ゲーム操作手段とゲー
ム表示手段との組を複数組接続しても、ゲーム別に、各
組のゲームの進行状態を記憶するようにしたので、複数
のプレーヤが離れた場所でも一緒にゲームを操作するこ
とが可能である。

【００３２】つぎの発明に係るゲーム実行管理方法は、
あらかじめ用意された複数のゲームについて各ゲームの
実行状態を管理するゲーム実行管理装置に適用されるゲ
ーム実行管理方法において、前記ゲーム実行管理装置は
メモリを有し、ゲームの進行状態は、プレーヤが操作で
きないゲーム場とプレーヤが操作できるプレーヤ場とに
分けてゲーム別に前記メモリに管理され、前記複数のゲ
ームうちのいずれかのゲームを実行している際に、プレ
ーヤからの１回の操作入力に応じて前記ゲーム場とプレ
ーヤ場の進行状態をそれぞれ処理する第１工程と、前記
第１工程で処理された進行状態を合成表示する第２工程
と、を含んだことを特徴とする。

【００３３】この発明によれば、複数のゲームのうちの
いずれかのゲームを実行している際に、プレーヤからの
１回の操作入力に応じてプレーヤが操作できないゲーム
場とプレーヤが操作できるプレーヤ場の進行状態をそれ
ぞれ処理してその結果である進行状態を合成表示する工
程にしたので、複数のゲームが統合化されてゲーム別に
プログラムを用意する必要がなく、これにより、ゲーム
に必要なプログラムメモリ容量を大幅に削減させるとと
もに一つのソフトで複数のプログラムを同時に実行させ
ることが可能である。

【００３４】つぎの発明に係るゲーム実行管理方法は、
前記第１工程で処理された進行状態について前記ゲーム
場とプレーヤ場間の合成表示上に不整合があるか否か判
断する第３工程と、前記第３工程により不整合ありとい
う判断結果が得られた場合、前記ゲーム場とプレーヤ場
の各進行状態に対して整合処理を実行する第４工程と、
をさらに含んだことを特徴とする。

【００３５】この発明によれば、ゲーム場とプレーヤ場
間の合成表示上に不整合があれば、ゲーム場とプレーヤ
場の各進行状態に対して整合処理を実行する工程を含む
ようにしたので、ゲーム場とプレーヤ場間の矛盾が解消
される。

【００３６】つぎの発明に係るゲーム実行管理方法は、
前記第２工程で前記ゲーム場とプレーヤ場の進行状態を
合成表示した後に、前記メモリに前記第１工程により処
理された前記ゲーム場とプレーヤ場の進行状態を保持す
る第５工程をさらに含んだことを特徴とする。

【００３７】この発明によれば、ゲーム場とプレーヤ場
の進行状態を合成表示した後に、メモリにゲーム場とプ
レーヤ場の進行状態を保持する工程を含むようにしたの
で、他のゲームあるいは他の処理に一時的に移行して
も、中断時の進行状態でゲームを再開することが可能で
ある。

【００３８】

【発明の実施の形態】以下に添付図面を参照して、この
発明に係るゲーム実行管理装置およびゲーム実行管理方
法の好適な実施の形態を詳細に説明する。

【００３９】まず、この発明の一実施の形態によるゲー
ム実行管理装置の原理について説明する。図１はこの発
明の一実施の形態によるゲーム実行管理装置を機能的に
示すブロック図である。

【００４０】図１において、１Ａはゲームを実行する場
合の部分処理部として機能する固定ゲーム場、１Ｂはゲ
ームを実行する場合の部分処理部および全体処理部とし
て機能する可動ゲーム場、１Ｃはゲームを実行する場合
の部分処理部，全体処理部および移動物体の移動処理部
として機能する固定プレーヤ場、１Ｄはゲームを実行す
る場合の部分処理部，全体処理部および移動物体の移動
処理部として機能する可動プレーヤ場、１Ｅは１または
複数のゲーム間の整合性をとるゲーム整合処理部、１Ｆ
は実行中のゲームを可視表示するゲーム表示部、１Ｇは
実行対象のゲームについてその進行を指示するゲーム操
作部、１Ｈはゲーム実行に付帯する音声を出力する音響
効果部、１Ｉは複数の物理的（電磁的、機械的）インタ
ーフェイスとしてゲーム整合処理部１Ｅ，音響効果部１
Ｈ，ゲーム表示部１Ｆおよびゲーム操作部１Ｇを接続す
るインタフェース（Ｉ／Ｆ）部、１Ｊは１以上のゲーム
進行状態を記憶する複数のゲーム進行状況記憶部、１Ｋ
は実行中のゲーム進行状態記憶部１Ｊのいずれか一つを
選択して切り替える切替スイッチをそれぞれ示してい
る。

【００４１】以上の構成において、このゲーム実行管理
装置の原理は、自立分散制御的な考え方を用いる。すな
わち、制御内容および制御方法を単純化、局所化するた
めに、制御対象（ゲーム）を事象の発生要因とそれに対
する制御の観点から以下のように細分化する。

【００４２】ゲーム機能状況を、プレーヤ（人）が制御
できる部分と制御できない部分に分離し、さらにそれら
を変化のある部分と変化の無い固定的な部分とに分離す
る。まず、プレーヤが制御できない部分を「ゲーム
場」、プレーヤがキー操作などによって制御できる部分
を「プレーヤ場」と呼ぶこととする。したがって、上記
構成において、ゲーム場としては固定ゲーム場１Ａおよ
び可動ゲーム場１Ｂが該当し、プレーヤ場としては固定
プレーヤ場１Ｃおよび可動プレーヤ場１Ｄが該当する。

【００４３】また、動きの無い部分（上述した変化のな
い部分）を「固定」、動きのある部分（上述した変化の
ある部分）を「可動」と呼ぶ。したがって、固定部分と
しては固定ゲーム場１Ａおよび固定プレーヤ場１Ｃが該
当し、可動部分としては可動ゲーム場１Ｂおよび可動プ
レーヤ場１Ｄが該当する。このようにして、制御対象
は、固定ゲーム場１Ａ、可動ゲーム場１Ｂ、固定プレー
ヤ場１Ｃ、可動プレーヤ場１Ｄの４つの機能属性部分に
分離される。これにより、事象の発生とそれに対する処
理をそれぞれの機能毎に独立に制御する。

【００４４】つづいて、各場の例を示す。固定ゲーム場
１Ａは、ゲーム場面の枠（ゲーム画面の形状）を規定す
るものである。可動ゲーム場１Ｂは、ゲームの進行にあ
わせ（ゲームの都合で）ゲーム場面を変化させるもので
ある。また、固定プレーヤ場１Ｃは、プレーヤ（人）が
操作可能または移動可能であるが、動作範囲（動作方
向）が限定されるもの（例えば、ブロック崩しのラケッ
ト）である。可動プレーヤ場１Ｄは、プレーヤが操作可
能または移動可能で動作範囲（動作方向）が限定されな
いもの（例えば、テニスゲームのボール）である。

【００４５】以上の固定ゲーム場１Ａ、可動ゲーム場１
Ｂ、固定プレーヤ場１Ｃ、可動プレーヤ場１Ｄの各構成
要素は、事象の発生要因の特質にあわせ、それぞれ独立
に他の機能部分の動作を参照すること無しに動作を試み
る。その動作の「試み：動作要求」は、うまく成功する
場合と失敗する場合がある。

【００４６】まず「うまく成功する場合」とは、その
「動作」が、他の機能部分の動作の「試み」と衝突して
いない場合である。この場合には、「試み」どおり動作
を実行する。また「失敗する場合」とは、他の機能部分
の動作の「試み」と衝突する場合である。前記「衝突」
とは、機能部分の「試み」によって生じるゲーム画面が
他のゲーム画面と表示的に重なることである。つまり、
画素が重なって表示出来ない場合を指す。

【００４７】この場合には、ゲーム場およびプレーヤ場
の状況を、ゲームルールに従い整合させ管理するため、
ゲーム整合処理を行う。このゲーム整合処理とは、各機
能部分の動作の「試み」を優先順位に従って、優先順位
の高いものを優先実行し、優先順位の低いものを実行保
留または要求取下げし、「衝突」状態を解消することで
ある。以上により、ゲーム場面の変化が各機能部分の動
作の「接触」を契機に発生するととらえ、その結果生じ
る「衝突」を解消することによってゲーム場面を進行さ
せることができる。

【００４８】また、図１の例では、ゲーム場面は４つの
場（固定ゲーム場１Ａ、可動ゲーム場１Ｂ、固定プレー
ヤ場１Ｃおよび可動プレーヤ場１Ｄ）に分割されている
が、すべてのゲームを４つに分割しなければならないわ
けではない。ゲームによっては２つ若しくは３つで構成
できるゲームもある。ただし、構成要素一つなら従来方
式となるため、ゲーム場面の分割は、事象の発生要因と
それに対する制御を独立化させることに目的があり、同
じゲームでも違った（複数の）ゲーム場面の分割が可能
である。

【００４９】また、ゲーム表示部１Ｆは、ゲームエンジ
ンによって、ゲーム場（移動、固定）とプレーヤ場（可
動、移動）のゲームの状況を合成表示する。プレーヤ
は、ゲーム表示部１Ｆで表示されるときに初めて合成さ
れ、ゲームの状況となってプレーヤ（人）に認識され
る。ゲーム場とプレーヤ場はお互いに作用を及ぼし合う
が、それぞれ独立にゲーム進行を制御している。

【００５０】ゲーム表示部１Ｆ、ゲーム操作部１Ｇ、音
響効果部１ＨなどのＨＭＩ（ヒューマン・マシン・イン
タフェース）は、インターフェース（Ｉ／Ｆ）部１Ｉを
通してゲーム本体に接続される。対戦型で２つ以上のゲ
ーム操作部で２人でゲームをしたり、場所を離れて２つ
以上のゲーム操作部、ゲーム表示部でゲームをすること
もできる。対戦型でゲームを実行する場合、本方式によ
れば、ゲーム管理部は一つでよいので、対戦型ゲームを
容易に構成できる。本体は一つで、ゲーム表示部・ゲー
ム操作部が２つ以上ある構成となる。

【００５１】また、ゲーム操作部１Ｇは、ゲームの種類
を選択したり電源の制御を行ったりする全体的な部分
と、ゲーム毎にゲーム動作に関するキー操作を記録する
部分の２つをもつ。前者の全体的な部分は、全ゲームに
共通的な部分である。本方式には重要な部分でないので
割愛する。また後者の記録部分は、インターフェイス部
１Ｉからキーデータを読み取り、それをキーデータ格納
エリアに格納するだけで、実際のゲーム画面の変化・移
動は行わない。実際のキー操作処理は、各機能属性部分
がキーデータ格納エリアの情報を読み込んで実行する。

【００５２】また、音響効果部１Ｈはゲームの進行状況
に合せて、効果音を発生させる部分である。ゲーム操作
部１Ｇの操作音や、可動プレーヤ場との衝突音や爆発
音、得点が入った時のゲームを盛り上げる効果音などで
ある。

【００５３】また、ゲーム進行状態記憶部１Ｊは、固定
ゲーム場１Ａ、可動ゲーム場１Ｂ、固定プレーヤ場１
Ｃ、可動プレーヤ場１Ｄ、得点状況、操作キーデータ等
のゲームの進行に必要な情報を記憶する部分（ゲーム進
行状態記憶メモリ）で、ゲームの種類毎に複数存在す
る。これらは、ゲーム進行状態記憶部１Ｊの切替スイッ
チ１Ｋによって切替えられる。スイッチを切替えると、
ゲーム進行状態がゲーム進行状態記憶部１Ｊにセーブさ
れ、ゲーム進行状態記憶部１Ｊの中から、実行したいゲ
ームのゲーム進行状態が読み出され、ゲーム進行状態記
憶部１Ｊに復元される。復元されたゲームは即実行可能
となる。

【００５４】また、ゲーム進行状態記憶部１Ｊの切替ス
イッチ１Ｋは、複数のゲームを実行を切替える部分であ
る。スイッチの切替えが発生する要因としては、以下の
ようなものがある。すなわち、（１）ゲーム実行中に他
の仕事が発生し、ゲームを中断、他の仕事を実行、
（２）ゲーム実行中に他の仕事が発生し、ゲームと同時
実行、（３）ゲーム実行をプレーヤ（人）の意思で中
断、ゲーム状態を保存、（４）中断しているゲームを再
開、そして、（５）２つ以上のゲームを同時実行、であ
る。

【００５５】つぎに、図１に示したゲーム実行管理装置
の動作原理について説明する。図１において、ゲームプ
レーヤ（人）は、ゲーム表示部１Ｆでゲームの進行状態
を見ながら、ゲーム操作部１Ｇにて操作を行い、音響効
果部１Ｈで音を聞きながらゲームを進行させる。これら
ヒューマンインターフェイス（ＨＭＩ）部分は、インタ
ーフェース部１Ｉのよって、下記ゲーム本体と接続され
る。インターフェース部１Ｉは、複数の物理的（電磁
的、機械的）インターフェイス手段を持ち、これに前記
ゲーム制御部や音響効果部、ゲーム表示部を接続するこ
とにより、複数の人間または２箇所以上での場所でのゲ
ーム実行（対戦型ゲーム実行）を可能としている。

【００５６】ゲーム場面の状況は、固定ゲーム場１Ａ、
可動ゲーム場１Ｂ、固定プレーヤ場１Ｃおよび可動プレ
ーヤ場１Ｄの４つの機能属性部分に分解して、ゲーム毎
に（１Ｊ）メモリ装置にデータとして記憶される。これ
ら４つの機能属性部分は、プレーヤ（人）の目に映る画
像（イメージ）を直接または間接（記号）的な形で記録
している。これら４つの機能属性部分はそれぞれ独立に
ゲーム進行状況を管理するが、機能属性部分の間に矛盾
が生じた場合にはゲーム整合処理部１Ｅによって処理さ
れゲームとして統合されている。

【００５７】ゲーム整合処理部１Ｅは、前記４つの機能
属性部分が発行する処理要求を調べて不整合が発生して
いれば（処理要求の実現に矛盾があれば）、優先順位に
したがって必要な属性部分に動作許可を与える。優先順
位は、一般的にはプレーヤ（人）より、バンカー（親）
のほうが強くするものなので、ゲーム場＞プレーヤ場に
設定する。

【００５８】同様に、移動物体は固定画面の枠内でしか
動けないので、優先順位は、固定場面＞可動場面であ
る。つまり、デフォルトの優先順位は、固定ゲーム場＞
可動ゲーム場＞固定プレーヤ場＞可動プレーヤ場とな
る。しかし、ゲームの特質にあわせ、設定により優先順
位を変更することも可能である。得点状態、ゲームの進
行状態はゲーム毎にゲーム進行状態記憶部１Ｊに記憶さ
れる。

【００５９】ゲームの進行状態は、上記４つの機能属性
部分の他、実行中のゲームの種類、得点・失点状態、ゲ
ームの実行形態、などである。ゲーム進行状態記憶部１
Ｊは、固定ゲーム場１Ａ、可動ゲーム場１Ｂ、固定プレ
ーヤ場１Ｃ、可動プレーヤ場１Ｄの進行状況などを記憶
するものでゲームの種類毎に１組存在する。したがっ
て、ゲームの数だけゲーム進行状態記憶部１Ｊが必要と
なる。

【００６０】ゲームを途中で中断する場合には、固定ゲ
ーム場１Ａ、可動ゲーム場１Ｂ、固定プレーヤ場１Ｃ、
可動ゲーム場１Ｄの進行状況をゲーム進行状態記憶部１
Ｊに記録する。逆に中断状態から再開する場合には、ゲ
ーム進行状態記憶部１Ｊから、再開したいゲームの固定
ゲーム場１Ａ、可動ゲーム場１Ｂ、固定プレーヤ場１
Ｃ、可動プレーヤ場１Ｄの進行状況を復元する。ゲーム
進行状況記憶部１Ｊは、固定ゲーム場１Ａ、可動ゲーム
場１Ｂ、固定プレーヤ場１Ｃおよび可動ゲーム場１Ｄの
組（制御ブロック）をゲームの種類だけ複数保持するこ
とになる。

【００６１】ゲーム進行状態記憶部１Ｊは、リアルタイ
ム制御システムなどのタスクコントロールブロック（Ｔ
ＣＢ）に相当する管理部分を含む。ゲーム進行状態記憶
部１Ｊへの待避／復旧は、実際にはメモリコピーではな
くて、リアルタイム制御システムのカーネル（リアルタ
イムＯＳ）のように、切替えスイッチ１Ｋでコンテキス
ト（制御ブロック）の切替えて実施される。

【００６２】これにより、本ゲーム実行管理装置のゲー
ムエンジンでは、ゲームを実行しながら他の仕事を行っ
たり、複数種類のゲームを同時に実行することができ
る。固定ゲーム場１Ａ、可動ゲーム場１Ｂ、固定プレー
ヤ場１Ｃ、可動プレーヤ場１Ｄの進行状況をゲーム表示
部１Ｆに重ね合せて表示する。これにより、プレーヤ
（人）にゲームの画面として視認させることができる。

【００６３】つぎに、上記ゲーム実行管理装置の具体的
な動作について説明する。図２は図１の基本構成を概念
的に示した図、図３は図１の情報管理方式を概念的に示
した図、図４は装置全体の動作を概略的に説明するフロ
ーチャート、図５は動作要求処理を説明するフローチャ
ート、図６は動作指示処理を説明するフローチャート、
図７はゲーム整合処理部１Ｅの動作を説明するフローチ
ャートである。

【００６４】まず、図２を参照して制御方式を概念的に
説明する。図２において、１Ｌは複数のゲームにおいて
仮想的な共通部分であるゲーム空間を示す。本ゲーム制
御方式では、ゲームストーリ（ゲームプログラム）の記
述は不要であり、全体を管理する部分はない。すなわ
ち、メインコントローラが無い。ゲームを構成する機能
要素すなわち固定ゲーム場１Ａ，可動ゲーム場１Ｂ，固
定プレーヤ場１Ｃ，可動プレーヤ場１Ｄおよびゲーム整
合性処理部１Ｅは、制御的にはそれぞれ同位であり、他
の機能要素の状態を直接には参照しない。

【００６５】ゲームの各構成要素は、独立に処理要求を
出し、それに対する処理許可を受けて状態を変化させ
る。ゲームの構成要素は、仮想的な制御対象すなわち要
求に対し指示を返す仮想的なゲーム空間１Ｌを共有する
ことでシステムとして結び付いている。

【００６６】つづいて、図３を参照して制御方式すなわ
ちゲーム情報管理方式を概念的に説明する。ゲーム構成
要素である固定ゲーム場１Ａ，可動ゲーム場１Ｂ，固定
プレーヤ場１Ｃおよび可動プレーヤ場１Ｄは、いろいろ
な作用属性を持つセル・ブロックの集合体である。各セ
ル、ブロックには安定状態と過渡状態（動作要求状態）
があり、ゲーム操作部１Ｇからのキー操作やゲーム整合
処理部１Ｅからの動作指示などのイベントにより、安定
状態または過渡状態から過渡状態（動作要求状態）とな
る。過渡状態から過渡状態になる場合とは、移動中にキ
ー操作により移動方向を変化させられる場合などであ
る。安定状態に戻るのは、動作要求を受理した場合およ
び拒否した場合（要求を処理した場合）である。

【００６７】ゲーム整合処理部１Ｅはゲーム構成部から
の動作要求間の不整合やセル上での重なりを検出し、ゲ
ーム空間すなわち各ゲーム構成部に「動作指示」を出
す。ゲーム空間Ｌから動作指示を受けた各ゲーム構成部
は動作を実行し、または動作保留や取消しの動作を行
う。このような動作を実行してその結果さらに動作が必
要であれば、動作要求をゲーム空間１Ｌに発する。図３
には可動プレーヤ場１Ｃの例が示されているが、仮想の
ゲーム空間１Ｌに対して、「処理要求」を出しその応答
として「処理指示」を受け取り、処理指示に従って処理
を実行する。他のゲーム構成要素部分の処理の実行形態
も同様である。

【００６８】各セル・ブロックの処理には、個別セル毎
の処理と場全体処理との２つがある。個別セル処理は、
各セル上に制御情報がのっている単一ブロック処理と、
各セル上には制御情報が乗らず別テーブルで管理してい
る複数ブロック処理と２種類が存在する。単一ブロック
処理は、単一セル／ブロックに対する処理であり、固定
的で移動しない単一セルに対するものである。

【００６９】複数ブロック処理は、複数セル（複数ブロ
ック）からなる「移動物体」などに対する処理である。
この詳細については後述する。「移動物体」つまり定型
ブロックは、複数セル（複数ブロック）からなっている
が、ゲーム構成要素上に物理的にブロックが存在するの
ではなくて、ゲーム構成要素上のあるセルの座標（「移
動物体」の場所を示す代表座標）を別テーブルで持って
いるだけである。

【００７０】ゲーム構成要素上のセル上の１点の座標に
対応しているという点で、個別セル処理としている。こ
のような管理方式とするのは、「移動物体」の移動を移
動物体管理テーブル（別テーブル）中の移動物体座標の
書き換えだけで行うためである。これにより、ゲーム画
面上に「移動物体」の消去が不要になり「移動物体」が
物理的形状に依存しなくなるため、「移動物体」の形状
や大きさを移動中に変化させることができる。上記別テ
ーブルには、移動処理を行うため、現在座標、移動原点
座標、移動方向、移動速度（移動カウンタ）などを持た
せている。なお、詳細については後述する。

【００７１】また、場全体処理は、「移動物体」のよう
な半固定的なブロックを扱うのではなく、ある条件が成
立したときに行うブロック消去（例えば横１列が詰まっ
た場合の列消去など）のように不定形のブロック処理を
行う。場全体処理の場合は、対象となるセルやブロック
は、ゲーム構成要素上に物理的に存在する。

【００７２】つづいて、図４を参照してゲーム実行管理
全体の動作を概略的に説明する。ゲームの構成要素（固
定／可動ゲーム場、固定／可動プレーヤ場）に関する処
理は、構成要素の各ゲーム構成要素毎に各個別セルに関
する「個別処理」と全ゲーム構成要素のセル全体に対す
る「全体処理」がある。

【００７３】前者の処理は各ゲーム構成要素で行う。プ
レーヤ（人）のキー操作があった場合には、操作部（キ
ー）情報が読み取られ（ステップＳ１）、そのキー情報
が記憶される。プレーヤ（人）のキー操作またはゲーム
整合処理部１Ｅの動作指示により状態変化が発生し、任
意の状態から過渡状態（動作要求状態）となったセルは
ゲーム空間に対し動作要求を出す（ステップＳ２）。す
なわち、可動プレーヤ場１Ｄの要求（ステップＳ２
Ａ）、固定プレーヤ場１Ｃの要求（ステップＳ２Ｂ）、
可動ゲーム場１Ｂの要求（ステップＳ２Ｃ）、および、
固定ゲーム場１Ａの要求が出される（ステップＳ２
Ｄ）。

【００７４】各ゲーム構成要素からの動作要求の間に矛
盾（不整合：表示的な重なり）があった場合（ステップ
Ｓ３）、ゲーム整合処理部１Ｅによって処理が行われ、
そのゲーム整合処理部１Ｅから要求を出したゲーム構成
要素に動作指示（動作許可）が返される（ステップＳ
４）。各ゲーム構成要素は、ゲーム整合処理部１Ｅから
の動作指示に従い、部分的動作（セル毎動作）が連続し
て実行される（ステップＳ５）。

【００７５】すなわち、可動プレーヤ場１Ｄの処理（ス
テップＳ５Ａ）、固定プレーヤ場１Ｃの処理（ステップ
Ｓ５Ｂ）、可動ゲーム場１Ｂの処理（ステップＳ５
Ｃ）、および、固定ゲーム場１Ａの処理が実行される
（ステップＳ５Ｄ）。この一連の動作は、全セルが安定
状態または順安定状態（動作を１回以上行ってつぎの動
作機会を待っている状態）になるまで継続する。

【００７６】全セルの動作が完了したら、ゲーム表示部
１Ｆにおいて各ゲームの構成要素を合成表示（重ねあわ
せ表示）する処理が実行され（ステップＳ６）、さらに
音響効果部１Ｈの効果音鳴動処理にてゲーム効果音が発
生させられる（ステップＳ７）。上記の一連の処理が終
了したらゲームの進行状態がゲーム進行状態記憶部１Ｊ
に保存され、本ゲーム処理から一旦抜けて別の処理が実
行される（ステップＳ８）。

【００７７】このように別の処理を行ったあとゲーム進
行状態記憶部１Ｊからゲームの進行状態が復元されて、
ステップＳ１よりゲーム処理の続きが行われる。以降は
この処理を繰り返す。これは、ゲームと他の仕事（携帯
通信端末のメール送受信等）を同時に行ったり、複数の
ゲームを同時に実行するための機構である。このため、
ゲームの全進捗状況を記憶するためのゲーム進行状態記
憶部１Ｊがゲーム毎に設けられる。

【００７８】つづいて、図５を参照して動作要求処理に
ついて説明する。動作要求は、前述のような各セル
（「移動物体：定型ブロック」を含む）の状態変化によ
って発生するもの、および、各ゲーム構成要素毎に複数
セル：ブロック処理（場全体的な不定形ブロック処理）
を行うものがある。各セルに対して行う処理は、ゲーム
の種類によらず同一であるが、複数セル／ブロックに対
して行う処理は、ゲーム毎に固有である。

【００７９】セル毎部分的動作要求においては、全セル
についてセル単独の処理と複数セル／ブロック（「移動
物体」）の処理を行う。全セル要求が終了するまでは
（ステップＳ１１）、セル要求の種別が判断され（ステ
ップＳ１２）、その種別に応じたｉ（１≦ｉ≦ｎ）番目
のセル処理が実行される（ステップＳ１３Ａ１〜ステッ
プＳ１３Ａｎ）。

【００８０】そして、セル個別要求処理がすべて終わっ
たら（ステップＳ１１）、移動処理が実行される（ステ
ップＳ１５）。この移動処理の詳細は図６に示される。
ステップＳ１５の後、場全体要求処理（不定形ブロック
処理）が実行される（ステップＳ１６）。そして、図５
の処理は終了する。

【００８１】さらに図６を参照して移動処理について詳
述する。移動処理では、図６に示すように、全セルにわ
たってステップＳ１５Ｃの移動関係の処理とステップＳ
１５Ｄの非移動関係の処理が完了するまではステップＳ
１５Ｂ〜ステップＳ１５Ｉまでの処理が繰り返し実行さ
れる（ステップＳ１５Ａ）。ステップＳ１５Ａにおいて
全移動物体の処理が未完という判定結果が得られた場合
には、続くステップＳ１５Ｂにおいて動作種別が判断さ
れる。移動処理であれば、ステップＳ１５Ｃにおいて図
６の演算内容に従って移動関係の処理が実行される。そ
の結果は移動物体管理テーブルに記憶される。

【００８２】すなわち、移動物体管理テーブルには、
（１）移動物体番号、（２）現在座標、（３）移動原
点、（４）移動方向、（５）移動速度（初期値）、
（６）移動カウンタ、（７）キー操作処理名が記憶され
る。この移動処理が行われた後に移動物体がゲーム場の
範囲内に収まっていれば（ステップＳ１５Ｅ）、要求フ
ラグが立てられるが（ステップＳ１５Ｆ）、ゲーム場の
範囲を出ていたら（ステップＳ１５Ｅ）、要求フラグは
オフされ（ステップＳ１５Ｇ）、移動処理が取り消され
る（ステップＳ１５Ｈ）。一方、ステップＳ１５Ｂにお
いて動作種別が移動処理以外の処理であれば、ステップ
Ｓ１５Ｄにおいて非移動関係の処理が実行される。その
後に、処理はステップＳ１５Ｅへ移行し、上述したステ
ップＳ１５Ｅ以降の処理が実行される。

【００８３】場全体に対する複数セル／ブロック処理
は、セル毎の処理では実現不能な複数セル（不定形ブロ
ック）に対する条件処理的な処理を行うので、ゲーム毎
に固有の処理となる。複数セル／ブロック処理要求にお
いては、列消去、行消去や複数セル／ブロック消去など
複数セルに関する要求処理が実行される。複数ブロック
処理要求も全セルにわたって要求の有無を確認する処理
が実行される。

【００８４】つづいて図６を参照して動作指示処理につ
いて説明する。この動作指示処理は、前述の動作要求に
対応するものである。全セル処理が終了するまでは（ス
テップＳ２１）、ゲームの構成要素（固定／可動ゲーム
場、固定／可動プレーヤ場）の各セルがゲーム空間（ゲ
ーム整合処理部１Ｅ）から動作要求に対する動作指示を
受けたら（ステップＳ２２）、セル毎に指示された動作
が実行される（ステップＳ２３Ａ１〜ステップＳ２３Ａ
ｎ）。動作指示を受けた状態では各ゲーム構成要素間の
矛盾は解消されている。

【００８５】上記動作指示処理は、全セルまたは全ブロ
ックが要求を実行または保留され安定状態または順安定
状態に変化するまで継続される。なお、個別セル処理の
後、セルのカウンタはステップＳ２４により一つずつア
ップされる。ステップＳ２３Ａ１〜ステップＳ２３Ａｎ
のいずれかによりセル個別動作処理が終わったら、移動
処理が実行される（ステップＳ２５）。この移動処理の
詳細は図８に示される。この移動処理の後、場全体動作
処理（不定形ブロック処理）が実行され（ステップＳ２
６）、図７の処理は終了する。

【００８６】さらに図８を参照してステップＳ２５の移
動処理について詳述する。図８は図７の移動処理を説明
するフローチャートである。移動物体は、管理テーブル
に移動カウンタを持っており、移動速度をコントロール
している。全移動物体の処理が未完であり（ステップＳ
２５Ａ）、移動物体ｉ（ｉは移動カウンタの値）の要求
が有れば（ステップＳ２５Ｂ）、動作タイマは一つダウ
ンカウントされる（ステップＳ２５Ｃ）。

【００８７】また、全移動物体の処理が終了すれば（ス
テップＳ２５Ａ）、図８の処理は終了し、移動物体ｉの
要求がなければ（ステップＳ２５Ｂ）、つぎの移動物体
のために処理はステップＳ２５Ｊへ移行し、移動カウン
タｉを一つアップする。

【００８８】移動タイマは場処理が定期的に呼ばれるた
びにダウンカウントされ（ステップＳ２５Ｃ）、その値
がゼロになれば（ステップＳ２５Ｄ）、図８の演算内容
に従って移動方向が計算され（ステップＳ２５Ｅ）、処
理はステップＳ２５Ｆへ移行する。一方、移動タイマの
値がゼロにならなければ（ステップＳ２５Ｄ）、処理は
上述のステップＳ２５Ｊへ移行する。

【００８９】ステップＳ２５Ｆにおいて、移動物体が壁
に衝突し、かつ、その壁が反転属性を持っていれば、移
動物体の移動方向は弾性反転する（ステップＳ２５
Ｄ）。その後、処理はステップＳ２５Ｈへ移行する。こ
の際移動方向はθ＝３６０°−θとなり、移動原点はｘ
＝衝突した壁のｘ座標、ｙ＝衝突した壁のｙ座標であ
る。実際のゲーム画面上での移動は、合成表示部で他の
ゲーム構成要素と重ね合わせ表示するときに行われる。

【００９０】また、壁への衝突が確認されないか、ある
いは、壁が反転属性を持っていない場合には（ステップ
Ｓ２５Ｆ）、処理はステップＳ２５Ｈへ移行する。ステ
ップＳ２５Ｈにおいて移動タイマは初期値に戻され、移
動が実行される。この場合の移動の実行とは、移動物体
の座標（ｘ，ｙ）を更新すること（ステップＳ２５Ｅ）
である。移動の実行が終わったら、要求フラグはオフさ
れる（ステップＳ２５Ｉ）。そして、移動カウンタは一
つアップされ（ステップＳ２５Ｊ）、処理はステップＳ
２５Ａに戻る。

【００９１】つづいて、図９を参照してゲーム整合処理
部１Ｅの動作について説明する。図９はゲーム整合部１
Ｅの動作を説明するフローチャートである。固定ゲーム
場１Ａ，可動ゲーム場１Ｂ，固定プレーヤ場１Ｃ，可動
プレーヤ場１Ｄは、ゲーム空間１Ｌに対してそれぞれ独
立に動作リクエストを出す。ゲーム整合性処理部１Ｅで
は、全セル処理が終了するまでは（ステップＳ３１）、
全ゲーム空間１Ｌにおいて各機能要素（ゲーム場／プレ
ーヤ場）のリクエストの矛盾点（不整合の発生点）が探
索される（ステップＳ３２）。

【００９２】ここで、矛盾点とは、固定／可動ゲーム場
と固定／可動プレーヤ場間で重なる場合を指す。その結
果、矛盾点が有れば、優先順位に従ってゲーム整合処理
が実行される（ステップＳ３３）。ここでいうゲーム整
合処理とは、動作リクエストに対して、ＯＫ／ＮＧを返
すことである。動作可：ＯＫを受けた機能要素は、リク
エストどおりに動作が実行され、動作不可：ＮＧを受け
た機能要素は、リクエストを取り下げ何の動作もおこさ
ず現状態を保持するか、リクエストを保留する。

【００９３】ステップＳ３２の結果において矛盾点がな
ければ、不整合無しとしてｉ番目セルに対するセル要求
が確認され（ステップＳ３４）、セル要求があった場合
についてのみそのセル要求に対して許可が与えられる
（ステップＳ３５）。このようにしてｉ番目のセルに関
する処理が終了すると、セルカウンタは一つアップされ
る（ステップＳ３６）。その後、処理はステップＳ３１
へ移行する。

【００９４】つぎに、ゲームを構成する各部の機能につ
いて説明する。まず、固定ゲーム場について説明する。
図１０は固定ゲーム場を説明する図であり、図１１は固
定ゲーム場の場合の属性を説明する図である。固定ゲー
ム場１Ａは、可動ゲーム場１Ｂとともにゲームを行う環
境（フレーム）を提供する。可動ゲーム場１Ｂは、名前
の通り固定壁や固定障害物のような固定的なゲーム環境
を与えるものである。

【００９５】固定ゲーム場１Ａは、可動ゲーム場１Ｂや
固定／可動プレーヤ場１Ｃ，１Ｄの動作や作用によって
増殖することはあるが、消滅することはない。ゲームの
進行によってゲーム場が消滅する場合は、その部分は可
動ゲーム場として扱う。本ゲーム管理方式では、固定ゲ
ーム場の形状は任意である。すなわち、どんな形をして
いてもかまわない。

【００９６】固定ゲーム場１Ａは、可変プレイヤー場１
Ｄにゲームのルールに基づき作用を及ぼし、ゲーム状況
を変化させる。固定ゲーム場１Ａが、各プレーヤー場１
Ｃ，１Ｄに与えるゲーム作用の例として以下のようなも
のがある。各セルは、ゼロまたは一つ以上のゲーム作用
属性を持っている（図１１参照）。（ａ）吸収固定ゲーム場に吸い込まれて消滅す
る。（ゲーム場外に落下・消滅、障害物に吸収・消滅）（ｂ）固定化固定ゲーム化と一体化し固定ゲーム場
の一部になる。（ブロックの底面到達・堆積、障害物に
接触・固定化）（ｃ）反射固定ゲーム場に接触したら、移動方向
が弾性反転する。（壁で反転、障害物で反転）

【００９７】（ｄ）妨害移動物体が固定ゲーム場
に接触したら、移動を妨害（阻止）する。反対方向へは
移動できる可能性がある。（壁，障害物）（ｅ）透過する。（壁ぬけ、落とし穴）（０）無作用プレーヤ場に対して、何の動作も発生
させない。（自由に移動可能な空間）（ｘ）範囲外固定ゲーム場でない部分。任意の固
定ゲーム場形状をつくるためのダミー部分（詰めもの）
である。（ゲームの管理範囲外）

【００９８】図１０（ａ）には長方形の形をした固定ゲ
ーム場２Ａが示され、同図（ｂ）には長方形以外の形を
した固定ゲーム場２Ｂが示されている。各固定ゲーム場
２Ａ，２Ｂの形状は任意であるが、説明の簡単のため
（およびコンピュータでの実現の簡単のため）、本明細
書では管理範囲をｎ×ｍ（ｎ，ｍは自然数）の行列にて
表現する。

【００９９】管理するデータ構造は、Ｎ（Ｎは自然数）
次元配列でも線形リストでもハッシュテーブルのような
ものでもかまわない。必要なデータが取り出せればよい
ので、特に制御データ構造（データ記憶管理方式）は任
意でよい。このことは、移動ゲーム場、固定プレーヤ
場、可動プレーヤ場の管理においても同様である。

【０１００】上記固定ゲーム場２Ａ，２Ｂにおいて、網
掛け部分が表示されプレーヤ（人）の目に映る部分であ
る。固定ゲーム場２Ａでは、左の壁と右の壁は（網掛け
部分を除く）、プレーヤ場の操作を妨害する部分であ
る。プレーヤ場は、左右の壁に接触したらそれ以上移動
できない。

【０１０１】下の床（網掛け部分を除く）は一体化属性
を持つので、プレーヤ場が「床」に接触すると、床と一
体化して「床」になる。一方、固定ゲーム場２Ｂでは、
下の床（網掛け部分を除く）は吸収性をもつので、プレ
ーヤ場は「床」に接触すると床に吸収され、消滅する。
床以外の面（網掛け部分を除く）に接触すると可動プレ
ーヤ場の移動方向が反転する（壁で男性反射する）。

【０１０２】つづいて可動ゲーム場について説明する。
図１２は可動ゲーム場を説明する図であり、図１３は固
定ゲーム場の場合の属性を説明する図である。可動ゲー
ム場１Ｂは、その名の通り移動するゲーム場のことであ
る。図１２において、３Ａ，３Ｃは正方形の形をしたゲ
ーム場である。可動ゲーム場３Ａは可動ゲームのベース
部分を示している。

【０１０３】可動ゲーム場３Ｃはベース部分である可動
ゲーム場３Ａに可動部分を重ねたものである。可動ゲー
ム場３Ｃにおいて、網掛け部分が移動物体部分である。
ゲーム場面中に破壊属性をもつブロックがあるので、可
動プレーヤ場１Ｄが接触すると、可動ゲーム場３Ａ，３
Ｃの一部（ブロック）が消滅する。３Ｂは移動物体の座
標、移動方向を記憶する移動物体管理テーブルを示し、
３Ｄは移動物体を示している（可動ゲーム場３Ｃの網掛
け部分）。

【０１０４】可動ゲーム場１Ｂとして、一部固定し動作
する場合の可動ゲーム場３Ａ（図１３（ａ）参照）と、
固体として移動可能な場合の可動ゲーム場３Ｃ（図１３
（Ｃ）参照）の２つがある。一部固定の可動ゲーム場３
Ａは、回転する障害物、上下動する壁、波打つ壁、床を
もつ。完全独立の可動ゲーム場３Ｃは、落下する障害
物、敵の攻撃弾、敵の移動陣地（ＵＦＯなど）などをも
つ。なお、可動ゲーム場の移動動作は、ゲームエンジン
が制御しプレーヤ（人）によって制御することは出来な
い。また、可動ゲーム場がプレーヤ場に与えるゲーム作
用は固定ゲーム場とほぼ同じものである。

【０１０５】可動ゲーム場がプレーヤー場に与えるゲー
ム作用の例として以下のようなものがある（図１３参
照）。各セルは、一つまたは２つ以上のゲーム作用属性
を持っている。（ａ）吸収可動ゲーム場に吸い込まれて消滅す
る。（ｂ）一体化可動ゲーム化と一体化し固定ゲーム
場の一部になる。（ｃ）反射可動ゲーム場に接触したら、移動方
向が反射する。（ｄ）妨害可動ゲーム場に接触したら、移動を
妨害する。（ｅ）透過可動ゲーム場に接触したら、固定ゲ
ーム場を透過する。

【０１０６】（ｆ）生成・移動可動ゲーム場を、ゲー
ムのルールに従って生成し、移動する。（可動ゲーム場
の生成）（ｇ）生成・移転可動ゲーム場は、生成と同時に可動
プレーヤ場になる。（可動プレーヤ場の生成）（ｈ）破壊プレーヤ場が接触したら、可動ゲー
ム場を破壊する。可動ゲーム場を消滅させる。（０）無作用プレーヤ場に対して、何の動作も発
生させない。（ｘ）範囲外可動ゲーム場でない部分。（ゲーム
の管理範囲外）可動ゲーム場に特有な作用としては、以下の「生成」
「破壊」がある。

【０１０７】可動ゲーム場３Ａの各セルは、上記のよう
な処理属性を持っている。可動ゲーム場が「移動物体」
をもつ場合、データは移動物体管理テーブル３Ｂによっ
て管理される。すなわち移動物体管理テーブル３Ｂに
は、（１）移動物体番号、（２）現在座標、（３）移動
原点、（４）移動方向、（５）移動速度（初期値）、
（６）移動カウンタ、（７）キー操作処理名を記憶して
いる。

【０１０８】可動ゲーム場の場合、移動物体の動きをプ
レーヤ（人）が制御することができないので、（７）キ
ー操作処理名の登録は無効となる。すなわち、何が登録
してあっても処理しない（無視する）。移動物体管理テ
ーブル３Ｂに移動物体３Ｄが登録されていたとすると、
その可動ゲーム場の表示イメージは、可動ゲーム場３Ｃ
のようになる。管理イメージは可動ゲーム場３Ａであ
る。

【０１０９】移動物体は、消滅することもあるが移動物
体の有効／無効の情報は、前記移動物体管理テーブルの
「移動方向」によって管理する。移動方向として存在し
得ないものを設定してあるとき無効とする。例えば、移
動方向を０〜３６０°の範囲とし、マイナス値を無効と
する方法などがある。また、移動物体の有効／無効のた
めの状態フラグを移動物体管理テーブル上に作る方法も
有り得る。

【０１１０】つづいてプレーヤ場について説明する。ま
ず固定プレーヤ場について説明する。図１４は固定プレ
ーヤ場を説明する図である。図１４において、４Ａ，４
Ｃは正方形をした固定プレーヤ場である。固定プレーヤ
場４Ａは、ベース部分を指し、固定プレーヤ場４Ｃはベ
ース部分である固定プレーヤ場４Ａに可動部分を重ねた
ものである。４Ｂは移動物体４Ｃの座標、移動方向を記
憶する移動物体管理テーブルを示している。４Ｃは移動
物体を示している。

【０１１１】固定プレーヤ場４Ａ，４Ｃは、プレーヤ
（ゲーム操作者）によってゲームの進行状況の作用を制
御できるものである。固定プレーヤ場は「固定」と称し
ているが、制限付きで「可動」である。固定プレーヤ場
４Ａ，４Ｃは、プレーヤの使う「道具」に当たる。例え
ばテニスゲームやブロック崩しゲームの「ラケット」、
ピンボールゲームの「フラップ」などに相当する。固定
プレーヤ場４Ａ，４Ｃは、その動作によって可動プレー
ヤ場を制御できるが、直接にゲームの「得点」を得るこ
とは不可能である。

【０１１２】固定プレーヤ場が、可変プレーヤ場に与え
る作用は以下のようなものである。各セルは、一つまた
は２つ以上のゲーム作用属性を持っている。（ａ）吸収固定プレーヤ場に吸い込まれて消滅す
る。（可動プレーヤ場：タマのキャッチ）（ｂ）反射可変プレーヤ場の移動方向を変える。
吸収または固定化しそうな可動プレーヤ場を救出する。
（ブロック崩しのラケット、ピンボールゲームのフラッ
プ）（０）無作用プレーヤ場に対して、何の動作も発生
させない。（ｘ）範囲外可動ゲーム場でない部分。（ゲームの
管理範囲外）

【０１１３】固定プレーヤ場４Ａの各セルは、上記のよ
うな処理属性を持っている。固定プレーヤ場が「移動物
体」をもつ場合、データは移動物体管理テーブル４Ｂに
よって管理する。すなわち、移動物体管理テーブル４Ｂ
には、（１）移動物体番号、（２）現在座標、（３）移
動原点、（４）移動方向、（５）移動速度（初期値）、
（６）移動カウンタ、（７）キー操作処理名が記憶され
る。固定プレーヤ場の場合、移動物体の動きをプレーヤ
（人）が制御するので、（７）キー操作処理名の登録を
行う必要がある。

【０１１４】キー処理はゲームの種類毎に異なるので
（有効なキーが違うので）、ゲーム毎に記述する必要が
ある。移動物体管理テーブル４Ｂに移動物体４Ｄが登録
されていたとすると、その可動ゲーム場の表示イメージ
は、固定プレーヤ場４Ｃのようになる。そのときの管理
イメージは固定プレーヤ場４Ａである。

【０１１５】つづいて可動プレーヤ場について説明す
る。図１５は可動プレーヤ場を説明する図である。図１
５において、５Ａ，５Ｃは正方形をした可動プレーヤ場
である。可動プレーヤ場５Ａは、ベース部分を指し、可
動プレーヤ場５Ｃはベース部分である可動プレーヤ場５
Ａに可動部分を重ねたものである。５Ｂは移動物体５Ｃ
の座標、移動方向を記憶する移動物体管理テーブルを示
している。５Ｃは移動物体を示している。

【０１１６】ゲームの進行の中心となるメインキャラク
タ（主人公）である。例えば、ピンボールゲームの玉や
テトリスのブロックなどである。可動プレーヤ場は、プ
レーヤの操作部の操作により動作を変化させ、その作用
としてゲーム場に変化を与える。その結果、ゲームのル
ールに従って、ゲームが進行しポイント（点数）が与え
られる。可動プレイヤー場は、操作者の操作によって移
動方向、移動速度、移動物体数、移動物体の種類の一部
またはすべてを制御可能である。可動プレーヤ場は、可
動ゲーム場によって生成され、自動的な属性変更によっ
て可動プレーヤ場となる。

【０１１７】可動プレーヤ場が、プレーヤー場に与える
ゲーム作用の例として以下のようなものがある。各セル
は、一つまたは２つ以上のゲーム作用属性を持ってい
る。（ｇ）生成・移動可動プレーヤ場を生成し移動させ
る。（１）無作用可動プレーヤ場有り。プレーヤ場に対
して、何の動作も発生させない。（０）無作用プレーヤ場に対して、何の動作も発生
させない。（ｘ）範囲外可動ゲーム場でない部分。（ゲームの
管理範囲外）

【０１１８】可動プレーヤ場５Ａは、正方形の形をした
可動プレーヤ場の例である。（５A）の各セルは、上記
のような処理属性を持っている。可動プレーヤ場が「移
動物体」をもつ場合、データは移動物体管理テーブル５
Ｂによって管理する。移動物体管理テーブル５Ｂには、
（１）移動物体番号、（２）現在座標、（３）移動原
点、（４）移動方向、（５）移動速度（初期値）、
（６）移動カウンタ、（７）キー操作処理名を記憶して
いる。

【０１１９】固定プレーヤ場の場合、移動物体の動きを
プレーヤ（人）が制御するので、前記（７）キー操作処
理名の登録を行う必要がある。キー処理はゲームの種類
毎に異なるので（有効なキーが違うので）、ゲーム毎に
記述する必要がある。

【０１２０】移動物体管理テーブル５Ｂに移動物体５Ｄ
が登録されていたとすると、その可動ゲーム場の表示イ
メージは、可動プレーヤ場５Ｃのようになる。そのとき
の管理イメージは可動プレーヤ場５Ａである。

【０１２１】つぎに、ゲーム内容について具体例を挙げ
て説明する。まず、テトリス（登録商標）を例に挙げ
る。図１６はゲームとしてテトリスに関するゲーム場／
プレーヤ場などの一例を説明する図であり、図１７はテ
トリスブロックの種類を説明する図である。図１６にお
いて、６Ａ，６Ｂはそれぞれ固定ゲーム場、可動ゲーム
場を示し、６Ｃは移動物体管理テーブルを示し、６Ｄは
テトリスブロックを示している。

【０１２２】図１７において、テトリスブロックとして
はＮｏ．１〜Ｎｏ．７までの７種類を用意している。こ
こで、テトリスとは、上から落ちてくるブロックをキー
操作により左右移動、回転をおこなって、下に積み重ね
ていくものである。任意の横１列が積み重なったブロッ
クで全ていっぱいになったら、その横１列を消去し１列
下に詰め合わせ、全ブロックを消去できたらゲーム終了
となるゲームをいう。

【０１２３】まず、テトリスのゲーム場／プレーヤ場の
設定を以下に示す。（１）固定ゲーム場６Ａテトリスの固定ゲーム場の４つの面（壁）の属性は、以
下の通りである。・天井、右壁、左壁：「妨害」テトリス移動して壁に
あたったらそれ以上移動できない。逆方向には移動でき
る可能性がある。・床面：「一体化」テトリスが床に触れ
ると壁と一体化する。（壁になる、壁の一部となる）・その他：「無作用」

【０１２４】（２）可動ゲーム場テトリスには固定ゲーム場は無い。全セルの属性を「無
作用」とする。（３）固定プレーヤ場テトリスには固定プレーヤ場は無い（プレーヤが使う
「道具」がない）。全セルの属性を「無作用」とする。（４）可動プレーヤ場６Ｂテトリスの可動プレーヤ場は、テトリスブロック６Ｄを
移動させる場である。その生成をプレーヤが制御するこ
とはできない。

【０１２５】テトリスブロック６Ｄが、全体処理部の指
示を受けた可動プレーヤ場６Ｂによって生成されると、
すぐにプレーヤ（人）の操作によって移動（左右回転、
左右横移動、下降）動作を行えるようになる。テトリス
ブロック６Ｄは、「移動物体」なので、可動プレーヤ場
上に実体（物理的なイメージ）は無く、移動物体管理テ
ーブル６Ｃに別に存在している。この移動物体管理テー
ブル６Ｃには、テトリスを動作させるための情報とし
て、（１）移動物体番号、（２）現在座標、（３）移動
原点、（４）移動方向、（５）移動速度（初期値）、
（６）移動カウンタ、（７）キー操作処理名が記憶され
ている。

【０１２６】生成される可動プレーヤ場６Ｂは、事前に
設定してある可動プレーヤ場の組（図１７の例では、Ｎ
ｏ．１〜Ｎｏ．７のすべて）のうちからランダムに一つ
だけ選択する。テトリスの可動プレーヤ場６Ｂは、ゲー
ム場面上に同時に１個しか存在しない。よって、移動物
体管理テーブル６Ｃも一つだけ存在する。

【０１２７】つぎに、上記テトリスの動作について説明
する。図１８はテトリスブロックの移動処理を説明する
フローチャート、図１９はテトリスブロックの回転処理
を説明する図、そして、図２０は図１９に示した回転処
理の変換テーブルを示す図である。

【０１２８】テトリスブロック６Ｄはブロックサイズが
３×３の例である。この例ではＮｏ．１〜Ｎｏ．７まで
の７種類のブロック形状を定義してあるが、上記可動プ
レーヤ場６ＢによってテトリスブロックＮｏ．１〜Ｎ
ｏ．７の中から一つのパターンがランダムに選択され
て、ゲーム場面内を移動する。本ゲーム管理方式では、
他の機能属性部分との重なり（不整合）を当事者が管理
する必要が無いので、ブロックサイズは本例のような３
×３でなく、任意のサイズ（４×４、３×４等）でもか
まわない。

【０１２９】テトリスは、移動中（落下中）プレーヤに
よってキー操作をされると、移動または回転を行う。そ
のため、まずキー情報を読み込んで移動種別が判別され
る（ステップＳ４１）。この判別により左移動／右移動
／下移動／左回転／右回転のいずれかであれば、移動処
理要求が作成される。

【０１３０】すなわち、移動種別が左，右または下への
移動であれば、処理はステップＳ４２Ａ１，ステップＳ
４２Ａ２またはステップＳ４２Ａ３へ移行して図１８に
従う移動処理要求を作成する。また、移動種別が左回転
または右回転であれば、処理はステップＳ４２Ａ４また
はステップＳ４２Ａ５へ移行して図１８に従う移動処理
要求を作成する。また、いずれの移動種別にも該当しな
い移動であれば、対象範囲外として処理は終了する。

【０１３１】ステップＳ４２Ａ１〜ステップＳ４２Ａ５
のいずれかの移動種別に応じた移動状態がプレーヤ場の
範囲に入っているかどうか判定され（ステップＳ４
３）、範囲内に入っていれば動作要求が行われる（ステ
ップＳ４４）。もし、プレーヤ場の範囲から出ていれ
ば、処理要求をＯＦＦして処理を無効化する処理が実行
される（ステップＳ４５）。そして、処理は終了する。
なお、キー操作情報は、可動プレーヤ場６Ｂに付属する
移動物体管理テーブル６Ｃの「キー操作」部分に登録さ
れる。

【０１３２】ここで、図１９に示したテトリスブロック
を例に挙げて回転を説明する。図１９には、ブロックの
１行目、２行目、３行目にわたって１列目，２列目，３
列目の順に１〜９までの番号が割り振られる。左回転の
場合には元の位置から「左回転処理」により左回転結果
が得られる。すなわち、左回転結果は、上記１〜９の順
番が、３，６，９，２，５，８，１，４，７の並びとな
る。

【０１３３】一方、右回転処理の場合には元の位置から
「右回転処理」により右回転結果が得られる。すなわ
ち、右回転結果は、上記１〜９の順番が、７，４，１，
８，５，２，９，６，３の並びとなる。実際の回転処理
（座標変換）では、簡単のため、図２０に示した如く変
換テーブルが用いられる。この場合には、回転中心を３
×３ブロックの中心に配置された“５”とする。なお、
その他の方法として三角関数の回転の公式を用いてもよ
い。

【０１３４】つぎに、上記テトリスの全体処理について
説明する。図２１および図２２はテトリスにおける全体
処理を説明するフローチャートである。この全体処理に
は、列消去／列詰め合わせ処理が含まれる。図２１にお
いて、テトリスの全体処理では、まずテトリスの全体処
理サブルーチンのアドレスが全体処理テーブルに登録さ
れる（ステップＳ５１）。そして、可動ゲーム場全体の
処理が実行され（ステップＳ５２）、初期化により列カ
ウンタはゼロにセットされる（ステップＳ５３）。

【０１３５】まず、固定ゲーム場６Ａに堆積したテトリ
スブロックの１列が消去可能かどうか判定され（ステッ
プＳ５４）、消去可能な場合つまり１列がテトリスブロ
ックでつながった場合にその１列が消去され（ステップ
Ｓ５５）、一つ上の列より順に一つ下に下げられる。１
列下げられた状態でゲーム空間に対して処理が要求され
る。

【０１３６】この処理は、所定のテーブルに登録され
る。ステップＳ５５による消去により全列が消去される
までの間は（ステップＳ５６）、続くステップＳ５７に
おいて列カウンタが一つずつアップされ、処理はステッ
プＳ５４へ戻る。一方、全列の消去が行われた場合には
（ステップＳ５６）、処理はステップＳ５８（図２２参
照）へ移行する。

【０１３７】ここで、ゲーム空間を整合処理する部分つ
まりゲーム整合処理部１Ｅは、要求された処理が他のゲ
ーム構成要素と不整合（衝突）を起こしていないかどう
か調査する。もしも不整合が発生している場合、優先順
位にしたがって、不整合（衝突）を解消する。なお、テ
トリスの優先順位は、固定ゲーム場＞可動ゲーム場＞固
定プレーヤ場＞可動プレーヤ場とする。

【０１３８】この全体処理では、得点のカウント処理お
よびゲームの終了判定も行われる。得点のカウントは、
列消去されたブロックの数で行われる（ステップＳ５
８）。続く終了判定は、生成ブロック数、ゲーム時間、
および、ゲーム進行不能状態の監視にて行われる。ゲー
ム進行状態監視とは、テトリスブロックが天井まで堆積
して新規にブロックを生成できなくなった場合を監視す
る。

【０１３９】この終了判定に時間条件を入れるのは、プ
レーヤ（人）の不在による放置や、デットロック状態に
至った時の脱出用である。以上をまとめると、ゲーム時
間が終了になると（ステップＳ５９）、処理はテトリス
の生成をせずにステップＳ６２へジャンプして移動カウ
ンタを一つダウンさせる。その後、処理はステップＳ６
３へ移行する。

【０１４０】また、ゲーム時間が終了していない場合に
は（ステップＳ５９）、続くステップＳ６０においてテ
トリスブロックが消滅したか否か判断される。その判断
でテトリスブロックが消滅していなければ、処理はステ
ップＳ６１へ移行してテトリスブロックのパターンをＮ
ｏ．１〜Ｎｏ．７からランダムに一つ選択する。これに
より、テトリスが生成される。

【０１４１】その後、処理はステップＳ６２へ移行す
る。さらに詳述すれば、このテトリスブロックを生成す
るかどうかの判定は、移動物体管理テーブル６Ｃの状態
に従って行われる。移動物体の有効／無効は、移動物体
管理テーブル６Ｃの移動方向を０〜３５９°で表した場
合、マイナス値を無効つまり移動物体消滅として判定さ
れる。

【０１４２】そして、移動カウンタがゼロに達していな
ければ（ステップＳ６３）、テトリスブロックはプレー
ヤ（人）の操作によらず一定時間毎に下降制御される
（ステップＳ６４）。このテトリスブロックの下降でテ
トリスブロックが床面に接触した場合には（ステップＳ
６５）、テトリスブロックは床と一体化される（ステッ
プＳ６６）。すなわち、固定ゲーム場６Ａの「一体化」
属性のセルに接触すると、テトリスブロック（可動プレ
ーヤ場６Ｂ）は固定ゲーム場６Ａに一体化される。これ
は、可動プレーヤ場６Ｂから固定ゲーム場６Ａにテトリ
スブロックがコピーされ、可動プレーヤ場６Ｂのテトリ
スブロックが消去されることを意味する。

【０１４３】つづいて、ブロック崩し（登録商標）を挙
げる。図２３はゲームとしてブロック崩しに関する固定
／可動ゲーム場の一例を説明する図であり、図２４はゲ
ームとしてブロック崩しに関する固定プレーヤ場などの
一例を説明する図である。図２３において、７Ａは固定
ゲーム場を示し、７Ｂは可動ゲーム場を示している。図
２４において、７Ｃは固定プレーヤ場を示し、７Ｄは移
動物体管理テーブルを示し、７Ｅはラケットを示してい
る。

【０１４４】ブロック崩しは、天井にぶら下がったブロ
ック群をタマで破壊していくゲームである。タマは、天
井、左右の壁に衝突すると移動方向が変化する（弾性反
転する）。タマがブロックに衝突するとブロックを破壊
し、プレーヤ（人）が移動方向が変化する（弾性反転す
る）。タマは、床に落ちると消滅してしまうので、床面
にあるラケットによってタマを打ち返す。タマは、ラケ
ットに衝突すると移動方向が変化する（弾性反転す
る）。

【０１４５】ここで、ブロック崩しのゲーム場／プレー
ヤ場の設定を以下に示す。（１）固定ゲーム場７Ａ固定ゲーム場の４つの面（壁）の属性は、以下の通りで
ある。・天井、右壁、左壁：「反射」タマは壁にあたったら
弾性反射する。・床面：「吸収」タマが床に触れるとタ
マが消滅する。（ブロックが床面に当っても消滅しな
い）・その他：「無作用」

【０１４６】（２）可動ゲーム場７Ｂブロック崩しの可動ゲーム場７Ｂは、ブロックを移動さ
せる場である。４つの面（壁）の属性は、以下の通りで
ある。・天井：「破壊」＋「反射」（２つの属性
を同時に持つ）ブロックは、天井（上）にある。タマ
がブロックにあたるとブロックは消滅し、タマは、弾性
反射する。・右壁、左壁、床：「無作用」プレーヤ場には作用し
ない。・その他：「無作用」

【０１４７】（３）固定プレーヤ場７Ｃ，ラケット７Ｅブロック崩しの固定プレーヤ場７Ｃの動作部分はラケッ
ト７Ｅである。このラケット７Ｅは、プレーヤ（人）の
キー操作により、「左」「右」に移動可能である。ラケ
ット７Ｅの属性は「反転」であり、タマ（可動プレーヤ
場）があたると、タマを弾性反射する。移動物体である
ラケット７Ｅは、移動物体管理テーブル７Ｄによってそ
の動作を管理される。

【０１４８】つぎに、ブロック崩しの動作について説明
する。図２５はブロック崩しのラケット移動処理を説明
するフローチャートである。ラケット移動処理では、キ
ー情報は、移動物体管理テーブル７Ｄに登録される。プ
レーヤ（人）の有効なキー操作は、「左」と「右」ヘの
移動である。ラケットは、左右の壁にあたるとそれ以上
は移動できない。ブロック崩しにおいて、プレーヤ
（人）が初期設定によって制御可能なのは、ラケット７
Ｅの「大きさ：形状」である。例えば、上級者向けは、
ラケットを小さく、初級者用はラケットを大きく設定で
きるようにする。

【０１４９】図２５において、キー操作によりキー操作
情報が取り込まれ、まずそのキー情報に応じて移動種別
が判別される（ステップＳ７１）。この判別により左移
動／右移動のいずれかであれば、移動処理要求が作成さ
れる。すなわち、移動種別が左または右への移動であれ
ば、処理はステップＳ７２ＡまたはステップＳ７２Ｂへ
移行して図２５に従う移動処理要求を作成する。また、
いずれの移動種別にも該当しない移動であれば、対象範
囲外として処理は終了する。

【０１５０】ステップＳ７２ＡまたはステップＳ７２Ｂ
の移動種別に応じた移動状態がプレーヤ場の範囲に入っ
ているかどうか判定され（ステップＳ７３）、範囲内に
入っていれば動作要求が行われる（ステップＳ７４）。
もし、プレーヤ場の範囲から出ていれば、処理要求をＯ
ＦＦして処理を無効化する処理が実行される（ステップ
Ｓ７５）。そして、処理は終了する。なお、ラケットに
関するキー操作情報は、固定プレーヤ場７Ｃに付属する
移動物体管理テーブル７Ｄの「キー操作」部分に登録さ
れる。

【０１５１】ここで、可動プレーヤ場について説明を付
け加える。図２６はブロック崩しに関する可動プレーヤ
場を説明する図である。図２６において、７Ｇは可動プ
レーヤ場を示し、７Ｉはタマを示し、７Ｈは可動プレー
ヤ場７Ｇの移動物体管理テーブルを示している。

【０１５２】ブロック崩しの可動プレーヤ場７Ｇは、そ
の移動部分をタマ７Ｉとする。その生成は、全体処理部
によって行なわれ、プレーヤ（人）が制御することはで
きない。タマ７Ｉは、プレーヤの操作によって移動（左
右回転、左右横移動、下降）方向を制御することはでき
ない。移動物体であるタマ７Ｉは移動物体管理テーブル
７Ｈによって管理される。

【０１５３】この移動物体管理テーブル７Ｈ上のキー処
理登録は無効である。登録内容が何であっても処理しな
い。または、何もせずすぐに処理を終了する手続き（ダ
ミー手続き）を登録しておく。ブロック崩しにおいて、
プレーヤ（人）が初期設定によって制御可能なのは、タ
マ７Ｉの「移動速度」である。例えば、上級者向けは、
タマを早く移動し、初級者用はタマをゆっくり移動する
ように設定できるようにする。

【０１５４】つぎに、ブロック崩しの全体処理について
説明する。図２７はブロック崩しの全体処理を説明する
フローチャートである。図２７において、ブロック崩し
の全体処理では、まずブロック崩しの全体処理サブルー
チンのアドレスが全体処理テーブルに登録される（ステ
ップＳ８１）。

【０１５５】そして、ゲーム終了が判定される（ステッ
プＳ８２）。ここで、ゲーム終了とは、ブロック全部の
消滅、ゲーム時間終了を指す。したがって、ステップＳ
８２において以上の内容が判定され、ブロック全部の消
滅が確認された場合（ステップＳ８３）、ゲーム時間終
了が確認された場合（ステップＳ８４）、本ブロック崩
しのゲームは終了する。

【０１５６】また、いずれのゲーム終了内容にも該当し
なければ、ゲーム終了とはせず、ステップＳ８５におい
て得点がカウントされる。すなわち、消滅ブロックが計
数される。そして、タマの存在が確認され（ステップＳ
８６）、タマが消滅していなければゲームが続行される
が、タマが消滅していればステップＳ８７においてタマ
を生成してからゲームが続行される。この生成は可動プ
レーヤ場７Ｇで行われる。

【０１５７】つづいて、インベーダ（登録商標）を例に
挙げる。図２８はゲームとしてインベーダに関する固定
／可動ゲーム場の一例を説明する図であり、図２９はゲ
ームとしてインベーダに関する固定プレーヤ場などの一
例を説明する図である。図２８において、８Ａは固定ゲ
ーム場を示し、８Ｂは可動ゲーム場を示している。図２
９において、８Ｃは固定プレーヤ場を示し、８Ｄは移動
物体管理テーブルを示し、８Ｅは移動陣地を示してい
る。

【０１５８】インベーダは、天井にぶら下がったブロッ
ク群をタマで破壊していくゲームであるインベーダは時
間とともに下に移動し、ロケット攻撃を行うゲームを言
う。プレーヤもこの攻撃に応戦して、タマを左右に移動
する砲台から発射する。インベーダを全て打ち落とすと
プレーヤの勝ちとなり、インベーダの攻撃により砲台を
破壊させると、プレーヤの負けとなる。

【０１５９】また、インベーダが砲台または床に達する
とプレーヤの負けとなる。ロケットが床に達するとロケ
ットは消滅する。陣地とインベーダの間には島があり、
この島でインベーダの攻撃を防ぐことができる。タマ
は、インベーダ、ロケットあるいは島に衝突するとそれ
らを破壊する。タマの数には限りが無く、時間が終了す
るまでタマを何発でも発射することができる。

【０１６０】つぎに、インベーダのゲーム場／プレーヤ
場の設定を以下に示す。（１）固定ゲーム場８Ａインベーダの固定場の４つの面（壁）の属性は、以下の
通りである。・天井、右壁、左壁：「妨害」インベーダは壁にあたっ
たら移動出来ない。・床面：「吸収」インベーダが床に触れる
と消滅する。（ゲームが終わる）・盾：「吸収」インベーダからの攻撃を
防ぐ盾（陣地）である。この部分は、「破壊」とし、イ
ンベーダの攻撃により破壊してもよい。・その他：「無作用」

【０１６１】（２）可動ゲーム場８Ｂインベーダの可動ゲーム場８Ｂの４つの面（壁）の属性
は、以下の通りである。・天井：「破壊」インベーダの可動ゲー
ム場は「インベーダ」である。プレーヤの発射したタマ
（可動プレーヤ場）にあたると、インベーダは破壊す
る。（消滅する。）・右壁、左壁、床面：「無作用」タマ（可動プレー
ヤ場）には作用しない。・その他：「無作用」この実施の形態では、インベーダの属性を可動ゲーム場
８Ｂの単独セルとしたが、移動物体：複数ブロックとす
ることもできる。この場合、インベーダ：移動物体は、
左右に揺れたり、下降上昇の動作を行うことができる。

【０１６２】（３）固定プレーヤ場８Ｃ，移動物体管理
テーブル８Ｄ，陣地８Ｅインベーダの固定プレーヤ場８Ｃは移動物体である移動
陣地８Ｅをもつ。この移動陣地８Ｅは、（８Ｄ）移動物
体管理テーブルの情報によって管理される。移動陣地８
Ｅの数は１個なので、移動物体管理テーブル８Ｄの数も
１個となる。

【０１６３】つぎに、インベーダの陣地移動処理につい
て説明する。図３０は陣地移動処理を説明するフローチ
ャートである。陣地移動処理では、キー情報は、移動物
体管理テーブル８Ｄに登録される。プレーヤ（人）の有
効なキー操作は、タマ発射，「左」または「右」であ
る。移動陣地８Ｅは、左右の壁にあたるとそれ以上は移
動できない。

【０１６４】図３０において、キー操作によりキー操作
情報が取り込まれ、まずそのキー情報に応じて移動種別
が判別される（ステップＳ８１）。この判別によりタマ
発射，左移動および右移動のいずれかであれば、移動処
理要求が作成される。すなわち、移動種別がタマ発射，
左または右の移動であれば、処理はステップＳ９２Ａ
１，ステップＳ９２Ａ２またはステップＳ９２Ａ３へ移
行して図３０に従う移動処理要求を作成する。また、い
ずれの移動種別にも該当しない移動であれば、対象範囲
外として処理は終了する。

【０１６５】ステップＳ９２Ａ１，ステップＳ９２Ａ２
またはステップＳ９２Ａ３の移動種別に応じた移動状態
がプレーヤ場の範囲に入っているかどうか判定され（ス
テップＳ９３）、範囲内に入っていれば動作要求が行わ
れる（ステップＳ９４）。もし、プレーヤ場の範囲から
出ていれば、処理要求をＯＦＦして処理を無効化する処
理が実行される（ステップＳ９５）。そして、処理は終
了する。なお、移動陣地８Ｅに関するキー操作情報は、
固定プレーヤ場８Ｃに付属する移動物体管理テーブル８
Ｄの「キー操作」部分に登録される。

【０１６６】ここで、可動プレーヤ場について説明を付
け加える。図３１はインベーダに関する可動プレーヤ場
を説明する図である。図３１において、８Ｆは可動プレ
ーヤ場を示し、８Ｈは迎撃ロケットを示し、８Ｇは可動
プレーヤ場８Ｆの移動物体管理テーブルを示している。

【０１６７】インベーダの可動プレーヤ場８Ｆは、タマ
である迎撃ロケット８Ｈを移動させる場である。その生
成はプレーヤが発射スイッチ（操作キー）によって制御
することができる。発射された迎撃ロケット８Ｈは、イ
ンベーダおよび固定陣地（固定ゲーム場８Ａ）を破壊す
る。一度発射した迎撃ロケット８Ｈは、プレーヤの操作
によって移動（左右回転、左右横移動、下降）すること
はできない。迎撃ロケット８Ｈは「移動物体」なので、
移動物体管理テーブル８Ｇによって管理されるが、キー
操作は無効である。この場合、無処理が移動物体管理テ
ーブル８Ｇに登録される。

【０１６８】つぎに、インベーダの全体処理について説
明する。図３２はインベーダの全体処理を説明するフロ
ーチャートである。図３２において、ブロック崩しの全
体処理では、まずブロック崩しの全体処理サブルーチン
のアドレスが全体処理テーブルに登録される（ステップ
Ｓ１０１）。そして、ゲーム終了が判定される（ステッ
プＳ１０２）。

【０１６９】ここで、ゲーム終了とは、一定数以上のブ
ロック生成、ゲーム時間終了、ゲーム進行不能状態を指
す。したがって、ステップＳ１０２において以上の内容
が判定され、一定数以上のブロック生成が確認された場
合（ステップＳ１０３）、ゲーム時間終了が確認された
場合（ステップＳ１０４）、ゲーム進行不能状態が確認
された場合（ステップＳ１０５）、本インベーダのゲー
ムは終了する。

【０１７０】また、いずれのゲーム終了内容にも該当し
なければ、ゲーム終了とはせず、ステップＳ１０６にお
いて可動ゲーム場８Ｆを用いてインベーダに対するロケ
ット発射が行われる。続いて、得点がカウントされる。
すなわち、得点のカウントは、列消去されたブロックの
数で行われる。

【０１７１】なお、ステップＳ１０５で判定されるゲー
ム不能状態には、撃つタマが尽きた／インベーダが消滅
した／インベーダに爆撃された等の事象発生が含まれ
る。

【０１７２】つづいて、テニスを例に挙げる。図３３は
ゲームとしてテニスに関する固定／可動ゲーム場の一例
を説明する図である。図３３において、９Ａは固定ゲー
ム場、９Ｂは固定プレーヤ場、９Ｃは移動物体管理テー
ブル、９Ｄはラケットを示している。以下に説明する
「テニス」のゲームは、平面ゲームなのでパーソナルコ
ンピュータや卓上ゲーム機に適用されるテニスゲームと
は違う動作となる。すなわち、ゲームの制約として、例
えば、サーブがない／ボレーのみの打ち合い／シングル
スのみが含まれる。なお、ネットプレイは可能である。

【０１７３】ここで、テニスのゲーム場／プレーヤ場の
設定を以下に示す。（１）固定ゲーム場９Ａテニスの固定場の４つの面（壁）の属性は、以下の通り
である。・天井、床面、左壁、右壁：「吸収」テニスボールは
天井または床にあたったら消滅する。・中心線：「透過」タマはネット
（中心線）をすり抜ける。なお、平面ゲームなので、タ
マがネットに引っ掛かることはない。・その他：「無作用」

【０１７４】（２）可動ゲーム場本テニスゲームには、可動ゲーム場はない。全セルの属
性が、「無作用」である。（３）固定プレーヤ場９Ｂ，移動物体管理テーブル９
Ｃ，ラケット９Ｄテニスの固定プレーヤ場９Ｂはラケット９Ｄを移動させ
る場である。ラケット９Ｄの動作は、上下左右への移動
のみである。ラケット９Ｄは２本必要なので、対戦型ゲ
ームとすることも可能である。また、一方のラケット９
Ｄを可動ゲーム場または一方の壁を固定ゲーム場（反転
属性）としてタマを打ち返し１人でゲームを実行するこ
とも可能である。移動物体であるラケット９Ｄは、移動
物体管理テーブル９Ｃによって動作を管理され、当該テ
ーブル内のキー処理部にラケット９Ｄの移動処理（図３
４に示す）が登録される。

【０１７５】つぎに、テニスの動作について説明する。
図３４はテニスのラケット移動処理を説明するフローチ
ャートである。ラケット移動処理では、キー情報は、移
動物体管理テーブル９Ｃに登録される。プレーヤ（人）
の有効なキー操作は、「左」と「右」ヘの移動である。
ラケットは、左右の壁にあたるとそれ以上は移動できな
い。テニスにおいて、ラケット９Ｄの「大きさ：形状」
について、例えば、上級者向けは、ラケットを小さく、
初級者用はラケットを大きく設定できるようにしてもよ
い。

【０１７６】図３４において、キー操作によりキー操作
情報が取り込まれ、まずそのキー情報に応じて移動種別
が判別される（ステップＳ１１１）。この判別により左
移動／右移動のいずれかであれば、移動処理要求が作成
される。すなわち、移動種別が左または右への移動であ
れば、処理はステップＳ１１２Ａ１またはステップＳ１
１２Ａ２へ移行して図３４に従う移動処理要求を作成す
る。また、いずれの移動種別にも該当しない移動であれ
ば、対象範囲外として処理は終了する。

【０１７７】ステップＳ１１２Ａ１またはステップＳ１
１２Ａ２の移動種別に応じた移動状態がプレーヤ場の範
囲に入っているかどうか判定され（ステップＳ１１
３）、範囲内に入っていれば動作要求が行われる（ステ
ップＳ１１４）。もし、プレーヤ場の範囲から出ていれ
ば、処理要求をＯＦＦして処理を無効化する処理が実行
される（ステップＳ１１５）。そして、処理は終了す
る。なお、ラケットに関するキー操作情報は、固定プレ
ーヤ場９Ｂに付属する移動物体管理テーブル９Ｃの「キ
ー操作」部分に登録される。

【０１７８】ここで、可動プレーヤ場について説明を付
け加える。図３５はテニスに関する可動プレーヤ場を説
明する図である。図３５において、９Ｆは可動プレーヤ
場を示し、９Ｈはタマを示し、９Ｇは可動プレーヤ場９
Ｆの移動物体管理テーブルを示している。

【０１７９】テニスの可動プレーヤ場９Ｆは、タマ９Ｈ
を移動させる場である。その生成は、全体処理部によっ
て行なわれ、プレーヤ（人）が制御することはできな
い。タマ９Ｈは、プレーヤの操作によって移動（左右回
転、左右横移動、下降）方向を制御することはできな
い。移動物体であるタマ９Ｈは移動物体管理テーブル９
Ｇによって管理される。

【０１８０】この移動物体管理テーブル９Ｇ上のキー処
理登録は無効である。登録内容が何であっても処理しな
い。または、何もせずすぐに処理を終了する手続き（ダ
ミー手続き）を登録しておく。テニスにおいて、プレー
ヤ（人）が初期設定によって制御可能なのは、タマ９Ｈ
の「移動速度」である。例えば、上級者向けは、タマを
早く移動し、初級者用はタマをゆっくり移動するように
設定できるようにする。なお、タマはラケットで打つ以
外は利用者によって制御することはできないものとす
る。

【０１８１】つぎに、テニスの全体処理について説明す
る。図３６はテニスの全体処理を説明するフローチャー
トである。図３６において、テニスの全体処理では、ま
ずテニスの全体処理サブルーチンのアドレスが全体処理
テーブルに登録される（ステップＳ１２１）。そして、
ゲーム終了が判定される（ステップＳ１２２）。ここ
で、ゲーム終了とは、ゲームセットを指す。したがっ
て、ステップＳ１１２において以上の内容が判定され、
ゲームセットが確認された場合（ステップＳ１２３）、
本テニスのゲームは終了する。

【０１８２】また、いずれのゲーム終了内容にも該当し
なければ、ゲーム終了とはせず、ステップＳ１２４にお
いて得点がカウントされる。そして、タマの存在が確認
され（ステップＳ１２５）、タマが消滅していなければ
ゲームが続行されるが、タマが消滅していればステップ
Ｓ１２６においてタマを生成してからゲームが続行され
る。この生成は可動プレーヤ場９Ｆで行われる。

【０１８３】つづいて、スカッシュを例に挙げる。図３
７はゲームとしてスカッシュに関する固定／可動ゲーム
場の一例を説明する図である。図３７において、１０Ａ
は固定ゲーム場、１０Ｂは固定プレーヤ場、１０Ｃは移
動物体管理テーブル、１０Ｄはラケットを示している。
以下に説明するスカッシュは、１人でゲームするもの
で、４つの壁全てにボールを反射させて得点を得る。プ
レーヤ（人）はラケットを動かし（操作し）、ラケット
にあてることができれば得点となる。

【０１８４】ここで、スカッシュのゲーム場／プレーヤ
場の設定を以下に示す。（１）固定ゲーム場１０Ａスカッシュの固定場の４つの面（壁）の属性は、以下の
通りである。・天井、床面、右壁、左壁：「反射」タマは右壁・左
壁、天井または床にあたったら弾性反転する。・その他：「無作用」

【０１８５】（２）可動ゲーム場スカッシュには、可動ゲーム場はない。全セルの属性
が、「無作用」である。（３）固定プレーヤ場１０Ｂ，移動物体管理テーブル１
０Ｃ，ラケット１０Ｄスカッシュの固定プレーヤ場１０Ｂはラケット１０Ｄを
移動させる場である。ラケット１０Ｄは２本必要なの
で、対戦型ゲームとすることも可能である。また、ラケ
ット１０Ｄを１本とし１人でゲームを実行することも可
能である。ラケット１０Ｄの動作は、左右への移動のみ
である。移動物体であるラケット１０Ｄは移動物体管理
テーブル１０Ｃによって動作を管理され、当該テーブル
内のキー処理部にラケット１０Ｄの移動処理が登録され
る。

【０１８６】つぎに、スカッシュの動作について説明す
る。図３８はスカッシュのラケット移動処理を説明する
フローチャートである。ラケット移動処理では、キー情
報は、移動物体管理テーブル１０Ｃに登録される。プレ
ーヤ（人）の有効なキー操作は、「左」と「右」ヘの移
動である。ラケット１０Ｄは、左右の壁にあたるとそれ
以上は移動できない。スカッシュにおいて、ラケット１
０Ｄの「大きさ：形状」について、例えば、上級者向け
は、ラケットを小さく、初級者用はラケットを大きく設
定できるようにしてもよい。

【０１８７】図３８において、キー操作によりキー操作
情報が取り込まれ、まずそのキー情報に応じて移動種別
が判別される（ステップＳ１３１）。この判別により左
移動／右移動のいずれかであれば、移動処理要求が作成
される。すなわち、移動種別が左または右への移動であ
れば、処理はステップＳ１３２Ａ１またはステップＳ１
３２Ａ２へ移行して図３８に従う移動処理要求を作成す
る。また、いずれの移動種別にも該当しない移動であれ
ば、対象範囲外として処理は終了する。

【０１８８】ステップＳ１３２Ａ１またはステップＳ１
３２Ａ２の移動種別に応じた移動状態がプレーヤ場の範
囲に入っているかどうか判定され（ステップＳ１３
３）、範囲内に入っていれば動作要求が行われる（ステ
ップＳ１３４）。もし、プレーヤ場の範囲から出ていれ
ば、処理要求をＯＦＦして処理を無効化する処理が実行
される（ステップＳ１３５）。そして、処理は終了す
る。なお、ラケットに関するキー操作情報は、固定プレ
ーヤ場１０Ｂに付属する移動物体管理テーブル１０Ｃの
「キー操作」部分に登録される。

【０１８９】ここで、可動プレーヤ場について説明を付
け加える。図３９はスカッシュに関する可動プレーヤ場
を説明する図である。図３９において、１０Ｆは可動プ
レーヤ場を示し、１０Ｈはタマを示し、１０Ｇは可動プ
レーヤ場１０Ｆの移動物体管理テーブルを示している。

【０１９０】スカッシュの可動プレーヤ場１０Ｆは、タ
マ１０Ｈを移動させる場である。その生成は、全体処理
部によって行なわれ、プレーヤ（人）が制御することは
できない。タマ１０Ｈは、プレーヤの操作によって移動
（左右回転、左右横移動、下降）方向を制御することは
できない。移動物体であるタマ１０Ｈは移動物体管理テ
ーブル１０Ｇによって管理される。この移動物体管理テ
ーブル１０Ｇ上のキー処理登録は無効である。登録内容
が何であっても処理しない。または、何もせずすぐに処
理を終了する手続き（ダミー手続き）を登録しておく。

【０１９１】スカッシュにおいて、プレーヤ（人）が初
期設定によって制御可能なのは、タマ１０Ｈの「移動速
度」である。例えば、上級者向けは、タマを早く移動
し、初級者用はタマをゆっくり移動するように設定でき
るようにする。なお、タマはラケットで打つ以外は利用
者によって制御することはできないものとする。

【０１９２】つぎに、スカッシュの全体処理について説
明する。図４０はスカッシュの全体処理を説明するフロ
ーチャートである。図４０において、スカッシュの全体
処理では、まずスカッシュの全体処理サブルーチンのア
ドレスが全体処理テーブルに登録される（ステップＳ１
４１）。そして、ゲーム終了が判定される（ステップＳ
１４２）。ここで、ゲーム終了とは、ゲームセットを指
す。したがって、ステップＳ１４２において以上の内容
が判定され、ゲームセットが確認された場合（ステップ
Ｓ１４３）、本スカッシュのゲームは終了する。

【０１９３】また、いずれのゲーム終了内容にも該当し
なければ、ゲーム終了とはせず、ステップＳ１４４にお
いて得点がカウントされる。そして、タマの存在が確認
され（ステップＳ１４５）、タマが消滅していなければ
ゲームが続行されるが、タマが消滅していればステップ
Ｓ１４６においてタマを生成してからゲームが続行され
る。この生成は可動プレーヤ場１０Ｆで行われる。

【０１９４】つづいて、迷路を例に挙げる。図４１はゲ
ームとして迷路に関する固定／可動ゲーム場の一例を説
明する図であり、図４２はゲームとして迷路に関する固
定プレーヤ場などの一例を説明する図である。図４１に
おいて、１１Ａは固定ゲーム場を示し、１１Ｂは可動ゲ
ーム場を示している。図４２において、１１Ｃは可動プ
レーヤ場を示し、１１Ｄは移動物体管理テーブルを示
し、１１Ｅはラットを示している。迷路ゲームは、事前
に設定された通路を通って、できるだけ早くゴールに到
達する内容のゲームである。

【０１９５】ここで、迷路のゲーム場／プレーヤ場の設
定を以下に示す。（１）固定ゲーム場１１Ａ迷路の固定場の属性は、以下の通りである。・迷路：「妨害」ラット（移動物）は壁にあたった
ら移動出来ない。ラットは、必ず少なくとも１方向には
移動可能である。・その他：「無作用」

【０１９６】（２）可動ゲーム場１１Ｂ迷路の可動ゲーム場１１Ｂは、ゴール（宝）を表す場で
ある。ラット１１Ｅがそのゴールに到達したら迷路ゲー
ムは終了となる。（３）固定プレーヤ迷路には固定プレーヤ場は無い。プレーヤの使う道具が
ない。全セルの属性を「無作用」とする。

【０１９７】（４）可動プレーヤ場１１Ｃ，移動物体管
理テーブル１１Ｄ，ラット１１Ｅ迷路の可動プレーヤ場１１Ｃは、移動物体であるラット
１１Ｅを移動させる場である。ラット１１Ｅについて、
プレーヤ（人）の操作によって移動（左右横移動、上下
移動）動作を行う。迷路における可動プレーヤ場１１Ｃ
内のラット１１Ｅは、一つのみである。この移動物体で
あるラット１１Ｅは、移動物体管理テーブル１１Ｄによ
って管理される。キー操作によるラット１１Ｅの移動処
理（図４３に示す）は移動物体管理テーブル１１Ｄに登
録される。

【０１９８】つぎに、ラット移動処理について説明す
る。図４３はラット移動処理を説明するフローチャート
である。迷路では、プレーヤによってキー操作をされる
と、ラットを移動または回転させる。そのため、まずキ
ー情報を読み込んで移動種別が判別される（ステップＳ
１５１）。この判別により上移動／下移動／左移動／右
移動のいずれかであれば、移動処理要求が作成される。

【０１９９】すなわち、移動種別が上下左右のいずれか
への移動であれば、処理はステップＳ１５２Ａ１，ステ
ップＳ１５２Ａ２，ステップＳ１５２Ａ３または１５２
Ａ４へ移行して図４３に従う移動処理要求を作成する。
また、いずれの移動種別にも該当しない移動であれば、
対象範囲外として処理は終了する。

【０２００】ステップＳ１５２Ａ１〜ステップＳ１５２
Ａ４のいずれかの移動種別に応じた移動状態がプレーヤ
場の範囲に入っているかどうか判定され（ステップＳ１
５３）、範囲内に入っていれば動作要求が行われる（ス
テップＳ１５４）。もし、プレーヤ場の範囲から出てい
れば、処理要求をＯＦＦして処理を無効化する処理が実
行される（ステップＳ１５５）。そして、処理は終了す
る。なお、キー操作情報は、可動プレーヤ場１１Ｃに付
属する移動物体管理テーブル１１Ｄの「キー操作」部分
に登録される。

【０２０１】つぎに、迷路の全体処理について説明す
る。図４４は迷路の全体処理を説明するフローチャート
である。図４４において、迷路の全体処理では、まず迷
路の全体処理サブルーチンのアドレスが全体処理テーブ
ルに登録される（ステップＳ１６１）。そして、ゲーム
終了が判定される（ステップＳ１５２）。

【０２０２】ここで、ゲーム終了とは、ゴール地点：宝
の場所への到達、ゲーム時間終了を指す。したがって、
ステップＳ１６２において以上の内容が判定され、ゴー
ル到達が確認された場合（ステップＳ１６３）、ゲーム
時間終了が確認された場合（ステップＳ１６４）、本迷
路のゲームは終了する。なお、いずれのゲーム終了内容
にも該当しなければ、ゲーム終了とはせず、ゲームが続
行される。

【０２０３】以上説明したように、この実施の形態によ
れば、ゲーム実行の際に、実行すべきゲームに対応させ
てゲーム別に記憶された進行状態を切り替え、その切り
替えられたゲームの進行状態をプレーヤが操作できない
ゲーム場とプレーヤが操作できるプレーヤ場とに分けて
管理し、その管理されるゲーム場とプレーヤ場のゲーム
の進行状態を合成して表示する。これにより、複数のゲ
ームが統合化されてゲーム別にプログラムを用意する必
要がなくなるので、ゲームに必要なプログラムメモリ容
量を大幅に削減させるとともに一つのソフトで複数のプ
ログラムを同時に実行させることが可能である。

【０２０４】また、ゲーム場とプレーヤ場との間でゲー
ムの進行状態に矛盾があった場合にゲームの整合をとる
ようにしたので、ゲーム場とプレーヤ場間の矛盾を解消
することが可能である。

【０２０５】また、ゲーム別に、キー操作などで部分的
にゲームルールを任意に記述するようにしたので、ゲー
ム毎に独立したソフトウェアを開発する必要がなく、大
掛かりな開発作業が不要である。

【０２０６】また、ゲーム別に、ゲーム場およびプレー
ヤー場の各構成要素を任意に設定するようにしたので、
設定の応じてオリジナルのゲームを作成することが可能
である。

【０２０７】また、ゲーム別に、ゲーム画面形状と任意
のゲーム画面構成を任意に設定するようにしたので、ゲ
ームの制御に影響を与えずに各ゲームに対して独立して
所望の環境を用意することができる。これにより、ゲー
ム画面形状やゲーム画面構成に依存しないゲーム実行管
理を実現することが可能である。

【０２０８】また、ゲームの実行中にゲーム場面形状お
よびゲーム作用を任意に変更するようにしたので、ゲー
ム実行中のゲーム場面の変化に影響されないゲーム実行
管理を実現することが可能である。

【０２０９】また、ゲーム中断時には、当該ゲームの進
行状態を待避させ、ゲーム復元時には、中断によって待
避されたゲームの進行状態を読み出して実行状態を復元
するようにしたので、中断があっても中断時の進行状態
でゲームを再開することができる。これにより、複数の
ゲームを同時に実行することが可能である。

【０２１０】また、本ゲーム実行管理装置を移動通信端
末に適用すれば、ゲーム実行中に移動通信端末でゲーム
以外の処理が操作された場合、ゲームを中断して実行す
る際に、当該ゲームの進行状態を待避させ、ゲーム以外
の処理が終了した際に、中断によって待避されたゲーム
の進行状態を読み出してゲームを再開することができ
る。これにより、ゲーム以外の処理が割り込んでも、そ
の後に中断時の進行状態でゲームを再開することができ
るので、ゲームと他の処理とを同時に実行することが可
能である。

【０２１１】また、ゲーム操作部１Ｇとゲーム表示部１
Ｆとの組をインタフェース部１Ｉで複数組接続すれば、
ゲーム別に、各組のゲームの進行状態を記憶することが
できる。これにより、対戦ゲームなどで複数のプレーヤ
が離れた場所でも一緒にゲームを操作することが可能で
ある。

【０２１２】以上、この発明を上述の実施の形態により
説明したが、この発明の主旨の範囲内で種々の変形が可
能であり、これらをこの発明の範囲から排除するもので
はない。

【０２１３】

【発明の効果】以上説明したように、この発明によれ
ば、ゲーム実行の際に、実行すべきゲームに対応させて
ゲーム別に記憶された進行状態を切り替え、その切り替
えられたゲームの進行状態をプレーヤが操作できないゲ
ーム場とプレーヤが操作できるプレーヤ場とに分けて管
理し、その管理されるゲーム場とプレーヤ場のゲームの
進行状態を合成して表示するようにしたので、複数のゲ
ームが統合化されてゲーム別にプログラムを用意する必
要がなく、これにより、ゲームに必要なプログラムメモ
リ容量を大幅に削減させるとともに一つのソフトで複数
のプログラムを同時に実行させることが可能なゲーム実
行管理装置が得られるという効果を奏する。

【０２１４】つぎの発明によれば、ゲーム場とプレーヤ
場との間でゲームの進行状態に矛盾があった場合にゲー
ムの整合をとるようにしたので、ゲーム場とプレーヤ場
間の矛盾を解消することが可能なゲーム実行管理装置が
得られるという効果を奏する。

【０２１５】つぎの発明によれば、ゲーム別に、部分的
にゲームルールを任意に記述するようにしたので、ゲー
ム毎に独立したソフトウェアを開発する必要がなく、大
掛かりな開発作業が不要なゲーム実行管理装置が得られ
るという効果を奏する。

【０２１６】つぎの発明によれば、ゲーム別に、ゲーム
場およびプレーヤー場の各構成要素を任意に設定するよ
うにしたので、設定の応じてオリジナルのゲームを作成
することが可能なゲーム実行管理装置が得られるという
効果を奏する。

【０２１７】つぎの発明によれば、ゲーム別に、ゲーム
画面形状と任意のゲーム画面構成を任意に設定するよう
にしたので、ゲームの制御に影響を与えずに各ゲームに
対して独立して所望の環境を用意することができ、これ
により、ゲーム画面形状やゲーム画面構成に依存しない
ゲーム実行管理を実現することが可能なゲーム実行管理
装置が得られるという効果を奏する。

【０２１８】つぎの発明によれば、ゲームの実行中にゲ
ーム場面形状およびゲーム作用を任意に変更するように
したので、ゲーム実行中のゲーム場面の変化に影響され
ないゲーム実行管理を実現することが可能なゲーム実行
管理装置が得られるという効果を奏する。

【０２１９】つぎの発明によれば、ゲーム中断時には、
当該ゲームの進行状態を待避させ、ゲーム復元時には、
中断によって待避されたゲームの進行状態を読み出して
実行状態を復元するようにしたので、中断があっても中
断時の進行状態でゲームを再開することができ、これに
より、複数のゲームを同時に実行することが可能なゲー
ム実行管理装置が得られるという効果を奏する。

【０２２０】つぎの発明によれば、ゲーム実行管理装置
を移動通信端末に適用して、ゲーム実行中に移動通信端
末でゲーム以外の処理が操作された場合、ゲームを中断
して実行する際に、当該ゲームの進行状態を待避させ、
ゲーム以外の処理が終了した際に、中断によって待避さ
れたゲームの進行状態を読み出してゲームを再開するよ
うにしたので、ゲーム以外の処理が割り込んでも、その
後に中断時の進行状態でゲームを再開することができ、
これにより、ゲームと他の処理とを同時に実行すること
が可能なゲーム実行管理装置が得られるという効果を奏
する。

【０２２１】つぎの発明によれば、ゲーム操作手段とゲ
ーム表示手段との組を複数組接続しても、ゲーム別に、
各組のゲームの進行状態を記憶するようにしたので、複
数のプレーヤが離れた場所でも一緒にゲームを操作する
ことが可能なゲーム実行管理装置が得られるという効果
を奏する。

【０２２２】つぎの発明によれば、複数のゲームのうち
のいずれかのゲームを実行している際に、プレーヤから
の１回の操作入力に応じてプレーヤが操作できないゲー
ム場とプレーヤが操作できるプレーヤ場の進行状態をそ
れぞれ処理してその結果である進行状態を合成表示する
工程にしたので、複数のゲームが統合化されてゲーム別
にプログラムを用意する必要がなく、これにより、ゲー
ムに必要なプログラムメモリ容量を大幅に削減させると
ともに一つのソフトで複数のプログラムを同時に実行さ
せることが可能なゲーム実行管理方法が得られるという
効果を奏する。

【０２２３】つぎの発明によれば、ゲーム場とプレーヤ
場間の合成表示上に不整合があれば、ゲーム場とプレー
ヤ場の各進行状態に対して整合処理を実行する工程を含
むようにしたので、ゲーム場とプレーヤ場間の矛盾を解
消することが可能なゲーム実行管理方法が得られるとい
う効果を奏する。

【０２２４】つぎの発明によれば、ゲーム場とプレーヤ
場の進行状態を合成表示した後に、メモリにゲーム場と
プレーヤ場の進行状態を保持する工程を含むようにした
ので、他のゲームあるいは他の処理に一時的に移行して
も、中断時の進行状態でゲームを再開することが可能な
ゲーム実行管理方法が得られるという効果を奏する。

【図面の簡単な説明】

【図１】この発明の一実施の形態によるゲーム実行管
理装置を機能的に示すブロック図である。

【図２】図１の基本構成を概念的に示した図である。

【図３】図１の情報管理方式を概念的に示した図であ
る。

【図４】装置全体の動作を概略的に説明するフローチ
ャートである。

【図５】動作要求処理を説明するフローチャートであ
る。

【図６】動作指示処理を説明するフローチャートであ
る。

【図７】図１に示したゲーム整合処理部の動作を説明
するフローチャートである。

【図８】図７の移動処理を説明するフローチャートで
ある。

【図９】図１に示したゲーム整合部の動作を説明する
フローチャートである。

【図１０】固定ゲーム場を説明する図である。

【図１１】固定ゲーム場の場合の属性を説明する図で
ある。

【図１２】可動ゲーム場を説明する図である。

【図１３】固定ゲーム場の場合の属性を説明する図で
ある。

【図１４】固定プレーヤ場を説明する図である。

【図１５】可動プレーヤ場を説明する図である。

【図１６】ゲームとしてテトリスに関するゲーム場／
プレーヤ場などの一例を説明する図である。

【図１７】テトリスブロックの種類を説明する図であ
る。

【図１８】テトリスブロックの移動処理を説明するフ
ローチャートである。

【図１９】テトリスブロックの回転処理を説明する図
である。

【図２０】図１９に示した回転処理の変換テーブルを
示す図である。

【図２１】テトリスにおける全体処理を説明するフロ
ーチャートである。

【図２２】テトリスにおける全体処理を説明するフロ
ーチャートである。

【図２３】ゲームとしてブロック崩しに関する固定／
可動ゲーム場の一例を説明する図である。

【図２４】ゲームとしてブロック崩しに関する固定プ
レーヤ場などの一例を説明する図である。

【図２５】ブロック崩しのラケット移動処理を説明す
るフローチャートである。

【図２６】ブロック崩しに関する可動プレーヤ場を説
明する図である。

【図２７】ブロック崩しの全体処理を説明するフロー
チャートである。

【図２８】ゲームとしてインベーダに関する固定／可
動ゲーム場の一例を説明する図である。

【図２９】ゲームとしてインベーダに関する固定プレ
ーヤ場などの一例を説明する図である。

【図３０】陣地移動処理を説明するフローチャートで
ある。

【図３１】インベーダに関する可動プレーヤ場を説明
する図である。

【図３２】インベーダの全体処理を説明するフローチ
ャートである。

【図３３】ゲームとしてテニスに関する固定／可動ゲ
ーム場の一例を説明する図である。

【図３４】テニスのラケット移動処理を説明するフロ
ーチャートである。

【図３５】テニスに関する可動プレーヤ場を説明する
図である。

【図３６】テニスの全体処理を説明するフローチャー
トである。

【図３７】ゲームとしてスカッシュに関する固定／可
動ゲーム場の一例を説明する図である。

【図３８】スカッシュのラケット移動処理を説明する
フローチャートである。

【図３９】スカッシュに関する可動プレーヤ場を説明
する図である。

【図４０】スカッシュの全体処理を説明するフローチ
ャートである。

【図４１】ゲームとして迷路に関する固定／可動ゲー
ム場の一例を説明する図である。

【図４２】ゲームとして迷路に関する固定プレーヤ場
などの一例を説明する図である。

【図４３】ラット移動処理を説明するフローチャート
である。

【図４４】迷路の全体処理を説明するフローチャート
である。

【図４５】従来のゲーム実行管理装置を機能的に示す
ブロック図である。

【図４６】従来のゲーム実行管理装置の動作を説明す
るフローチャートである。

【図４７】従来のゲーム実行管理装置による一ゲーム
の動作を説明するフローチャートである。

【図４８】従来のゲーム実行管理装置による他のゲー
ムの動作を説明するフローチャートである。

【符号の説明】

１Ａ固定ゲーム場、１Ｂ可動ゲーム場、１Ｃ固定
プレーヤ場、１Ｄ可動プレーヤ場、１Ｅゲーム整合
処理部、１Ｆゲーム表示部、１Ｇゲーム操作部、１
Ｈ音響効果部、１Ｉインタフェース部、１Ｊゲー
ム進行状態記憶部、１Ｋ切替スイッチ、１Ｌゲーム
空間。

Claims

【特許請求の範囲】

【請求項１】あらかじめ用意された複数のゲームにつ
いて各ゲームの実行状態を管理するゲーム実行管理装置
において、前記複数のゲームについてゲーム別に進行状態を記憶す
るゲーム別記憶手段と、ゲーム実行の際に、実行すべきゲームに対応させて前記
ゲーム別記憶手段に記憶されたゲーム別の進行状態を切
り替えるゲーム別進行状態切替え手段と、ゲーム実行の際に、前記ゲーム別進行状態切替え手段で
切り替えられたゲームの進行状態をプレーヤが操作でき
ないゲーム場とプレーヤが操作できるプレーヤ場とに分
けて管理する場管理手段と、ゲーム実行の際に、前記場管理手段で管理されるゲーム
場とプレーヤ場のゲームの進行状態を合成して表示する
ゲーム表示手段と、を備えたことを特徴とするゲーム実行管理装置。
【請求項２】ゲーム実行の際に、前記場管理手段で管
理されるゲーム場とプレーヤ場との間でゲームの進行状
態に矛盾があった場合にゲームの整合をとるゲーム整合
手段をさらに備えたことを特徴とする請求項１に記載の
ゲーム実行管理装置。
【請求項３】前記ゲーム別記憶手段には、ゲーム別
に、部分的にゲームルールが任意に記述されることを特
徴とする請求項１または２に記載のゲーム実行管理装
置。
【請求項４】前記ゲーム別記憶手段には、ゲーム別
に、前記ゲーム場およびプレーヤー場の各構成要素が任
意に設定されることを特徴とする請求項１，２または３
に記載のゲーム実行管理装置。
【請求項５】前記ゲーム別記憶手段には、ゲーム別
に、ゲーム画面形状と任意のゲーム画面構成が任意に設
定されることを特徴とする請求項１〜４のいずれか一つ
に記載のゲーム実行管理装置。
【請求項６】前記ゲーム別記憶手段には、ゲームの実
行中にゲーム場面形状およびゲーム作用が任意に変更さ
れることを特徴とする請求項１〜５のいずれか一つに記
載のゲーム実行管理装置。
【請求項７】ゲーム中断時には、当該ゲームの進行状
態を前記ゲーム別記憶手段に待避させ、ゲーム復元時に
は、中断によって前記ゲーム別記憶手段に待避されたゲ
ームの進行状態を読み出して実行状態を復元することを
特徴とする請求項１〜６のいずれか一つに記載のゲーム
実行管理装置。
【請求項８】前記ゲーム実行管理装置は移動通信端末
に適用され、ゲーム実行中に前記移動通信端末でゲーム
以外の処理が操作された場合、ゲームを中断して実行す
る際に、当該ゲームの進行状態を前記ゲーム別記憶手段
に待避させ、前記ゲーム以外の処理が終了した際に、中
断によって前記ゲーム別記憶手段に待避されたゲームの
進行状態を読み出してゲームを再開することを特徴とす
る請求項１〜７のいずれか一つに記載のゲーム実行管理
装置。
【請求項９】ゲームの実行を操作するゲーム操作手段
と、前記ゲーム操作手段およびゲーム表示手段を接続す
るインタフェース手段とをさらに有し、前記インタフェ
ース手段は、前記ゲーム操作手段と前記ゲーム表示手段
との組を複数組接続可能に設けられ、前記ゲーム別記憶
手段は、ゲーム別に、前記インタフェース手段に接続可
能な組数分のゲームの進行状態を記憶することを特徴と
する請求項１〜８のいずれか一つに記載のゲーム実行管
理装置。
【請求項１０】あらかじめ用意された複数のゲームに
ついて各ゲームの実行状態を管理するゲーム実行管理装
置に適用されるゲーム実行管理方法において、前記ゲーム実行管理装置はメモリを有し、ゲームの進行
状態は、プレーヤが操作できないゲーム場とプレーヤが
操作できるプレーヤ場とに分けてゲーム別に前記メモリ
に管理され、前記複数のゲームのうちのいずれかのゲー
ムを実行している際に、プレーヤからの１回の操作入力
に応じて前記ゲーム場とプレーヤ場の進行状態をそれぞ
れ処理する第１工程と、前記第１工程で処理された進行状態を合成表示する第２
工程と、を含んだことを特徴とするゲーム実行管理方法。
【請求項１１】前記第１工程で処理された進行状態に
ついて前記ゲーム場とプレーヤ場間の合成表示上に不整
合があるか否か判断する第３工程と、前記第３工程により不整合ありという判断結果が得られ
た場合、前記ゲーム場とプレーヤ場の各進行状態に対し
て整合処理を実行する第４工程と、をさらに含んだことを特徴とする請求項１０に記載のゲ
ーム実行管理方法。
【請求項１２】前記第２工程で前記ゲーム場とプレー
ヤ場の進行状態を合成表示した後に、前記メモリに前記
第１工程により処理された前記ゲーム場とプレーヤ場の
進行状態を保持する第５工程をさらに含んだことを特徴
とする請求項１０または１１に記載のゲーム実行管理方
法。