「ゲームプログラミング/デバッグ」の版間の差分
削除された内容 追加された内容
792 行
まず、その追加したばかりの機能が実際に動作しているかを、（デバッグモードでいいので）プログラマー自体がチェックします。
もし集団作業なら、これは
また、集団作業でなく個人製作でも、まずデバッグモードでも何でもいいので、追加したばかりの機能をチェックします。この個別チェックというか局所的なチェックでは、けっしてバランス調整などをする必要は無いです。
個別チェック・局所チェックと、バランス調整とは、目的が異なります。個別チェック・局所チェックでは、単に、デバッグモードなどで、その項目だけをチェックします。▼
▲個別チェック・局所チェックでは、単に、デバッグモードなどで、その項目だけをチェックします。
もしデバッグモードの機能が無いゲームの場合や、製品に近くデバッグモード不搭載のバージョンの場合には、デバッガーは、なるべくデバッグモード利用時に近いプレイ方法で、個別にチェックしていきます。
===== 異業種との関連 =====
817 ⟶ 810行目:
「チェックの最終確認においてシミュレーションが無駄」といのは、これは自動車業界だけでなく、航空宇宙などでも同様です。日本のJAXAは「はやぶさ」の部品モジュールの開発において、実際に部品を組み立てたうえでの（シミュレーションではなく）物理実験をしています（※ 講談社ブルーバックス『小惑星探査機「はやぶさ」の超技術』で確認できます。）。また、産業技術総合研究所での測定の国家標準器開発などでも同様の手法であり、実際に測定器を製品として組み立てた上での物理実験をしています（テレビ番組では、TBS科学番組『夢の扉』でメタンハイドレート採掘の産総研の研究者が、そうシミュレーションの問題点を指摘しました）。
ソフトウェアの開発では原理的に物理実験は無理ですが、それでも不具合対策の確認は、最終的には、実際にそのソフトをユーザー視点で使用してみる「実践」/「試用」しかありません。
827 ⟶ 819行目:
重要なのは、ゲーム開発のデバッグにおいても、実際に「通しプレイ」というビッグバンテストが必要だという事です。「ビッグバンテスト」という名称の知識は、割とどうでもいいです（知識の無いよりかは、あるに越した事はありませんが・・・）。
本書は製造業ではなくゲーム開発の教科書なので、これ以上の製造業でのチェック方法への深入りを避けます。
なお、アニメ業界でも、1990年代くらいまでは、アニメ業界での分業による生産システムを説明するのに、自動車産業などでの分業になぞらえてアニメの分業を説明したりする説明手法がよく行われていました。
デバッグではないですが、バランス調整や各種の演出・シナリオなどの面白さの確認でも、実際に通しプレイで確認する必要があります。商業ゲームでも、任天堂が『ゼルダの伝説 時のオカリナ』では、社員300人で通しプレイで最初から最後まで実際にプレイして確認したという手法でチェックしているというノウハウを公開しています<ref>[https://news.denfaminicogamer.jp/projectbook/zelda/4#i-2 『まず2Dゲームで開発、社員300人で1週間遊ぶ!? 新作ゼルダ、任天堂の驚愕の開発手法に迫る。「時オカ」企画書も公開！ 【ゲームの企画書：任天堂・青沼英二×スクエニ・藤澤仁】』 2017年3月2日 12:03 ] 2020年12月1日に確認. </ref>。
ネットのバイト紹介記事などだと、こういう社員での通しプレイによるチェックなどは紹介されませんが、順序的には、チェックシートによる細かいチェックよりも、まず通しプレイチェックのほうが先です。
任天堂の場合も、デバッグを開発初期と終盤とで別々の方法に分けて、開発序盤からデバッグしています。（[https://game.watch.impress.co.jp/docs/news/1078888.html 岩泉茂『【CEDEC2017】「ゼルダの伝説」作成を裏から支えたエンジニアたち 大規模プロジェクトをいかに効率的に乗り切るか』 、2017年9月4日 07:00]。） 開発初期のデバッグでは、ゲームの面白さに関わる部分のデバッグを優先的に修正していきます。開発終盤では、製品化やリリースなどにむけて、今まで後回しにしていた細かいバグも修正していきます
大規模なゲーム開発になると、開発初期からデバッグしないと、発売日・リリース予定日・公開日までに間に合いません。
855 ⟶ 844行目:
なので、それぞれの段階に適して調整方法なりデバッグ等の方法を変えていきます。
また、社内デバッグでは、テスター専門のヒト以外にも、各種のアーティストやプログラマーなどもテストプレイに参加しましが、彼らは本業のアート素材制作（ゲームに組み込みためのイラスト素材、音楽素材などの制作）で忙しいので、バグ報告後の次バージョンでの修正チェック確認などはテスターが受け持ちます（任天堂がそうしています）。
866 ⟶ 854行目:
ですが、デバッガーは、こうして確認をしていきます。
たとえばRPGなら他にも、すべての道具をとりあえず最低1回ずつは使ってみるとか、
878 ⟶ 865行目:
さらに商業ゲームでは、たとえば、壁（かべ）の通行不能の処理が、本当に壁として行き止まりになっているかとか、通行止めであるかとか、そういう行き止まりチェックみたいな事も、します。
なお、この、本来なら行き止まりであるべきの壁が通れるバグのことを通称「壁抜けバグ」と言います。壁以外の海とかガケとかの行き止まりも含めて一般的な言い方をすると、「通行（つうこう）判定バグ」または「通行設定バグ」などと言います。
なお、「進行（しんこう）不能バグ」は、これとは意味が異なります。「進行不能バグ」とは、ゲームのストーリを進められなくバグのことです。
デバッグ（テストプレイ）でツライ事の一つは、この「通行（つうこう）設定バグ」の有無のチェック、つまり行き止まりチェックでしょう。
もし、スーファミ風のドラクエ・ファイファン的なゲームのようにマップがマス目で作られている2D-RPGの場合、デバッグ仕事でなら、すべての壁マスの通行設定を確認する事になります。
898 ⟶ 885行目:
なのでフリーゲームだと、この行き止まりチェックはよく、省略されます。なのでフリーゲームでは、ver1.00公開直後には、よくあるバグで、本来なら行き止まりのハズなのに通行可能になる壁のようなモノの存在するバグが、よくあります。
907 ⟶ 893行目:
このように、とりあえず、どちらの選択肢を選んでも、当面の数分はバグの無く、正常に動作しているかを、（デバッグモードや、セーブデータの複数用意などで）なんらかの方法で確認します。
921 ⟶ 906行目:
なので、デバッガーは、ところどころで、自殺プレイをします。ゲームオーバーや全滅などのイベントが正常動作するかを、ときどき確認します。
難易度の高いゲームなら、意図的に自殺プレイしなくてもよく全滅しますが、たとい難易度の低いゲームでも、わざと自殺プレイをします。
特にボス戦などは、ソースコードでは特殊なフラグ処理が入りこんでいるのでバグの混入している可能性も高く、そのため、たとえ弱いボスであっても、ワザと敗北したりする自殺プレイが、デバッガーのすべき事です。
;カウンターストップのチェック
たとえば、RPGのゲームの上限レベルが「99」の場合、きちんとレベル99で止まるかを、とりあえずデバッグモードでチェックします。
938 ⟶ 919行目:
レベル98からレベル上げをしてみたりとか、レベル97から一気に2レベル上がったらどうなるかとか、いろいろと確認しましょう。
また、所持金や道具の個数なども同様に、上限できちんと止まることをデバッグモードなどを活用して確認します。
959 ⟶ 938行目:
IT業界の格言ですが、「デバッグされてないコードは、（資産ではなく）負債である」という格言があります。なので、コードを書くことよりも、自分で書いたコードをひとつずつデバッグすることのほうが重要です。
ともかく、このように、機能をひとつずつ、個別的にチェックしていきます。
;ボタン連打や、壁に何度も衝突など
ボタンを1回だけなら押しても異常は無くても、ボタンを何度か押すと異常のあるバグも、ときどきあります<ref>STUDIO SHIN 著『ゲームプランナーの新しい教科書』、翔泳社、96ページ、2018年3月10日 初版第2刷発行、257ページ</ref>。
とはいえ、ゲーム中の全てのシーンで何度もボタンを押していたら、ゲームが進行せずにデバッグも進行しないので、たとえばゲーム中で使用頻度の多いメニュー画面などでボタン連打するとか、あるいはイベント進行などで「ここが、もしかしたらバグが潜んでいる可能性がありそうだな」とか思ったところだけボタン連打するとか、工夫しましょう。
| |||