ゲーム開発でのコードジェネレーターの使われ方

プログラマーの尾関です。

今回はゲーム開発でのコードジェネレーターの使われ方について解説します。

■コードジェネレーターとは

コードジェネレーターとは、ソースコードを生成するためのプログラムとなります。言い換えると、「プログラムからプログラムコードを生成する」ものです。

コードジェネレーターを作るメリット

コードジェネレーターを作るメリットとしては以下のとおりです

  • 一度仕組みを作ってしまえば、設定ファイルやデータが更新されても、自動的に正常に動作するコードとなる
  • データを入力する場所がわかりやすいので修正が楽

コードジェネレーターを作らずに作業を行うと、何かデータを追加するたびにソースコードを修正したり、それに付随する修正が行われることがあります。その手間を削減するのが、コードジェネレーターを作成する大きなメリットです。

また、ソースコードを直接修正するよりもわかりやすい入力方法になるので、作業分担しやすい、というメリットもあります。

もちろん、想定しない仕様変更があった場合や、機能に不備がある場合にはコードジェネレーターそのものを修正しなければなりませんが、仕様がある程度固まっていれば、データや設定情報の更新頻度の方が高いので、相対的に修正コストは抑えられる傾向があります。

デメリット

コードジェネレーターを作る際のデメリットとして考えられるのが、最初の作る手間が大きいことです。また通常は生成後のソースコードは修正しない(生成し直すと上書きされるため)ので、直接ソースコードを書くよりも修正コストがやや高くなり、動作確認も少し手間がかかります。

また仕様が固まっていない状態でコードジェネレーターを作り始めると、仕様変更があった場合に大きく作り直さなければならない可能性があるので、ある程度仕様が固まったら作り始めるのが良いかと思います。

■コードジェネレーターの実例

ここではコードジェネレーターの実例として、

  1. サウンドデータからデータテーブルを自動生成する
  2. エフェクトのIDとパスを生成する
  3. ソースコードの雛形を生成する

という3つのパターンを見ていきます

1. サウンドデータからデータテーブルを自動生成する

サウンドデータは、ゲーム開発ではかなりの頻度で更新されるデータの1つですが、それによりサウンドラベルの追加やサウンドアーカイブ(サウンドデータがカテゴリごとにまとめられたファイル)の追加などが頻繁に行われます。

その際、サウンドデータを参照するためのヘッダファイルやサウンドアーカイブのパスを自動生成するスクリプトを作成する(さらにサウンドデータを実行環境にコピーする)ようにしておくと、サウンドの更新が楽になります。

また自動生成ツールを作ることで、更新されたIDやファイルの差分が取りやすくなるメリットもあります。

例えば以下のようなテンプレートとなるヘッダファイルと.cppファイルを用意します

○ヘッダファイルのテンプレート

○cppファイルのテンプレート

所々に「$PATH」「$RES_NAME」などの文字がありますが、ここにはデータのパスやリソース名が入ります。置き換え処理はスクリプト側で行うことで、コードを自動生成することができます。

2. エフェクトのIDとパスを自動生成する

例えばExcelで以下のようなエフェクト一覧を作成します

これをもとにエフェクトのID(enum)とエフェクトのパスを自動生成するツールを作ると、エフェクトの追加や管理が楽になります。

また画像をよく見ると、常駐設定があり、バトルのみで常駐するようにして読み込み処理を自動化する、ということもしています

3. ソースコードの雛形を自動生成する

とあるプロジェクトでは、戦闘中の演出の場合分けが多く、プログラムでゴリゴリ書くことが必要とされました。

そして分業のためには各演出をクラスとして実装する必要があったのですが、テンプレートとなるクラスを毎回コピーして作るのも不便だな、と思って雛形を自動生成するスクリプトを作成しました

このスクリプトの先頭に定義してある

  • BRIEF: 説明文
  • AUTHER: 作成者
  • CLASS_NAME: クラス名

を設定すればそれによりソースコードの雛形を作ることができます。

以下、上記スクリプトで生成したコードです。

○ヘッダファイル (AnimActSpecialAttack.h)

○cppファイル (AnimActSpecialAttack.cpp)

スクリプトとしては200行程度のものですが、これでクラスが大量生産できたので、かけた手間に見合ったリターンが得られたのではないかと思っています。

そして念のためとして、クラスの仕様変更がありそうな部分に関しては、外部にパラメータを定義できるようにしたり、クラス継承をして継承元を修正できるなどの工夫をしておいて、仕様変更に柔軟に対応できる作りにしておきました。

■生成後のコードを修正してよいか、修正すべきではないか

コードジェネレーターにより生成したコードを修正してよいか、または修正すべきではないか、ということについて考えてみます。

基本的にはコードジェネレーターで作られたコードは修正すべきではないと思っています。特にコードジェネレーターの例として上げた「サウンドテーブルの自動生成」「エフェクトのIDとパスを自動生成」するコードは、”もととなるデータや設定を頻繁に修正して再出力する” ということを繰り返すため、生成後のコードを修正しても、元のデータに変更が入ったら再生成時にその修正は上書きされます。

そのため生成後のコードの先頭にあるコメントに「このコードをは自動生成されました。変更禁止」などと書いておくのが良いと思います。

ただ「ソースコードの雛形ジェネレーター」のように修正して使用するのが前提である場合、修正しても問題ありません

■まとめ

  • コードジェネレーターを活用することで、頻繁に更新される部分に伴う修正作業を自動化・簡素化できる
  • ジェネレートされるコードの元データが存在する場合は、出力後のコードを変更しない
  • ただし、ソースコードを量産する場合にはその限りではない

以上、ゲーム開発に使われるコードジェネレーターについて解説しました

(Visited 88 times, 1 visits today)

コメント投稿は締め切りました。