ゲームプログラミング/デバッグ

出典: フリー教科書『ウィキブックス(Wikibooks)』
ナビゲーションに移動 検索に移動

ゲームのデバッグ[編集]

ゲームにかぎらず、一般にソフトウェアのバグを取り除く修正のことを「デバッグ」といいます。

本書では、主に、ゲームにおけるベータテストにおけるデバッグの方法を説明します。


ゲームにかぎらず「ベータ版」(β版)とは、おおむね「バグが多いかもしれないけど、とりあえずソフトウェアとして最低限は機能するバージョン」のような意味のバージョンのことです。

いっぽう、「そもそも起動しない」とか「コンパイルできない」とか、「クローズボタンを押して無いのに、いきなりアプリが異常終了する現象が頻発」とか、「画面が、ずっと、まっくら」とか「データが勝手に消える」みたいな重大バグの多いバージョンは、アルファ版(α版)というか、または、単に開発初期のバージョンです。


ベータよりも前のアルファ版は、プログラマー側だけでチーム内部でチェックしたほうが、ラクです。

いわゆる、「テストプレイヤーを広く募集してテストプレイ」というテストは、ベータ版から行います。

ゲームに限らず、こういう、プログラマー外部のテスト者にも協力してもらって、ベータ版をテストしていくことを、「ベータテスト」といいます。


「ベータ版」と、商品として発売した「リリース版」との違いは、相対的なものでしかなく、実際にはリリース版であっても、バグが含まれるのが一般的です。

ゲームに限らず、現代の複雑化・高度化したソフトウェアでは、すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能なのです。


そのため、デバッグの最終目標は、けっして「バグをゼロにする」ではなく、「もしバグが残っていても、アプリの致命傷にならないようにする」などの、フェイルセーフ(fail safe)的な方針でデバッグしていく方法になります。そのため「影響度の大きい重大バグから、潰していく」などのような方向性で仕事していくことになるでしょう。

最初から「面白いバグ」はまず無い[編集]

また、バグは原則、発見したら、なんらかの修理的な処置により直すべきです。

よく、「面白いバグは裏技として残す場合もある」と言われますが、たとえ最終的に裏技として残す場合であっても、とりあえず発見者はそのゲームの問題点のある挙動を『バグ』として報告し、判断を担当者に任せます。

そして「バグ」報告を受けた担当者は、その「バグ」をたとえ裏技として残す場合であっても、現状ではテストプレイヤー視点ではバグ的に見えるわけですから、そのゲーム中の挙動には、なんらかの修正対処が必要です。

そもそも、ゲーム開発序盤では、そのままでは「面白いバグ」というのは、ありません。

たとえ有名ゲームの面白い仕様の挙動が、バグ由来の現象でも、そのプログラムコードはゲームの実装開発中に何度も修正を受けて改善されてきています。

つまり、「改善すれば、面白くなりそうなバグ」なら、あるかもしれません。

バグ報告を受けた担当者は、そのバグが「改善すれば、面白くなりそうなバグ」なら、その挙動が一般プレイヤーにとっても面白くなるように、修正していく必要があるのです。

総論[編集]

ゲームのデバッグのためには、まずバグを発見する必要があります。

しかし、すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能です。


なので、まず製作者は、プレイヤーのよくやる行動をゲームプレイで再現してみて、そして遭遇したバグから直しましょう。

※ 「仕様書やチェックシートなどをもとに確認しなくていいの?」と思うかもしれませんが、(想像ですが)本格的な仕様書・チェックシートが作成される時期は、ゲーム開発の中期あたりからでしょう。
なぜかというと、仕様書を作成する前にまず、試作品ゲームソフト(プロトタイプ)をある程度はキリよく遊べるところまで作ってから、その試作品にデバッグをして大きなバグや目につくバグを潰してから、通しプレイをするなどしてマトモに遊べることを確認してから、ようやく仕様書などの書類を作ることになるからです。仕様書が無い段階では当然、チェックシートなんていうモノも無いのです。
試作品(プロトタイプ)とは言っても、バグは早めに直しておく必要があります。そのゲームが、万が一にバグが起きてもバグを直しやすいシステムになってるかどうかを確認するのも、試作で行うべき確認事項のひとつです。しかし、試作品ですので、あまり多くの人員をテストに導入できないので、なので、プレイヤーのよくやる行動で遭遇するバグから先に潰していく必要があります。

さて、プレイヤーのよくやる行動を優先する理由は、極端な例を挙げると、例えば、もし普通のプレイヤ-のやらない行動をしてみてバグを見つけて直しても、 たとえば、RPGで、薬草の使用をキャンセルするのを20000回連続で続けると遭遇するバグがあったとして、もし製作者がそのバグを直しても一般プレイヤーは気づきません。

1960年代のような古いコンピュータのデバッグ方法と、現代のデバッグ方法は違います。

つまり、パソコン黎明期の科学計算のデバッグやファミコン黎明期(1980年代)のゲームのバグの探査方法と、現代の廉価or無料のパソコン用ゲームのバグの探査方法は、微妙に違います。

アセンブラなどをいじくる必要のあったテレビゲーム機の黎明期の時代のバグ発見の方法は、現代では、あまり向いていません。

現代のゲームでは、バグ修正は、ネットワーク通信ゲームなら、公開後にもネット経由でアップデート修正することもできます。

また、有料ゲームでも、販売前に体験版などを配布してプレイヤーにテストプレイしてもらう事で、プレイヤーの遭遇しやすそうなバグを探せます。


一方もしゲームでなく、たとえば自動車用の組み込みプログラムや、あるいは工作機械などの組み込みプログラム組み込みなどのバグ探索ならば、バグが人命の死につながりかねないので、たとえば、電源ケーブルや通信ケーブルなどの抜き差しをしたりとか不安定な状態にしてバグを探したりとか、温度をあげたり下げたりとかまでしたりとか、そういうハードウェアとの関連のありそうなバグも様々な方法で徹底的に探します。

しかし、現代のゲーム開発では、そこまでしてバグを探す必要は無いでしょう。

また、こういったハードウェア関連のバグは、OSメーカーやあるいは業務用の組み込み機器メーカーなどが探すべきバグです。 けっしてPC用ゲームメーカーの探すべきバグではないです。

新発売されたばかりの新ハード用の対応ゲームをハードメーカーやOSメーカーが制作しているならともかく、既存のパソコン用の無料ゲームや廉価ゲームなどでは、そこまでしてハード関連のバグを探す必要は無いでしょう。


なお、IT業界において、デバッグは一般的に品質管理(QA)部門の仕事です。(※ 異業種の人に説明する際、こう説明しよう。)


優先順位づけ[編集]

ともかく、ゲーム産業にかぎらず一般のIT業界でも、発見されたバグは、修正の優先順位にもとづいて格付けをされます。

医学における、どの患者から先に治療すべきかという概念である「トリアージ」という医学用語になぞらえて、IT業界でもバグの修正対応の優先順位(priority)の格付けのことを外国でも「トリアージ」と言います。

このことは、ゲーム作家の側には「トリアージ」などの用語の暗記は不要ですが、どちらかというとプレイヤーのテスト協力者などに考え方を知ってもらう必要があるでしょう。

もし科学者が科学計算ソフトウェアで世界最先端の開発を目指すのなら、(予算が国から与えられる限り)好奇心や興味のおもむくままに研究して、「トリアージ」の概念を無視するのも可能かもしれません。しかし一般のIT産業やゲーム開発では、予算の制約が厳しく、人員や設備の制約も厳しく、そうはいかないので、「トリアージ」的な優先順位づけが必要になります。

ゲーム業界でも当然、このようなバグ修正の緊急性の格付けは行われております。(参考文献: STUDIO SHIN 著『ゲームプランナーの新しい教科書』)[1]


バランス調整との違い[編集]

敵の強さなどの設定のバランス調整も、デバッグのためのテストプレイも、一見すると似ていて、ゲームを延々とプレイしたり、問題点を発見したらレポートを書いたりするので、似ているかもしれません。


ですが、目的が違いますし、そして重要な相違点として、要求されるゲーム内知識が違います。


バランス調整のためのテストプレイヤーには、なるべく、そのゲームに詳しくない人のほうが最適です。そのため、他の開発者は、テストプレイヤーにあえて情報を伏せたりする事も考えられます。いっぽう、バランス調整テストプレイヤーも、あまりそのゲームの裏事情を知り過ぎないように気をつける必要があります。

ただし、バランス調整チームのリーダーだけ、そのゲームの裏事情を知ってたりします(でないと、他部門とコミュニケーションが取れなくなりかねない)。


いっぽう、デバッガーは、なるべく、そのゲームの裏事情や開発事情などにも精通し、そして、そういった知識も動員しつつ、バグの起きそうな所をテストプレイで探して、バグを発見する必要があります。


※ バグの報告をする人を「テスター」という場合もありますが、本wikiではバランス調整用のテストプレイヤーとの区別のため、デバッガーと呼ぶことにします。また、バグ報告を受けてプログラムを修正する人だけを限定して「デバッガー」という場合もありますが、本書ではやはりバランス調整との区別のため、バグ報告マンも、バグ修正プログラムのプログラマーも、まとめて「デバッガー」と呼ぶことにします。


バグの中には、そのゲームの仕様に精通しないと気づきづらいバグもあります。気づきやすいバグというのは、たとえば「画面がノイズだらけになる」というバグなら誰でも気づきます。しかし、そういう分かりやすいバグばかりではないのです。たとえば「あるシーンでの登場人物のセリフが微妙に、前後の話の流れにあってない。特殊イベント管理フラグのミスか?」みたいなバグも起きうるのです。なので、デバッグ作業では仕様を知る必要があるのです。


また、似たようなプログラムを使っている2つの特殊イベントの片方にバグがあったら、もう片方にもバグがあると考えるのが自然です。デバッガーにはそういう論理性が要求されます。また、こういうデバッガーの論理思考に協力するため、プログラマーなどもデバッガーにアルゴリズムの要点などの情報提供を適度にする必要があります。

なお、初心者の視点のほうが気づきやすいバグもあるので(たとえばチュートリアル説明などのバグ)、デバッグテスターも最初は仕様の知識の無いところか始めますが、デバッグ作業の進行に応じて仕様制定者(プランナー)や上長などからデバッグ状況に応じて仕様を随時、教えてもらうことになったり、仕様書をもらいます。

このように、上長などは、デバッガー系テスターに、そのゲームの設計図や仕様の一部を随時に教える場合もあります。商業ゲームの場合なら、デバッガーは最終的には仕様書(そのゲームの設計図)を見ながら、そのゲームのすべての仕様を一通りはチェックすることになります。


一方、バランス調整テストプレイヤーでは、逆にそういうヒントは、一般プレイヤーとは異なる先入観を与えてしまう結果になってしまうので、こういうヒントは与えてはいけないのです。


デバッグの当初は、デバッガーもバランス調整テストプレイヤーも、知識が少ないとこから始めるので、知識事情が似通っていますが、次第に要求されるゲーム内知識が違ってきます。


なお、デバッグは、人数が多いほうが有利です。なるべく、異なった視点で色々なプレイするほうが、色々なバグを発見できます。


バランス調整はややコツが必要ですが、それと比較すると、バグを発見するためのプレイは、比較的にコツが少なめで済みます。

なので、もし同人サークルなどチームでゲーム製作している場合、なるべくチームメンバーの多くでデバッグしたほうが、より簡単に見つかるでしょう。

すべての組み合わせの検証は無理[編集]

たとえばRPGなら、武器や防具といった装備の組み合わせは、

もし武器(剣や槍や斧や杖や弓など)が合計で100種類、
頭防具が合計で50種類(カブトや帽子)、
胴ヨロイや服が合計で50種類、

だとしたら、組み合わせは装備だけでも合計で 100×50×50 = 250000種類 (25万)にもなってします。

つまり、もしすべての組み合わせを検証しようとすると、作業が指数的に増えてしまいます。

しかし、こんなに多くの組み合わせを検証するのは個人では無理ですし、無駄です。


デバッグ検証はせいぜい、武器なら100種類の装備をすべて装備してみて、装備できるキャラクターが装備しても異常が無いかとか、戦闘で実際に攻撃を見て以上が無いかとか、そういうことを確認すればいいのです。

同様に、防具のデバッグ検証もそうです。

これなら、装備の検証作業は、100+50+50=200種類なので、大幅に作業が減ります。

つまり、足し算、加算的に検証すれば、十分です。


実際の市販のRPGなら、さらに装備の数が多くなるでしょう。

また、どのキャラクターが装備するかとか、どこのエリアで装備するかとか、いろいろな組み合わせが実際のプレイにはありますが、もちろん、そんな検証をすべてするのは無理で無駄です。


上記の例ではRPGの装備システムを例にとりましたが、別にRPGやシミュレーションゲームなどのパラメータの多いジャンルのゲームに限らず、 異なるジャンルのたとえばアクションゲームやアドベンチャーゲームなどのゲーム内の各種システムでも同様です。

なのでデバッグは、ゲーム内の各種のアイテムやコマンドなどのデバッグなら、せいぜい、とりあえず、そのアイテムやコマンドなどを選択したり実行しても異常が無いかを1回だけ試せばいいのです。

そもそも、ゲームのシステムは基本的に、プレイヤーごとに異なる多様なプレイスタイルに対応するために多くのアイテムやパラメータやイベントをゲーム内部に持っていて、そういった組み合わせの意外性などをシミュレートして楽しむものです。

なので、組み合わせは膨大になるのが普通なので、全組み合わせの掛け算的な回数の検証は無理です。


テレビゲーム黎明期の1980年代なら、装備アイテムの数などが少なかったので、もしかしたら組み合わせをすべて試すのも可能だったかもしれませんが、しかし現代では、アイテムの数などは膨大に増えており、もう無理です。


なので、もしバグがあっても、そのゲームをクリアできるようにゲームを設計する必要があります。このためにはどうするかというと、デバッグの困難な箇所は、そのゲームのクリア要件から外す、という手法で簡単に出来ます。とはいえ、イチイチ考える必要はなく、一般のゲームのクリア条件は普通、そういうふうになっています。たとえば対戦格闘ゲームなら、敵を打撃してライフをゼロにまで持っていけば、途中経過は問わないワケです。こういうふうに、クリア要件さえ満たせば途中経過は問わない、というふうにクリア要件を設定すればイイだけです。


また、現代の複雑化したゲームでは、ver1.00以降の発表後にも、アップデート修正が必要になる可能性が高いです。なので、ver1.00の発表前に事前にアップデート版の配布が可能な環境を整えておきましょう。

さらに、もし有料ゲームのアップデート配布の場合なら、なるべく

有料版ソフトを買った人だけに、無償でアップデート適用ずみのフルパッケージ版を配布できるような環境

があるかを事前に環境準備しておく必要があります(「修正パッチだけ無料公開」とかではなく、すでに修正パッチを適用した状態でのフルパッケージ版という意味。消費者が有料で購入しているのだから、修正パッチ適用などの手間を掛けさせない。そもそも、修正パッチを適用するのにソースファイルが必要な場合が普通なので、普通はメーカー側で修正パッチを適用してから配布する)。


個人でそういう配布の環境を構築するのは困難なので、個人の場合には、ネット上のいくつかの企業がソフトウェア公開・販売環境を提供している企業がいくつかあるので、そのサービスを利用すると良いでしょう。

さらに、アップデート版のソフトウェア内部のシステムでは、過去バージョンの有料ゲームから、最新の修正後バージョンへのプレイデータの引継ぎをできるようにする必要があります(たとえばRPGの場合、プレイヤーにレベル1の序盤から再開させるワケにはいかない)。このデータ引継ぎの工夫は、ソフトウェア販売サービス提供の企業では無理なので。


もし、上述のようなアップデート配布が不可能な環境にあるのなら、そのゲームが個人製作のゲームの場合には、無料ゲームソフトにしておきましょう。

ゲームにかぎらず一般に有料ソフトを販売した場合には、開発元のメーカーは「保証期間」または「アフターサービス」のような社会的責任として、発売開始後から数年ていどは無償で不具合対応などのアップデートをすべきという社会的な責任があります。

食料品やティッシュペーパーのような消耗品でないかぎり、ソフトウェアにかぎらず一般の工業製品などでも企業は商品の有料での販売においては、発売開始後から数年は、「保証期間」などとして無償または低価格の不具合対応などの社会的責任が要求されます。

無料のソフトではそこまで保証する義務は無いですが、まあ実務の練習だと思って「保証期間」的なものも頭の片隅に意識しておいたほうが無難でしょう。

ソースファイルにモニター(監視)機能を入れる[編集]

主にアルファ版や新機能の追加時のテスト方法ですが、

もうひとつのバグ発見の方法として、

一般にゲーム開発では、作者用のソースファイルと、プレイヤー用のファイルを分けるので、

作者用のソースファイルにデバッグ用の機能をいくつか入れておく方法もあります。


ゲーム内のシステム内部の監視のためのデバッグ用メッセージ(「現在のパラメーター herosPower は 134 です。」のようなメッセージ)を表示するモニター的な機能は、こちらソースファイル側で行うとよいでしょう。

なぜなら、プレイヤーが細かいシステムメッセージを見ても退屈ですので。


まずテストプレイしよう

アルファ版でもベータ版でも、まずバグ発見のためには、モニター機能プログラムを書くよりも先に、まず先に実際にゲームを起動してゲームをプレイしてみることです(いわゆる「テスト プレイ」)。テストプレイで挙動のオカシイ部分があったら、そこで、ソースコードで、挙動のおかしい箇所のプログラムの近辺で、変数の内容を表示する機能のあるモニタープログラムを自分で書きます。


ブレークポイントは後回し

なお、WindowsのVisual Studio には、ブレークポイントという、デバッグ用にコード中に強制停止するポイントを設定する機能があり目的の箇所でコードを停止させ、変数を表示させる機能がありますが、しかしこの機能(ブレークポイント)をいきなり使うのは、ゲーム製作では、あまりオススメできないです。

なぜなら、ゲームが止まってしまうので、実際のプレイ中でのパラメータの変化が不明です(ブレーク時点での変数の値しか、分かりません。)。


ブレークポイントを使う場合は、起動そのものの不可能なバグとか、ゲームが異常停止していまうようなバグの場合などの、テストプレイそのものが困難な重篤なバグの場合にだけにしましょう。

テストプレイが可能なていどのバグなら、なるべく実際にゲームをテストプレイして、モニタープログラムでバグの性質をさぐったほうが早いです。


モニタープログラムは最小限にするのがコツ

しかし、まだバグの見つかって無い段階で、モニタープログラムを入れるのは、オススメできません。

なぜなら、ソースファイルが見づらくなるからです。

バグが見つかってから、関連しそうな変数を表示するモニタープログラムを書きましょう。

モニタープログラムは最低限にするのがコツです。

そして、バグが修正し終わったら、そのモニタープログラムのコードは、量が多くなってきたら場合は、さっさとソースコードから該当する変数のモニタープログラムをコメントアウトするなどして、非表示にしてしまいましょう。

なんでもかんでもシステム内メッセージを画面に表示したとしても、メッセージを読みきれないので無理です。


また、あまり、ソースファイル独自の機能を追加しすぎると、一般にソースコードじたいが読みづらくなります。


デバッグルームなど[編集]

デバッグルームとは[編集]

ゲーム内でめったに起きないイベントなどのデバッグは、通常のプレイ方法では、めったに遭遇しないために発見が困難になります。

たとえば、ゲーム内でくじ引きがあり、1000分の1で大当たりが出るとしましょう。(※ 説明の単純化のために、極端に確率を低くしている。実際のゲーム製作では、低すぎる確率は避けたほうがデバッグしやすく安全である。)


通常のプレイでは、このくじ引きを1回だけしか出来ないとしましょう。


このようなイベントのデバッグ検証の場合、「大当たり」にバグがないかは、デバッグ用に、ゲーム作者だけ、くじびきを何百回も続けてチャレンジできるようにしたりとか、あるいは、ゲーム作者だけ、くじ引きの結果を操作できるようにして強制的に「大当たり」が出たりするようにするとか、

そういう作者だけの特殊システムが必要になります。一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。


このような、デバッグ用の作者専用システムのことを、俗にゲーム業界では「デバッグルーム」とか「デバッグモード」とかいいます。

デバッグルームとは「デバッグの部屋」という意味です。作品によっては、実際にゲーム内に「デバッグルーム」というエリア、ステージを用意する場合もあります。

この機能を作者が使うことを「デバッグルームに入る」とか「デバッグモードをオン(ON)にする」いいます。

名前こそ「デバッグルーム」や「デバッグモード」などというものの、しかし、その場所ではバグそのものの退治・修正はしないですし、そもそも、ゲーム起動中にバグ修正は不可能です。

最終的にバグを修正するには、(ゲームをシャットダウンさせてから)ソースコードを開発ツールなどで直す必要があります。

「デバッグルーム」とは、単にゲーム内でバグ探しの作業をしやすいように、プレイヤーキャラクターを強化したり、あるいは敵を弱体化させるなどの環境を調整するだけなのが、デバッグルームです[2]


背景として、基本的にはプレイヤーキャラクターが強めのほうが、ゲーム内世界をいろいろと探検しやすいのでバグは発見しやすくなります。


なぜならゲームでは、たとえばRPGでゲーム終盤の強敵を倒したときに発生するバグなどは、主人公がゲーム序盤の弱いキャラクターの状態では無理です。一方、ゲーム序盤の弱い敵に主人公が負けるなら、単に油断したり無防備になればいいだけなので、主人公は強いままでもデバッグ可能です。

「大は小を兼ねる」といいますが、ゲーム内では強めのキャラは弱めのキャラを兼ねます。

しかし、その逆は困難です。


なので、たとえ、デバッグ用の機能の名前に「デバッグルーム」などの名前がついていなくても、もし裏技や隠しアイテムなどでプレイヤーを強化するものがあれば、実質的にデバッグモードでしょう。

また、ゲームクリア後に、初回プレイよりも強い状態でニューゲームを出来る機能があれば(いわゆる「強くてニューゲーム」)これも実質的にデバッグ機能して活用できます。ゲーム序盤~前半のイベントに潜むバグなどを探すには、「強くてニューゲーム」のような機能があれば便利でしょう。


プレイヤーによっては、「デバッグ」などのIT用語を嫌がる人もいるので、そういうのに気をつける必要もあります。

また、ゲームのジャンルによって、近未来SFファンタジーやSFアクションなどでは、ゲーム中のシナリオにもIT用語が出てくるので、そういうのと区別するために「裏技」などの言い換えをしたほうがいいかもしれません。


デバッグルームの建築[編集]

さて、デバッグルームを建築する際は、なるべく、既にそのゲーム内にあるシステムを流用します。なるべく、一般プレイヤーにも公開されている機能を組み合わせてルームを作る必要があります。そうしないと、デバッグルーム独自機能の検証の手間が増えてしまうので、かえって、メンドウになってしまいます。


デバッグルームの中では、普通のプレイヤーが操作できないものを操作できるようにします。たとえば、RPGなら、プレイヤーキャラのレベルをある程度の上昇させたり下げたりとか、主人公の入手している武器や防具ある程度の範囲でを操作したりとかの機能が必要です(けっして、完全に数値をピッタリ調整する必要はないです。最終目的はあくまでバグ発見です。けっして数値をピッタリと調整することは目的ではないです)。

RPGなら、たとえば、強めの武器や防具をいくつかデバッグルーム内においておいたりとか、あるいは、通常プレイでは商店では非売品の武器・防具をデバッグルーム内では有料(ゲーム内の通貨)だが販売しておくとかすれば、万が一、一般プレイヤーがデバッグルーム内に進入してしまっても安全です。

あるいは、デバッグルーム内に、経験値アップや、レベルアップなどのアイテムとかをいくつか置いておくと、レベル上げの手間が減ります。

このようにデバッグルーム内に強化システムを配置しておくと、ゲーム後半のイベントなどの検証も、ラクになります(キャラクターの育成などに掛かる時間などが短くなるので)。


くじ引きの「大当たり」などのイベントをデバッグ検証で容易にしたいなら、デバッグルーム内に、たとえば「幸運のお守り」のような感じのアイテムを置いておいて、それを装備すると、ゲーム内のくじ引きなどの大当たりの確率が100%になるとか50%になるとかの機能をつけておいて、そういうふうなアイテムを作っておけば、くじ引きなどの検証がラクになります。


さて、一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。

作者のファイルにだけ、デバッグルームに入れるアイテム(「デバッグルームの鍵」など)とかを設置するとかして、実装します。一般プレイヤーに配布するゲームデータには、デバッグルームの鍵などを与えないようにします。デバッグルームの場所は、ゲーム内の中盤や後半に隠して立てておくと安全です。

あるいは隠すのではなく正式な公開機能として、ゲームクリアしたプレイヤーに、デバッグルームの一部を開放するなどする方法もあります。こうすると、あまり気にやまなくても済みます。

または、ゲーム開始のオープニング画面中に、画面には表示されてないが実はパスワード入力を受け付けしている状態を起動させておいて、パスワードが正しければデバッグモードがオンになった状態でゲームを開始できるようにするとか、そういう方法もあります。パスワードの受付をしているのを、プレイヤーには見せないようにします。


アクションゲームなど、あまりRPGのようなアイテム配布をしづらいようなシステムの場合は、この裏技のような方法のほうが便利でしょう。


裏技システムの場合、もし一般のプレイヤーがたまたまデバッグルーム用パスワードと同じキー配列を入力しないように、パスワードは十分に複雑にしておくとかの工夫が必要です。万が一、パスワードを運よく一般プレイヤーが知らずに偶然に入力してしまってゲームを開始した場合でも、プレイヤーがゲームプレイを楽しめるように、「これは裏技モードです」とかとでも冒頭で紹介しておいて、プレイヤーキャラクターの強さを(通常モードと比べて)やや強めに変更するくらいの設定にしときましょう。

1980年代のファミコンなどの市販ゲームで、こういう「裏技」(うらわざ)がよくあります。おそらく、そのソフト開発者がデバッグ用に残した機能だったのでしょう。

個別チェックと通しプレイ[編集]

まずは個別チェック・局所チェック[編集]

総論[編集]

ゲームで新しい機能を追加した場合、たとえばデバッグモードなどの機能を使ったりしてでもいいので、

まず、その追加したばかりの機能が実際に動作しているかを、(デバッグモードでいいので)プログラマー自体がチェックします。

もし集団作業なら、これは、プログラマー本人が、まず率先して、ある程度は自分たちでデバッグモードによるチェックをやる必要があるでしょう。(いちいち他の部署に作業を回すと、かえって時間が掛かってしまう。)

また、集団作業でなく個人製作でも、まずデバッグモードでも何でもいいので、追加したばかりの機能をチェックします。


この個別チェックというか局所的なチェックでは、けっしてバランス調整などをする必要は無いです。

個別チェック・局所チェックと、バランス調整とは、目的が異なります。

個別チェック・局所チェックでは、単に、デバッグモードなどで、その項目だけをチェックします。

もしデバッグモードの機能が無いゲームの場合や、製品に近くデバッグモード不搭載のバージョンの場合には、デバッガーは、なるべくデバッグモード利用時に近いプレイ方法で、個別にチェックしていきます。

各論[編集]
全装備品の装備、全アイテムの使用など

たとえば、RPGの装備品のシステムが正常に動作しているかどうかを確認するためなら、とりあえず、すべての装備品をいったん装備および装備解除してみる、というような作業をします。

これは、一般プレイヤーがゲームを楽しむ方法とは、異なります。

ですが、デバッガーは、こうして確認をしていきます。


たとえばRPGなら他にも、すべての道具をとりあえず最低1回ずつは使ってみるとか、

到達可能なマップチップには、すべてのマップチップの上を歩いてみるとか、そういう事をします。


とはいえ、これらは普通のゲームプレイでも、プレイヤーによっては、アイテム効果確認や隠しエリア探索などのために、よくやる事でもありますので、これはまだ楽しいほうです。

通行止めの確認

さらに商業ゲームでは、たとえば、壁(かべ)の通行不能の処理が、本当に壁として行き止まりになっているかとか、通行止めであるかとか、そういう行き止まりチェックみたいな事も、します。

ツライ事の一つは、この行き止まりチェックでしょう。(とはいえ、すべての壁をチェックするのは、現代では不可能なので、サンプリング的にいくつか体当たりしたり、重要なカベだけ体当たりしたりとかでしょうが。)

なのでフリーゲームだと、この行き止まりチェックはよく、省略されます。なのでフリーゲームでは、ver1.00公開直後には、よくあるバグで、本来なら行き止まりのハズなのに通行可能になる壁のようなモノの存在するバグが、よくあります。


選択肢の総確認

他にもデバッガーのすべき事は、たとえば、ゲーム中にもし、なんらかの選択肢の入力がある場合、選択肢すべての(当面の)結果を確認します。

たとえば、もしRPGのストーリー中の重要なシーンでのコマンド選択肢で、善行と悪事との選択肢があった場合、2つのセーブデータを用意して、両方の選択肢とも試してみて、とりあえず数分は動作しているかを確認します。

このように、とりあえず、どちらの選択肢を選んでも、当面の数分はバグの無く、正常に動作しているかを、(デバッグモードや、セーブデータの複数用意などで)なんらかの方法で確認します。


なお、一般ユーザーのプレイ傾向としては、もしゲーム中に選択肢で、善行と悪事の選択肢があったら、なんだかんだで普通のプレイヤ-は善行を選びます。

なので、もし普通のプレイヤーに任せていては、いつまで経ってもゲーム中では、ゲーム中の悪事の確認は、なかなか、できないです。

このためデバッガーは、意識的に、自分のプレイスタイルとは異なる悪事の選択肢でも、デバッグして動作確認する必要があります。


全滅テスト、自殺テスト

また、一般プレイヤーは、上手にプレイしたがるので、わざとゲームオーバーする自殺プレイを嫌がります。

なので、デバッガーは、ところどころで、自殺プレイをします。ゲームオーバーや全滅などのイベントが正常動作するかを、ときどき確認します。


難易度の高いゲームなら、意図的に自殺プレイしなくてもよく全滅しますが、たとい難易度の低いゲームでも、わざと自殺プレイをします。


特にボス戦などは、ソースコードでは特殊なフラグ処理が入りこんでいるのでバグの混入している可能性も高く、そのため、たとえ弱いボスであっても、ワザと敗北したりする自殺プレイが、デバッガーのすべき事です。


カウンターストップのチェック

たとえば、RPGのゲームの上限レベルが「99」の場合、きちんとレベル99で止まるかを、とりあえずデバッグモードでチェックします。

こうしたデバッグを短時間で出来る用途のために、やたらと経験値の高い敵でも一体、ゲームのソースファイルにでも混ぜて、作っておきましょう。

レベル98からレベル上げをしてみたりとか、レベル97から一気に2レベル上がったらどうなるかとか、いろいろと確認しましょう。


また、所持金や道具の個数なども同様に、上限できちんと止まることをデバッグモードなどを活用して確認します。


さて、とにかく上述のように個別デバッグ・局所デバッグをして、まずはデバッグモード(またはデバッグモードに近いプレイスタイル)で正常動作するようになるまで、まずプログラムを修正していきます。

もちろん、デバッグモードで正常動作したからといって、けっして、必ずしも通常起動のモードでも正常とは、かぎりません。

ですが、もしデバッグモードですら異常動作をするなら、これはもう通常起動時にも異常動作をするだろう事は、ほぼ確実です。(数学でいう「必要条件」と「十分条件」の関係みたいなもんです。)

なので、まずデバッグモードで正常動作するようになるまで、まずプログラムを修正していきます。


このように、追加した幾つもの機能を、それぞれデバッグモードで即座にチェックしていきます。


また、もし機能を新たに追加したい場合には、まず前の機能のデバッグモードでの正常動作を確認し終えてからにしましょう。なぜなら、こうしないと、集中力が落ちるし、また、もしバグが発生した場合の修正が、とても複雑になってしまいます。


IT業界の格言ですが、「デバッグされてないコードは、(資産ではなく)負債である」という格言があります。


なので、コードを書くことよりも、自分で書いたコードをひとつずつデバッグすることのほうが重要です。

ともかく、このように、機能をひとつずつ、個別的にチェックしていきます。


ボタン連打や、壁に何度も衝突など

ボタンを1回だけなら押しても異常は無くても、ボタンを何度か押すと異常のあるバグも、ときどきあります[3]


とはいえ、ゲーム中の全てのシーンで何度もボタンを押していたら、ゲームが進行せずにデバッグも進行しないので、たとえばゲーム中で使用頻度の多いメニュー画面などでボタン連打するとか、あるいはイベント進行などで「ここが、もしかしたらバグが潜んでいる可能性がありそうだな」とか思ったところだけボタン連打するとか、工夫しましょう。


同様に、通行止めの壁などの場所なども、ときどき何度も壁に衝突したりしましょう。


わざと弱めのボス敵などに負ける全滅テストも、ときどき、2回以上はワザと全滅してみましょう。


壁衝突やボタン連打などのチェック中のデータは、なるべく混ぜない。

セーブ機能のあるRPGやシミュレーションや長いアクションゲームなどで、上述のようなボタン連打や壁衝突などのプレイを確認するとき、原則的にあまりセーブしないようにするほうが効率的でしょう。

なぜなら、もしそのゲームのあとのプレイで何らかのバグが発見された場合、原因として、ボタン連打などの影響を考慮する手間が増えてしまうからです。


1つのセーブデータで、複数の異常プレイの実験をしてしまうと、たといバグが発見できても、その原因が果たしてボタン連打の処理ミスなのか、それとも悪事のフラグミスなのか、ミスの箇所が不明になってしまいます。

なので、まずひとつのセーブデータでは1つの異常プレイだけにします。

もし、複数の異常プレイを一人のデバッガーがする場合には、セーブデータを別々に分ける必要があります。


同様に、ボタン連打にかぎらず、もし何らかのバグが発見された場合でも、たとい報告のためにセーブする必要があっても、そのデータはまだバグを発現していない未発症データとは分けて別データとしてセーブしましょう。

次に、通しプレイ[編集]

さて、こうして、いくつか機能をデバッグモードで個別チェックしていき追加していくのが完了したら、今度は次に、ゲームを最初から始めて、エンディングまでプレイをします。

このように、ゲームをオープニングからエンディングまでプレイすることを、「通しプレイ」(とおしプレイ)といいます。

通しプレイは時間にかぎりがあるので、たとえばある程度の週の間隔を置いて、前回のクリア以降に新バージョンが出てたら行うとか、そういうふうに工夫します。(もし機能の追加のたびに通しプレイすると、時間が不足する。)


さて、商業作品の場合、通しプレイでは、けっして上手にプレイするのが目的ではないのです。

とりあえず、色々なことをそのゲーム中でしてみて、それでもバグが起きないことを確認するためのモノです。

1回目の通しプレイ

とはいえ、最初の1回目の通しプレイでは、まず普通に、自分のやりたい自分本来のプレイスタイルでプレイするのもイイでしょう。(もしもゲームのクリア所要時間が長すぎる場合や、クリア困難な難易度の場合には、とりあえず数時間ほどのプレイで区切るべきだろう。)

なぜなら、世間の他人から見れば、アナタのプレイスタイルも、他人にとっては「色々なプレイスタイル」のひとつですから。

また、そのゲームの中でどういった行動が可能なのかを知るためにも、とりあえず最初の1回は、普通にプレイする必要があります。


2回目以降の通しプレイ:パターンA

さて、とりあえずの1回目の通しプレイが終わったら、2回目以降の通しプレイでは、プレイスタイルを変えます。

けっして、通しプレイの目的は、「エンディングに最短時間で到達する」(×)とかではないし、「上手にプレイする」(×)とかでもないのです。


自分のプレイスタイルではなく、自分以外のスタイルで、他の多くのプレイヤーがやりそうなプレイをします。


とはいえ、プレイスタイルを変えてみるのも、(自分の性格にもよりますが)そんなにツマラナクは無く、1回目では見過ごしていたイベントを発見できたりとかも出来ますので、さまざまなプレイスタイルを自身で再現してみることで今後の自分のゲームとの付き合い方の勉強にもなります。(というか、コレがツマラナイと感じる人は、そもそも性格的にデバッガーに向いてないので、別の職種を頼むべきかと。)

また、1回目と同じプレイスタイルでプレイしても、どうせ1回目で見たことある現象と同じ現象しか見られないので、むしろ2回目以降はプレイスタイルを変えたほうが面白くなるでしょう。


2回目以降の通しプレイ:パターンB

普通のプレイヤーは、ある程度は上手にプレイしようと目指します。

また、ゲーム中の選択肢で、善行と悪事のどちらかを選ばせる選択肢がある場合、たいていの一般人は善行を選びます。


なので、彼ら一般人と同じプレイスタイルでは、たとえばもし、ゲーム序盤のとても弱い敵に負けた際に発生するバグがあったとしても、そういうのは発見されづらくなります。


なので、ときどき意図的にヘタな通しプレイをします。

事前のデバッグモードなどでの個別チェックでも、このような確認はしているハズですが、確認モレがあったり、あるいは通しプレイ時にしか発生しないバグなどもありうるので、念のため通しプレイでも、意図的に下手なプレイをします。


壁衝突やボタン連打などのチェック中のデータは、混ぜない。

通しプレイでも、ときどき壁衝突のテストや、ボタン連打などの異常プレイのテストは必要ですが、しかしそれらのセーブデータは、なるべく、(自分以外の)通常プレイヤーの行動再現のセーブデータには、混ぜないようにしましょう。

また、さまざまな選択肢を選んでプレイしているセーブデータにも、ボタン連打プレイなどのプレイデータは混ぜないようにしましょう。


もし今後、何らかのバグが発見された場合に、ひとつのセーブデータにて壁衝突・ボタン連打プレイ・通常プレイヤー再現プレイ・選択肢チェックのデータをセーブしてしまうと、せっかくバグ発見できても、想定されるバグ原因としてボタン連打などの影響の可能性などが増えてしまうからです。


ただし、通しプレイの場合、さまざまなプレイスタイルの再現中に、ゲーム中の選択肢などで、やや変わった選択肢をする場合もあるし、ややゲームの苦手なプレイヤーの行動を再現する場合もあるので、(つまり、選択肢プレイと苦手プレイは)そういうのまではセーブデータを分ける必要はないでしょう。(もしそこまでセーブデータを分けると、セーブデータ数が膨大になり、管理しづらくなる。)

よほどの異常プレイでないかぎり、セーブデータを分ける必要は無いでしょう。

しかし、かなり異常なプレイを意図的にする場合には、セーブデータを分けるか、あるいはセーブしないようするなど、工夫しましょう。

バグを発見したときに、原因の特定が容易になるように、セーブデータを分類して管理しましょう。

全体の流れ[編集]

さて、一般プレイヤーの行動を再現しただけの通しプレイがなぜ重要なのかというと、コレによって、重症なバグの有無を確認できます。

「クリア不可能バグ」のような重症なバグは、実際に通しプレイをしてみないと、分かりづらいのです。

また、クリア不能バグでなくとも、もし一般プレイヤー的な通しプレイなのにバグが発見された場合、これは発生確率の高いバグなので、どちらにせよ優先的に直す必要があります。

デバッグで重要なことは、けっして単に多くのバグ報告の件数を増やすだけではないのです。

件数ではなく、重度の高そうなバグから発見する必要があります。

単にバグ報告の件数を増やすだけなら、通しプレイをせずに、個別チェックだけをしたほうが、形式的にはバグ報告の件数が上がります。


裏を返すと、いったん、一般プレイヤーの行動を再現した通しプレイをしたら、しばらくは通しプレイをする必要は無いです。


なので、全体の流れとしては、

まず、

  1. プログラマーなどがデバッグモードでもいいので新機能の個別チェックをして
  2. 次に、通しプレイによって大きいけど少ないバグを潰し、
  3. 再度の個別チェックによって、小さいけど件数の多いバグを潰します。
  4. その個別チェックが終わったら、また通しプレイ。
  5. 同様に、個別チェックと通しプレイとを交互に繰り返し。

このように、個別チェックと通しプレイとを交互に繰り返すことで、バグの大きさと潜伏範囲とをどんどん小さく狭めていき、バグを潰していきます。


個別チェック漏れのチェック

個別チェックなどで事前に、それぞれの機能のチェックをしているハズですが、 しかしチェック漏れのある場合もあります。

なので、上述の手順のように、通しプレイと個別チェックとを交互に繰り返します。

集団制作におけるソフトでのバグ報告の書式[編集]

ゲーム業界に限らず、IT業界ではバグ報告の書式がおおむね、下記のように決まっています。次の情報がバグ報告には必要です。

・バグの症状 :
・バグの発生方法 :
・発生の頻度 :
・バグ発生したソフトのバージョン :

と言った情報が最低限は必要であり、その報告が『バグ報告』である事とともに伝えます。

要するに、サラリーマンの社内の『ホウ・レン・ソウ』(報告・連絡・相談)のメールやIT企業などでのバグ報告メールなどと同様の書式です。


個人作業では不要ですが、集団作業の際などに、ご参考に。

ゲーム業界に限らず、リナックスなどのオープンソースのソフトウェアなどのバグ報告サイトでも、こういったバグ管理手法をしています。(というか、そういった海外プログラマーのバグ管理手法を、日本プログラマーが真似たと思われる。)

ゲーム業界でも同様に、こういったバグ管理手法です[4]

つまり、会社などで業務としてバグ報告をする場合には、ダメな報告の例としては「ゲームが壊れた! どうにかして!」とか「ゲームが止まった! どうにかして!」みたいなのは、論外という事です[5]

さて、下請け仕事でデバッグをする場合、自分は客ではないので、「ゲームが壊れた! どうにかして!」みたいな報告は論外です。


とはいえ報告の時点では、まだバグの原因が不明ですので、けっして、完全にピンポイントな原因特定をした報告は、不可能です。


なお、IT企業などでは、バグ報告については、社内サーバーに専用のページが用意されていたり、あるいは社内サーバーのバグ報告用エクセルなどに記入する方式だったりしますが、いずれの方式にせよ、上述のバグ発生方法・頻度・バージョン・症状などの記入が必要です。

「バグトラッキングシステム」(BTS)というバグ報告用の社内サーバが開発されているので(Redmine やJIRAやTracやMantisやBacklogなど)、それを設置したり、あるいはもっと単純にエクセルみたいなので代用されていたり、などです。なお、JIRAとBacklogは有料です。一方、RedmineとTracとMantisはオープンソースなので無料でも使えます。


なぜサーバが必要かというと、 2人以上の集団でのデバッグ作業の場合、自分の発見したバグを、自分よりも前に他のデバッグメンバーが発見して既に報告ずみの場合もあります。

なので、サーバでバグ情報を公開しておかないと、報告が重複してしまい、非効率になってしまいます。プログラマー側も、それぞれの報告に別個、報告するのは、とても面倒です。

2人ていどなら、まだイイですが、5人以上とかになると、まずメールなどで個別に連絡するのは無理です。


ただし、小規模なサークルでは、こういった社内サーバーの設置は難しいでしょう。とにかく、なんらかの方法で、バグ報告が重複しないようにしてください。このため、あまりにも開発初期の段階では、あえてデバッグメンバーを少数に限って、メールでやり取りする事もありえます。(いちおうメールにも、CC(カーボンコピー)などの機能がある。)


もっとも、同じバグについての報告を重複させないというのもバランスの問題であり、例外的にすでに他の人の発見したバグであっても、解決方法がまだ不明で未解決バグになっている場合には、自分がバグ調査して得た情報のうち、まだ報告されていない情報があれば、サーバーのバグ記入欄に追加の情報を記入するぶんには、構いません。(ゲームに限らず、GitHubなどのバグ報告欄でも同様の慣習です。)

べつに特許や発明ではないので、最初の一人だけが名誉と権限を独占する必要は無く、みんなで協力しあってバグ解決という問題解決するのが仕事です。


さて、バグ報告の手本として、もしメールで報告する場合、一例を書くと、たとえば

【バグ報告】 ウッキークエスト ver0.87 。ハジメガルド武器屋オヤジの会話時のキャラチップ表示ズレ

   ・[バグの症状]   ゲーム中盤でのハジメガルド武器屋の親父の会話時のキャラチップ位置表示ズレです。 

   ・[発生の頻度]  当の武器屋オヤジに話しかけるたび、毎回バグ発生です。3回、確認しました。

   ・[添付ファイルの内容] メール添付画像は、バグ発生時のオヤジ画像チップが店の壁に乗ってしまってるナゾ画像です。
    
   ・[バグの発生方法]   ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、
      ゲーム中盤の第三章になってからハジメガルドに行き、
      自軍パーティ構成が戦士・戦士・僧侶の3人パーティの
      味方平均レベル28くらいの状態で武器屋親父に話しかけると、
      なぜか親父が話しかけるたびに、
      バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。

    ・[参考情報]
      私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。
     「伝説の盾」は、このバグ発生の時点で入手しています。
      伝説の盾を守っている中ボス・暗黒大王も撃破してあります。
      
     今回のプレイでは、装備はまだハガネ装備です。ミスリル装備は、していない状態です。
     ミスリル鉱山の街をすでに帝国軍から解放しましたが、プレイヤー所持金を節約するためハガネ装備のままです。
     ハガネ装備のままレベル28まで上げて暗黒大王を倒しています。

みたいな感じでしょうか。(もしメール方式でなくサーバー方式の場合でも、こんな感じの書式で報告・連絡を入れる欄があるハズでしょう。サーバの場合の詳しい書式は会社によって違うので、説明は省略します。)

※ 「バグ発生原因などを報告前に特定しなくていいの?」と思うかもしれませんが、発生原因の特定は(あとで必要だけど)後回しです。先にまず、再現性のある(何度も起きる)バグを発見したことを、なるべく早く(「なるはや」で)、上司などにメールでも何でもいいので報告します(何度も起きるバグは、重要度が高いので)。なぜなら、発生原因の特定には、時間がけっこう掛かるからです。なので、まずバグ発見を報告したあと、そのあとに返事を待つ間などに、発生原因などを絞り込んで生きます。


なので、バグ報告は、1件のバグにつき基本、

1回目のバグ発見の速報(そくほう)と、
翌日(翌営業日)の2回目の詳報(しょうほう)とで、

最低でも2回以上、行うことになるのが通例です。


もし、バグ発生時の画面をキャプチャ(「スクリーンショット」ともいう)した画像があると、伝わりやすいです。

ウィンドウズでは、ショートカット・キー [Fn] + [Alt] + [Prt Sc] で選択中のアプリウィンドウごとにキャプチャでき、それをWindows アクセサリ『ペイント』のキャンバスに貼り付けしてセーブ保存すれば、キャプチャ画像が作成できます。

なので、バグ発生中のソフトのキャプチャ画像を作りましょう。


さて、バグの報告では、実際に起きたバグの症状を、主観を交えずに、見たままに報告します。

(要約には主観の混じらざるを得ず、)要約などを書いてもいいですが、しかし必ず報告の文中に、必ず、実際に起きた事だけを報告する段落・節などが必要です。なので、要約の文とは、段落などを分離したほうが良いかもしれません。

バグ報告に限らず、一般企業のサラリーマンのトラブル報告などの報告文などでも一般に、段落として(分析を交えずに)実際に起きた事だけを報告する専用の段落などが必要です。

なので、実際に起きたバグの症状の現状とは別に、バグ発生原因かもしれない関連情報・参考情報を併記する場合には、あくまでその関連性は推測に過ぎないので、段落を別々に分けましょう。上記の報告メール例でも、「バグの症状」と「参考情報」というふうに別々の節に分けて報告しています。


なお、報告メールの際、参考情報などで、とりあえずバランス調整に関係ありそうなテストプレイ時の行動も書いておくと、バランス調整チームがデバッグついでにバランス調整のための資料にも出来るので、一石二鳥です。また、ひょっとしたら、そのバランス関連の参考情報で書かれたテストプレイの行動も、バグ発生条件に関係しているかもしれない場合もあります。

(ただし、商業作品の場合は、バランス調整はデバッグよりも前のほうに、ある程度は終わらせておく必要があるだろう。)


しかし、あくまでバランス調整に関するテストプレイ報告については、後回しの付属的な情報です。メインに報告すべきは、バグに関係ありそうな情報から優先的に報告です。バランス報告については、せいぜい5行くらいまでで充分でしょう。

また、「バランスがイイ」だの「バランス悪い」だのといった良否の判断は、これはバランス調整者側の判断することでありますので、デバッガー分野の判断することではないです。

デバッグのついでのバランス報告では単に「レベルは○○くらいです」「装備は○○くらいです」とか「中ボスの△△戦では負けて1回全滅しました」とかプレイ事実だけを報告するべきであり、良否の判断はプレイヤー側ではしないのがポイントです。


このように、バグの発生方法についての説明は、バグが起きた時やその前にゲーム中で主人公のしていた行動を記述します。

(実際のプレイ行動だけを先に報告文面で書いた上での)追加情報として、「おそらく、バグの原因はコレだと思われます」という分析があるぶんには、構いません。


また、バグを報告する場合は、けっして即座に報告するのではなく、できれば最低限あと2回は同じ行動をしてみて(つまり合計で3回以上はしてみて)、それから同じバグが発生するかどうかを確認できたら報告します。

もし最初の1回しかバグが起きなかった場合は、もしかしたら、ソフト側ではなくハード側のその瞬間での不調などの原因も考えられますので、その場合にはバグ報告が、相手プログラマーにとって余計な手間になってしまいます。

ただし、ランダム性の高いバグなどの場合、本当はソフト側のバグなのに、2回目に試しても発生しない場合もあります。 なので、もし再現性が悪くても、けっして「ハード側のバグだな」と早合点せず、とりあえずは再現性の情報とともにバグ報告します。

再現性の悪いバグの場合、報告の文面では、たとえば

このバグの再現性は、3回試しましたが、1回しか発生しませんでした。

などという、再現性の悪いことを併記した説明書きとともに、バグ報告をします。


さて、ゲームのバグ報告の場合、もしそのバグの再現性が高い場合なら、

バグ発生の直前の行動だけでなく、バグ発生に影響のありそうな行動も報告する事になると思います。

なぜなら、RPGやシミュレーションゲームの場合なら、たとえば、「ゲーム中の中盤ストーリー中でしか起きないバグ」とか「東部地方でしか起きないバグ」のように、発生箇所や発生時点が限定されているバグもあるからです。

つまり、単に「Aボタンを押したら、こういうバグが起きました。」なんてのは論外です。

ゲーム中のどこのストーリー時点のどんな場所(マップやエリア、ステージなど)で、どんな操作キャラクターで、キャラクターに何をさせたらバグが起きたのか、といった、5W1H(いつ、どこで、だれが、なにを、どのように、どうした)のような情報を、バグ報告での発生方法では、書きましょう。

たとえば、

「ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、ゲーム中盤の第三章になってからハジメガルドに行き、自軍パーティ構成が戦士・戦士・僧侶の3人パーティの味方平均レベル28くらいの状態で武器屋親父に話しかけると、なぜか親父が話しかけるたびに、バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。」

みたいに、5W1Hで報告するのです。

バグ発生時の瞬間のプレイヤー行動は単に、武器屋で話しかけるですが、しかし、発生に影響を与えてるかもしれないと思った行動など、その他の行動も報告します。

なぜなら、バグ発生の条件は、必ずしも1つとは、限りません。複数の条件が満たされた場合にだけ、バグが発生する場合もあるからです。


これがもし、

(ダメな例)「武器屋の親父に話しかけると、表示が1マス、ズレます」

だと、報告を聞いた側のプログラマーにとってはバグ発生方法がサッパリ不明です。また、ハジメガルド以外の別の街の武器屋の親父では、バグは発生しないかもしれないので、プログラマー側が再現性を確認プレイしても、 ハジメガルド以外の武器屋でプレイしてしまう可能性もあります。その場合、バグ発生を確認できないので、その結果「間違った報告」としてプログラマーに処理されかねません。


また、ダメな例として

「武器屋の親父に向かって決定ボタンを押すと、表示が1マス、ズレます」

だと、決定ボタンを押した結果、何が起きる状態なのか、やや不明です。親父に話しかけるために決定ボタンなのか、それとも、たまたま親父の前でメニューコマンドで道具を使おうとして決定ボタンなのか、解釈が分かれてしまいます。

つまり、発生方法の操作の説明は、プレイヤーの動作ではなく、なるべくゲーム中のキャラクターの動作で、バグ報告しましょう。


なお、たといこのバグの発生条件で自軍パーティ構成が結果的に無関係だとしても、報告時に「自軍パーティ構成が戦士・戦士・僧侶の3人パーティの味方平均レベル28くらいの状態で武器屋親父に話しかけると、」のような情報があるのは、構いません。

なぜなら、バグ報告の時点では、まだ自軍パーティ構成がバグ発生に影響しているかどうかは不明だから、です。


バグ発生の条件は、必ずしも1つとは限らず、複数の条件が満たされた場合にだけ、バグ発生する場合もありますので、バグ報告では「影響してそう」と思った情報も提示します。


その他、プレイヤーによって行動が分かれそうなゲーム中での過去イベントでどうしたかとか、そういうのも後に追記しましょう。

たとえば、先のバグ報告バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。」の次の文で、

「私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。「伝説の盾」は、このバグ発生の時点で入手しています。伝説の盾を守っている中ボス・暗黒大王も撃破してあります。」

などのようにです。

もしかしたら結果的には「伝説の剣」や「伝説の盾」の入手の有無はバグには無関係かもしれないですが、しかしバグ報告の時点ではプログラマーにすら一切、原因は不明なので、よって報告の時点では、関係ありそうだと思った追加情報を手短かに5行~10行くらいで、いくつか選んで情報を報告します。


さて、報告する側は、もし時間に余裕があるなら、次からの検証プレイではバグ発生時の行動を少し変えてみて、それでもバグが起きるかどうかを試してみると、プログラマー側の今後の検証がラクになります。


さて、ゲームに限らずパソコンソフトの場合、

たといデバッガー側で何回もバグを再現できる事を確認できたとしても、

それでも、プログラマー側の環境ではバグが起きない場合がある。


このような場合は、たとえば、OS(オペレーティングシステム)の違いによって起きる場合がある。

たとえば、Windows の特定のバージョンでしか起きないソフトバグもある。

なので、もしプログラマー側ではバグをテストしても確認できない場合、 自分のOSを変更してみる等して、確認する必要がある。



細かな追試プレイは後回しに

バグ報告は、発見しだい、再現性が3回くらい確認できた時点で、なるべく早めに報告したほうが、最終的に効率的です。(バグ報告は『なるはや』(「なるべく早く」の略)で、と言われます。)

再現性が確認できたら、さっさと報告しましょう。


もちろん、バグ発見箇所の周囲にも類似のバグが潜んでないかとかも、今後はチェックするわけですが(理科でいう『対照実験』みたいに比較検証プレイを、あとでする)、

しかしそんなのは、そのときにチェックすればいいのです。


どうせバグ修正後にも、バグが本当に直ってるかを確認するためのチェックプレイするのですから、


だったら早めにバグ報告して、プログラマー側にとりあえず該当部分のバグを直してもらい、

そのあとに周辺箇所をまとめて通しプレイで調べればいいのです。


仕事術としては、おそらくですが、プログラミングやゲーム産業に限らずなにか仕事で、 自社や同僚などの設計ミスのようなものが見つかったら、 再現性が取れた時点で、その後の詳細な調査は後回しにして、ひとまず、 早めに設計担当の部署に報告をするほうが効率的でしょう。


その他

会社によっては、社内サーバで、バグ報告シートと、その他のバランス調整報告シートや提案シートなどを共用している場合もあります。

その場合、報告シートに、報告の種類の分類の記入欄があるハズなので、そこに「バグ報告」と記入して、バグ報告であることをきちんと明示しましょう。


なお一般に仕事において提案する場合、その提案の思いついたキッカケになったトラブルなどを一緒に報告すると、伝わりやすいです。

たとえば集団でのゲーム製作での提案の場合なら、「現在の仕様では、テストプレイ中に○○な不都合に遭遇しました。なので提案・要望ですが仕様変更として□□な仕様に変更してほしいです」みたいに伝えると、伝わりやすいです。

バグ報告のその後[編集]

バグ報告のあとは、次のような流れになります。

  1. (返事 :)とにかく、担当部署に報告を読ませ、報告を読んだかどうかの返事を書かせる。
  2. (優先度 :)修正するのか、または修正の優先度などの評価の決定をして、情報の共有をする。
  3. (修正 :) コード上でのバグ修正。コード上での修正が終わり、プログラマーの環境で再発しなくなれば、とりあえず「修正」として中間報告。
  4. (修正確認 :) 修正版が公開・配布されてから、プログラマー以外のコンピュータ環境でもバグが再発していないか、品質管理チームなどが実際に修正版をテストプレイして確認する。

ゲームに限らず、一般のIT企業でも大抵、似たような流れになります。

オープンソースやフリーソフトの場合などは、返事や修正確認が省略される場合もありますが、しかしゲーム開発では返事や修正確認は行ったほうが安全でしょう。

返事[編集]

集団作業でのバグ報告の場合、

バグ報告を受け取った側(主にプログラマー)は、

とりあえず返事をする必要があります。


プログラマーがバグ報告にもとづいて実際のプレイしてみて調査した結果として(プログラマー側でも)バグが再現できたのかとか、そういう事を社内のバグ報告用サーバーの専用ページ(あるいはバグ記入用エクセル)に記入するとか、あるいはメールでのバグ報告なら返信するとか、とりあえず、初期対応によって返事をします。

社内で情報共有する必要があるので、社内サーバーを使うのです。


さて、こういった社内サーバー経由のバグ報告では、たとい、すぐにバグが修正できなくても、とりあえず

「調査中」とか、
「プログラマー部署でもバグが再現しました」とか、あるいは「プログラマー部署ではバグが再現できませんでした」とか

とにかく、なにか現状が分かるように、バグ報告用サーバーなどにプログラマー側など返事の権限のある側が対応を記入します。


さらに企業などの場合、バグ修正後にも、

バグ記入用紙に、どのようにバグ修正のプログラムを対応したのかを、簡潔に1行~2行ていどで、バグ報告用サーバーの専用ページ(あるいはバグ記入用エクセル)に書いておきます。

したがってゲーム企業などの場合、冒頭の

・バグの発生方法 :
・発生の頻度 :
・バグ発生したソフトのバージョン :
・バグの症状 :

に加えて、さらに

・対応:

のような項目が専用ページ(あるいはグ記入用エクセル)に加わります。


さらに、会社によっては、

・バグの原因:

などの項目もあるかもしれないです。もちろん、バグの原因を調査するのはプログラマー側です(ソースコードを見れないとバグの原因を特定できないので、ソースコードを扱っているプログラマーなどが原因を記述する場合が多いだろう)。

もちろん、ここでいう原因は、たとえば「テンキーの1と4を押し間違えてしまい、その結果、武器IDが4番の『ハガネの剣』の番号がズレて『青銅の剣』(武器ID:1番)の攻撃力になっていました。」みたいなゲームのコードのミス内容とバグ動作の対応を特定できるような説明のことです。

けっして「寝不足だったんです」とか「風邪気味だったんです」とか、そういう情報は不要です。


ともかく、バグ報告記入シートに「原因」の項目のある場合、2行~4行ていどでバグの原因を記述しましょう。


なお、プログラマー側や管理者は、バグ発生部に関連する他の情報も知っている場合がありますが、なるべく、リリースまでは、最低限のバグに直接・一次的に関係する仕様しか情報の共有しないようにする必要があります。

つまり、デバッガーが報告した事に直接・一次的に関係する事は情報を公開、またはそのデバッガーに連絡する必要があります。

しかし、それ以外の間接的・二次的~三次的にそのバグに影響することは、あまり詳細を教えないようにする必要があります。


なぜそうするかというと、もし、間接的なことまで色々と仕様の裏側を知ってしまうと、デバッガーの次回の通しプレイからは、仕様を知ってしまってるので、自然なプレイが出来なくなってしまいます。


デバッガーによる通しプレイの際には、開発初期には、なるべく一般プレイヤーに近い予備知識の状態でいてもらい、一般プレイヤーの取りそうな行動をデバッガーに再現してもらう必要があります。(一方、開発中期ぐらいからは、デバッグ用テストプレイヤーにも裏仕様などを教えて、確認プレイしてもらう必要がある。)

なので、そのために、開発初期のうちにはデバッガーには余計な知識が無いほうが一般プレイヤーの感覚に近づくので、あえて間接的にバグに影響する仕様については、デバッガーには公開しないでガマンしてもらう必要があります。


具体例を挙げると、たとえばアクションゲームで、全10面あるゲームのうちの4面のボス「暗黒大王」との戦闘アルゴリズムにバグ報告があったとして、その報告をもとにプログラマー側は8面のボス「ゾンビ暗黒大王」にもバグをプログラマー側で別途に発見したとしましょう。

この場合、プログラマー側は、8面の「ゾンビ暗黒大王」にもバグがあることについては、デバッガー・テストプレイヤー達には、開発初期のうちは教えないでおきます。

なぜなら、報告を入れたデバッガー側・テストプレイヤー側はまだ、8面まで進んでおらず、4面ボス「暗黒大王」までしか進んでない人もいるからです。

なお、手前のステージ(この例の場合は1面~3面)のバグについては、報告したプレイヤーだけには個別にメールなどで情報共有しても構わないでしょう(ただし、共有サーバーなどは、他の人も見るので、共有サーバー側では教えないでおく必要があるだろう)。


このような場合の対応策としてオススメなのは、「合計で何個の同種のバグがあるか」という情報を情報共有することです。

たとえば例の「暗黒大王」バグと「ゾンビ暗黒大王」バグの場合なら、合計でボス2体あるいは2ステージぶん、このバグがあるわけですから。

たとえば情報共通では

4面ボス戦でバグで○○が起きてしまうバグ、およびゲーム後半ステージでの似たようなアルゴリズムのボス敵の類似バグとで、少なくとも合計2件、このバグがありました。

みたいにプログラマー側とデバッガー側とで情報共有すれば、

これはデバッガー側にもネタバレにならずに済みます。

また、万が一、デバッガー側があとから5件や10件も同種のバグを見つけたら、「合計2件」を大幅に超えてることから、プログラマー側の確認モレをデバッガー側が発見したことも分かるようになるという、情報共有の仕方です。

プログラマー側の大幅な確認モレが分かれば、デバッガー側は再度、追加報告する必要があることも、分かるようになります。


優先度[編集]

この段階で、対応の優先度などのトリアージをします。

最初のバグ報告の時点ですでにとりあえずのトリアージがある場合、返事の際にトリアージの優先度を変更する場合もあるかもしれません。

修正[編集]

コードの修正は、プログラマーが実際にキーボードを使って手入力などで行います。こればかりは、自動化は出来ないのです。


修正確認[編集]

よくあるミスで、間違えて修正前バージョンをアップロードしてしまう、バージョン番号は修正版になっているのに中身が修正前のまま、などもミスもあります。

また、修正のコード自体に別のバグが新規に追加されてしまう(「エンバグ」という)場合などもあります。

デバッグ用の文字などの消し忘れ、デバッグモードのオフのし忘れ、などのミスもあります。


そのようなミスが無いかは、実際にバグ報告者や品質管理チームなどがゲームの「修正版」とされるバージョンをテストプレイをして、確認します。


このため、最初のバグ報告を終えても、データはなるべく消さずにセーブなどをして保管しておく必要があります。修正確認が終わるまで、バグ報告時点のプレイデータは残しておく必要があります。

バグが無かったという報告[編集]

ver0.01を最初にデバッグプレイする場合[編集]

ver0.01やver0.10のような、とても初期のバージョンをプレイする場合、

たとえバグが無い場合でも、ここには「バグが無かった」という報告をします。(ゲームにかぎらず、Linuxなど大手オープンソースソフトのテスト報告なども同様に、「〇〇にはバグが無い」という事を報告します。)

さて、ゲーム業界ではなくLinuxなどの業界でのテストの場合は、バグが無かった報告のための報告データシートなどの書式が決まっていたり、報告用にテスト操作ごとに入力チェック欄のある専用サイトなどがあったりします。


しかし、ゲームの開発初期バージョンにおける「通しプレイ」には、そんな気の聞いたシステムやサービスは、ありません。(ただし、「壁に体当たり」みたいな、どこのゲームでもチェックするようなデバッグ手法の場合には、個別チェック欄がある可能性もありうる。)

しかし、ゲーム全体の通しプレイでは、そんな個別チェック欄の存在は、まず期待できないでしょう。


なので、デバッガーは、通しプレイの報告スタイルを、自分で考える必要があるかもしれません。

『仕様書』といわれる設計図がデバッグ用のシートを兼ねる場合もありますが、しかし開発初期のほんとに初期バージョンすぎる場合、その『仕様書』そのものが不確定だったり未完成だったりします。

※ アルバイトなどで、デバッグ系テスターを事業としている会社のアルバイト要項などを見ると、あたかもデバッグテストは仕様書やチェックシートにもとづく行為だけかと錯覚しがちです。しかし、そういう外注企業に外注する前に、まず先に発注元のゲーム会社で大まかに通しプレイなどをしてデバッグをしていく必要があります。
発注元が仕様書そのものを策定するためにも、まず自社でのデバッグによる確認が必要なのです。
一方、のちの段階で、外注企業としてデバッグ依頼を有料で受ける場合なら、あらかじめ発注元で大まかに通しプレイをして、大まかなデバッグをしてあるハズなので、通しプレイよりも、(選択肢を全パターン確認したり、敗北時の反応を確認するなどの)局所的なチェックを優先する事が望ましい、と考えられます。(ただし、仕様の把握のために外注サイドでもテスターは一度は通しプレイをする必要があるので、程度問題です。)


ともかく、開発初期の時点のデバッガー・テスターは、プランナー(仕様の制定者。いわゆる作者)などとヤリトリをしていく仕事を通じて、そのゲームに適したバグ報告スタイルそのものを模索して確立していく必要が生じますので、ある程度はそのゲームを一般プレイヤーの目線でゲーム攻略的にプレイする必要があります。(ただし、短めの日数で攻略プレイを区切る。)


その後、デバッガーは開発のすごく初期の最初のバージョンでは、たといバグが無くても、「自分がプレイした範囲では、どこにバグが無いか」という事を報告する必要があります。


さて、ゲームの場合、単にけっして「どこのシーンでバグが無いか」だけを報告するのではないのです。(一般のITソフトとは、ここの仕方が違っているかもしれない。)


なぜならゲームは、そのシーンに到達する前に(重要イベントの選択肢などの選択結果によって)フラグ変数などの影響を受けているからです。


フラグの状況によっては、他のデバッガーや開発者が追試してもバグが発生しない場合もあります。

なので、「ここにはバグが無かった」という報告をする際には、加えて、そのシーンに至るまでに、途中でどんな感じのプレイをしていたかも加えて報告する必要があります。

たとえばRPGなら、フラグに影響を与えそうな重要イベントの選択肢などでは、自分がどの選択肢を選んだかなどを、加えて報告する必要があるのでしょう。

ただし、大まかに報告する必要があります。

なぜなら、ゲーム中のすべての選択を報告するのは、選択肢が膨大すぎるので、まず不可能だからです。(細かい報告をするのは、もう少し完成度の高くなった仕上げの段階からです。)


開発初期のほんと初期バージョンver0.01あたりでは、ゲーム全体に開発チームの労力を回す必要があるため、細かいデバッグは後回しにします。


さらに開発初期では、ゲーム中のどの要素が潜在しているバグに影響を与えやすいかが全く不明であり、重要イベントの選択肢 以外も潜在バグに影響を与える可能性すらありえるので、とりあえずバランス調整に必要になりそうなプレイ結果も、ついでに報告します。

たとえばRPGの新機能の公開直後なら、いくつかの重要イベントの時点でのレベルとか大まかな装備とか、どこのステージまで攻略したかとか、そういうのも初期テストでは報告します。

レベルが潜在バグに影響を与える可能性だって、開発初期では、ありえるのです。


ただし、この時点(ver0.01あたり)ではバランス調整はしません。なぜなら、ゲーム全体にチームの労力を回す必要があるからです。


なので、デバッガーは今後のバランス調整をみすえて、今後のバランス調整にも使えそうなプレイ結果のデータを、デバッグのテストプレイのついでに報告しとくだけです。


こういったテスト結果をもとに、数人のデバッガーが共通して、「こういうプレイをした結果、ここにはバグが無かった」という事が保証されたなら、

とりあえず、たとい もしそこにバグが潜んでいたとしても、そのバグの発生確率は(「バグが無かった」報告により、発生確率が)低い事が保証されるようになるので、開発チームは他の部分の開発に専念できます。


また、デバッガーどうしでも「〇〇にはバグ無し」情報の共有により、バグ発生確率の低いシーンの検証プレイを後回しにして、まだ未検証の部分の検証プレイに取り掛かることができるようになります。


大幅な更新の直後[編集]

ゲームのバージョン更新によって新機能が追加されたばかりの新バージョンには、バグが多く、いろいろな場所にバグが発生する場合があります。

なぜなら、その新機能が、ゲーム中のさまざまな要素に影響を与えるからです。(ゲームに限らず、ITソフトでなにか新機能が追加された場合、バグが多く発生しがちです。)

なので、大幅な機能の追加や、大幅なストーリーの追加などといった、大幅な更新があったら、たといバグが無くても、「ここにはバグ無し」系の報告の必要があります。


【デバッグ報告】「異常なし」です。
ソフト「□□□□」のver0.85で大幅にストーリー追加されたバージョンが公開されたので、このver○○で通しプレイおよび、下記の行動をしてみましたが、異常は見られませんでした。今のところ、正常です。

通しプレイ内容
重要アイテム『ヒスイの首飾り』を本イベントでマップ『隠し洞窟』の魔女から貰いました。
その後、アサシンギルドのボス『アサシンマスター』を倒したことにより、ダンジョン『アサシンギルド』を攻略しました。

通しプレイでのレベル : Lv40で突入、Lv53で本バージョン追加イベントのクリア 

確認した行為
・ △△△
・ ~~~

みたいな感じでしょうか。


他の利用者が別の利用方法をしてたらバグが見つかる場合もあるので、なので、「自分が何をしている限りは、とりあえず、このソフトにはバグが見つからない」という情報が「異常なし」報告に必要です。

こうすることで、もしバグが今後に他の場所で見つかった場合でも、ソフト作者が「異常なし」報告を受けた部分は後回しにできます。


バグが無かったという報告もときには必要[編集]

もし仕事でデバッグ依頼を受けている際、開発版ソフトウェアがバージョン更新されてデバッガーなどの協力者に限定公開された場合、デバッガーは検査のためにソフトをテスト使用するワケですが、テストの結果、バグが見つからない場合もあります。

もし仕事のデバッグ依頼を受けている場合、たといバグが見つからなかった場合でも、デバッガーからソフトウェア作者に連絡する必要があります。(ただし、仕事でないソフトの場合、いちいちソフト利用の際に報告の必要は無いし、むしろ作者の手間をかけてしまう。なぜなら、もし作者が利用者全員から報告を受けていたら、人気アプリ作者などは、多くの人から報告されてしまうので返事に手間が掛かってしまうので。)


仕事の場合、IT産業にかぎらず何かの検査では、もし検査の結果として異常が見つからなくても、「今回の何月何日の検査では、ver○○には異常が見つからなかったです」という報告が必要です。日付が必要です。翌日の検査でバグが見つかることも、よくあるので。

なので、最初から、報告レポートに、日付欄を作っておくのが良いでしょう。

またレポート文中でも、「昨日の報告では」とか書くのではなく、「昨日の5月10日の報告では」みたいに、後日に日付を見ても分かるように、報告書では文中の日付も書きましょう。


ともかく、「異常なし」報告をしないと、そもそも検査の依頼の連絡がテスト者に行き届いてないのかとか、確認のための手間が、製品の作者側に掛かるからです。

さて、ソフトの「異常なし」報告をする場合、「自分はどういった作業をそのソフトウェアで何時間くらい利用していた所、今のところ、ver○○にはバグが見つかりませんでした」というように報告をする必要があります。


たとえば、一例ですが、(※ 未記述)

仕様かバクか不明な場合[編集]

ゲーム演出のなかには、一見するとバグっぽい演出もあります。

なのでデバッガーが、ゲームのテストプレイをしているときに見つけた現象が、はたしてバグなのか、それとも意図的な演出なのか、悩むこともよくあります。


このような場合でも、とりあえずはデバッガーは念のためバグかもしれないと報告を挙げておくのが、ゲーム業界での通例だと言われています。

たとい結果的にバグではなく意図的な演出だとしても、プログラマー側にとって、ユーザー視点に近い人からの参考意見になります。

もしプログラマー側やクリエイター側は、このような仕様のつもりの部分にバグ報告を受けたら、きちんとデバッガーたちに、「この現象はバグではなく仕様です」ということを説明し、デバッガーたちとプログラマーとで情報共有する必要があります。

その他[編集]

レベル上げやノー・ミスは目的ではない[編集]

プレイするバージョンについては原則、なるべく最新バージョンをプレイします。

なぜなら、今後のプレイヤーがプレイするバージョンに、もっとも近いバージョンは、現時点での最新バージョンだからです。

なので、RPGやシミュレーションなどのデバッグをしている場合、もし最新バージョンが出たら、とりあえずセーブデータを最新版に移行可能なら、さっさと最新版に移行しましょう(念のため、古いほうのセーブデータもしばらくは残しておく)。


なお、レベル上げのバグの有無の確認については、デバッグ初期の段階で、デバッグモードなどでカンスト(カウンターストップ)チェックを行っているハズです。なので、通しプレイでは、レベル上限チェックの確認の優先順位は、低めでしょう。


とはいえ、一度は誰かが通しプレイでもレベル上げの通しプレイで最高レベル近くなどのレベルをチェックする必要がありますが、しかし時間が掛かりすぎるので、もし誰かが既に1度や2度はレベル上げのカンストのチェックしていれば、あとは他の人がレベル上げをチェックするのは不要でしょう。

このように、一応は通しプレイで誰かが最高レベルや最高スコアなどの上限を確認する必要があるので、なので自分のプレイでの最高レベルなどのセーブデータも一応は保管しておくべきでしょう。

ともかく、このようにデバッガーどうしで役割分担をしましょう(複数のデバッガーがいれば、の場合ですが)。


なお、最新バージョンにセーブデータを移行した際は、攻略の前に、まず『更新履歴』などの情報を読んで、そしてその更新したゲーム内環境の周囲に異常のないことを確認するデバッグ的に色々としてみるプレイをしましょう。

いちおうプログラマー側でも、更新箇所についてはデバッグモードなどで簡易的に確認をしているとは思いますので、この段階ではバグはあまり見つからないのが普通ですが(なので正常な動作が見れるのが普通ですが)、しかしデバッガーにとっても、まず正常な更新結果がどういう結果なのかを知る必要があるのです。


なので、まず正常な更新結果を実際にプレイでさっさと確認してから、そのあとで、通しプレイを始めたり、あるいは移行後のデータを攻略してゲームクリアしたりします。


その後にまだ次のバージョンが出てなければ、今度はニューゲームで最初から通しプレイをしましょう。


また、ノー・ミス(たとえばシューティングゲームなら敵のミサイルを一発も受けないで、全ての敵弾を避けるとか)でクリアするのが目的ではないです。

RPGなどでは、ついつい普通の感覚では、全滅したあとにアプリを保存しないでクローズ(いわゆるリセット)してしまいがちですが、しかし、なるべくデバッグの序盤では、通常のプレイ中にはリセットしないで、そのまま続けて保存してクリアを目指しましょう。なぜなら、デバッグ中にしだいにデバッガーもプレイに上達してしまうので、普通にプレイしてると全滅の回数はしだいに減っていくので、全滅時のデバッグが面倒になっていきます。

なので、ミス時や全滅時などにバグが起きないことも確認する必要があるので、プレイでミスしても、なるべくリセットしないようにしましょう。(ただし、わざと異常なプレイをしている場合には、保存せずにリセットする場合もあります。)

バグ報告したあとのデバッガ-[編集]

バグが見つかって、報告が終わったら、デバッガー・テスターは空き時間に、類似のバグが無いかを探します。

デバッガーの手元に、バグ再現時に近いデータがありますので(しばらくセーブデータなどを残す必要があります)、ソレを使い、

報告したバグ内容に近いけど微妙に変えた操作をいろいろとしてみて、バグが起きるか起きないかを調べます。


たとえば、もし報告したバグ内容が下記の例の場合、

【バグ報告】 ウッキークエスト ver0.87 。ハジメガルド武器屋オヤジの会話時のキャラチップ表示ズレ

   ・[バグの症状]   ゲーム中盤でのハジメガルド武器屋の親父の会話時のキャラチップ位置表示ズレです。 

   ・[発生の頻度]  当の武器屋オヤジに話しかけるたび、毎回バグ発生です。3回、確認しました。

   ・[添付ファイルの内容] メール添付画像は、バグ発生時のオヤジ画像チップが店の壁に乗ってしまってるナゾ画像です。
    
   ・[バグの発生方法]   ゲーム序盤の第1章から行ける街・ハジメガルドの武器屋の親父に、
      ゲーム中盤の第三章になってからハジメガルドに行き、
      自軍パーティ構成が戦士・戦士・僧侶の3人パーティの
      味方平均レベル28くらいの状態で武器屋親父に話しかけると、
      なぜか親父が話しかけるたびに、
      バグによって親父のキャラチップの表示位置が1マスぶん右にズレます。

    ・[参考情報]
      私の今回のテストプレイでは、まだ「伝説の剣」は入手していません。
     「伝説の盾」は、このバグ発生の時点で入手しています。
      伝説の盾を守っている中ボス・暗黒大王も撃破してあります。
      
     今回のプレイでは、装備はまだハガネ装備です。ミスリル装備は、していない状態です。
     ミスリル鉱山の街をすでに帝国軍から解放しましたが、プレイヤー所持金を節約するためハガネ装備のままです。
     ハガネ装備のままレベル28まで上げて暗黒大王を倒しています。

上述のような報告を先にしたら、デバッガーは報告後にテストプレイで、たとえば、

ハジメガルド街の武器屋ではなく、道具屋の主人に話しかけたらどうなるかとか、あるいは宿屋の主人に話しかけた場合はどうなるかとか、
あるいは自軍パーティ構成を変えたらどうなるかとか、
あるいは、周囲の他の街の武器屋や道具屋・宿屋の主人に話しかけたらどうなるかとか、

いろいろとテストプレイで試します。(このテストには時間が掛かるので、なので先に報告しておく必要がある。)

仕様の矛盾や不具合を見つけた時の報告[編集]

デバッガーは、場合によっては、バランス調整チームよりも先に、テストプレイをする場合もあります。

その場合、細かなバランス調整などはデバッガーはしないで、あとのバランス調整チームに任せます。さて、このようなデバッガー先行のテストプレイのとき、仕様(設計)そのものの問題点をデバッガーが見つける場合も、ときどきあります。


プレイヤーにとって「よかれ」と思って作られた設計が、実際にゲームに実装されてみたバージョンをプレイしたとき、その仕様のせいで他の問題点が発生していたりとか、そういう現象にデバッガーが遭遇する場合もあります。

なので、バグ報告のサーバなどは、仕様の改善案などの提出サーバなども兼ねます。


この場合、けっして単に「この仕様のここはオカシイ」とだけ報告を入れるのではなく、できれば大まかに改善案を提案し、つまり、どう直すとイイかを自分なりに考えて数パターンほどの改善案に提案すると、担当者に話が通じやすいです。

こう説明したほうが通じやすい理由は、具体例があったほうが分かりやすいから、です。提案する事自体はあまり目的ではなく、具体例で説明して分かりやすく伝える事が目的です。


なお、改善すべき仕様が、キャラクターの会話文などの表現の問題である場合、たとえば、「この性格のキャラクターが、こういう事を言うのはオカシイ」ような問題の場合なら、

改善案の提案はたとえば

「このシーンでなら、このキャラクターは、これこれこういう内容の発言をすべきです。なぜなら~~~」

みたいに、説明文で説明したほうが伝わりやすいです。


あまり、キャラクターの言い回しなどの具体的な表現は、デバッガー側では考えず、表現についてはシナリオライターなどの著作者に任せます。

その理由は、法律の著作権などの理由もあります。著作権法では、アイデアは著作権の対象には、ならないのです。(法学の専門用度で「アイデア/表現の二分論」と言います。)

社内の権利関係の管理をラクにさせるため、著作権者はなるべくシナリオライターに統一させます。


そのため、あえてデバッガーなどは、もし表現の不整合に気づいて改善案を出す場合でも、アイデア提案までに留まります。具体的な言いまわしなどはシナリオライターに任せます。

これは裏を返すと、ゲーム製作では、じつはメインのシナリオライター以外にも、プログラマーやグラフィッカーやデバッガーなどのスタッフも、テストプレイなどを通して、実は少々のシナリオ提案をしている、という事でもあります。(もちろんシナリオ作成の比率はシナリオライターのほうが高いですが)

会話文にかぎらず、ゲーム中の説明文の表示なども、実際にどう表示するかは、それぞれの担当者に任せます。

テストプレイ中に矛盾点に気づいた場合は、具体的な表現には踏み込まないようにして、しかしアイデアは具体的に「ここでコレを表示すべきです」みたいに具体的に提案する必要があります。


チェックシートを作成する場合[編集]

テストシートを作るなら[編集]

フリーゲームや小規模の同人ゲームでは不要かもしれませんが、大規模なゲームを作る場合は、テストにおいて、確認漏れの無いようチェックシートが普通は必要であり、そのような一覧表のことを「テストシート」または「テスト仕様書」などと言われます。

ここでいう「テストシート」または「テスト仕様書」とは、バグが無いかの検査するためのチェックリストの一覧表のことです。

なお、「デバッグシート」とは意味が違います。デバッグシートとは、バグが実際に発生した際、そのゲームに寄せられたバグの報告を一覧にまとめたものです。


ゲームの場合、テストシートに必要とされる項目はある程度は慣習的に決まっていて、

【前提条件】 下記の手順のための前提条件(イベントAをクリア済みとか、アイテムBを入手済みとか、)
【手順】 確認すべき手順の明記。手順が複数の段階に分かれる場合、「1番: 〇〇画面で□□のボタンを押す」「2番: △△画面で××キーを押す」のように、番号も明記しつつ、手順を確実に明記。
【期待される結果】 上記の手順の実行後に期待される、(もしバグが無い場合の)正常とされる場合の仕様の明記。
【実際の結果 手順の実行後に実際に起きた結果を、欄内にうまくまとめる。
【合格、NGの明記】 けっして文章で曖昧に長々と説明するのではなく、「合格」または「NG」などと明言する欄を設けるべきです。(「不合格」だと脱字の際に「合格」と混同の恐れあり)
【日付、確認日】 仕事の書類を作る際、後日の管理のために、確認日の日付が必要です。
【確認者】 その確認日に、確認した人物が誰なのかも明記します。順序が逆の場合もあります(先に確認者、あとに確認日の場合も)。

なお、ゲーム以外の一般のIT業界でも、テストシートの要件はおおむね上述のように「前提条件」・「手順」・「期待される結果」の3件を含んでいます。


また、数値などをチェックする際は、実際のゲーム中に表示された数値を【実際の結果】欄に書くと良いでしょう。(ゲームに限らず、製造業などの品質管理チェックシートでも同様です。)

なお、【備考欄】などが、最後の列に付く場合もよくあります。(IT業界に限らず、仕事での一覧表は、たいてい、備考欄がいちばん右にあります。)

エクセル(表計算ソフト)などで、上述のような事を、そのゲームの全ての分岐において、チェック項目として各行に記載して、シートにします。なので前提として、そのゲームの設計仕様書が出来上がっている事が望ましいです。

後日に追記したりするので、紙面ではなくパソコン上にシートを作成する必要があります。


デバッグシート(リスト)を作るなら[編集]

バグ報告とその対応をまとめた一覧表としてn「デバッグシート」を作成するなら、最低限、下記の3つが必要でしょう。(※ 個別のバグの詳細をまとめたものもデバッグシートという場合もありますが、しかしこの節でいう「デバッグシート」とは別物です。このシートでは、いくつものバグ報告の一覧表の事を「デバッグシート」という事にします。)


【報告時のバグの内容】
【修正後にあるべき目標の正常仕様の定義】
【現在の状態】 報告内容がバグのものなら「確認中」、「修正中」、「修正済み」などの対応を明記。また、要望(※ 後述)などに対しては、採用したのか現状維持なのか等も。他、「仕様確認」などがテスターから送られてくる場合も。

後日に追記したりするので、紙面ではなくパソコン上にシートを作成する必要があります。


この他、バグの詳細説明などを書く場合もありますが、しかし、スペースの都合などもあり、なかなか記載すべきか難しいです。

とりあえず、最低でも、上記の3点(「バグ内容」「正常仕様の定義」「現在の状態」)は必要かと思われます。


また、ゲーム制作の場合、バグ発見テスターから、操作方法の改善提案などの提案や要望などが入る場合があります。

デバッグシートが、この要望リストを兼務する場合もあります。


なので、「要望」なのか「バグ報告」なのかと言った、テストチームなどからの報告の【種類】も一覧に書く必要があるかもしれません。


本来、「バグ探し」と「バランス調整」または(操作システムなどの)「開発」とは別の業務なのですが、しかしテスターが実際に発売前の開発中ゲームの制作にテスターとして参加してみると、色々とバランスや操作性などの問題点にも気がつくものなのです。


テスターにどの程度の権限を与えるかは会社によって違うでしょうが、一応デバッグシート側では念のため、要望などにも対応できるように【種類】の項目を作っておくと良いでしょう。


この他、仕様書に無い実装、仕様書では不明瞭な実装について、確認の要請の報告がテスター等から送られてくる事もありますので、【種類】の項目に『仕様確認』なども入れられるようにしましょう・


その他、

【確認日】
【確認者】

なども必要かもしれません。

参考文献[編集]

  1. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、262ページ
  2. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、264ページ
  3. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、257ページ
  4. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、258ページ
  5. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、258ページ