特殊な実装手法

スクリプト言語や、オーバーレイなどについてのお話です。

スクリプト言語 / オーバーレイ / ミドルウェア / 戻る / トップページ

スクリプト言語
RPG、アドベンチャー、アクションアドベンチャーなど、 フラグ管理や分岐のため、ゲームの進行を記述する方法として 「スクリプト言語」があります。
　
Perl や JavaScript のようないわゆる一般的なスクリプト言語と そう大差ないものと思って間違いありませんが、それは当然ゲームの 進行を記述することに特化され、会社によっては企画職が それを書くことができるほどに簡素化がされています。
　
その言語体系は会社・プロジェクトによって千差万別で、 アセンブラ言語そのままでプログラマーが書かざるを得ないものから、 C 言語そっくりのもの、Lua、 Squirrel などの 組み込み言語を使うもの、GUI ツール上で命令を並べるだけのもの、 GUI ツール上と連動して企画職が扱えるものまであります。 スクリプト言語の設計は設計者の考え方やゲームのジャンルなどに 依存して変わり、イベントドリブン型やオブジェクト指向的なものもあります。
　
なぜ、プログラマしか触れなくなっていても、コンパイラを製作する 手間をかけてでも、スクリプト言語を作るのでしょうか。 それは、それだけスクリプト言語にそれなりのメリットがあるためです。
　
まず、スクリプト言語の (コンパイル後のコードを実行する) インタープリタが必ず、ゲームのシーケンスを書いたコード (スクリプト言語) とゲームの各プログラムコードとの橋渡しをするため、 そのレベルでメモリリークなどの不具合を食い止められることがあります。 スクリプト言語の書き方をどんなに間違えても、ゲームのシーケンスは おかしくなっても、メモリの破壊やフリーズは起こさなくできます。 これにより、ゲームのシーケンスの構築に集中できます。
　
また、そのインターフェース部分のコードの作り方次第では、 様々なデバッグ機能を実装できます。例えば、あるキャラクターに 話したときに立つべきフラグがなぜか立っていないときに、 フラグを立たせていなかったのか、別のコードがそのフラグを クリアーしてしまっていたのか、などです。
　
また、スクリプト言語のコンパイル後のコードはバイナリのデータになるため、 そのリコンパイルさえすれば、ゲーム本体のプログラムのリコンパイルや リンクをすることなく、コンパイル後のスクリプト言語を差し替えて チェックできます。ゲーム本体のプログラムが肥大化すればするほど、 この利点は大きくなります。ゲーム本体を上手く作れば、 スクリプト言語の書き直し → そのコンパイル → スクリプトデータの読み直し指示、という流れだけで修正後の スクリプトのチェックができてしまうのです。

スクリプト言語の設計
以下は、スクリプト言語にあると良い機能・特徴を書きます。 スクリプト言語の設計は設計者の考え方やゲームのジャンルなどにも 依存するので、これが必ずしもベストだとは言い切れませんので、 その点は考慮ください。
　
とっつきやすい事
　
スクリプト言語を設計する上で気をつけなければならないことは、 プランナー、デザイナなどのプログラムに精通しきっているわけでは ない人がスクリプトを組むことが多い点です。
　
そのためには、言語仕様が覚えやすいことが必要になってきます。 C 言語などの既存の言語にそっていれば、その解説本は普通に書店で 購入できるため、覚えやすいですが、独自の言語仕様になっていると、 それを設計した人以外に使い方を知る人がいないため、 設計者に直接聞くか、設計者が詳細なマニュアルやサンプルを用意する 必要がでてきます。
　
また、既存の言語に添った場合は、その既存の言語と 開発したスクリプト言語の微妙な差異が混乱を招く可能性もある点には 注意が必要です。
　
これらを回避する方法としては、Lua などの 書籍が出ているスクリプト言語を採用する手段もあります。
　
また、オブジェクト指向などの習得に時間を要する、 複雑な構造を持つ言語仕様にするのも場合によっては良くないこともあります。 スクリプトを組む人がプログラマタイプのロジックで思考できる人とは 限らないからです。
　
エラーチェックの強靭さ
　
次に気をつける点として、言語構造上、不具合がでにくいことが求められます。 プログラムを触ったことがある方なら、プログラムの大半はデバッグに 費やされることはお分かりかと思います。プランナー、デザイナがスクリプトを 組む場合、彼らはプログラムのプロではないため、デバッグのノウハウや コツを掴んでいるわけではありませんし、スクリプトによって実現される 遊び・デモの見た目の向上がその目的でもあるため、できるだけデバッグに 時間は使いたくありません。
　
例えば、型宣言はない方が楽に組めますが、識別子のタイプミスで 同じ変数だと思って組んでいるのに実際には違う変数にアクセスしていた、 という不具合を招きます。型宣言があれば、コンパイル時にエラーとして はじくことでこのようなミスを防ぐことができます。
　
当然、スパゲティプログラム (プログラムの実行順序ががあちこちに 飛びまくるため、流れが一見して分からなくなっているプログラム) を 招く GOTO 文などは避けたいところです。
　
スクリプトの組み方による不具合は、インタープリタ、もしくはコンパイラ レベルで可能な限り、事前に感知して分かりやすいエラーメッセージを 出すと良いです。Null ポインタうんたらのエラーで ASSERT しました、 と言われても、プログラムに詳しくない、スクリプトを組む人は 原因が分からず、結局スクリプト言語設計者に原因特定を依存することになり、 作業分担の効率を落としてしまいます。 特にインタープリタレベルでの不具合感知はスクリプト言語を使っている 利点でもあるため、念入りに用意しておくと親切です。 スクリプトをどのように間違って組んでいてもインタープリタが エラーメッセージを出すようにして、フリーズや ASSERT が発生しないように できると良いでしょう。
　
再試行の容易さ
　
可能なら、テスト時はインタープリタのみで動作 (リリース時は コンパイルして最適化を行う) するか、ボタン一発で コンパイルとデータのパック、実機でのリロードまで行われると便利です。 せっかくスクリプト言語を通しているのですから、直接実装する時には できない利点があると望ましいです。
　
デバッガに相当する機能も豊富であれば、それだけ便利でしょう。 最低でも変数の値を見る機能や printf に相当する機能程度は用意して おいてあげると喜ばれます。ここは、自分がプログラムをする際に デバッガに求める機能だと思えば、自ずと必要な機能はわかってきます。

オーバーレイ
プログラムコードを使われるシチュエーションで分けてモジュール化し、 必要な場合に必要なモジュールを読み込んで使用するシステム構造の事です。 アドレス固定の DLL みたいなものと考えて良いでしょう。
　
コンシュマー機では複数のアプリケーションを同時に実行するような OS を積んでいるわけではないため、プログラムはメモリ上で 常に同一の配置になります。そこでゲームのステージに依存した プログラムコードをデータファイルとして実行中のプログラムコードの 一部に上書きすることを入れ替えを行います。 このように読み込む領域を重ねて設計する為、オーバーレイと呼びます。
　
オーバーレイはプログラムコードを分割するため、それだけメモリの消費を 減らすことができます。また、モジュール化が進められるためコードの 独立性が増し、多人数での作業に向いています。 そして、一つのオーバーレイのソースの変更を行っても、 そのオーバーレイのコンパイルだけで済み、コアモジュール以外の リンク時間はそれほど掛らないために、末端プログラムの 作業修正効率が上がります。
　
しかし、オーバーレイにも弱点はあります。特にオーバーレイ部分の デバッグがしにくくなる点が大きな欠点です。 オーバーレイが入れ替わるたびに、デバッグシンボルを再読み込みすれば、 この問題は解決できますが、なかなか難しいのが現状です。 また、オーバーレイのバイナリファイルの管理、リコンパイルの タイミング等の管理上の手間も増えます。ゲームの仕様によっては オーバーレイ化できるところが少なく、メリットが少ないこともあるため、 プロジェクト序盤ではひとまずオーバーレイは使わない、 とすることが多いようです。
　
また、親子モジュール間 (メインプログラム部分とオーバーレイ部分) の つなぎ方が問題となり、一つのアクセス関数を使用する関数テーブル方式や、 モジュール間を直接リンクする方法などが取られます。 オーバーレイから関数テーブルを介してメインプログラムの関数に アクセスする方法は、モジュール同士の独立性が高まり、 メインプログラムの変更時にオーバーレイのリコンパイルが不要となる 利点がありますが、関数テーブルに用意した関数しかアクセスできなくなり、 その関数の用意の手間も少なくありません。 どちらの方式を使うかは一長一短です。

ミドルウェア
開発規模の拡大、美麗なグラフィック・AI・コリジョン・剛体と 抑えなければならない技術の増大により、ミドルウェアの需要が高まりつつあり、 ゲームでもミドルウェアを使って開発するケースが現れ始めています。 各方面の技術に長けた人材を一通り集めることはなかなか難しいためです。
　
ミドルウェアで比較的良く使われているものには Unreal Engine, HAVOK, Renderware などがあります。

戻る