ポケコンBASICによるゲーム制作講座
第5章 テストプレイはゲームの味見
ゲームがある程度出来た段階で重要となるのがテストプレイです。私が考えるテストプレイを行う主な理由は以下の2つです。
(1)は基本的にあらゆる場合を想定して行わなければならず、制作者本人ではなかなか見つけにくいバグも存在します。それは、制作者であればどういう使い方をするのかという先入観があるために特定の操作方法しか行わないためです。
例えば数値入力を行うのにINPUTによって数値変数を用いた場合を考えてみると当然、制作者はこの場面では数字入力のみを行うから問題ないと思うでしょうが人によっては文字（数字ではなないもの）を入力することは十分考えられます。そういった場合にエラーが起こりますがこれは言ってしまえばバグといえます。
しかし、制作者側からすればここは数値入力しか行わないことを前提とした処理となっているから使用上の誤りと解釈も可能となります。こういった制作者側が認めている不具合については「仕様」と呼ばれることがあります（つまり、そのゲームはそういう使い方をしたらそうなるように意図的に作っているということ）。とはいうものの、バグが見つかったらいつでも「仕様です」で済ますのは怠慢と言われても仕方がないので、「バグ」は徹底的に見つけそれについての対策を行っていくべきだと私は思います。もっとも、メモリが少なく処理速度が遅いポケコンにおいてはある程度のトレードオフは仕方がない場合もありますが・・・。
最低限、完成した時点では普通にプレイをしていて発生するバグは無くしておきたいものです。RPGをプレイしていてエンディング直前でエラーなんてことになったら泣くに泣けないですからね。
私は処理速度向上のためにかなり無茶な処理（※注1）をしていることがありますが、これをやると少しでもゲームの仕様が変更になった場合に対処がしにくくなるのであまり真似をしない方がいいでしょう（笑）
(2)についてですが、これはゲーム制作においてはゲームバランスが非常に重要になるからです。いくらアイデアがすばらしくてもバランスがダメなためにゲーム自体が台無しになってしまうこともあり得るのです。
第4章でも少し書きましたが、まずは全体的なバランスが自分の意図してるようになっているかどうかを見る必要があります。そして、一部のもの（アイテムの力、パラメータの上がりやすさ等）が他のものと比べてバランスが崩れてないかどうかを見る必要があります。
さて、ここで問題となるのはゲームバランスがちゃんと取れてるかどうかは個人では分かりにくいと言うことです（第4章でも書いたようにゲームバランスは主観的な要素が大きいため）。リアルタイム型ゲームの場合はプレイしていくごとにどんどん慣れていくので全体的なバランスを高めに設定しがちだし、思考型のゲームは制作者だと簡単にクリアできてしまう（パズルゲームの場合は最初から解答を知ってるわけだしね）のでバランス調整を行うのは非常に難しいといえます。
できることならば、バグ取りと同様に誰か他人にテストプレイをしてもらうのが一番なのですが、そうもいかない場合もあるでしょう。その場合は自分の力（アクションゲームは得意かどうか等）を把握していればそれを元にしてある程度客観的なバランス調整は可能になります。私はキーの連射が人並以上はできる（こすりを使わなくて秒間15連射くらい）ということで100m走のゲームを作る場合に私がの10秒ぎりぎりくらいに調節をしておけばいい感じのバランスになるわけです。
私が全体のバランス調整として心がけているのは「間口が広く奥が深く」です。どういうことかというと序盤のうちはゲームに慣れてもらうために誰でもクリアできるくらい簡単にして（※注2）、完全クリアやスコアアタックをしようとすればプレイに相当のテクニック等が要求されるといった感じです。
作ったゲームをより多くの人に遊んでもらおうとするならば最初のつかみの段階であまりに難しくしないことです。数回チャレンジしてそのゲームの面白さが伝わる前にゲームオーバーになってしまってはよほどそのゲームに興味を持った人しかプレイしてもらえないでしょう。また、完全クリアが簡単にできて向上心を刺激されないものだとすぐに飽きてしまうので向上心を刺激する仕掛け（いわゆる「やり込み要素」）を用意しておくといいかもしれません。いくらプレイしても上達が実感できないようであればプレイの意欲が薄れてしまうし、完全クリアが簡単に狙える（もしくは運のみで決まってしまう）のであればやり込もうとは思わないですからね。
これは私の考えでありそれがすべてのゲームにおいて正しいというわけではないので、自分がどんなゲームにしたいのかイメージしそれを実現に近づけるようにするのが一番だと思います。しかし、面白いゲームをイメージ化するには様々なタイプのゲームに触れてみるだけではなく、ゲーム以外の事象にも興味を持って接する必要があります。
ゲームバランスをうまく調節することが面白いゲームに仕上げるためには重要な要素なのですが、そのためにもテストプレイは何回も繰り返し行う必要があります。すると1回や2回のテストプレイでは気が付かなかったことが見えてくる場合があります。それは例えば、1回のプレイが短いアクションゲームにおいて1プレイがごとにRUNをしなくてはならないものであったり、ゲーム開始までやたら時間がかかるものであったり・・・。このように自分が繰り返し遊んでみて初めて実感できるシステム面のまずさは普段あまりテストプレイをしてない人の場合は無頓着になりがちなので注意が必要かもしれません。
テストプレイは料理に例えるのであれば味見に相当します。テストプレイが不十分なゲームは初めて作る料理でろくに味見をしないで人に食べさせるようなものです。「おいしい料理を作りたい」とか「他の人に食べてもらいたい」とかいう場合には十分味見をしておきたいものですよね。しかし、料理に凝り出したら味見をするのがきりが無くなるようにゲームのテストプレイにおいてもやりだしたらきりがないというのも事実です。そのためどこかで妥協せざるを得ないのですが、その妥協点をどこにおくかというのは解答が無いだけに難しい問題ですね（※注3）
※注1
私の場合は処理の高速化のため本来ならば正しくない式や条件判断文を使用している場合があります。正しくないと言っても厳密にはゲーム内で取りうる範囲の値のみ成立するものなので使用上には問題はありません。しかし、少しでもゲームの仕様が変わってしまうと使えなくなるという問題点は残されています。小規模なゲームですべての内容を完全に把握できるものであれば高速化において非常に有用なのですが、大規模なものを作ろうとすると自らバグの原因を作るような物なのであまりおすすめはできません。
※注2
こんなことを書いてるけど私が作ったゲームの中にはやり込まないと1面すらクリアできないゲームもあったりします。「宇宙戦艦ナデツコ」がそれに当たるわけですが、独特の操作を要求するものは簡単に作ったつもりでも初プレイでの難易度が跳ね上がってしまうので注意が必要でしょう。
※注3
私の場合は最低限通常の使用でバグが無いことを確認し、リアルタイム型ゲームではメインルーチンを限界まで高速化を行った後に完成としています。この場合、変数の取り得る範囲を明確に把握してないと限界までの高速化はできないために完成時には通常あり得ない操作におけるバグも防げるというメリットもあります。ただし、上記※注1のような問題もありますが・・・。
NEXT PAGE
序章
第1章 素材選びはすべての源
第2章 ゲーム性がおいしさのカギ
第3章 キーレスポンスでおいしさが変わるリアルタイム型ゲーム
第4章 アイデアでおいしさが変わる思考型ゲーム
第5章 テストプレイはゲームの味見
終章
RETURN/
RETURN *MAIN
