テストプレイ、あなたは何をテストする？

コンピュータの話をする前に、少しテストプレイについて語ってみます。

とは言っても、先日、OKAZU brandさんがテストプレイについて素晴らしい記事を書いて下さいました。
→ 『テストプレイとの付き合い方』

ここに書いてあることに私も全く同感なのですが、日頃テストを生業の一部とする者としては一つ補足したくなります。
それは「テストを”する前に” テスト項目を決めておこう」というものです。

テストプレイヤーにゲームをプレイしてもらって意見をもらいました。その意見を反映してゲームを改良しました。これで完成です…では不十分だということです。

1.テスト設計をしよう

前述のやり方では、そのゲームが世に出して良いクオリティ(これを決めるのはもちろんゲームデザイナー自身です)に達しているかをテストによって判断しているとは言えません。ただなんとなく、あるいは「もう入稿しないと締切に間に合わないから」等の理由(ドスッ ←勢いよく自分にブーメランが突き刺さる音)から、そう思いたがっているだけにすぎないのです。

テストによってゲームの完成度を判断するのであれば、テスト項目をあらかじめ決めておき、それをどの程度クリアしたら完成とするかを決めておきましょう。これがテストを設計するということです。

実は、このことも既に述べられている方がいまして、らりおさんが言うところの“引き出したい言葉”がそれにあたります。
→ 『ボードゲームのドラマ性について考えてみる』

上記記事の「1. 自由な選択」から引用させてもらうと、こういう感じです。

テスト項目：ゲームは自由な選択を有すること
判定基準：「うーん……どっちにしようかな……」「あそこであれしとけばよかったなぁ……」もしくはこれに準ずる言葉がプレイヤーから発せられること

そしてこれらの項目についてそれぞれ「これはクリア必須」「これはできればクリアしたい」といった感じでランク付けをしていき、『「必須」項目の全て＋「できれば」項目の50%以上クリアしたらリリースする』とするのです。

そうは言っても、改まってテスト項目を記述しようとすると上手く言葉が出てこないかもしれません。
そこでいくつか例を挙げてみようと思います。

2.ゲームバランスに関するテスト項目例

特定のカードの組合せで○点以上スコアが上がらないこと。
→ これは、さらにカードの組合せごとに項目化する必要があります。理想は全組合せ、無理なら一部をピックアップ。少ない項目数でなるべく網羅的にテストするためには「マトリクス法」等の技法があるわけですが、そちらの解説はGoogle先生に任せます。
一つのリソースを集中して集めた場合の勝率が○割以下であること。
→ これもリソースごとに項目が必要でしょう。

もっとも、バランスが取れすぎているとダメという意見もあるようです。ゲームデザインて難しいね…
参考記事：『スーパースター列伝　第3回　クニツィア博士　中編』

話がそれました。続けます。

3.ルールの不備に関するテスト項目例

プレイにおける全ての状況についてルールが決められていること。
→ とある状況でそれを解決するルールが存在しない場合、それはゲームの不具合です。

4.プレイアビリティに関するテスト項目例

マニュアルとコンポ一式をプレイヤーに渡し、デザイナーによる説明無しでゲームを始められること。
→ ドスッ(←二本目のブーメランが突き刺さる音)…これは必須項目ですよね。
プレイ中、同じステップが○回以上飛ばされないこと。
→「カードを引き忘れた」とかそういうのです。

5.楽しさに関するテスト項目例

1プレイ中に最低1回笑い声が出ること。
→ この項目はほとんどのゲームに入ってくるのではないでしょうか。もちろん、ウンウンうなり続けながら考えるのが楽しいゲーム等は例外ですが。
ゲームの概要を誰かに話したとき、質問が返ってくること。
→ この項目は本来なら、制作に”入る前に”テストすべきなんだろうなあと思ったり。これは楽しさというより、ゲームに対する関心度のテストと言った方が正確かもしれません。

6.どうやってテストする？

「What」の次は「How」の話です。
上記のうちプレイアビリティと楽しさに関するテストについては、実際にプレイヤー相手にテストしないと意味がない項目だと思われます。しかし、それ以外についてはコンピュータでテストする余地がありそうです。

次のページはそんな話です。ここからが本題！

→ 2.コンピュータで自動テストプレイ！

→ TOPに戻る