今夜は、基底でも派生でも無い、ランタイム半彼女DLLとの夜会があるので仕事のペースを調整中でした。
開発者の皆さん、出来る限り残業をしない毎日をお互い心がけましょう。まあ無理な時は無理なのだが。

 昔からゲームを作ってきた方なら判ると思うのだが、デバッグ用の操作を乱雑に増やしていくのはいい加減に止めた方が良い。「スタートを押すとデバッグカメラモード」、「L2で無敵」etc.etc。実際の現場では結局各プログラマがその場その場で空いているボタンに割り当てる事が多い。誰かが仕切るにしてもゲームパッドなんてのは本質的に最小限の入力デバイスである為、どうしたってボタンが足りなくなる。結果操作は複雑化し開発後期は混乱を極めるワケだ。その状況を強制されるデザイナやプランナの混乱は日々増長され、それを収める為にデバッグ操作一覧書なんかを配布する羽目になった日には、何より余りにもバカっぽい
 ウチのプログラマ、バカだろ・・・とか思われたくなければ、デバッグUIに関しては開発初期から根本解決手法を確立しておくべきであろう。

 まず、全てのターゲットにおいてマウスとキーボードを導入しよう。マウスだけでもまあ良い。これに加えて、ある程度ちゃんとしたウィンドウシステムを実装するのだ。タイトルによっては画面解像度に制限があるかもしれないが、ウィンドウシステムの性能が高ければ何とでもなる。ビューアーモジュールや、ゲーム本編モジュールからクリック一つでシーンのレンダリング結果上に(もしくはスケーリングし余白を作り)、画面最前面へ透明なデスクトップを呼び出すイメージだ。ここへ幾つかのウィンドウを生成し様々なチェックボックスやスライドバー等を配置する。シーン毎に全く任意の配置で構わない。これだけで、無尽蔵に存在するパラメーター群へマウス一つアクセス出来る環境が手に入る
 この機構がチーム全体へもたらす貢献度は計り知れない。時間は有限だ。であればこそ、プログラマが出来る、否やるべき事は早期にしっかり提供し時間の節約に貢献する事が大切なのだ。

 また、画面上にずらずらとデバッグ用スクリーンフォントの出力が溢れているタイトルを良く見かける事もあるであろう。あれも同様に罪深い事だ。基本的には自分以外のプログラマが出力している情報は見ない事が多いであろう。見ないだけでなくそれらは大量に溢れているかもしれないし、それではそもそもレンダリング結果がよく見えないではないか。
 こういったものは、同様のウィンドウシステム上へ個人用テキストログウィンドウを作成し、その中へ自分だけの出力をまとめる事も可能だ。ビルド時に個人識別用マクロと組み合わせるとか、起動時にユニークIniファイルを読む等いくらでも方法はあるのだ。

 更に更に。こういったゲーム内ウィンドウは当然ドラッグ可能な実装にするとして、マルチプラットフォーム開発におけるWindowsターゲットでは、このゲーム内ウィンドウを「ゲーム外へドラッグ」させる事も良いアイディアである。Windows下の子windowとして動的に生成し、サーフェイスを用意してやれば良い。基本的なターゲットをWindowsにする事のもたらすメリットの数々は以前のエントリーに記した通りだが、これらの実装はさほど難易度の高いモノでは無い。

 若いルーキーの諸君。こういった手法についても興味を持って勉強にあたって貰えれば幸いだ。


 さて、ランタイム半彼女DLLへ、メールをするとしよう。