はじめに
「個人制作ゲームでも、テストを頼むべきかな」
この記事は、そんな悩みがある人向けのコラムです。
結論からいうと、頼める相手がいるなら、テストプレイは頼んだ方がいいと思っています。
特にRPGのように、マップ移動、戦闘、アイテム、イベント、フラグ管理などが絡むゲームは、作者一人ではどうしても見落としが出やすいからです。
ただ、ここで言うテストプレイは、本格的なテスト計画を立てて、項目を作って、一つずつ確認していくようなものではありません。
- 観点を洗い出す。
- 漏れのないように項目を作る。
- 結果を記録する。
- 修正後に再テストする。
こうした工程は、もちろん品質を高めるには有効ですが、個人制作でこれをそのままやるのはかなり重いです。
そもそも趣味で作っているのに、急に仕事のようになってしまうので「さすがにできない」と感じる人も多いと思います。
しかし、それで終わらせず、完璧なデバッグを行えなくても、まずは「誰かに遊んでもらう」くらいでも意味があると思っています。
そこで見えてくるのは、「バグ」だけではありません。「反応」も含まれてきます。
制作ツール（ツクール等）でもテストは重要
ゲームの作り方にもよりますが、ツクールのように型がある制作環境なら、個人制作で業務レベルのテスト計画まで作らなくても、危険度は比較的低いと思います。
セーブ、メニュー、マップ移動、戦闘、アイテム管理など、基本的な仕組みが用意されているためです。
ゼロから自作エンジンで作るゲームに比べると、土台部分の危険度は比較的低いと思います。
しかし、それでもバグは出ます。確認した方がいいのは、自分が作った部分です。
たとえば、ツクール系なら以下のような部分です。
- 通行設定
- イベント条件
- スイッチや変数
- 分岐処理
ほかにも、ユーザー視点での次のような確認も大切です。
- 進行不能にならないか
- 想定外の動作ができないか
- 次に行く場所が分かるか
- 説明不足になっていないか
作者は正しい進み方を知っています。作者は「ここは壁」と思っています。
作者は「このイベントのあとに次へ行く」と分かっています。
だからこそ、自分以外の人に一度触ってもらう意味があります。
個人制作で学んだこと：「動く」と「壊れない」は違う
小中学生の頃ですが、遊びでRPGを作っていたことがあり、そのとき兄弟にテストプレイ（試遊）をしてもらいました。そこで私は、作者の想定外を思い知ることになります。
ケース1：お金を無限に増やして遊んでいた
あるとき、様子を見ようと覗いたら、なぜかお金を無限に増やして遊んでいました。
当時はかなり驚きました。
遊び方が想定外過ぎて、なんとも言えない気分でしたが、確認してみると「ロジック上は確かにそうなる」というこちら側のミスでした。
つまり、プレイヤーが変なことをしたというより、特定の手順を踏むと、ゲーム側に“そうできてしまう仕組み”がありました。
ケース2：壁をすり抜けてマップ外に侵入していた
さらに、次に様子を見たときは、今度は壁をすり抜けていました。
１回目は驚きで済みましたが、２回目は少し悲しい気持ちでした。
せっかく作ったものが、想定していた遊び方から外れていくように見えたからです。
でも、今思えば、お金を無限に増やせる穴に気づき、マップの通行設定の甘い場所にも気づく。
つまり、普通にデバッガーとして優秀過ぎたようにも思えます。
作者の想定ルートではなく、「このゲームで何ができるのか」を自然に試していたのだと思います。
でも今振り返ると、それは本当にありがたいことでした。
公開する前に、作者が見落としていた穴を見つけてくれていたわけです。
分かったこと：想定外の抜け道が見つかることがある
作者はどうしても正しいルートを知っている状態で確認してしまいます。
しかしプレイヤーは、
- 壁沿いを歩く
- 入れそうな場所を試す
- 同じ処理を繰り返す
といったことを自然に行います。その結果、想定外の抜け道が見つかることがあります。
結果的にこのゲームは、心が折れて完成できませんでしたが、振り返れば良い経験だったと思います。
バグには「仕組みの穴」と「進行を壊す穴」がある
バグといっても、全部が同じ危険度ではありません。
大きく分けて、2つの種類があります。
仕組みの穴
たとえば、お金を無限に増やせる、強化をコストなしで繰り返せる、報酬を何度も受け取れてしまう。
こういうものは、ゲームバランスを壊すタイプの穴です。
困るバグではあります。でも、原因は比較的見えやすいことが多いです。
「この処理を繰り返せば、無限にお金が得られる」なら、実際にそういう仕組みができていることが多いです。
「単純に、強化で消費するコストが減っていない」なら、コストの計算処理が漏れているかもしれません。
というように、仕組みを見れば理由が分かることが多いです。
進行を壊す穴
一方で、壁抜けや進行不能につながるバグは、別の怖さがあります。
RPG制作では、壁抜けは個人制作でもかなり起こりやすいと思います。
ツクール系のように、マップチップごとに通行可・不可を設定するタイプの制作環境では、見た目は壁でも設定上は通れる、装飾チップの通行設定だけ抜けている、レイヤーの重なりで想定外に通れる、ということが起こり得るためです。
作者はその場所を「壁」として見ています。
だから、わざわざそこへ突っ込もうとしないことがあります。でも、プレイヤーは違います。
- 壁沿いを歩く。
- 入れそうな隙間を試す。
- マップの端を確認する。
ゲームに慣れている人ほど、こういうことを自然にやる人もいます。
そして、壁の外に出られてしまうと、単なる見た目の問題では済まないことがあります。
本来入れない場所に入ることで、イベントの起動順やフラグ管理が崩れたり、進行不能につながったりする可能性があるからです。
特にRPGでは、見えない場所やマップ外に、イベント処理やテスト用の起点を置いていることもあります。
そこにプレイヤーが入れてしまうと、何が起こるか分かりません。壁抜け系のバグはかなり危険です。
共同制作で学んだこと：遊ぶ相手により見えるものが違う
その後、共同制作チームを組んでゲームを作ったときには、もう少し自然に「人に遊んでもらうこと」の大事さが分かっていました。
そのため、完成した際には、チームメンバーのほか、何人かの友人にテストプレイを頼みました。
ケース1：チームメンバーは実装の穴やミスを拾えた
制作メンバー同士でもかなりバグを拾ってくれました。
特に、相手がゲームに慣れている人だったり、制作側の視点を持っていたりすると、「ここが怪しそう」という感覚があるのだと思います。
- 単純な誤字の発見。
- タンス等、テキストが出るはずのものに出てこない。
- 本来やり直しが利くはずが、手順によりできなくなる。
などです。こういうミスや不具合を見てくれることもありました。
ケース2：普段ゲームをしない友人は素直な反応をくれた
一方で、制作に関わっていない人にもやってもらっています。
中には、普段ゲームをしない友達に遊んでもらったこともあります。
そのときは、特に不具合は見つかりませんでした。
でも、その代わりに、素直な反応をくれました。
「面白かった」
「また何かあればやりたい」
そう言ってくれたのを覚えています。これはこれで、とてもありがたいことでした。
ゲームに慣れている人は、抜け道やバランスの穴を見つけやすいです。
制作経験がある人は、イベント処理や通行設定の危ない場所に気づきやすいです。
でも、ゲームに慣れていない人は、作者が忘れがちな「初めて触る人の感覚」を持っています。
- 操作が分かるか。
- 次に何をすればいいか分かるか。
- そもそも楽しいと思ってもらえるか。
- どこで興味が続くか。
- どこで飽きるか。
そういう反応を見せてくれます。
分かったこと：些細な反応も、あとから見るとヒントになる
ゲームをしない友達に遊んでもらったからといって、必ず良い反応が返ってくるわけではありませんでした。
別のゲームでは、あまり楽しんでもらえなかったこともあります。
そのときは、途中で少し飽きが来ているような感じがありました。
当時は深く言語化できていませんでしたが、今振り返ると、改善できそうな点はいくつも思い浮かびます。
特に、冒頭の引き付けや盛り上がりの作り方があまりうまくなかったと思います。
- 最初に「何を楽しむゲームなのか」が伝わるまでが遅い。
- 目的や気持ちよさが弱い。
- 盛り上がる前に、遊ぶ側の集中力が落ちてしまう。
そういう弱さがあったのかもしれません。
テストプレイで見るべき「反応」は、言葉でもらう感想だけではありません。
- 遊んでいる途中のテンション。
- 手が止まったり反応が薄くなったりする場面。
- 続きを見たそうにしているかどうか。
そういう小さな反応にも、作品のヒントが出ます。
ただし、一人の反応だけで作品全体を判断しすぎる必要はありません。
単にその人の好みと合わなかった可能性もあります。
大事なのは、「この反応は何を示しているのか」を考えることだと思います。
反応がそのまま反響につながることもある
面白いことに、あとから実際に反響があったのは、普段あまりゲームをしない友達が喜んでくれた方のゲームでした。
感想をもらったり、攻略方法を質問されたり、実況してもらえたりしました。
特に攻略方法の質問は、ただ「詰まったから聞いた」というより、「この人、エンディングをコンプリートしようとしてくれている」と分かるような質問でした。
これはかなりうれしい反応でした。
最後まで遊んでもらえたというだけではなく、別の結末も見ようとしてくれていたからです。
遊び手が「もう少し見たい」「他のルートも知りたい」と思ってくれるかどうかは、作品の反応を見るうえで大きな手がかりになります。
もちろん、身近な人が喜んでくれたからといって、必ず多くの人に届くとは限りません。
でも、その作品に「外へ届く何か」があるかどうかを考える材料にはなります。
そう考えると、テストプレイ中の反応はかなり正直だったのかもしれません。
プレイ中をずっと見ている必要はない
とはいえ、テストプレイ中の様子をずっと見るのは、正直かなり難しいと思います。
自分の場合は、テストを頼んだ相手が仲の良い相手だったため、遊んでいるところを時々覗くことができました。
でも、社会人になってから同じことをやろうとすると、時間も場所もなかなか合いません。
なので、無理に、プレイ中を最初から最後まで見ている必要はないと思います。
もちろん、見られれば分かることはあります。
- 集中が続いているか。
- 反応が薄くなるところ。
- 迷っている場所。
そういうものは、実際に見ていると拾いやすいです。
でも、それができなくても、プレイ後の感想や質問だけで分かることはあります。
- どこまで進んだか。
- どこで迷ったか。
- どこが面白かったか。
- もう一度遊びたいと思ったか。
- 別エンディングを見ようとしたか。
こういう話を聞くだけでも、十分に価値があります。大事なのは、プレイ中を監視することではありません。
遊んだ人から出てくる素直な感想や発見を受け取ることだと思います。
遊んでもらう相手によって、見えるものが違う
振り返ると、遊んでもらう相手によって、見えるものはかなり違っていました。
| 遊んでもらう相手 | 見えやすかったもの | 役割 |
|---|---|---|
| 兄弟 | バランス崩壊、想定外の進め方など | デバッグ |
| 共同制作仲間 | 実装ミス、仕様漏れなど | デバッグ |
| ゲームをしない友達 | 初見の分かりやすさ、素直な感想 楽しめた部分、合わなかった部分 | 反応確認 |
テストプレイを頼む相手は、全員がデバッガーである必要はありません。
- バグを見つける人。
- 導線を確認してくれる人。
- 素直な感想をくれる人。
それぞれ違う形で、ゲーム制作を助けてくれます。
まとめ
テストプレイは、バグを探すためだけのものではありません。
もちろん、バグを見つけてもらうことは大事です。
作者はどうしても、正しい進み方を知った状態で確認してしまいます。
でも、他の人は違う順番で進めたり、壁沿いを歩いたり、何度も同じ処理を試したりします。
その結果、自分一人では気づきにくい問題が見つかることがあります。
一方で、反応を見ることも同じくらい大事です。それは、作者一人ではなかなか分かりません。
完璧なテストができるなら、それに越したことはありません。
でも、個人制作で最初からそこまでやるのは大変です。
だから、何もしないくらいなら、誰かに遊んでもらう。
本格的なデバッグではなくてもいい。プレイ中をずっと見ていなくてもいい。
「どこまで進んだか」「どこで迷ったか」「面白かったところ」「変な挙動があったところ」
これだけでも聞けると、かなり参考になります。
反応とバグ。この2つは、作者一人ではどうしても見えにくいものだからです。
コメント