ゲームに限らず、プログラミングによって作成されるアプリケーションの開発において、デバッグ機能を丁寧に開発しておくことは非常に重要です。
(例外として、1人で1ヶ月以内とか短期間開発し、完成したら二度とメンテナンスしないようなものは気にしなくていいです)
デバッグ機能のすゝめ
どんなデバッグ機能を作ればいいのかというと、理想は、ゲームプレイにおいて変更されうる全ての状態を監視、変更する機能です。
将来的にどんなバグが起きるかわからないので、これができればまぁ理想です。
実際のところこれを実現しようとするとC#で言えばSource Generatorを使うなどコード生成に頼る必要があるでしょうし、
小規模の開発であればそこまでの頑張りに見合うリターンがあるかと言われると、ちょっとやりすぎな感じはありますね。
そこまで徹底しない場合は、初めからデバッグ機能を用意するのではなく、後から気軽に、リリース環境に影響を与えずに追加できる状態にしておくのが良いです。
デバッグ機能は割と何をしてもいい
デバッグ機能は大して設計を気にしなくても構いません。「デバッグシンボルが有効な場合はpublic static
なアクセスが可能」とかもやっていいと思います。
↓くらい自由でもいいと思います。
public class HogeClass : IDisposable { public HogeClass() { # DEBUG Debugackdoor = this; #endif } public void Dispose() { # DEBUG Debugackdoor = null; #endif } # DEBUG public static HogeClass DebugBackdoor; // その他、デバッグ機能時にアクセス可能な色々なメソッドやプロパティ #endif }
見栄えが悪い感はありますが、まぁこの辺実際どう実装するかは些事でしょう。
デバッグ機能があると、気軽に作れると何故嬉しいのか
バグ修正が簡単になる
当然ですが、バグの調査と修正が格段に楽になります。最初から見通しが立っていない実装や修正の重要なところは、基本的に情報集めです。
必要な情報が無いから難しく感じるのであって、必要な情報さえ集まっていれば誰でも対応は可能です。
というわけで、気軽に色々試せる環境を作って、情報集めのコストが下がることは間違いなくバグ修正を楽にしてくれるでしょう。
クオリティアップに繋がる
創作物のクオリティアップには、試行錯誤の回数が不可欠です。
デバッグ機能が充実していると、部分部分の設定変更が容易になり、様々なものを高速に試すことができます。
設計が綺麗な状態に保たれる
デバッグ機能はpublic static
とか作って雑にしてもいいんだ、と書きましたが、実のところそれで上手くいく状態にする前段階では真っ当な設計がなされている必要があります。
どこのパラメータを変更したらどこに影響があるのか? デバッグ機能から変更することによって整合性が取れないモジュールが出ないか?(表示と内部パラメータがずれるとか)とか。
デバッグ機能が適切に追加できる状態は、単一責任原則をしっかり守ってモジュール分割するであったり、
プロパティ変更レイヤーを間に挟むであったり、あとモジュール間の依存の方向性を適切に一方向にするであったり、
そういった一般的に良いとされている設計を丁寧に実践することによって実現できます。
そのため、デバッグ機能を作りやすい状態は、そもそもバグが出にくい状態にもなっているのではないかな、と思います。
逆にデバッグ機能の危ういところ
デバッグ機能の開発は楽しいです。楽しいんですが、デバッグ機能ばっかり作っていても本質的な開発は進まないので、楽しさに引っ張られないようにしましょう。
まとめ
デバッグ機能は作り得です。作った方がむしろ開発が早く終わるまであるくらいには役立ちますし、デバッグ機能を充実させることも念頭において設計することでアプリケーションそのもののクオリティも向上します。 とはいえデバッグ機能の開発ばかりしても作業は進まないので、簡単に作成できる環境を維持し、適切に気軽に用意し活用するようにしましょう。
ちなみに、今回記事のタイトルはAIに考えてもらったんですが、意外と悪くないですね。(はてなブログにそういう機能が追加されていた)
AIの発達で開発が楽になるといいんですが、今回話題にしたような抽象的な戦略の部分はしばらくは人間の仕事なんだろうなぁと、ぼんやり思います。早く仕事を奪ってくれ。