「ゲームプログラミング」の版間の差分
削除された内容 追加された内容
編集の要約なし |
|||
702 行
この個別チェックでは、けっしてバランス調整などをする必要は無いです。
個別チェックと、バランス調整とは、目的が異なります。
個別チェックでは、単に、デバッグモードなどで、その項目だけをチェックします。
もしデバッグモードの機能が無いゲームの場合や、製品に近くデバッグモード不搭載のバージョンの場合には、デバッガーは、なるべくデバッグモード利用時に近いプレイ方法で、個別にチェックしていきます。
たとえば、RPGの装備品のシステムが正常に動作しているかどうかを確認するためなら、とりあえず、すべての装備品をいったん装備および装備解除してみる、というような作業をします。
これは、一般プレイヤーがゲームを楽しむ方法とは、異なります。
ですが、デバッガーは、こうして確認をしていきます。
たとえばRPGなら他にも、すべての道具をとりあえず最低1回ずつは使ってみるとか、
到達可能なマップチップには、すべてのマップチップの上を歩いてみるとか、そういう事をします。
とはいえ、これらは普通のゲームプレイでも、プレイヤーによっては、アイテム効果確認や隠しエリア探索などのために、よくやる事でもありますので、これはまだ楽しいほうです。
さらに商業ゲームでは、たとえば、すべての壁（かべ）の通行不能の処理が、本当に壁として行き止まりになっているかとか、そういう行き止まりチェックみたいな事も、します。
ツライ事の一つは、この行き止まりチェックでしょう。
なのでフリーゲームだと、この行き止まりチェックはよく、省略されます。なのでフリーゲームでは、ver1.00公開直後には、よくあるバグで、本来なら行き止まりのハズなのに通行可能になる壁のようなモノの存在するバグが、よくあります。
他にもデバッガーのすべき事は、たとえば、ゲーム中にもし、なんらかの選択肢の入力がある場合、選択肢すべての（当面の）結果を確認します。
たとえば、もしRPGのストーリー中の重要なシーンでのコマンド選択肢で、善行と悪事との選択肢があった場合、2つのセーブデータを用意して、両方の選択肢とも試してみて、とりあえず数分は動作しているかを確認します。
このように、とりあえず、どちらの選択肢を選んでも、当面の数分はバグの無く、正常に動作しているかを、（デバッグモードや、セーブデータの複数用意などで）なんらかの方法で確認します。
なお、一般ユーザーのプレイ傾向としては、もしゲーム中に選択肢で、善行と悪事の選択肢があったら、なんだかんだで普通のプレイヤ－は善行を選びます。
なので、もし普通のプレイヤーに任せていては、いつまで経ってもゲーム中では、ゲーム中の悪事の確認は、なかなか、できないです。
このためデバッガーは、意識的に、自分のプレイスタイルとは異なる悪事の選択肢でも、デバッグして動作確認する必要があります。
また、一般プレイヤーは、上手にプレイしたがるので、わざとゲームオーバーする自殺プレイを嫌がります。
なので、デバッガーは、ところどころで、自殺プレイをします。ゲームオーバーや全滅などのイベントが正常動作するかを、ときどき確認します。
難易度の高いゲームなら、意図的に自殺プレイしなくてもよく全滅しますが、たとい難易度の低いゲームでも、わざと自殺プレイをします。
特にボス戦などは、ソースコードでは特殊なフラグ処理が入りこんでいるのでバグの混入している可能性も高く、そのため、たとえ弱いボスであっても、ワザと敗北したりする自殺プレイが、デバッガーのすべき事です。
さて、とにかく上述のように個別デバッグをして、まずはデバッグモード（またはデバッグモードに近いプレイスタイル）で正常動作するようになるまで、まずプログラムを修正していきます。
もちろん、デバッグモードで正常動作したからといって、けっして、必ずしも通常起動のモードでも正常とは、かぎりません。
725 ⟶ 781行目:
====
さて、こうして、いくつか機能をデバッグモードで個別チェックしていき追加していくのが完了したら、今度は次に、ゲームを最初から始めて、エンディングまでプレイをします。
732 ⟶ 788行目:
通しプレイは時間にかぎりがあるので、たとえば新バージョン公開のたびに直前に行うとか、そういうふうに工夫します。（もし機能の追加のたびに通しプレイすると、時間が不足する。）
さて、商業作品の場合、通しプレイでは、けっして上手にプレイするのが目的ではないのです。
とりあえず、色々なことをそのゲーム中でしてみて、それでもバグが起きないことを確認するためのモノです。
;1回目の通しプレイ
とはいえ、最初の1回目の通しプレイでは、まず普通に、自分のやりたい自分本来のプレイスタイルでプレイするのもイイでしょう。（ｍそいゲームのクリア所要時間が長すぎる場合や、クリア困難な難易度の場合には、とりあえず数時間ほどのプレイで区切るべきだろう。）
なぜなら、世間の他人から見れば、アナタのプレイスタイルも、他人にとっては「色々なプレイスタイル」のひとつですから。
また、そのゲームの中でどういった行動が可能なのかを知るためにも、とりあえず最初の1回は、普通にプレイする必要があります。
;2回目以降の通しプレイ：パターンA
さて、とりあえずの1回目の通しプレイが終わったら、2回目以降の通しプレイでは、プレイスタイルを変えます。
けっして、通しプレイの目的は、「エンディングに最短時間で到達する」（×）とかではないし、「上手にプレイする」（×）とかでもないのです。
自分のプレイスタイルではなく、自分以外のスタイルで、他の多くのプレイヤーがやりそうなプレイをします。
とはいえ、プレイスタイルを変えてみるのも、（自分の性格にもよりますが）そんなにツマラナクは無く、1回目では見過ごしていたイベントを発見できたりとかも出来ますので、さまざまなプレイスタイルを自身で再現してみることで今後の自分のゲームとの付き合い方の勉強にもなります。（というか、コレがツマラナイと感じる人は、そもそも性格的にデバッガーに、向いてないので、別の職種を頼むべきかと。）
また、1回目と同じプレイスタイルでプレイしても、どうせ1回目で見たことある現象と同じ現象しか見られないので、むしろ2回目以降はプレイスタイルを変えたほうが面白くなるでしょう。
;2回目以降の通しプレイ：パターンB
普通のプレイヤーは、ある程度は上手にプレイしようと目指します。
また、ゲーム中の選択肢で、善行と悪事のどちらかを選ばせる選択肢がある場合、たいていの一般人は善行を選びます。
なので、彼ら一般人と同じプレイスタイルでは、たとえばもし、ゲーム序盤のとても弱い敵に負けた際に発生するバグがあったとしても、そういうのは発見っされづらくなります。
なので、ときどき意図的にヘタな通しプレイをします。
事前のデバッグモードなどでの個別チェックでも、このような確認はしているハズですが、確認モレがあったり、あるいは通しプレイ時にしか発生しないバグなどもありうるので、念のため通しプレイでも、意図的に下手なプレイをします。
797 ⟶ 893行目:
参考情報などで、とりあえずバランス調整に関係ありそうなテストプレイ時の行動も書いておくと、プログラマー側はデバッグついでにバランス調整のための資料にも出来るので、一石二鳥です。また、ひょっとしたら、そのバランス関連の参考情報で書かれたテストプレイの行動も、バグ発生条件に関係しているかもしれない場合もあります。
（ただし、商業作品の場合は、バランス調整はデバッグよりも前のほうに終わらせておく必要がある。）
しかし、あくまでバランス調整に関するテストプレイ報告については、後回しの付属的な情報です。メインに報告すべきは、バグに関係ありそうな情報から優先的に報告です。バランス報告については、せいぜい5行くらいまでで充分でしょう。
916 ⟶ 1,015行目:
こうすることで、もしバグが今後に他の場所で見つかった場合でも、ソフト作者が「異常なし」報告を受けた部分は後回しにできます。
=== 仕様かバクか不明な場合 ===
ゲーム演出のなかには、一見するとバグっぽい演出もあります。
なのでデバッガーが、ゲームのテストプレイをしているときに見つけた現象が、はたしてバグなのか、それとも意図的な演出なのか、悩むこともよくあります。
このような場合でも、とりあえずはデバッガーは念のためバグかもしれないと報告を挙げておくのが、ゲーム業界での通例だと言われています。
たとい結果的にバグではなく意図的な演出だとしても、プログラマー側にとって、ユーザー視点に近い人からの参考意見になります。
== セーブとデータベース ==
| |||