磨き上げる
デバッグやクオリティアップについてのお話です。
デバッグウィンドゥ /
実機エディタ /
ASSERT /
戻る /
トップページ
デバッグ用ウィンドゥ
- ゲーム画面の上に、OS の Windows のように GUI のウィンドゥを表示し、
デバッグ情報の表示や編集が行えるようにすることがあります。
-
- マウス・キーボードの操作やフォントの表示、ウィンドゥの制御など
その実装には多くの手間がかかりますが、やるだけの利便性があります。
メモリやタスクの状態の表示、テクスチャの転送の有無など、
必要な情報があったときにキーボードの操作一発で
それが表示できるのは便利ですし、編集機能を作って企画やデザイナさんに
各パラメータの調節をしてもらうこともできます。
もちろん、不具合があったときに情報をかき集めるのにも役立ちます。
実機エディタ
- 実際にゲームに出したときと全く同条件 (処理速度や見栄え) で
エディットできること、企画職がプログラマやデザイナの力を
借りずにエディットできる、などの利点から、実機上でゲーム画面に
重ねて各情報を編集できるツールが使われることがあります。
-
- マップ上にギミックやエネミー (敵キャラ) を配置するツールを
作ることが多いですが、ゲーム内容に大きく依存するため、
ゲームごとにツールを作らざるを得ないこともしばしばです。
デバッグ用ウィンドゥを利用して、Windows のような画面で
エディットできるものもあります。
-
- しかし、その製作の手間をかけてでも得られる利点は大きく、
実機エディタを開発することは良くあります。
特に、企画職が一人で細かいトライ＆エラーが繰り返せるようになるため、
ゲームバランスなどの質に大きく影響してきます。
ASSERT
- 通常のプログラムにおいても行われることですが、
ASSERT は入念に組み込んでおくと良いです。
-
- コンシュマー機など特殊なハードウェア上での開発ではデバッガなどの
機能が PC での開発に比べてそれほど豊富ではないためです。
特にメモリリークが一つでも発生するとプロジェクト全体の進行に
支障がでる危険性もあるため、念入りに対処しておくと良いでしょう。
当然、リリース時には ASSERT は無効になるため、ASSERT 条件に引っかかる
事態になってもプログラムの進行が止まったりメモリリークしないように
その後の処理も書いておく必要があります。
-
- そして、ASSERT が発生したときはブルーバック画面に ASSERT が
発生した箇所のソースファイル名と行番号をマクロを使って表示するようにし、
エラーメッセージも ASSERT 文に指定して表示すると何かと役に立ちます。
-
- またその一方で、グラフィックデータ (モデルデータやモーションデータ)、
スクリプトのデータ不備、つまりプログラマ以外の作業が原因で
引き起こされる状態異常については ASSERT 以外の方法で
捕獲することが肝心です。
プログラムが正しく動作しなくなる直前に ASSERT でつかまるようにする一方で、
それらのデータのロード時などには念入りなチェックコードを入れ、
その際に異常が見つかったら誰が見てもわかるエラーメッセージを
画面上に表示し、ASSERT でブルーバック画面に陥ることなく
処理が進行するようにすると良いです。
-
- プログラムの開発とそれらデータの開発は同時進行で行われるため、
開発メンバーはプログラムによる不具合によって ASSERT を目にする機会が
頻繁にあります。
そのためプログラムに詳しくない人は、グラフィックデータや
スクリプトデータが原因で ASSERT が発生しても
何が原因でそのような事態に陥っているのか判断できないため、
プログラムの不具合で止まっているのだと認識してしまうためです。
デザイナなどが自分のデータが原因で止まっていることを自分で判断して
対処を行えるように、わかりやすいエラーメッセージが必要とされるわけです。
-
- また、データが原因で簡単に ASSERT が発生してしまうようだと、
開発人数が増えるにつれてデータが更新される機会も増え、
ASSERT の発生頻度も上がるため、いつも動かないプログラムのために
開発が滞ってしまう危険性もあります。そのために多少のデータ不備が
あってもエラー表示の上で ASSERT を回避して動くように
することが重要になってきます。
もちろん、データ更新前に代表者がチェックする等の人的な
チェック機構も有効な対処方法ですが、
プログラム側でもこれらの対応があることが望ましいです。
戻る