少し前に興味本位で、デバッグについてゲーム開発者向けにアンケートをとってみたんです。

はい。デバッグは勘でやっているよって人が大多数でした。数多のゲームは勘でチェックされている。

まぁ、プログラマなら業務上使いますし、資格の問題にも出るのでお勉強せざるを得ないと思うんですが……独学でプログラミングを勉強してゲーム作っている人とか、プランナー系統の人はあまり勉強する機会がないのかなーと思ってたりします。

ちょうど良さげなので、この記事では私が普段「まぁこれくらいは…基本だよね……」と思っているデバッグの基礎知識についてまとめていきます。

あ、ちなみに私もそんな知識がある方ではなくて、まぁ最低限かなぁ…というレベルです。（入った会社のデバッグ状況があまりに酷くて、勝手にデバッグチームを育てたことはあります）

そんな難しい話をするつもりはないので、まぁ軽く見てやってください。

◆デバッグで大事なのは？

まずは基本的な考え方から。

最初に言っておくと「バグを絶対に出さない完璧なデバッグ」は実質的に不可能です。バグって色んな条件が組み合わさって発生する物もあるので、その色んな条件を全て確認しようとするとですね。色んな条件を掛け算していくことになって確認項目が天文学的な数字になります。

ただ、だからと言って適当にデバッグしているとバグを見逃して死にます。致命的なバグなんかを見逃すとゲームが成立しませんし、お金を払った人からすれば「金返せ！！！」となるわけです。

じゃあどうすりゃええねん…と言う話になりますが。これはもう、現実で出来る範囲を頑張るしかないです。なのでデバッグでは

・限られた時間で、効率よくバグを潰す

のが重要です。これを言い換えると、

・バグが出にくい所はさらっと確認しながら
・バグが発生しやすい所をしっかり確認する

というのが大事になってきます。バグが出ない所に時間をかけてもしょうがないので、バグが出やすい所に時間を使う。

そうなると重要になるのは

じゃあバグが発生しやすい所ってどこ？

って事ですね。それを知らないと、しっかり見るべき場所が分からんって話になります。それじゃあ効率の良いデバッグはできません。

◆"境界"にバグは潜む

バグりやすい場所の代表格が「境目」です。例が無いと分かりにくいので、今私が作っているゲームを例に使いましょうか。例えばコレの数字確認。

少し解説すると、これはTRPG的なイベント判定で1～100の範囲で判定値が決まり、その数字によってイベントが分岐します。今回の分岐条件は

大失敗：1～5
失敗　：6～56
成功　：57～94
大成功：95～100

ですね。さて、このイベントにおける「バグりやすい数字」って何だと思いますか？

・

・

・

まぁ先に境目の事を話しているので検討はついていると思いますが、

5・6（大失敗と失敗の境目）
56・57（失敗と成功の境目）
94・95（成功・大成功の境目）

あたりが特に危険です。じゃあ、なぜこの数字が危険なんでしょうか？

・

・

・

簡単に言うと、プログラミング上で誤字が発生しやすいからです。例えば大失敗の条件は

5以下で大失敗（ 判定値 <= 5  ）⇒ 5で大失敗、6で失敗

ですが、不等号を入れ忘れたり、方向を間違えると

①5未満で大失敗（ 判定値 < 5 ）  ⇒ 5で失敗、6で失敗
②5以上で大失敗（ 判定値 >= 5 ）⇒ 5で大失敗、6で大失敗

になったりするわけです。ちょっとしたミスですが、さらっと眺めているくらいだと不等号の方向とかって見逃しがちでバグりやすいんです。

境目を見ていないと見逃しがちなパターンとしては、例えばミスって①の条件（5未満）になっていた時、

1~5が大失敗だな、じゃあ代表的な数字を見て確認しよう！
真ん中の数字でいいか！3だな！！！
　↓
①5未満（1～4）にも当てはまるので見逃す
②5以上（5～100）には当てはまらないので見つかる

なパターンとか。片方のバグパターンは見つかるけど、もう片方のは見逃しちゃう。こわーい。

ちなみに用語としては

・境目をチェックする：境界値分析
・代表的な数字をチェックする：同値分割

って言ったりします。テストに出ますよ。基本情報技術者試験とか。

こんな感じで、数字の境目にはバグが潜みやすいんです。

・

・

・

って話で終わらないと思うんですよ。

もうちょっとコレ応用が効く話なんだと私は思ってます。数字だけでなく、あらゆる境目にバグが潜む。

例えば、装備のデータ。こんな感じのデータがあったとしましょう。

この時、バグりやすいのはココ。武器と防具が切り替わる瞬間。

これはつまるところ、データの境目です。データ上、何かが切り替わる境目はバグが出やすいって話になります。何でこういう境目が危ないのかと言うと、データを作ってて「1行ミスった」って話は起こりやすいんですよ。

例えば4～6のIDと装備名を作った後、コピペで4～6の種別を一気に入力した時とか。この時に入力が1行ズレたら、

・「釘バット」を防具として着る
・「ぱんつ」を武器にして戦う

みたいなバグが出たりします。境目じゃない所は1行ずれても問題ないですけど、境目の所は1行ズレたらバグります。

こんな感じで、数字に限らずこういった「境目」となる場所を気を付けてチェックすると、バグは見つけやすいのです。

◆同じミスはしているもの

あとは、何かバグが起きたらですね。同じようなパターンで別の所がバグっている事が多いです。

今回も私のゲームで例を出します。どーん。

状況を解説すると、

基本クラスとして以下の4クラスがある。
①ファイター  (レベル2でSTR+1)
②サムライ     (レベル2で TEC+1)
③メイジ         (レベル2でINT+1)
④ソーサラー  (レベル2でVIT+1)
クラスのレベルを上げるとステが上がったりスキルを覚えたりする。
ここでは、ファイターのレベルを2にするとSTRが+1される。

という仕様です。

さて、ここで

ファイターのレベルを2にしたら、STRではなくINTが上がった

というバグが起きたとしたら、他のクラスでも目当てのステータス以外の物が上がっている可能性が高いです。

例えばバグの原因が

・ファイターで上がるステータスが間違っていた

ならファイターだけの修正で済みますが、

・ファイターとメイジで逆になっていた

であるなら、メイジのデータも間違っている事になります。STRの上がるムキムキメイジが爆誕するかもしれません。

他の状況も考えて見ましょう。例えば、

ファイターのレベルを2にしたら、STRが+1でなく+2上昇した

というバグがあった場合、別のクラスで同様に+2の上昇がする事を疑った方が良いです。

例えば最初にファイターを作って、ファイターのデータを基にコピペしながら他のクラスを作っていたら、同じバグが蔓延している可能性はとても高くなります。

バグには原因があるので、バグがあったら同じような原因で似たバグがある可能性が高いのです。

ちなみに、同じようなパターンのバグがないか確認するのを『水平展開』と呼んだりします。水平展開大事ですよ。確認するの面倒くせぇって思うかもしれないけど。私はいつも思ってます。

ただ、似たようなバグを乱発すると「コイツ学習しねーのか」って思われてもしょうがないです。あと、同じようなバグを何度も

報告→修正→確認、報告→修正→確認、報告→修正→確認……

を繰り返すよりは、1度のバグ報告で

報告→類似バグをまとめて修正→まとめて確認

で済ませる方が、結果的に時短にはなります。

◆ガチャプレイで想定外のバグを炙り出す

想定外のバグ。怖いですよねー。想定外。できるだけ潰そうと思っても、

こうなると思わなかったから想定外っていうんだよォ！

という状態なので、まぁ、作っている側の人間としてはできるだけ目を背けたくもなります。

動作確認とかデバッグとかで、「正常な動作」に対する確認だけしていると、想定外のバグにはブチ当たりやすいです。例を出しましょう。

広場を通り抜けたいけど敵が踊っていて邪魔。そこで、どうやって通り抜けるのかを選択するシーンです。

選択肢を選ぶ所なので、ここでの「正常な動作」は

①↑↓で選択肢を選ぶ
②決定ボタンを押したら、選択肢に対応したイベントに分岐する

あたりですかね。各イベントを確かめてちゃんと分岐してたらOK。では、この状況における想定外のバグって、どういう事が起きるのでしょうか？

実際に私がココでやらかした想定外バグは、

①←→を押したらボタンの選択状態が吹っ飛んでどっかいった
②メニューボタンを押したらメニューが開けちゃった（封印しなきゃいけない事にそれで気が付いた）

あたり…です……（遠い目）

この辺りは、「正常な動作」を確認するだけでは見つかりません。②なんかは、そもそも仕様から漏れているので、仕様に従ってどんなに確認項目を考えていても漏れます。こわーい。HAHAHA。

そんな恐怖の想定外バグですが、デバッグのテスト手法の中にはこういった想定外のバグを潰すための手法もあります。最も手軽なのは『モンキーテスト』と呼ばれる手法です。簡単に説明するとこう。

◆モンキーテスト
猿にゲームをさせた時みたいに、とにかく法則性なく出鱈目に操作をしてテストをする手法。

はい。お猿さんへの風評被害がスゴイですね。「考えてもダメなら考えなければ良い」というパワープレイです。

ただ、なんだかんだでコレで見つかるバグもあります。さっき私が紹介した

①←→を押したらボタンの選択状態が吹っ飛んでどっかいった
②メニューボタンを押したらメニューが開けちゃった（封印しなきゃいけない事にそれで気が付いた）

このやらかしも、モンキーテストをやると見つかるんですよ。お猿さん侮れない。

◆自分で作った物をデバッグするな

さて、突然ですがちょっと想像をしてみてください。

ゲームイベントに向けて、試遊できるように頑張って作ったぞ！
試遊している時にバグが起きたら大変だし、自分でデバッグも頑張った！！
　↓
～当日～
「すみません、バグったっぽいんですけど…」
「何かイベント中に別のイベントが始まりました」
「フリーズしました」

な゛ん゛て゛！と゛お゛し゛て゛！！
か゛く゛に゛ん゛か゛ん゛は゛っ゛た゛の゛に゛！！！
こ゛ん゛な゛こ゛と゛に゛な゛っ゛た゛の゛ぉ゛ぉ゛ぉ゛！！！

っていう状況。胃が痛くなりましたか？私はなりました。

でもこの状況が起きるの、運が悪かったとかチェック不足だったとかそういうのじゃなくて、必然的に起きると思うんですよ。

これ、本当に大事です。いいですか。

開発者は、自分が作ったところをチェックしてもバグを見逃しやすい

肝に銘じてください。作った奴は自分のバグを見逃します。これは、開発者の人格がダメとか自分に甘いとかそういう話ではないです。

人間は自分が把握している物については簡略化して見る
　↓
自分が作った所は「こうなっているだろう」という認識して、チェックしようとしてもアバウトに見てしまう。

という特性が、人間の本能レベルであると思ってください。ヒューリスティックな処理だのなんだの深く解説することはできますが、本題から逸れるので解説はしません。

例えば誤字脱字なんかは書いている本人は気が付かないけど、文章を読んだ他人はすぐに気が付く…なんてのもありますよね。アレと同じようなものがゲーム開発全体にあると思ってください。

さっき紹介したモンキーテストも、自分でやるよりも他人にやってもらう方が良かったりします。なまじ中身を知っていると考えちゃうので、何も知らない人にやらせた方が良かったり。

個人開発者だと中々難しいかもしれませんけどね。ただ大きなイベントとかあるなら、1人でもいいので家族でも友人でもネットの知り合いでも誰でもいいので、遊んで貰った方が良いと思います。じゃないと、冒頭のような状況が起こりますよ。

◆開発者が最低限確認するべきライン

とはいえ、

よし！じゃあ俺は何も確認しなくていいな！

とか言って動作確認すらしないと、デバッグを始める前にゲーム自体がまともに動作しないので論外ですよ。動作確認はしましょう。義務です。

ただ一口に動作確認と言っても、どこまでやるのか線引きがアバウトだとアレなので。ここから話すのは基礎知識と言うよりも私の考えなんですが、私の基準を話します。

まず、バグを2つの要素で考えましょう。

◆バグが起きる頻度
高：ゲームを進めたら高い確率～確定で発生する
中：特定の条件下でのみ発生する
低：特定の条件下で、非常に低い確率で発生する

◆バグの危険度
高：ゲームがフリーズする or ゲームプレイに深刻な悪影響がでる
中：ゲームプレイに悪影響は出るが、操作次第で回避できる
低：ゲームプレイへの影響は少ない

例えば

①ボスを倒したら確定でフリーズ…頻度：高　危険度：高
②消費MP半減が一部の魔法に作用しない…頻度：中　危険度：中
③誤字脱字…頻度：高　危険度：低

とか。ちなみに、この辺りの分類やら基準やらは人やチームによって変わるので、とりあえずのサンプル程度に捉えておいてください。

こうした中で開発者が動作確認で潰すべきは

・頻度　：高
・危険度：中～高

のものです。上記の例だと①のみですかね。

要するに、

動かしたらすぐに見つかるようなヤバいバグは開発者が動作確認で取り除く

って感じです。動作確認の文字通り。

誤字脱字みたいに頻度は高くても危険度が小さい奴ならデバッグに回して大丈夫です。動作確認の段階で気が付いたら直した方が良いですけど、全てをチェックする必要はない。

頻度が中以下のは条件付きなので、発見するためには色々試さないといけないです。しっかりやるなら確認項目を作ったりも。そこまでやると動作確認の域を出ますし、どうせ開発者がやるとガバガバなんで、デバッグに回して他人に見てもらった方が効率良いです。

開発者のTHE・ガバガバ・デバッグでも、高頻度で発生して目に見えてヤバいようなのはさすがに見つかるので、それを見つけて潰しましょう。

◆バグ報告のコツ

ここは開発者向けというよりは、デバッグする人向けの話です。

たまに勘違いされるんですが、バグを直す人はですね。神様でも魔法使いでもないんですよ。

なんかバグりました
フリーズしました

ってだけだと、何もできません。バグが発生した時は

あ～、この症状ならあそこの処理が原因かな？

みたいな感じで、バグの発生場所についてアタリをつけて調べていきます。そしてアタリが正確につけられるかどうかは、バグ報告の内容に左右されると言っても過言はありません。つまり、情報。情報が必要なのです。

バグの原因を突き止めるには、発生しうる状況をできるだけ絞るのが重要です。そのための情報としては、

①いつ、どこで
②何が起きたのか
③発生条件や再現性はあるか
④エラーメッセージ等の表示内容

があると助かります。イメージが付かないと思うので、また例を出しましょう。モンキーテストの解説で出した状況と同じやつです。

この時、デバッグをしていたら

「踊りに混ざる」を選択したら「爆弾で吹き飛ばす」のイベントが発生。ただし確定ではなく、条件がある

としましょう。

この時の悪い報告として例をあげると、

イベントの選択肢で、選択したイベントとは別のイベントが発生する

ですかね。事実だけど、情報が広くて限定ができない。

対して良い報告はこうです。

①いつ、どこで
「盗賊のアジト」の広場のイベントで

②何が起きたのか
「踊りに混ざる」を選択したら「爆弾で吹き飛ばす」のイベントが発生した

③発生条件や再現性はあるか
「別の道を探す」を選択して1度イベントをキャンセルした後、イベント2回目で必ず発生する（1回目では発生しない）

④エラーメッセージ等の表示内容
なし

悪い例のように、情報がアバウトだと原因を特定するために調査することが大量に増えます。こっちで試したら普通に動いたよ？とかなると、どうやったらバグが起きるのか…から検証しないといけないですし。

対して、良い例のように情報がしっかり載っていると

・1回目では発生しないので「踊りに混ざる」自体に単純なバグがあるわけではなさそう。
・「別の道を探す」や2回目専用の処理の中にバグがあるかも？

みたいな形で、原因についてアタリがつけられます。アタリをつけた場所に原因があれば、それを修正して終わりです。もしエラーメッセージが出ている場合はそれも重要な手がかりなので、エラーメッセージが出たらスクショとって送るなりすると良いでしょう。

こうした情報を伝えられるかどうかで、原因の特定のしやすさは全然違いますし、それによってバグ修正の負担とスピードは大きく変わっていきます。

ちなみにバグ修正１つ１つに手間取ると、

予想以上にバグ修正に時間をとられて遅れてるよォ！
このままだとリリース日に間に合わないよォ！！
遅れからのプレッシャーから精神も病みそうだよォ！！！

とかになりかねないので、良いバグ報告をすることは大事です。ほんと。お願いします。

◆まとめ

今回の話は以上です。内容をまとめると

①効率よく、バグの多そうな所を重点的にデバッグするのが大事。
②あらゆる境目にバグが多い。境界値分析で潰す。
③同じ原因で似たバグがある可能性があるので、水平展開で潰す。
④想定外のバグはモンキーテストで潰す。猿は神。
⑤開発者がデバッグすると本能に抗えずガバガバになるので注意。
⑥でも動作確認くらいはしようね。ヤバいバグは潰しておいて。
⑦バグの報告は、原因を特定するための情報を載せましょう。

ですかね。

まぁなんです。この記事にも誤字脱字があるかもしれませんが、推敲していないわけではないんですよ。そういうことなんです。えぇ、はい。

◆宣伝

今回の話で例に使った『いのちのつかいかた』というゲームですが、体験版が遊べます。ゲームブック風の、悩むのが楽しいゲームです。

もし興味があれば、遊んでみてくださいなー。

あと、普段はゲームデザインに関する記事を書いているので今回の記事が参考になった人はそっちもチェックしてみてください。