プレイシナリオを使ってテストプレイをする

テストプレイのアイデアを一つ。


まずは、僕が中心の物語を。

ドラクエ9の本編を一応クリア。そして、今作では歴代魔王と戦えるらしいというモチベーションだけで、クリア後を楽しもうとしてた僕。攻略wikiを見る限り、戦えるまではそこそこ面倒そうな雰囲気ではある。できれば面倒なことはスキップしたいという思いが頭をよぎる。クエストなんかほとんどやらずにここまで来たのに、どうやら今回は避けられないみたいだ。そして、この記事の存在なんかも思い出す。

なかなかいい機能じゃないか、と思いなおす。RPGにも導入してほしいものだ。
さて、目の前に立ちはだかったクエストである「幻の巨大魚を追え」をクリアするには、まずは以下の装備を手に入れる必要があるみたいだ。

うみなりの杖: 4700G
水のはごろも:18000G
みかがみの盾:30500G

合計43200G。手持ちの金は、えーと、5000Gぐらいだった。目標までは結構遠い。セガサターンを買いたいけど買えない中学生みたいな気分だ。サターンとの違いは、別にこんな装備は欲しくないという点にある。攻略wikiを見れば、金の稼ぎ方なんて自分で考えなくても教えてくれるだろう。金稼ぎのやり方のページをざーっと眺めて、自分に合いそうなのはこれだと思った。

ぬくもりのシャプカ(錬金:防具(頭))

  • うさぎのおまもり(エラフィタ村:240G)、けがわのフード(船着場:550G)、やわらかウール(カルバドの集落:180G)の3つを購入。(合計970G)×99=96030G
  • 購入した3つを錬金し、ぬくもりのシャプカを作成。
  • 店に売れば1つ1200Gで売れる。(230Gの儲け)
  • 1つ自体の効率は低めだが、複数まとめて作れるので元となる資金があれば楽になる。
  • 99個以上錬金で作成できるが、99以上数は増えないのでMAX作成したら必ず売る事。さもないと損をする事になる。
  • 収益率約1.23倍、99個売却で22770G
  • 仲間をルイーダに預けておいて主人公のみで動けば処理が軽くなり効率が上がる。
お金稼ぎ:ドラゴンクエスト9攻略Wiki

とにかく、やるのは、村を飛び回り、素材を買い、錬金し、売りさばいて差額で稼ぐということだ。この単純作業を我慢できるなら、どうってことない。

ところが、やりはじめてみると我慢できない点が出てきた。何かと言うと、錬金は一度に9個までと制限されている点である。そのため、99個の素材を錬金し、99個の「ぬくもりのシャプカ(最後の「カ」をどうしても「力」に読んでしまう」を錬金するには、9×11回の作業をしないといけない。こうなってくると「錬金のアニメーションをスキップできない」という些細なことでさえ重大な欠点に思えてくる。
どうして、いっきに99個錬金できないのか? この制約はどこからできているのか? どんな意図があって9個に制限しているのか? 開発者にとっては、僕のようなプレイヤーには思いつけない合理的な根拠があるに違いない。あるいは、ないのかもしれない。

ドラクエ9に対する不満を書くのがこのエントリの目的ではないし、そもそもまだこのエントリの核心にも到達していない。僕にとって興味深かったのは、「一度にできる錬金は9個までしかない」という不満が、ndsmk2の237件のレビューの不満の中に、1件もなかった点である。でも、google先生で聞いてみたところ、僕以外にも何人かは不満に思っていることが判明した。たとえばここ。そして僕は思った。「何? 今の僕がやってたようなプレイシナリオってそんなにレアなの?」


以上で、このエントリの核心に到達した。ここでいうプレイシナリオというのは、当然、ストーリーでのシナリオとは異なる。ここでは、プレイシナリオというのを、ゲームプレイにおいてあるゴールを達成するための特定のアクション(動作)の流れである、と定義しよう。上記の僕のプレイシナリオは、少し簡略化して書けばこのようになる。

  • ゴール:「幻の巨大魚を追え」のクエストをクリアしようと思っており、
  • サブゴール:そのためにはお金を稼ぐ必要があり、
  • アクション:錬金を利用して、出来る限り効率的にお金を稼ぎたいと思っており、具体的には、
  • サブアクション:所持金の全額を使って素材を買い、
  • サブアクション一度に9個の錬金を繰り返して、素材の全てを錬金し
  • サブアクション:錬金したアイテムを売る、ということを繰り返す。

ゴール要素やアクション要素の対応付けは、やや大雑把ではあるけれど、こんな感じだと思う。僕の不満である「一度にできる錬金は9個までしかない」というのは、このプレイシナリオで判明した不満の一つである。もちろん、このプレイシナリオでなくても同様の不満を持ったプレイヤーがいるかもしれない。


それでは、このプレイシナリオの話を、テストプレイの話と関係付けてみよう。まず、ゲームプレイというのは、このようなさまざまな具体的なプレイシナリオの過程であるとみなせると言ってよいかもしれない。

以下の点が考察できる。

  • (1) あるゲームにおけるプレイシナリオは、プレイヤーによって異なる。プレイスタイルが異なる、といっても良いかもしれない。
  • (2) あるゲームにおけるプレイシナリオは、プレイヤー間で共通あるいは似ている場合がある。
  • (3) ゲームプレイ上の不満は、特定のプレイシナリオを通ったときに判明する。
  • (4) あるゲームに特有のプレイシナリオがある。
  • (5) ゲーム間、あるいは、あるジャンル内のゲーム間で共通あるいは似たようなプレイシナリオがある。

下記の図は項目(1)と(2)を示してる。

下記の図は項目(3)を示してる。

下記の図は項目(4)と(5)を示してる。


さて、テストプレイというものが、単なるプログラム上のバグを検出するような作業(デバッグ)ではなく、プレイにおける問題点や改善できる点を発見する活動であるとすると、プレイシナリオはどのようにこの活動に影響するか。

  • あるテストプレイヤーが、全てのプレイシナリオを想像できるわけではない。そのため、プレイシナリオの抜けが起こりうる。結果として、抜けたシナリオを通れば判明するような不満を特定できないことがある。

もちろん、現実的には全てのプレイシナリオを通ることは困難であるし、各プレイシナリオがテスト対象として同等の価値を持つわけではない。

とはいえ、この問題に関しては、以下のようなアプローチが考えられる。

  • プレイシナリオの明示的な記述、および共有化により、プレイシナリオの想像のコストや不満の取り残しのリスクを削減する。
  • プレイシナリオの共通性にもとづき、プレイシナリオをゲーム間、あるいはジャンル内のゲーム間で再利用する。

つまり、プレイシナリオを明示的に記述し、その記述をもとにテストプレイをするということである。


まとめとしては、このエントリでは、プレイシナリオというコンセプトを考えてみた。また、プレイシナリオを利用したテストプレイ方法というのも考えた。あるいは、小難しく表現するなら、

  • プレイシナリオに基づくテストプレイ手法

というのを提案した。

今後のエントリでは、もう少し具体的にこのアプローチを考えていきたい。なお、このエントリを書くにあたっては、まだ全部読めていないが以下の本を意識しながら書いた。

シナリオに基づく設計―ソフトウェア開発プロジェクト成功の秘訣

シナリオに基づく設計―ソフトウェア開発プロジェクト成功の秘訣

この本では「シナリオに基づく設計」というものが提案されている。

シナリオに基づく設計では、デザイン問題の解決がもつ複雑性を、具象化(concretization)によって管理する。シナリオは使用に関する具体的な物語である。例えば「ある人がコンピュータの電源を入れた。そのスクリーンにはスタートとラベル付けられたボタンが表示された。その人はマウスを使ってそのボタンを選択した」といった具合である。つまり、機能やコードモジュールのリストを積み重ねてソフトウェアをデザインするかわりに、そのソフトウェアが現在あるいは将来実現可能なシナリオを、観測・記述・発想・開発することで、ソフトウェアをデザインするのである。

シナリオに基づく設計

このエントリでは、デザイン(設計)ではなく、ゲームプレイにおけるテストプレイという観点からシナリオというコンセプトを導入した。ゲームデザイン時にもこのようなシナリオの利用は有効かもしれない。