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

ゲームのデバッグ編集

概要編集

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

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


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

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


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

いわゆる、「テストプレイヤーを広く募集してテストプレイ」という外部に体験版ゲームを公開してのテストをするには、とりあえず開発チーム内部で試しプレイとして「通しプレイ」(そのゲームをニューゲームからクリアまですること)を先にした後に、最低限1~2回の「通しプレイ」が終わってから外部へのベータ版の公開をすると良いでしょう。「通しプレイ」とは、ゲームをスタート画面の最初からエンディングの最後のクリアまで、そのゲームをプレイする事です。

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

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

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


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


内部テスト

公開βテストの前に、まずはチーム内部で軽く、一般プレイヤーと同じ目線で軽くプレイする事や(俗に「フリープレイ」と言います)、あるいはβ公開後でも開発チーム内部でも引き続きテストプレイを時々することを「内部テスト」などと言います。俗に「内部デバッグ」とも言いますが、「デバッグ」とは本来はプログラム修正のことなので、正確には「内部テスト」というべきでしょう。

よって順番としては、

とりあえずの体験版などの完成 → 内部テスト → バグ修正 → 公開βテスト → 体験版の修正 → リリース版にむけての作りこみ 

のような順番になります。


プログラマー用の自己デバッグ報告文について編集

まず、あなたがプログラマーだとして、自作ゲームのテストプレイで、バグを発見したとしましょう。

その修正方法がもし簡単に思いつけば、その通りに修正すればいいのです。


ですが、なかなか修正方法が思いつかなかったり、あるいは考え付いた修正方法が間違っていて上手くは修正されない場合などは、なかなか大変です。


こういう場合、どうやってバグの事態を打開するかというと、

自分で自分にバグ報告メールのような文章を書くことです。


例を示します。たとえばRPGの作成中、装備コマンドで、アイテム無限増殖のバグが起きたとしましょう。 その場合、なかなか上手く直せずに、てこずったとしましょう。

ならば、書きのように自分で自分にバグ報告メールを書くのです。(もっとも、投函の必要は無い。あくまで思考を整理するために書くだけであrつ。)

プログラマー自身による自己確認用のバグ報告文の例
【バグ概要】
アイテムの無限増殖バグ。
装備コマンド時に、アイテム無限増殖バグが発生する。


【バグ発生条件】
装備武器と選択武器が違う場合に発生。

装備中の武器が1行目にあり、
一方で選択中の武器はアイテム欄の2行目以下にある場合に発生する。

この条件で、決定キーを押すと、バグ発生する。


【起きる結果】
選択中の武器の個数 +1 したものが、
選択カーソルの一つ上の武器(テスト時には、決定ボタンの直前に装備していた武器)の個数としてセットされる。(これがバグ)


なお、選択中の武器の個数に関しては、正しく-1される。 


【期待される挙動】
一つ上の武器の個数(決定ボタンの直前に装備していた武器としてセットされるべきものは、
「選択中の武器の個数+1」ではなく、
一つ上の武器(決定ボタンの直前に装備していた武器と同じ武器の個数+1であるはず。

以上。

のように自分で書くのです。(再現性などはプログラマー自身で把握しているので、この場合(自分用の報告の場合)は書かなくていい。)

コツは、

選択カーソルの一つ上の武器(テスト時には、決定ボタンの直前に装備していた武器)の個数としてセットされる。(これがバグ)

における 「決定ボタンの直前に装備していた武器」という記載のように、文節「選択カーソルの一つ上の武器」というゲーム中で実際に起きた現象だけでなく、さらにその現象の意味することを別の言葉で説明することです。


プログラマーの書いたバグありのコードを見れば、上記メモの「起きる結果」の通りにコードが書いてあるから、バグが起きるのです

なので、「期待される挙動」に書かれている通りに、コードを直せばいいのです


つまり、「【起きる結果】」と「【期待される挙動】」の報告文の内容を、バグ修正時にはコードとして置き換えることになります。

よって、プログラマー自身による自分用のバグ報告メモでは、必ずこの2つの項目が必要です。


公募プレイヤーなどのバグ報告の片寄り編集

公開βテストなどで募集した一般プレイヤーは、ゲーム制作においては素人・初心者だったりしますので、デバッグの手法を知りません。

このため、公募プレイヤーのバグ報告パターンには、報告されるバグに、やや片寄りがあります。

よくある片寄りとして、

  1. プレイヤ-に有利なバグは報告しない。
  2. クリア不能にならないバグは見つけても報告しない。
  3. 開発者でないため正常な仕様を知らないので、仕様と不一致のバグに遭遇しても気づかない。

などの片寄りがあります。


たとえば、具体例として

  • 本来、BGMがボス戦(中ボス用)に変わるはずのシーンなのに、小ボス用のボス戦BGMのままのバグだけど、プレイヤーは正常仕様を知らないので気づかないので報告しない。
  • 誤字脱字を見つけても、プレイヤーにとってはクリアに支障ないので報告しないプレイヤーも多くあります。

のような事例が、時々よくあります。

仕様と違う挙動をするという類のバグは、ゲームの快適性を確実に下げますが、しかし、初見プレイヤーはそのバグが「これはバグである」という事自体に気づかないので、バグとして報告されないという、厄介な問題があります。

なので、テストプレイヤーの人数と、取り除けたバグの量は、必ずしも比例しません。

公募プレイヤーが報告する傾向のあるバグは、たいてい、クリア不能バグの類ばかりです。


なので、そのゲームの実際のバグの合計数については、公募プレイヤーの報告しなかった細かいバグが、公募プレイヤーからの報告数の何倍やヘタしたら十数倍もゲーム内に隠れていると思ったほうが良いでしょう。

なのでゲーム作者は、自分でも体験版などをときどきテストプレイする等の自己的なチェックが必要です。


さて、大きな更新などをした直後の場合などは、デバッグモード使用などでも良いので通しプレイをすると、バグがよく見つかります。

しかも、この手の大規模更新の影響を受けて発生したような細かいバグほど、初見プレイヤーには気づきづらい細かい箇所で発生するので、初見プレイヤーが遭遇しても報告されないという傾向があります。なのでゲーム作者は、通しプレイをとにかくデバッグモードを使ってでも何でもいいので定期的または大規模更新の直後などに行うことが必要です。

デバッグモード自体のバグによるチェックミスを防ぐため、ときどきデバッグモードを使わないでの通しプレイも行ってみると良いでしょう。また、もしそのゲームがデバッグモードを使わないとプレイ時間が莫大に掛かってしまい、ときどきの通しプレイすらもしたくなくなるゲームなら、そもそも大元のバランス調整が不適切な可能性があります。


守秘義務とか編集

デバッグに限らず、有料ソフトウェア制作に参加する人は、仕事で知りえた非公開情報を、けっして社外やチーム外には漏らしてはいけません。

仕事における、こういう企業秘密などを守る義務のことを「守秘義務」(しゅひぎむ)と言います。もしゲームテスターのアルバイトなどをする場合、守秘義務の契約書などを書かされるでしょう。当然、守秘義務の契約は守りましょう。

ゲーム業界やIT業界に限らず、一般の商社やメーカーや小売業や土建業などでも同様に、業務上の企業秘密は漏らしてはならないですし、それらの業種でも自社および取引先の企業秘密を守る義務があって、その義務のことを「守秘義務」と言います。

ともかく、「守秘義務」は社会人の常識です。

もし守秘義務に違反すると、たとえば損害賠償などを請求されたり、場合によって刑事罰を受けて逮捕される可能性もあります。


テスターの場合、「〇〇社でテスターのバイト経験があります」程度のことなら公表しても平気でしょう(就職活動にも公表の必要な情報なので)。ですが「〇〇社の△△のゲームをテストしました」(△)のような具体的な作品名のある情報は、(ゲーム会社からの)公開許可を貰わない限り、守秘義務により秘密にすべきでしょう。

まして、「あのゲーム、実は裏仕様では□□なんだぜ」(×)的な情報は、絶対に秘密すべきです(もし機密を漏洩したら、損害賠償などを確実に起こされるでしょう)。


テスターには多くの人数が必要なので、そのゲームのクレジット(エンディングなどで流れるスタッフ一覧)にはテスター名は載らない場合もあります。(クレジットに名前が載るテスターは、居たとしてもテストチームの代表者など一部でしょう。)


フリーゲームや同人ゲームなど

さて、フリーゲームや同人ゲームなどの場合はどうかというと、特に契約書などは書かないですが(作者も面倒ですので)、しかし社会常識的に、ゲームテストで知りえた裏仕様などの裏情報は、なるべく黙っておきましょう。特に有料同人ゲームの場合、有料である以上は、もし裏仕様やネタバレなどの漏洩をしたら損害賠償などに発展する可能性もあるでしょう。

フリーゲームでも常識的に、裏仕様などは、もしテスト中に知っても、(裏仕様を)秘密のままにしましょう。

なお、フリーゲームでもある程度の作品ならテスターは多人数に上るので、クレジットにはテスターは記載されないのが普通です。

テストプレイは開発段階によってテスト内容が異なる編集

解説編集

同人ゲーム程度の小規模な商業ゲームや、あるいは高品質なフリーゲームなどのテストプレイをする際、開発中の中盤くらいの段階でのテストプレイか、それとも発売直前・ダウンロード公開直前かの段階かで、必要とされるテストプレイのノウハウは、大きく異なります。

その理由は、まず外注アート素材などの出来上がってくるのが、けっこう後のほうだからです。

外注イラストや音楽などは作成に時間が掛かり、またもしイラストや音楽などのアート部品にミスがあった場合には修正の手間が大きくなるので、よってイラストなどは出来上がるのが、かなり開発の後半になります。

逆に、比較的に早い段階で出来上がるのは、テキスト部分です。


このため、開発の後半になるまで、画像などの納品待ちをしてい素材などのテストプレイは、初期段階のテストプレイでは不可能になります。

ラフ画や仮音楽などを初期段階テストプレイでゲームに組み込むという方法もありますが、しかし開発後期の本番むけテストの際にも、もう本番用のイラストや音楽などに置き換えてから一度テストプレイをしなおす必要があります。

こういった事情から、チェックシートなどを使ってでの、総当り的な本格的なテストプレイは、実は開発の後期になってからになる事が考えられます。(また、このため外注テストも、後半の段階からだろうと考えられる。)


開発の前期~中期では、あまり細かくテストプレイをしすぎる必要はありません。開発の前半では、これから仕様がコロコロと変わるので、開発前半で一時的にバグがゼロになっても、これからまた仕様変更により、開発前半で確認した場所にバグがまた発生する可能性も高いからです。

もちろん、開発前半でもサラっとテストプレイをしたほうが良いのですが、でもサラッとした感じで充分です。ここら辺の感覚はゲーム開発チームで無いと分からないでしょうから、外注はされない確率が高いと思われます。


さて、開発初期~中期でのテストプレイの場合、チェックシートなどは全く出来上がってないので(そもそも仕様書(設計仕様)が未確定の可能性もありうる)、なのでテスタトではメールなどを使っての文章でのバグ報告のヤリトリが多くなるので、あまりテストプレイヤーを増やすべきではないです。(初期段階からテストプレイヤーを増やしすぎると、メール対応が大変になります。)


開発前期のテストプレイ方法編集

開発後半のチェックシートなどを使ってのテストプレイは、外部サイトなどで元ゲーム業界の人達がチラホラとノウハウを公開してくださってますので、ソレを参考にしてテストプレイをすると良いでしょう。

ですが、開発前期のテストプレイ方法は、なかなか公開されてません。(一応、任天堂がゼルダなどを例に手法を公開している。)


開発前期の場合、そもそもチェックシートが無い場合が普通ですしょう。仕様自体が今後の仕様変更で変わる可能性もありますのでチェックシートを作るメリットも薄いです。このような事情もあり、あまり細かくチェックする必要も無いでしょう。

なので、基本的に、一般プレイヤー目線での「通しプレイ」による通常のプレイ方法を中心にしてのテストプレイをする事になります。


さて、同人ゲームやフリーゲームなどの場合、開発初期のテストプレイヤーの人数は、せいぜい4~5人など一ケタ人数になります。

この程度の一ケタ人数でのテストプレイの場合、バグ報告などのヤリトリは、メールで行う場合が普通でしょう。


こういった開発初期でのテストプレイでもしバグを見つけて、これからメールでバグ報告をする場合、バグのあった箇所を報告する際に、さらにどこまでゲームを進行させたかを追記的に数行ていどで報告すると良いでしょう。

たとえば、

第4章の〇〇のシーンで、下記のバグを発見しました。
【バグ内容】
※ 中略


【追記】
第6章までクリアしました。第5話の結婚イベントのヒロイン選択では、花嫁にはビビアンを選びました。ビビアンの見た目で選びました。なぜなら金髪ツインテールは正義だから。ビビアンかわいい。

みたいにです。

このようにクリアした範囲を報告する理由としては、報告を受ける側としては、プレイヤーがどこまでプレイしたか、分からないです。

たとえば、全10章のゲームで、第4章にバグが特に多く報告されている場合、はたしてプレイヤーが

第10章まで進んでクリアした上で、第4章のバグを多く報告しているのか?、

それとも、

第4章や第5章までの前半~中版のステージでプレイヤーが行き詰ってるのか?、

といった事が、バグ報告だけでは不明だからです。

もし、テストプレイヤーが第4章か第5章から先に進めない場合、作者はバランス調整やヒント追加などとともに、テストプレイについても作者側で、テストプレイヤー側が未検証が第6章以降をテストプレイする必要も生じます。

また、ゲーム中のフラグ管理に大きな影響を与えそうな重大な選択肢のあるイベントなどでは、どういった選択を選んだかも追記すると、作者側と情報共有しやすいでしょう。


たとえば上記の例のゲームの「第5章」の花嫁選択の場合、たまたまテストプレイヤーが3人いる花嫁候補のうち、ビビアンばかりを選んだりするかもしれません。

なぜなら開発初期~中期のテストプレイでは、開発後期でのテストプレイとは違うので、いちいちテストプレイヤーどうしでチェック作業を分担したりしません。というか、そもそもテストプレイヤーはお互いには連絡しません。これはゲーム作者や開発チーム管理者に情報を一元的に集中させる必要があるので、テスターどうしでの情報共有は自粛すると言う側面もあるからです。(伝言ゲームみたいな情報劣化を防ぐため、開発初期の小人数テストプレイでは作者と直接やりとりをするので。)

その結果、そのゲーム中に選択肢イベントのある場合、別々のテスターどうしでも重複して同じ選択肢をたまたま選ぶ場合もあります。


また、開発後半のデバッグでは、チェックリストなどを作って、「〇〇月○〇日の時点では、どこにバグが無かったか」というバグの無かった箇所も確認する必要があるのですが、しかし開発の初期で、いちいちそこまでのチェックシートを作るのは面倒ですし、開発初期は今後の仕様変更の可能性も高いのでチェックシートを初期からいきなり作っても無駄になる可能性があります。

そこで、他のバグ報告の際に、追記的に、ゲーム内でどこまで進行したかの情報も書くことにより、「どこにバグが少ないか?」という情報についてを、作者は間接的に知ることが出来るからです。


なお、バグ報告が無い場合に、いちいちプレイのたびに、「どこにバグが無かったか?」のメールを送ると、メールの量が増えたりして、読む側の作者も面倒だし、書く側のテスターも面倒です。

ただし、上記の方法は、あくまで開発初期~中期での、さらに少人数(せいぜい5人ていど)でのテストプレイの場合です。


商業ゲームのテストプレイは全くの別

プレステ作品や任天堂ゲーム機作品などの商業ゲーム作品などを作る場合は、もっと多くのテストプレイヤーが必要になりますし、「通しプレイ」だけでなくチェックリストなどを作ってのブルドーザ的な総当たりの点検も必要になってきます。

なお、商業ゲームの外注テストプレイの場合、いちいち開発メンバーにメールしません。なぜなら、普通は開発の後期に外注テストは開始され、この段階になるとテスターの人数が多いことなどや、すでにバグ報告用サーバーの投稿フォームなどが整っているので、そちらサーバー側の投稿フォームのほうに、会社などで定められた書式のとおりに投稿します。

商業ゲームのテストの場合なら、テストチームのリーダーなど現場リーダー的な人が、テスト全体の計画を考えて、部下である各テスタ-たちに指示を具体的に出しますので、テスターはその指示に従ってテストをする事になるでしょう。(テスターがいちいち、次にテストする内容を考えたりしないと思います(それを考えるのは現場リーダーの仕事だし、各テスターに考えさせると人によってテスト程度のバラツキが発生しかねないので、テスト品質を一定に保つためにあえて現場リーダーに管理を任せます)。)

部下テスターは指示されたとおりのテストが終わったら、それを現場リーダーに報告します。すると現場リーダーは、全体のテスト状況やゲーム仕様などをもとに、次のテスト内容を部下テスターに指示します。

どういった内容が次のテスト内容になるかは状況にもよりますが、よく指示で出されると言われるのは、まだテストが不足していたりして遅れている箇所の手伝いとか、そういった箇所のテストの指示が出される可能性が高いと思います。

(実は同人ゲームなどのβテストでも、テストをボランティアなどで手伝う場合、テストが遅れている箇所のテストなどを同人ゲーム作者からテスターが依頼される場合もありますが、ハナシがややこしくなるので、ここでは同人ゲームの話は省略する。)

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

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

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

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

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

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

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

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

総論編集

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

何が「バグ」か編集

ゲームにおける「バグ」は、クリア不能などは当然「バグ」です。

ですが、クリア可能であっても、仕様と違っていたらバグです。


仕様と違えば「バグ」編集

たとえば、武器「鉄の剣」を装備したとき、本来の仕様なら攻撃力が15アップなのに、攻撃力が12しかアップしなかったら、それはバグです。

なので、商業ゲームのテスターは、仕様書などを参考に、そういうパラメータもひとつひとつ、最終的に完成まではにはチェックする必要があります。


ボタン入力後の状態遷移バグ編集

典型的なバグとしては、連打などボタン操作による、状態遷移のミスによるバグがあります。

けっして連打そのものが目的ではなく、状態遷移ミスを見つけるのが目的ですので、目的を勘違いしないように。なので、連打中に十字キーを入力してみるとか、そういうふうに色々と確認します。

たとえば連打だけでなく、別々のボタンの同時押しなども、商業ゲームでは、よくあるバグ調査手法です。

たとえば

決定: Zボタン
キャンセル:Xボタン

などの仕様が決まっているなら、ZとXの同時押しなども確認します。

ゲームの説明書があれば、操作説明などが説明書に書いてありますが、説明書は鵜吞みにしないようにしましょう。

あるいは、画面が変わる途中(「画面遷移」)などに、何かのボタンを連打したり、色々と試してみましょう。

特に、ゲーム中で特殊なキー入力イベントがある場合、そのキー入力イベントなどでは、このようなボタン関連の状態遷移バグが多発しやすいので、要チェックでしょう。

RPGツクールなどの既製品のゲーム制作ツールでは、標準設定のUIでは、この手のバグは少ないです。しかしツクール作品などでも、作者の自作したUIなどだと、こういうバグも時々ありますので、テストプレイなどで確認してみましょう。

漢字ミスや誤字脱字編集

ゲーム制作において、誤字脱字もバグに分類します。

たとえば道具「ポーション」(potion)が「ボーション」(botion?)になってたりとか、そういうのもバグです。日本人のキーボード入力ならありえないミスですが、中国など人件費の安い海外にプロフラミングを発注していると、似た文字をよく間違えます。なので、文字が正しいかもチェックします。

「エアロ」(aero)が「工ア口」(こうあろ)とかになってたりとか、字体の似ている文字どうしは要注意です。


誤字どころか、原文自体がオカシイ場合もあります。

本来なら、たとえば「さあ、行くわよ!」と女性キャラのセリフを書くべきところを、

バグでは、助詞の使い方は外国人には難しいので「わ」と「よ」が入れ替わって「さあ、行くよわ!」みたいになっている場合もあります。

他にも「い行くわよ」みたいに、フリガナを勘違いして前後に出している場合もあります。こういうのも仕事では「バグ」として種類「誤字」などとして報告します。

「気づく」が「気ずく」になってるような、「づ」と「ず」の間違いも、海外系ではチラホラあります。「貴様の殺気に築かないとでも思ったか!」みたいな「きずく」だと変換に「気づく」が出てこないので、変換に出てきた「築く」を使った誤記とか。


なのでテスターの誤字修正のための学力の要件として、最低でも中学卒業レベルの国語力は必要です。もちろん、けっして偏差値30の底辺高校の合格なんて国語力では不十分です。偏差値55くらいのそこそこ賢そうな高校に国語教科だけなら合格点を取れそうな国語力ぐらいは、大人なら習得しときましょう。

こういう仕事は一見、出版業界でいう「校正」や「校閲」の仕事に一見は近そうですが、しかし本当は、どっちかと言うとゲームの誤字デバッグは翻訳家(外国語→日本語)のほうがイメージに近いです。ある程度、英語の勉強もしておきましょう。中学~高校初級の英語レベルは、見につけておくと便利でしょう。

世間的には「翻訳」で説明したほうが分かりやすいでしょうが、業界用語的にはゲームの「日本語ローカライズ」でしょう。たとえ日本企業のゲーム会社の作品でも、なんらかの大人の事情で、中国などに一部の工程を外注していたりする場合もあるので、テストプレイの際には日本語ローカライズみたいに文章チェックもして、誤字脱字やカタコトっぽい表現などを報告して修正させます。


なお、多くの業界で翻訳の仕事は通常、翻訳先の現地の国のその言語を母語にしている現地人が、最終的に自国語に翻訳します。

たとえば、日本語に翻訳するなら日本人が最終的に翻訳します。同様に、英語に翻訳するなら、アメリカ出身のアメリカ人が翻訳するのが普通です。

この慣習はIT業界だけでなく、裁判などでも同様で、たとえばアメリカで海外展開している日本企業の裁判は、アメリカ出身で英語を母国語としている弁護士が訴訟活動を行います。たとえ日本出身の日本人弁護士がどんなに英語に堪能でも、その日本弁護士はせいぜい、アメリカ弁護士に依頼をするまでしかせず、最終的にアメリカの法廷で法廷闘争するのは、日本企業や日本人弁護士から依頼を受けたアメリカ出身弁護士です。「国際弁護士」と言う肩書きの人は、それぞれの国の現地の弁護士に依頼するのが仕事です。けっして、国際弁護士本人が、各国の法廷で直接に訴訟や弁護を展開するわけではないのです。

よく、漫画やアニメとかだと、日本人の自称「国際弁護士」がなぜかアメリカの法廷で直接に訴訟してたりしますが(たとえば実際、1990年ごろにアニメ映画版『ルパン三世』の金曜ロードショーのやつで、ヒロインの峰不二子が弁護士に経歴詐称して、アメリカで荒稼ぎしていた)、アレはフィクションです(90年代当時、流行語で「キャリアウーマン」という用語が流行してたので、そのような女性にも不二子は変装できる能力もあるという演出にすぎない)。映像的なテンポを優先しただけの演出です。けっして真に受けてはイケマセン。


弁護士の国際活動の話はあくまで類似例としての一例でして、とにかく翻訳をするのは、現地の人です。


さて余談ですが、出版業界の校正・校閲でも、誤字脱字は修正の対象です。日本人の作者でも、タイプミスなどで、ときどき誤字脱字をしますので。「わがはいははネコである」みたいに、日本人だって「は」を2回続けるようなタイプミスもする場合だってあります。

ですが、「校正」と言った場合、老人っぽくて若者には分かりづらい表現を現代風に言い換えさせたりとか(時代遅れの表現とか)、差別用語(「メクラ」や「片手落ち」とか)や放送禁止用語(「魔女」とか)などが含まれているかを見つけて修正したりとか、そういうのも含みますので、誤字修正とはニュアンスが異なります。ちなみに校正や校閲も、(PCデータではなく)実際に印刷物として試し刷りした状態の印刷物(「ゲラ刷り」)で、確認をするようです。ドコの業界でも、製品に近い状態でチェックをする傾向があるようようですね。


何が「バグ」ではないか編集

・ゲームの難易度が、「やさしすぎる」または「難しすぎる」などの改善点は、「バグ」ではないです。
・ゲームのここが「つまらない」または「こう改善すれば、もっと面白くなる」などの改善点は、バグではないです。


「バグ」とは、明らかなミスだけが「バグ」です。具体的には、プログラムの誤動作や、漢字の誤字脱字、仕様書と実装が異なる場合など、客観的に「間違い」と誰でも判定できるのがバグです。


ゲームが「やさしい」とか「難しすぎる」とかは、個人の好き嫌いや趣味の問題なので、バグではないのです。(ただし、難易度調整のプログラム自体にミスがある場合などは例外。たとえば高難易度モードでは本来なら敵の攻撃力が1.5倍になるべき仕様のはずが、プログラム時のキーボード入力ミスで1.2倍になっていた場合とかは、バグである。)

難易度の調整は、テストやデバッグではなく、「バランス調整」という別の部署の担当業務です。


「バランス調整」と「デバッグ」との区別がついてない人は、門外漢や1980年代のファミコン黎明期ならともかく、2020年以降にゲーム業界に入ろうとする場合には、その程度の用語の知識もない人は確実に能力が低い、また、おそらく下記の理由で人格の性根も(表面的には取り繕っているかもしれないが、中身は)悪いので、待遇も低くすべきです。


その理由は、けっして単に「バランス調整」という専門用語の知識の有無の問題ではなく、そもそも「好き嫌い」と物事の「真偽」を区別できない人は、集団作業において迷惑だから、です。

世の中には、自身の「好き嫌い」と「真偽」または「 上手い/下手 」の区別がつかない幼稚な人がいるのです。

たとえば、嫌いな画風のイラストレーターの絵を、人体の構造とか背景パースとか正確に把握したデザインで書けていても、画風が嫌いだからという感情にもとづいて「あのイラストレーターは絵が下手だ」とか評論する、素人の子供のような人は、クリエイター系の仕事では邪魔です。

あるいは、実写ドラマで悪役を演じた俳優に対して「あの役者は演技が下手だ」とかいうような、好き嫌いと 上手い/下手 の区別がついていない子供のようなものです。(なお、実際のドラマなどでは、悪役はベテランや若手でも経験豊富な俳優が演じたりする場合も多い。悪役を演じるには、実は意外と演技力が必要なのである。)


そういう「好き嫌い」と「真偽」の区別を混同している知能水準の人は、そもそも、ゲーム制作の共同作業では邪魔です。


プレイヤーの集団の中にも、そういう「好き嫌い」と「真偽」の区別がついてない幼稚な精神年齢の人がいるので、ゲーム業界は対外的には「デバッグ」と「バランス調整」との区別を曖昧にしている場合もありますが、あくまで対外的です。

商売とは、けっして「教育」ではなく、バカな客はバカのままでいてくれたほうが、商売的にはボッタクリやすくて都合がいいので、バカな客の勘違いを放置しているだけです。

しかし、ゲームを作る側の人までが、バカな客と同レベルのままで「好き嫌い」と「真偽」を区別できないようでは、さすがに、ちとゲーム制作では困ります。


ゲームに限らず、娯楽系の仕事とは、バカな客に外面(そとヅラ)を合わせる必要があります。実際、テレビのバラエティ番組は、視聴者のレベルを中卒の学歴を想定して作成している、というのがテレビ業界の公然のノウハウです。しかし、実際にテレビ番組を制作しているのは、大卒などの学歴のスタッフです。テレビ業界の大卒スタッフは、単に商売の都合で、客の知能の低さにあわせて演技しているだけ、です。なお、俳優やお笑い芸人などの学歴も、表向きは「高卒」でも、実は表向きの学歴よりも少し高学歴だったり(ビートたけしが著書で暴露しています)、子役出身などだとマスコミ業界のコネなどで有名私立大学やその付属私立高校(偏差値は高い)などを特別枠で推薦入学していて実は卒業している場合もあります。(賢い人が少しだけ実力よりもバカなフリをするのは比較的に簡単だが、バカな人に賢い演技を続けさせるのは、なかなか難しいのである。なので、表向きの学歴よりも芸人は高学歴な場合も多い。)


なお、政治家の田中角栄も、よく「小卒」を名乗っていましたが、実際は専門学校卒であり、工業系の専門学校卒業(中央工学校)です。(中央大学とは異なる。) 昭和の当時の工業系の専門学校は、工業高校で習う程度の強度計算などの公式を計算できる程度の学力がなければ卒業できないと思われます。

ギャンブルの格言で、次のような格言があります。

「賭場で周囲を見渡して、周囲にカモが見つからないとき、カモは貴方だ」

と。

漫画などでも、不良漫画などをよく連載している少年マガジンも少年チャンピオンなどでも、ああいった出版社の編集員の学歴は、難関大学の文系学部卒などの高学歴です。

優先順位づけ編集

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

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

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

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

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


デグレやエンバグなどを防ぐには

ゲームの場合、バグが軽微な場合で、そのバグの発見された開発の後半の場合なら、軽微バグをあえて修正しないでおく、という場合もあります。この理由は、他の重大なバグに余力を割く目的の他にも、よく言われる理由として、余裕の無い短時間にプログラムをいじってしまって更に大きな別のバグが発生する事などを防ぐ、などの目的が考えられます。

「バグを直そうとしてプログラムをいじったら、修正したつもりのコードの内容が間違っていて、別のバグを埋め込んでしまった」的なミスのことを、ニュアンスは不正確ですがIT用語では「デグレ」degrade とか「エンバグ」enbug などと言います。


3D-CGで壁CGにキャラCGが、めり込む場合

また、これとは別に、3D-CGのあるゲームなどで、人類のCG技術的な限界により、わずかにだけ人物キャラクターが壁などに数センチ程(たとえば指の長さ程度)だけ、めり込んだりとか、そういうのは「バグ」ではなく「仕様」とするのが一般的だと言われます。技術的な限界により、少々の画像めり込みは、仕方ないのです。

もっとも、(通行設定ミスなどで)壁貫通を出来たりして向こう側にキャラが行けてしまってゲームのストーリーが変わってしまうとか、そういうのは「バグ」扱いですが。

テスト用語で、ゲーム中の壁のバグなどの「通行設定ミス」という言葉がありますが、裏を返せば、壁については通行設定さえミスしてなければ、少しくらい壁にキャラが めり込んだりしてしていても、構わないわけです。

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

敵の強さなどの設定のバランス調整も、デバッグのためのテストプレイも、一見すると似ていて、ゲームを延々とプレイしたり、問題点を発見したら場合によってはレポートを書いたりして開発チームとコミュニケーションする場合もあるので、似ているかもしれません。


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


バランス調整のためのテストプレイヤーには、なるべく、そのゲームに詳しくない人のほうが最適です。(英語では「ティッシュ テスター」とか、「フレッシュミート」と言います。ティッシュとはもちろん、鼻をかむチリ紙のティッシュの事です。フレッシュミートとは「新鮮な肉」の意味です。)

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

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


一方、デバッグに参加している人のことを、たぶん和製英語で「デバッガー」といいます。

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

※ バグの報告をする人を「テスター」という場合もありますが、本wikiではバランス調整用のテストプレイヤーとの区別のため、「デバッガー」と呼ぶことにします。また、バグ報告を受けてプログラムを修正する人だけを限定して「デバッガー」という場合もありますが、本書ではやはりバランス調整との区別のため、バグ報告マンも、バグ修正プログラムのプログラマーも、まとめて「デバッガー」と呼ぶことにします。
英語では、デバッガ debugger とは、ソフトウェアの一種で、デバッグのためにログなどをとるソフトのことです。タイプライターが人間ではなく機械なのと同様、英語の debugger は人ではなくソフトウェアです。


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


また、似たようなプログラムを使っている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の序盤から再開させるワケにはいかない)。このデータ引継ぎの工夫は、ソフトウェア販売サービス提供の企業では無理なので。


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

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

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

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

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

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

もうひとつのバグ発見の方法として、「printf デバッグ」と俗に(ぞく)言われる手法があります。

これは単純で、printfなどの文字表示をするためのプログラム文で、バグに関連しそうなパラメータを画面中に表示して、異常がないかを監視する方法です。

ただし Windows のVisual C++ デスクトップアプリの場合、コンソール用の printf では文字表示できないので、 TextOut 文で表示する事になります。(※ Windows API プログラミングについては wikibooks『Windows API/文字表示の命令』などを参照せよ。) Visual C#でも命令文は異なりますが、同様に printf ではなく別の命令文ですので、それぞれのプログラム言語にあわせた文字表示命令の関数をつかうことになります。


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

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

一般にゲーム開発では、作者用のソースファイルと、プレイヤー用のファイルを分けるので、作者用のソースファイルにデバッグ用の機能をいくつか入れておく方法もあります。


まずテストプレイしよう

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


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

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

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


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

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


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

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

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

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

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

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

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


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

典型的なバグ編集

配列のバグ編集

ゲームを作る場合、典型的かつ重大なバグは、配列に関するバグです。どのゲームでも、配列を使います。

極端な事を言うと、配列以外の変数名などの不一致のバグなどは、Visual C++ で作っている場合なら、変数名のバグはそもそもコンパイルできない場合が多いので、コンパイラが自動的に変数名のバグを発見してくれます。

必然的に、残されたバグは、配列のバグと、あとはゲームの仕様に一致してないという類のバグです。

仕様に一致しているかどうかは、コンパイラでは発見できないので、プログラマーやテスターなどが自力でテストプレイによって発見する必要があります。


配列のバグでよくあるバグは、下記のようなプログラムミスが多いでしょう。

典型例編集

宣言数よりも番号が多いバグ

配列で、たとえば hairetu[10] の10個までしか宣言してないのに hairetu[13] を呼び出すなどのように宣言した数以上に呼び出したり、よくあるバグです。


数え間違え

また、配列の番号は0番から数え始めるので、 hairetu[0] から hairetu[4] までの5つしか値を用意してないのに hairetu[5] を呼び出してフリーズしたりなど、よくやるミスです。


バグの発見後の原因調査の方法編集

バグそのものの有無は、テストプレイによって発見できます。

ですが、そのバグを引きおこしている原因の探査は、テストプレイだけでは不可能です。

こういったミスを発見する方法も、上述のように、printfデバッグ的にモニタープログラムを書くことでパラメータの動向を追う事で、バグのありかを限定していきます。

(正常な値の数値がprintfデバッグの画面に表示されている場所にはバグがないので、つまり、まだ確認されてない残りの場所にバグが潜んでいます。)

そして、上記printfデバッグのような方法でテストプレイ中にモニタリングしつつ、バグ発生箇所の周囲でテストプレイを色々なパターンで試していくことにより、バグの発生原因などを絞り込んでいきます。

なお、通しプレイは、このプログラミング段階でのデバッグでは(通しプレイは)不要です。この場合、すでにバグの発生箇所は限定されて分かっいるので、上述のように局所的なチェックによるテストプレイをしていきます。


そして、バグ原因を突き止められてコードが修正し終わったら、コードの修正後に再度、局所的なテストプレイで何種類かの行動パターンでチェックします。ここでは、テストプレイは不要です。(通しプレイは後でまとめて行う。)

一つのゲーム開発につき、バグ発生箇所は何十個や何百個も存在しており個数が多いので、通しプレイは 後で まとめて 行いますので、この段階ではまだ通しプレイは行いません。

デバッグルームなど編集

デバッグルームとは編集

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

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


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


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

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


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

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

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

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

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

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


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


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

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

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


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

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


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

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

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

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


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

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

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

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


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


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

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

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

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


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


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

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

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

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

総論編集

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

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

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

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


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

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

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

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


異業種との関連編集

ゲームに限ったことではないのですが、上記のように部品ごとにチェックと、全体の組み合わせたあとのチェックとの組み合わせは、製造業などの製品開発でもよく行われます。

少なくとも、自動車業界はそうです。

個々の材料部品などは、実際に引張り試験や荷重試験などを実際に物理実験を行い、部品の耐久値が規定や要求仕様を満たしているかを、事前に確認します。そして自動車の走行試験や衝突試験などは、実際に部品を組み立てて製品の状態である自動車にしてから走らせて見るしか、方法はありません。

チェックにおいて、シミュレーションなどは無駄です。なぜなら、もしそのシミューレション手法自体にバグや不具合が潜んでいたら、元も子もありません。

「チェックの最終確認においてシミュレーションが無駄」といのは、これは自動車業界だけでなく、航空宇宙などでも同様です。日本のJAXAは「はやぶさ」の部品モジュールの開発において、実際に部品を組み立てたうえでの(シミュレーションではなく)物理実験をしています(※ 講談社ブルーバックス『小惑星探査機「はやぶさ」の超技術』で確認できます。)。また、産業技術総合研究所での測定の国家標準器開発などでも同様の手法であり、実際に測定器を製品として組み立てた上での物理実験をしています(テレビ番組では、TBS科学番組『夢の扉』でメタンハイドレート採掘の産総研の研究者が、そうシミュレーションの問題点を指摘しました)。


ソフトウェアの開発では原理的に物理実験は無理ですが、それでも不具合対策の確認は、最終的には、実際にそのソフトをユーザー視点で使用してみる「実践」/「試用」しかありません。

ソフトウェア業界だと、個々の部品ごとにチェックすることを「単体テスト」といいます。一方、全体的に組みたててみてチェックすることを「ビッグバンテスト」と言います。

ソフトウェア業界では あまり体系化されてませんが、上述の自動車業界や航空宇宙などのチェック方法を参考にした結果、必然的にソフトウェア動作チェックでも「単体テスト」と「ビッグバンテスト」をなるべく交互に行うことが必要だという結論が導かれます。


重要なのは、ゲーム開発のデバッグにおいても、実際に「通しプレイ」というビッグバンテストが必要だという事です。「ビッグバンテスト」という名称の知識は、割とどうでもいいです(知識の無いよりかは、あるに越した事はありませんが・・・)。


本書は製造業ではなくゲーム開発の教科書なので、これ以上の製造業でのチェック方法への深入りを避けます。

なお、アニメ業界でも、1990年代くらいまでは、アニメ業界での分業による生産システムを説明するのに、自動車産業などでの分業になぞらえてアニメの分業を説明したりする説明手法がよく行われていました。


デバッグではないですが、バランス調整や各種の演出・シナリオなどの面白さの確認でも、実際に通しプレイで確認する必要があります。商業ゲームでも、任天堂が『ゼルダの伝説 時のオカリナ』では、社員300人で通しプレイで最初から最後まで実際にプレイして確認したという手法でチェックしているというノウハウを公開しています[3]


ネットのバイト紹介記事などだと、こういう社員での通しプレイによるチェックなどは紹介されませんが、順序的には、チェックシートによる細かいチェックよりも、まず通しプレイチェックのほうが先です。

任天堂の場合も、デバッグを開発初期と終盤とで別々の方法に分けて、開発序盤からデバッグしています。(岩泉茂『【CEDEC2017】「ゼルダの伝説」作成を裏から支えたエンジニアたち 大規模プロジェクトをいかに効率的に乗り切るか』 、2017年9月4日 07:00。) 開発初期のデバッグでは、ゲームの面白さに関わる部分のデバッグを優先的に修正していきます。開発終盤では、製品化やリリースなどにむけて、今まで後回しにしていた細かいバグも修正していきます・

大規模なゲーム開発になると、開発初期からデバッグしないと、発売日・リリース予定日・公開日までに間に合いません。

しかし開発初期ではまだ全体像が出来ていないので、ゲームの土台の面白さが確認できたあとには、先にゲームの全体像を(細部はいいので)作らせることを優先します。これは任天堂だけでなく、女神転生シリーズのアトラスも類似の開発手法をとっています。アトラス社では「ゲーム全体に血を回さなければならない」という格言があります[4]

このように、実際にゲーム全体をゲーム序盤からエンディングまで一通り作ってみないと分からないので、まずは先にエンディングまで作ります。そのあと、細かい作りこみやデバッグなどの細部を仕上げていきます。

まとめると、順序としては、

ゲームの土台の面白さ確認(2Dなど単純なものでよい)
→ ゲーム全体を作る
→ ゲームのエンディングまでのとりあえずの完成後、細部の作りこみ

のように、段階が分かれていきます。

なので、それぞれの段階に適して調整方法なりデバッグ等の方法を変えていきます。


また、社内デバッグでは、テスター専門のヒト以外にも、各種のアーティストやプログラマーなどもテストプレイに参加しましが、彼らは本業のアート素材制作(ゲームに組み込みためのイラスト素材、音楽素材などの制作)で忙しいので、バグ報告後の次バージョンでの修正チェック確認などはテスターが受け持ちます(任天堂がそうしています)。

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

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

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

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


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

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


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

通行止めの確認

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

なお、この、本来なら行き止まりであるべきの壁が通れるバグのことを通称「壁抜けバグ」と言います。壁以外の海とかガケとかの行き止まりも含めて一般的な言い方をすると、「通行判定バグ」または「通行設定バグ」などと言います。

なお、「進行不能バグ」は、これとは意味が異なります。「進行不能バグ」とは、ゲームのストーリを進められなくバグのことです。


デバッグ(テストプレイ)でツライ事の一つは、この「通行設定バグ」の有無のチェック、つまり行き止まりチェックでしょう。

もし、スーファミ風のドラクエ・ファイファン的なゲームのようにマップがマス目で作られている2D-RPGの場合、デバッグ仕事でなら、すべての壁マスの通行設定を確認する事になります。

アクションゲームやアクションRPGの場合、すべての壁を1ドットずつ通行設定をチェックするのは、不可能です。なのでアクションゲームなどの場合、

とりあえず壁にぶつかって突進ボタンを押しつつ、横移動ボタンも押して移動するなどして、確認したりとか、
横移動ボタンを一瞬入力して少しだけ横移動した後にカベに突進、その後、また横移動ボタンを一瞬入力して横移動した後にカベに突進を繰り返す、・・・を繰り返してカベの右端から左端までチェックするのを、さらに何周も繰り返すとか、

でしょうか。(ということは、アクションRPGゲームまたはそれ風のマップ移動システム搭載のRPGでの壁通行設定チェックは、とてもハードな業務だという事になります。一方、アクションRPGでも、もし移動の単位が1ドットではなくマス単位だったら、頑張って1マスずつカベ通行設定をチェックするべきなのでしょう。)


ゲーム中で特に重要そうな壁のテストの場合、おそらく上記テストに加えてさらに、たとえば壁に向かって突進するのを何十回も、毎回微妙に突進先の位置を変えつつ突進するとか、あるいはナナメ移動とかジャンプしながら壁に突進するとか、色々と試すのかもしれません。

当然、とても面倒です。

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


選択肢の総確認

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

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

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


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

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

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


全滅テスト、自殺テスト

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

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


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


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


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

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

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

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


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


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

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

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

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


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


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


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


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

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


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

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


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


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


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


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

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

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


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

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

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


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

次に、通しプレイ編集

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

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

概要編集
デバッグモードは原則的に封印

「通しプレイ」では、デバッグモードは原則的に使わないほうが安全です。通しプレイは、プレイヤーとなるべくプログラムで実機的に確認する事に意義があるので、できるだけプレイ条件を一般プレイヤーに合わせる必要があります。

RPGなら、よくある確認ミスで、たとえデバッグモード自体にはイベントなどのフラグに直接の影響を与える機能が無くても、本来なら入場不可能なゲーム内の場所にプレイヤーが入場してしまうと、その影響でフラグが変わってしまう場合もあるという、間接的にフラグに影響を与えてしまう確認ミスもあるので、なので通しプレイではなるべくデバッグモードは避けるべきです。

どうしてもデバッグモードを使う場合はファイルを分ける

どうしても通しプレイでもデバッグモードを使わざるを得ないゲーム内現象をテストのために確認したい場合は、通しプレイのゲームファイルをデバッグモード使用バージョンと非使用バージョンとに分けましょう。セーブデータ分けだけではなく、ゲームファイルごと別々に分けるのが安全です。 s しかし、そこまでしてファイル分けをしても、よくあるミスで、ファイルが本来「デバッグモード使用バージョン」なのに、間違えて「デバッグモード非使用バージョン」として保管してしまうミスもあります。

後述ですが、ゲームファイルやセーブデータをプログラマーからの確認待ちなどのため、複製してファイル数が何十倍にも増えますので、ファイルが多すぎるので、よくあるミスで、デバッグモードの使用バージョンと非使用バージョンとのファイルがときどき混入してしまいます。

なので、原則的に通しプレイではデバッグモードは封印する、などの自己規律的な方針をもっておくほうが安全です。


また、デバッグモードを使わないとレベル上げなどに時間の掛かりすぎるゲームの場合、そもそも、そのゲームのゲームバランスやレベルデザインなどが調整不足で崩れている可能性があります。(ただし、バランス調整チームとテストプレイチームとは別々のチームであるのが一般的ですが。)

そういった意味合いを含めて、とにかく通しプレイではなるべくデバッグモードを封印しましょう。


保管中のゲームファイルが10~20倍に増える

また、通しプレイでは、バグ報告後のプログラマーからの返事待ちとかのゲームファイルも保管するので、1つの作品あたりゲームファイルを20個~30個くらい最終的に複製したりするので、パソコンに保管するゲームファイルの数がかなり多くなります。たとえば作品1個は500メガバイト(0.5ギガバイト)のサイズでも、保管中のゲームファイルのサイズが合計で10ギガバイト超えとかになる場合も多々あります。

フリーゲームや同人ゲームなどゲームファイルのサイズが比較的に小さい(高々1ギガ程度)なら、データの控えのための複製の際は、ゲームファイルごとセーブデータとセットで複製してしまうほうが安全です。もっとも、さすがに20ギガ以上もあるような商業ゲームの大作ではファイル複製は非効率でしょうが、しかし高々1ギガ程度の作品ならゲームファイルごと複製して通しプレイしたほうが安全です。

その他

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


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

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

手順編集
1回目の通しプレイ

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

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

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

なお、特に仕事的な規律も無く、気の向くままにプレイすることを「フリープレイ」と言います。つまり通しプレイの最初の1回目は、フリープレイ的なプレイでよいでしょう。


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

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

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


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


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

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


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

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

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


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


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

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


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

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

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


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


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

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

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

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

全体の流れ編集

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

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

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

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

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

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


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


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

まず、

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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


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


なお、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など大手オープンソースソフトのテスト報告なども同様に、「〇〇にはバグが無い」という事を報告します。)

このように現状ではバグの無い、またはバグのきわめて起きづらい部分を見つけ出すことにより、裏を返すと、バグの無いことがまだ確認されていない箇所にバグが潜んでいる確率が高いわけですので、そうやってバグの居場所を突き止めていきます。

実際に商業ゲームでも、たとえば1980~1990年代のセガ(企業名)のアーケードゲーム(ゲームセンターの筐体機用のゲームという意味)では、このような方法で、バグのありかを突き止める方法が行われたらしいです[8]

例えるなら、プログラムの中に犯人がいて、まだ捜査をしてない場所に犯人が潜んでいる可能性が高いわけです。(参考元のセガ開発者のインタビューで、そういうふうに警察捜査に例えている。)


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


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

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


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

『仕様書』といわれる設計図がデバッグ用のシートを兼ねる場合もありますが、しかし開発初期のほんとに初期バージョンすぎる場合、その『仕様書』そのものが不確定だったり未完成だったりします。このような事情により、IT用語でいう「探索的テスト」という方法で、ゲームの社内デバッガー/テスターはバグ報告せざるを得ない場合も多いかもしれません。ゲームテストの場合、そのゲームの実装にもとづく独自のいろいろな内部プログラムのアルゴリズム/パターンがあるので、そういうのを(開発初期に加わっている)社内デバッガーは察知して、仕様書に無いこと/そもそも仕様書が無い場合もあること、などを意識して探索的テストをする事になる場合も多々あります。

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


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


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


さて、ゲームの場合、単にけっして「どこのシーンでバグが無いか」だけを報告するのではないのです。(一般の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まで上げて暗黒大王を倒しています。

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

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

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

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

概要編集

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

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


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

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


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

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


シナリオなどのデバッグ編集

シナリオ系バグの種類編集

まず、一口に「シナリオ系のバグ」と言っても、下記のように大まかには幾つかの種類があります。

  • 大元の脚本自体に矛盾があり、ストーリーなどが前半と後半で矛盾しているような場合、
  • 脚本のストーリーには問題なさそうだが、ゲーム作成時のフラグ分岐などの対応用シナリオの作成漏れや内容ミス、

などです。

実際には、上の2種類のバグが融合したような、シナリオバグもあります。もしかしたら、だいたいソレかもしれません。


ともかくゲームの場合、一般の小説やマンガとは違い、プレイの結果によるフラグ分岐によってストーリーが変化するという性質があります。

このため、上記のように、フラグ分岐の数が増えたら、ゲーム内イベントなどの小ストーリーも追加して新たに作成して加える必要があります。


一つのゲーム内には、イベントがいくつもあるので、ときどき、イベント用の小シナリオ作成時にミスとして、そもそものフラグ分岐に対応し忘れたために、そもそもの分岐先シナリオが欠けてしまうバグの場合があります(もちろん、デバッグで直す必要がある。つまりデバッグとして、忘れていた分岐シナリオを作成してゲームに実装する必要がある)。

あるいは、分岐先の対応シナリオそのものは存在しているが、しかし実際のフラグ内容と、分岐シナリオのメッセージ内容がミスって不整合になっている、などのような事例です。

脚本自体のバグの場合編集

仮に、改善すべきシナリオバグの種類が、脚本自体のバグだとしましょう。もし、キャラクターの会話文などの表現の問題である場合、たとえば、「この性格のキャラクターが、こういう事を言うのはオカシイ」ような問題の場合なら、

改善案の提案では、具体的なセリフは書かないでおくほうが、著作権などの理由で安全な場合もあります。

たとえば、

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

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


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

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

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


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

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

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


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


このようにシナリオのデバッグをする際の注意点・留意点として、なるべくシナリオ変更のアイデアの決定権は、シナリオライターに任せます。つまり、けっして多数決には、しないほうが安全です。理由は幾つかありますが、理由のひとつとして、追加シナリオや次回作シナリオなどの今後のシナリオ作成時にも対応する必要があるから、です。

単に現時点で存在しているシナリオ案だけの一時的・一部の矛盾を直すだけなら、単なる(非シナリオライターの)テスター・デバッガーでも出来てしまいますが、しかし変更したシナリオをもとに今後のシナリオを考える事をするのはシナリオライターでないと困難です。

このため、シナリオ変更案の採用の有無の権限は、シナリオライターおよび開発リーダーなどに(採用の権限を)委ねましょう。また、けっしてシナリオライターを飛び越して開発リーダーに直訴・越訴するような事は断じて、やめましょう。

このような直訴・越訴のようなトラブルを防ぐ方法として、たとえば、最初から社内公開のサーバーで仕様変更案を受け付けるとかのように社内公開の場でのみシナリオ変更案を受け付けるなど、そういった工夫などをすると良いかもしれません。


さて、シナリオ改善案の採用の権限は、シナリオライターと開発チームリーダだけが握るのでした。

つまり、けっして小中学校の学級会のような、多数決で何でも決まるような決定方法は、行わないほうが良いでしょう。というかそもそも企業社会は基本的に、学級会のようなシステムは取っていません(たとえば株式会社における株式総会ですら、決して多数決ではありません(株数に応じて票数が割り当てられるので))。

ときどき、高校や大学を卒業したばかりの人は、ここら辺の社会常識を勘違いしている人がいます。自分がそういう勘違い人間にならないように、気をつけましょう。学級会や、現実の政治選挙のような決定システムは、社会全体で見れば、割合と特殊で異例な決定システムです。


なお、開発チーム内に複数人のシナリオライターがいるサークル内での場合については、その場合でも上記の開発例と同様に、なるべく、メインのシナリオライターと開発リーダーにだけシナリオ変更の採用の権限を委ねるのが、トラブルを防げて安全だと思います。(ただし、劇中劇などのように、特殊性の高い部分シナリオの場合、その劇中劇だけサブ・シナリオライターなどにも決定権を与えるのも、アリかもしれません。)


たとえば、ゲームに限らずアニメ業界などでも一昔前では、アニメ監督をしている人が、自身の監督している作品が終わった後の時代には、他のアニメ監督の下で下働きをしているような場合もありました(最近はどうか知りませんが)。

マンガ界などでも一昔前では、月刊マイナー漫画誌などで連載終了して手の空いて収入も無くなった漫画家が、別の連載作家(たいてい、終了した側の漫画家が元アシスタントをしていた作家)の連載中マンガ制作を手伝うような事も、ときどきありました。


「船頭多くして、船、山に登る」という戒め(いましめ)のコトワザがあります。

ゲーム開発でも、決して船が山に登らないようにするため、メインのシナリオライター・開発リーダーなどにシナリオ採用の権限を一元化するのが安全でしょう。


そうそう、漫画家は、会社員ではありませんので、連載やアシスタント仕事などの無い期間は、給料はゼロ円です。印税などで稼ぐしかありません。また、単行本の売り上げが少なすぎる場合、単行本化を打ち切られますので、印税の収入源も途絶えます。

世間でよくある勘違いで、「作家を、いったんプロになれば、(公務員のように)定年まで身分(および収入)が保証される」というような勘違いをしている人が多々います。しかし、全く現実に即していない勘違いですので、考えを改めましょう。漫画家の 小林よしのり も、彼は少年ジャンプでのデビュー前まで、てっきり漫画家は定年まで収入が保証されるものだと勘違いしていたと著作『ゴーマニズム宣言』で述べています。


マンガに限らずアニメでも同様です。


これはつまり、元・連載漫画家が、自身の連載終了後に他作家のアシスタントとして生計を立てている場合、当然ですが収入額はアシスタント時代にまでダウンしています。

アニメ監督が、別のアニメ監督の人の下で下働きをしている場合もおそらく同様に、給料は下働きか、せいぜい中間管理職くらいの収入額までダウンしている、という事です。


なのでゲーム会社員でも、他のシナリオライターの下でシナリオのデバッグをしている場合、当然ですが収入は(もしあるとしても)、テスター程度のものだろうという事を覚悟しなければなりないでしょう。もっとも、そもそもフリーゲーム開発の場合なら、収入自体がゼロですが。


どんな矛盾がシナリオ脚本のバグか?編集

ゲームに限らずマンガやアニメも含めた娯楽フィクションのシナリオの場合、現実とは違って、意図的に矛盾を起こしたシナリオを使う場合があります。たとえばギャグ作品なんか、わざとトークの前後で矛盾をさせる事もよくあります。落語なども同様でしょう。

さらにファンタジー世界やSF世界などで(私たちの)現実世界とはゲーム中の物理法則や時空の法則が違っているので、現実では矛盾していても、ゲーム設定としては矛盾していない場合や、矛盾していても「演出」などとして許される場合もあります。


このため、シナリオの矛盾の報告で、修正すべき矛盾を見つけるのは、なかなか難しいです。

ゲームでは更に、テンポ感などの理由で、小さな矛盾を製作者が意図的に無視する場合すらあります。もし矛盾を修正しようとすると、ゲーム中での説明会話が長くなってしまい、「テンポ感を損ねるだろう」といった判断によって、小さなシナリオ矛盾を残すという高等的なテクニックすらあります。

例外として推理ゲームや推理イベントなどといった、けっして矛盾の許されない例外を除き、ゲームシナリオのデバッグでは必ずしも、杓子定規に全ての矛盾をゼロにするという事は、ゲーム開発では良策とは限らないのです。


直すべきバグとは作品テーマに反するバグ編集

ですが、それでもあえて、あるシナリオの矛盾を修正しなければならない場合もあります。その例の一つとしては、物語のテーマに反する誤解を与えるような矛盾のある場合です。

たとえば、物語のテーマが、「思春期の男女は、恋愛を通じて人間性も成長する」というようなテーマの場合、もし、たとえば恋愛関係にある男女(仮にボブ(男)とクレア(女)としましょう)が、本来ならボブとクレアは恋愛関係にあるのに、テンポなどの事情でセリフが削られたりして、あたかも「ボブとクレアは嫌いあってる」とか、そもそも「ボブとクレアが恋愛関係にはない、単なる同級生」のような印象をプレイヤーに与えるようなシーンがあるとしたら、おそらくそのシーンはバグと見なして修正されるべきです。

このように、物語テーマに反するシーンなどは、シナリオのバグの可能性があります。


裏テーマという存在編集

なお、ゲーム開発において必ずしも、いちいち「このゲームのシナリオのテーマは、〇〇です。どういうことかというと(以下略)」みたいな説明は無いことが、よくあります。

「プレイすれば、まともな感覚があれば、物語のテーマくらい分かるでしょ? 大人なんだからさぁ」みたいな感じで、いちいちシナリオテーマはデバッガーなどには説明されないでしょう。

あるいは、表向きのテーマとは別に、名言されていない裏のテーマなどが存在している場合もあります。演出などの都合で、裏テーマはあえて名言されない場合もあります。

たとえば小学生くらいの子供むけのターゲットな明るいゲーム作品などで、「良い大人になるためには、子供はどうあるべきか?」みたいなマジメなテーマは普通、名言はされないで、裏テーマに回るでしょう。

なのでシナリオのデバッグをする場合には、そういった裏テーマも読み取った上で、シナリオをデバッグする必要があります。


上記のノウハウを聞くだけなら簡単そうですが、しかし大変なのは、この「裏テーマの発見」をする事です。シナリオのデバッグ中に、けっしていきなり裏テーマにピンポイントな修正案件が見つかることはありません。

たいてい、最初に見つかるシナリオバグは、単なる設定矛盾などです。

単に仕様書などと照らし合わせれば発見できる一般的なバグとは違い、シナリオのバグの発見には作品への読解や理解が必要です。なので、けっしていきなり最初にピンポイントにシナリオの裏テーマ関連バグは見つかりません。というか、そもそも裏テーマは巧妙に隠されてるからこそ、「裏」のテーマなのです。

テスター・デバッガーたちが細かな設定矛盾などを報告してプログラマーなどが直しているうちに、たまに、ついに裏テーマにピンポイントなシナリオ矛盾をデバッグ関係者の誰かが見つけるって事が、たまにあります。

このように、けっしていきなりは、ピンポイントなシナリオ矛盾は見つかりません。

なのでまず、小さなシナリオ矛盾であっても、よほどテンポ感を下げない限りは、(なるべくテンポ感を下げないまま)とりあえずは矛盾を直していく(矛盾を小さくしていく)のが安全です。

諺(ことわざ)「将を射んと欲せば、まず馬を射よ」のようなものです。


あと、そもそもシナリオライター自身が、自身の脚本に隠れた裏テーマにあまり自覚できていない場合もあります。なのでライターに「この作品のテーマはなんですか?」とか質問しても無駄です。なのでテスターなどが頑張ってシナリオを読解・推察していくしか、裏テーマを見つけだす方法は、ありません。


なお、本wikiでは説明の都合で、あたかも報告当時に「これが裏テーマだ」と気づいたかのように説明しますが、しかし実際には「裏テーマ」として気づくのは数ヵ月後またはリリース後だったりします。

月日が経ってから、ようやく、あとで「あ、あのときシナリオ修正されたアレこそが物語の裏テーマだったんだ」と気づいていきます。

シナリオライター自身の見落としてい第3の物語テーマがテスト中に見つかる場合もありますが、これも「テーマだ」として自覚されるのは数ヵ月後だったりリリース後だったりして、リリース前のデバッグ期間中にはテーマかどうかは分からないものです。


このように、裏テーマか第三テーマかどうかは、リリース前のデバッグ期間中には判定しづらいので、あまり杓子定規には堅苦しくは考えすぎないようにして、とりあえず、ある程度はシナリオライターたちの感性に任せてシナリオ修正していくことになるでしょう。


レアケース対応漏れなどのシナリオバグの探し方編集

レアケース対応漏れなどといったシナリオ作成漏れのバグの探査方法は、仕様書があればそれで見つけるのも良いですが、他にもゲーム実機の実際のテストプレイなどで見つかることも多いです。


なので、テスターはまず、そのゲームの想定するシナリオを通しプレイなどでクリアして、いったんシナリオを把握します。その後、フリープレイ時やテストプレイ時などに、ついでにシナリオ上の矛盾点が見つかる場合もあります。

イベント進行などの状況によって会話などのテキストメッセージ内容が変わりゲーム作品も多くあります。もしゲーム中の説明文や会話文などのメッセージ文の内容と、イベント進行状況が組み合っていなかったりする場合には、バグとなります。

つまり、シナリオ作成時のミスで、分岐先シナリオの作成漏れが出てくる場合もあります。

このようなメッセージ内容のバグは、テスターが実際にゲームのシナリオを把握していないと、そもそも「これはバグである」とは気づかないのです。


さて、このイベント進行状況とメッセージ文の不整合により、ときどき、作品テーマに反する誤解をプレイヤーに与えてしまう場合があるのです。

たとえば、(いくつか前の段落の例での)ボブとクレアの恋人関係の例なら、ストーリー前半でクレアが主人公の仲間になっているのに、もしボブのメッセージ文がストーリー前半でのクレアのパーティ加入に対応してなかったら(もしフラグ管理ミスでストーリー中盤以降からしかクレア加入の場合にしかボブ会話文のフラグ分岐が対応してなかったら)、あたかもボブが恋人クレアをガン無視している(←フラグ上ではクレアが未加入なので. )かのようにプレイヤーに誤解を与えてしまいかねず、ボブとクレアが不仲になったかのように誤解されかねない・・・、というワケです。

たとえば、クレアが仲間になる条件が、加入条件になっている中盤ボス(レベルはストーリー中盤相当)を倒すことだとして、一般的なプレイヤ-はゲーム中盤にそのボスを倒すので、クレアを仲間にするのも中盤になるプレイヤーが多いとしましょう。

ですが、もしゲーム前半でその強ボスを倒すのが原理的に可能なプログラムになっているゲームの場合、プレイヤーの一部はストーリー前半でもそのボスを倒して、クレアを(中盤ではなく)ストーリー前半で仲間にする場合もあるのです。こういったレア目なケースは、理想的にはシナリオ作成の段階でレアケースにも対応できれば理想ですが、しかしライターやプログラマーなどの忙しさなどの関係で、レアケース対応のシナリオの執筆や実装そのものが忘れられて分岐先シナリオ自体の作成漏れというミスをしている場合があります(特にフリーゲームや同人ゲームなど)。

つまり、(「あるイベントのシナリオが仕様と不一致」ではなく)「そもそも、イベントのレアケースの場合だと、その場合のシナリオ自体が作成漏れで無い」という事例もあるのです。

しかしプログラム的に禁止されて無いプレイである限りは、どんなにレアなケースでも、プレイヤーの一部には、そのレアケースのプレイをする人も少数の割合ながら、いるのです。

このようなレアケース漏れや分岐シナリオ作成漏れを見つけるには、テスターは実際に何周もテストプレイをしてみて、様々な攻略パターンでプレイして見つけるしか、ありません。


このような事例があるので、なのでシナリオのバグの有無の確認では、(けっして脚本テキストデータの通読だけでなく、加えて)実際にゲームをプレイしてみて、ゲーム中のメッセージ文をプレイの順序どおりに読んでいくという方法により、テストプレイではバグの有無を確認していく必要があります。

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

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

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

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

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


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

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

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


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

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

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

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


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

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


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

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


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

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


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

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


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


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


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


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


その他、

【確認日】
【確認者】

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

参考文献編集

  1. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、262ページ
  2. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、264ページ
  3. ^ 『まず2Dゲームで開発、社員300人で1週間遊ぶ!? 新作ゼルダ、任天堂の驚愕の開発手法に迫る。「時オカ」企画書も公開! 【ゲームの企画書:任天堂・青沼英二×スクエニ・藤澤仁】』 2017年3月2日 12:03 2020年12月1日に確認.
  4. ^ 『【ゲームの企画書】『ペルソナ3』を築き上げたのは反骨心とリスペクトだった。赤い企画書のもとに集った“愚連隊”がシリーズを生まれ変わらせるまで【橋野桂インタビュー】』2019年10月30日 11:30 2020年12月1日に閲覧して確認.
  5. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、257ページ
  6. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、258ページ
  7. ^ STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、258ページ
  8. ^ 『「アストロシティミニ」発売目前! Hiro師匠&光吉猛修氏に聞く,FM音源に彩られた1980~1990年代セガ・サウンドの裏側』2020/12/03 00:00 2020年12月4日に閲覧して確認。