デバックとエリ草ー –

ゲームのプランナーの仕事をしていると、かなりの頻度「デバック」と書かれているのを書類やメールで見かけます。

というのを書いていたら──今「でばっく」とタイピングしたところで、
ATOKさんが【「デバッグ」の誤り】とおっしゃいました。

そういうわけで、バグを見つけて修正するから「デ【バッグ】」なわけで。
バクを見つけるわけでは。なくて。まぁ単なる間違いです。

名称はそれほど大事ではないのです（気になるけど）。
それより危険なのは、

ゲームにおけるデバッグ＝ゲームをひたすらプレイしてバグを見つける

だと認識している人がけっこういる。気がする。
だからデバッガーさんは一日中ゲームをプレイしているんだろ、と。
ゲームが動いたらデバッグ会社さんにお願いして、バグを見つけてもらうんだろ、ってことなのでしょう、けれど、も。

半分合ってて半分まちがい。
正確には、

『仕様書』と『実装』が合っているかをチェックする

のがデバッグです。
スマホなら

・ゲームの仕様書
・絵素材やテキスト素材のリスト
・パラメータなどの設定ファイル
・DVD なり apk なり ipk なりのビルド＝実装

などをデバッガーさんに渡して、仕様通りに実装されているかを確認してもらうわけです。

だからずっとゲームをプレイするのはまぁ、正しい。

そのとき、デバッガーさんは仕様書片手に、その仕様書通りに実装（動作とか絵とか音とかテキストとか）されているかを確認しながらゲームをチェックします。

仕様書があって、それを元に作ったわけで、仕様と実装は同一のはずです。
この大前提を持って、デバッガーさんはチェックをします。

じゃないと、初見のゲームの実装だけを見て、ある動作が正しい（仕様＝制作者の意図通り）のか、不具合なのかは判断ができません。

フリーズしたとかアプリがクラッシュしたとか、誰が見ても「不具合だろ」というものは仕様書が無くても分かります。

たとえば。「RPGの最初の戦闘で、敵を倒したらレベルが2個上がった」場合。

別に普通じゃん？とか、ちょっとサービスしすぎ？とか考えるかもしれませんが、それはプレイヤーの視点です。

今デバッグプレイしているのは、「完成前の、バグや実装ミスがあり得るゲーム」なのです。すべての挙動が（言葉通りの「すべて」です）仕様書通りなのかをチェックしないといけません。

・最初の戦闘で出るべき敵の種類を仕様書で確認
・出現する設定通りの敵なら、手に入った経験値を確認
・キャラクターの経験値／レベルの資料を確認
・レベルが一度に2個上がることがしようとして許容されているか確認

……などなどのチェックを経て、問題なければ「この動作は仕様通り」となって次のチェックに進みます。

さらっと飛ばしましたが、「レベルがいっぺんに2個上がるのは正常か異常か？」というところが気になるかどうかは、そのデバッガーさんの感覚です。

いっぱいゲームをプレイして、脳内にあるデータベースにそのプレイデータが蓄積されています。

その中から「この状況はあまり見たことが無いのでもしかしたらバグかも」というのがあれば、そこから仕様書の確認などが始まるわけです。

こういう「ゲームプレイヤーとしての経験値」が必要なのは、デバッガーさんもプランナーさんも変わりません。まぁどっちも同じ開発者ですから。

デバッガーさんから「仕様書をください」と言われるのは、今にして思えば当然です。だって、ROMだけあっても停止バグのチェックくらいしかできませんし。

でも、僕がゲームの仕事を始めた18年ほど前は「仕様書と実装をつきあわせてチェックする」のがデバッグだと認識していなかったのでした（品証のみなさますみません）。

ということで。

デバッグってのは、『仕様書』と『実装』が合っているかをチェックすること、です。自戒を込めて。

あ。

タイトルの「エリ草ー」は、「エリクサーってどんな草なんですか？」と聞かれたことがあったから。この視点は無かった。

薬草は回復するでしょ、エリクサーも回復するでしょ、だからなんかの草なんでしょエリクサーって、というロジック。素敵なセンスだと思うー。

– TaleFactory –