ゲームプログラマが語る。竜田揚げと並列処理のススメ 2011-08-12 13:52

　まるでそれは、世紀末を彩る死鳥星の如し悪意を持って襲いかかる昨今の猛暑。近所のお弁当屋さんにて初お目見え「竜田揚げ弁当」を注文するも、「大きい竜田揚げが、一つだけドンと入っている」という、謎の上位互換機ップリにトキめいてしまいました。
　もう少しネタろうかと書き出した筈なのですが、「死鳥星」が一発で変換出来てしまい、思いがけず８秒ほど無言で怯んでしまったTeamDyquemで御座います。みなさまこんにちは。




　ゲーム制作初心者さん向けのエントリーとして幾つか展開させております、技術ネタ。当ブログにおきましては比較的真面目なネタで筆の乗り辛い、しかしながら、「これをメインコンテンツにしなくてどうするんだカス」的なおしかりが、ジリジリと目に痛い昨今。

　久しぶりの技術ネタで御座いますが。
直接関連性はありませんが、今回も特定の機種に依存させていない話題でありますので、以前の、マルチプラットフォーム開発関連エントリー群

「ゲームプログラマが語る。iOSゲームをWinマルチプラットフォーム開発・その４」
「ゲームプログラマが語る。iOSゲームをWinマルチプラットフォーム開発・その３」
「iPhoneアプリ作者が語る。マルチプラットフォーム化その２・アトミック型定義のススメ」
「ゲームプログラマが語る。iOSゲームをWinマルチプラットフォーム開発・その１」

　上記も、併せてご覧頂けましたら幸いです。

　さて。




　アプリ内におきまして、例えば水槽内でランダムに現れる沢山の泡をバラバラに動かしたい、若しくは、リアルタイム記録系等において、様々な視覚的メーターを個別に制御したいといった様に、単一のアプリとして動作していながらも、その内部では様々な動作がさも並列独立しているかの様に個別に制御させたいという事例が求められる事もあるでしょう。
　ゲーム等はまさにその集大成と言って良く、操作するプレイヤー、飛んでくる敵の弾、画面を舞う爆発エフェクト等、その全てが言ってみれば独立した小さなコンピューターであり、その全てが自律的に動作し、又は他の個体と協調し動作が共鳴していく事で、最終レンダリング結果は構成されています。
　ゲームやそれに類する主にアクション系エンターテイメントアプリというものは、それらフレームを次々と綴る連鎖の上に構築され、美麗なアニメーションとしてユーザーの目に到達するのです。

　この為に重要な技術が、並列化です。並列化に枷のあるシステムによって構築されたゲーム等は、みな一様にどこか動きが固く、画一的な印象をもたらす事が多いものです。そして何より、メンテナンス性を極端に欠き、また実装コストも高くなりがちであり、商業作品と呼ぶには厳しいと言わざるを得ないでしょう。

　並列化が旨く進めば、個別個体のブラッシュアップも自由自在。モジュール差し替えも文字通り差し替えるだけですし、メンテナンス性は抜群です。コストも最小に見積もる事が出来、禁煙も成功し、恋人も出来、宝くじにも当たります。並列化を採用しない手はありませんね。

　ゲームにおける疑似並列処理技術の代表例としましては、昨今では「ファイバー」実装が市民権を得ていると言って良いでしょう。その使い勝手、実装コスト等が、昨今の事例に留まらずゲームというカテゴリーにマッチしているという面が大きい様に思います。

　処理の単位をもう一つ大きな段階にて考える必要のあるアプリ、例えば、WEBブラウザ等において、ページ内フレーム群を構成する際にはファイバー単位では小規模なあまり、使い勝手に優れません。こういったケースではフレーム毎に「スレッド」分化を施すという手法が言わば通例でありましょう。
　更に大きな枠組みとして、タブブラウザ等が持つそれぞれのタブ処理におきましては、スレッドよりも更に大きな処理の枠組みとして、「プロセス｣分化の領域にまで持っていく事も有力な方策と言えます。

　この様に、ざっと羅列しただけでも「ファイバー」「スレッド」「プロセス」と、処理の単位をどの様に区切り、またどの様に運用するかという点に意味の異なる手法がこれだけ挙げられますが、重要な点は用途にマッチする技術の選択であり、ゲームにおける単一のプレイヤーや敵キャラ一体一体を全てスレッド化する事は、通常、良い選択肢ではありません。

　さて。
　ここでは、所謂一般的な「ファイバー」技術に触れてみましょう。
　画面上で沢山のボールが跳ねているといった単純なシチュエーションを仮定します。それぞれのボールにおいては、ある瞬間の情報として速度と位置があり、ボールの数だけこの情報を管理運用していけば良いのですが、これをどこかでまとめて計算するという形はいかにも前時代的でありましょう。「ボール個体」に関する制御をクラス化し、個々のボール情報はそのボールが知っていれば良い、という実装が通例です。

　この時、個々のボールはファイバー特性を持たせる形にし、自律させる事が今回の目的です。
　以下の様なシステムを、この仮定理論の土台に設定してみましょう。

class CFiber 
{
	public:
		class CKernel;
		class CUnit;
};

class CFiber::CKernel
{
	public:
		void Attach( CUnit& aUnit );
		void Detach( CUnit& aUnit );
		void Progress();
};

class CFiber::CUnit :
{
	public:
		virtual void Progress() = 0;
};

　エントリー紹介用の至極シンプルな形になっていますが、重要な点は表現出来ています。CKernelというインスタンスを一つ以上用意し、無数にあるCUnitを登録していくイメージです。CKernelは、自身に登録されているCUnit群のProgressメソッドを、次々に呼び出していくカーネルです。

　このシステムの上に、ボールを載せてみましょう。

class CBall :
	public CFiber::CUnit
{
	public:
		virtual void Progress();
};

CKernel kernel;
CBall ball1;
CBall ball2;
CBall ball3;

kernel.Attach( ball1 );
kernel.Attach( ball2 );
kernel.Attach( ball3 );

while( true )
{
	kernel.Progress();
}

　この様にする事で、任意の数のボールインスタンスをコントロールします。ボールの他に箱も追加で跳ね回らさせたいのであれば、単純に箱を追加すれば事が足りてしまいます。

class CBox :
	public CFiber::CUnit
{
	public:
		virtual void Progress();
};

CBall ball1;
CBall ball2;
CBall ball3;
CBox box1;
CBox box2;
CBox box3;

kernel.Attach( ball1 );
kernel.Attach( ball2 );
kernel.Attach( ball3 );
kernel.Attach( box1 );
kernel.Attach( box2 );
kernel.Attach( box3 );

　拙作種々アプリでも勿論この機構は採用しており、例えば拙作「ネコりす」等におきましても、タイトル画面の後ろで歩くネコや、それぞれのブロックネコ、ブロッククリア時に発生するエフェクト等、ありとあらゆる個体は並列制御されています。
　更に動きのあるアプリ等におきましては、登録されるCUnitの数が数百数千に上る事も、なんら珍しくありません。

　更に理論を進め、画面上にて動きのある、言ってみれば「判り易い」個体のみを並列管理させていくのではなく、例えば、「当たり判定処理」「表示順番並べ替え処理」、更に「タイトル画面処理」「ゲーム処理」等、処理の単位もCUnit化を進めます。
　それぞれの実行順番を管理する為の機構、「優先順位」の実装が必要となりますが、それにより、個々の処理までもユニットとして管理し、必要に応じて取り外しを行います。例えば、タイトル画面では「当たり判定処理」は不要なので、外しています。「ゲーム処理」というユニットが、「当たり判定処理」というユニットを自分に装着します。ユニットにユニットを持たせられる、親子構造にまで発展さられれば用途は更に広がります。この辺りでの運用にまで昇華させる事が出来れば、商業レベルアプリケーションの実装も現実的な視野に捉える事が出来る様になるでしょう。




　そろそろ「残暑だ」と言いはってしまいたい程にまで冬が待ち遠しい。
休日よりも「明日は休日」が好きなTeamDyquemでした。

　それではみなさま。良い週末を^^