ゴマメのスマタ・第5回・クエスト制

 ゲーム制作エッセイ、第5回はクエスト制のお話です。
 その昔、聖剣伝説レジェンド・オブ・マナというゲームを作りまして、このゲームは体裁上はクエスト制で、クエストが始まるとそのタイトルが表示されていたのですが、じつは内部的には旧来の古臭ーい書き方をしていまして、クエストとしてデータ化はされていませんでした。
 そのため、複数のクエストが重なった場面、だとえば――このキャラはエスカデ編進行中はここにいてこのセリフを話すけど、宝石泥棒編では別のとこに行ってる――などは、条件分岐不能寸前のところまで行ってました。

『クエスト』というのはわかりますかね?
 ゲームで言うところの、『お使いイベント』なのですが、ほとんどのゲームのシナリオはこの『クエスト』の組み合わせで表現されています。
「それじゃあ、ゲームってのはどれも『クエスト制』ってことなんだね!」
 ……と言われると、それは少し違います。
 確かにドラゴンクエストもファイナルファンタジーもお話はクエストで構成されているのですが、『クエスト制』と言った場合にはもう少し明確に、クエスト受領やクエスト実行中にガイドが表示され、クリア時には特別なUIが表示されて経験値や報酬が手に入るもの――を指すことが多いようです。
 ただこの『クエスト制』に関しても明確な定義はなく、今はほとんどのゲームが内部的にはクエスト制の体裁を取っていますので、ここで扱うのは次のようなものだと考えておいてください。

  • お話がクエスト単位で進む
  • クエストはどれから順番にこなしてもいい
  • 請け負ってるクエストはメニューに表示され、クエストの始まりと終わりにも明確な表示がある

 今のゲームはほとんどがクエスト制です。
 クエストが始まると『◯◯に会ってみよう!』などと表示され、マップに示されたガイドに沿って歩いていくとイベントが起きて、達成すると報酬がもらえたりします。
 でも、ほんのちょっと前のゲームはそうではありませんでした。
 村の人に話しかけると、いろんな情報を仕入れることが出来て、その中から『あっちの洞窟に行くと、逃げた盗賊がいるんだろうな』とプレイヤー自身がアタリをつけて行動するしかありませんでました。
 
 こう書くと、クエスト制はヒントに縛られていて不自由で、そうでない昔のゲームには自由度があった、というように捕らえられるかもしれませんが、案外そうでもありません。
 クエスト制のゲームではおおむね目的地が示されていますが、その目的地へ行くまでに仕掛けがあったり、複数のクエストを受けてどの順番で解いても良かったりするので、謎も自由度もしっかりと設定することができます。
 それに「謎なんか解きたくねぇよ」というユーザーも少なくなく、とくにストーリーが盛り上がってる時は多くのユーザーが謎などそっちのけで遊びたいものです。なので基本的にはスルスルと迷わずに遊べるようにしておいて、謎解きを求める人にはサブストーリーでそれを提供する、というのがベターな解決案で、それを実現するためにはやはり、完全でわかりやすいガイドを示すことが必要となるんじゃないかなと思います。

 では、クエスト制のシナリオとそうでないシナリオの一番の違いは何か、という点についてですが、これは『物語が構造化されているかどうか』に尽きると思います。
 クエスト制でないゲームは、朝起きて、王様の話を聞いて、事件の発生を知って、町の人から話を聞いて、洞窟に入るための鍵を手に入れて……というようなエピソードがひとつにまとまって物語になりますが、クエスト制では、

  1. 王様に会いに行くクエスト
  2. 町の人に話を聞くクエスト
  3. 洞窟の鍵を入手するクエスト
  4.  :

 というように、明確にその時々で何をしたらよいか、物語を構成する要素の1個1個がクエストになっています。
 昔のゲームでも、ちゃんと筋道を考えればこの通りになっているのですが、更にこれを徹底して、データ構造的にもそれに倣った実装をしているものが、クエスト制のゲームです。
 ものすごく雑な言い方をすると、スクリプトで実装されているものが旧来の非クエスト制のシナリオ、データで実装されているものがクエスト制のシナリオです。

 クエスト制のシナリオはデータで実装されているので、そのぶんスクリプト(簡単なプログラムのようなものです)の手間が省けて量産が可能で、また、個々のエピソードの中でフラグ操作したりしないので、安全にシナリオを実装することができます。いわゆるフェールセーフな設計となって、シナリオライターが多少ミスしていようとも、それを機械的にトラップすることができるようになります。
 昔はシナリオで出たバグはプログラマーには追いかけようがなく、シナリオを実装したのはスクリプト経験も浅い人、というケースが多々あったのですが、そのケースは少なくなったと思います。(以前はよくやらかしていました、ごめんなさい)
 とは言え、今でもデータ化されてないっぽいゲームもよく目にします。実際のコードでも見るし、遊んだ感触でクエストのデータ構造なさそうだなって感じるものは少なくなく、よくバグもなく組み建てられたもんだと感心してます。

 で、最初に「クエストは『お使いイベント』のようなもの」と書いたのを思い出してください。
 確かにクエストは『お使い』なのです。
 では、クエスト制のゲームはお使いだらけのお使いゲーになるかと言うと、そうではありません。むしろ逆です。
 ほんの少し前、『JRPGはお使いゲーばっかりだ』と揶揄されていたことがありました。――あれをしろこれをしろと指示された上で、どこかに行って、解決して、帰ってくるの連続――で、冒険している感じがしない、と。これはもう、お使いをどんなにドラマチックにしても、内容をどんなに複雑で豊かにしても、そう言われていました。
 では、それに対してじゃあ『お使いじゃない洋ゲー』はどうだったんだ、というと、お使いはお使いだったんですが、その単位がめちゃくちゃ短かったんです。

「族長に話を聞いて来い」

 のような、お使いにもならないような指示が数十個まとまってひとつの物語を構成していたのです。
 たとえばこうです。

  • 族長に話を聞いて来い
  • 族長「成人になったので◯◯を狩って、□□を手に入れてこい」
  • 族長「その□□を呪術師に届けろ」
  • 呪術師「おまえの専用の武器を作ってやった、これで××を倒してこい」
  • ××を倒すと、手紙が手に入る
  • 手紙を族長に持って帰ると、新しい町への旅立ちを促される

 と、このような小さなエピソードが積み重なる中で、背後にうごめく組織の姿が見えてきたり、天変地異が起こったり、というのがいわゆる洋ゲーの基本でした。お使いというよりは、今の自分の状況が文字になって書いてあるもの=クエスト、のような感じですね。

 クエスト制のゲームでは、多くの場合、次にどこへ行くべきかはガイドが示されるのですが、これも昔は、それだと自由度がない、ユーザーは考えずに遊べてしまう、と言われていましたが、実際には逆でした。
 クエストの単位が短く、常にガイドが表示されるのでユーザーは迷わないし、クエストの途中で別のことをやっても復帰できるので、常に好きなことができたのです。クエストも複数が同時進行し、自由だったんです。

 また、クエスト制というと、誰かからお願いされて、解決する、というエピソードの連続で単調なのではないかと思われることもあったのですが、実際にはクエストの起点は、誰かからお願いされる他に、

  • アイテムを拾った
  • 街に入った
  • 何かを調べた
  • 他のクエストを終えた

 などなど様々で、場合によってはリアル0:00になると同時に配信クエストが開始される、なんてケースもあって、決して単調ではありませんでした。

 さて、そんなクエスト制のゲームのシナリオの書き方ですが、難しい言い方をすると、『トリガーに対してどんなカットシーンが発生するかを記述する』という書き方になります。
 たとえば、『王様に話しかけた』というトリガーに対して『ドラゴン退治を依頼される場面が発生』する、など。どういうトリガーに対して何が起きるか、というのを書き連ねていく感じになります。
 その際、どんなトリガーがあるかはゲーム次第で、たとえば『特定のアイテムを捨てた時』とか『メニューの特定項目を開いた時』のような細かいトリガーを設定できるものもあれば、『誰かに話しかけた時と、特定の場所に侵入した時にしかカットシーンは発生させられない』のような大雑把なものまで千差万別です。
「細かいトリガーなんてわかんない、怖い」
 ……と、思われるかもしれませんが、細かく条件を取れるゲームってのは、それだけ予算もかけて基礎が作られ、シナリオ班もしっかりと構成されているゲームだと思われますので、心配せずともチームでサポートしてくれると思います。
 この、トリガーに対してカットシーンを記述する、という書き方だと、クエストデータを最初に用意してしまえば、カットシーンの出来上がりが遅れようともゲームとしてはプレイできるので、制作やデバッグの手を止めずに進められるというメリットもあります。

 今回のお話で重要なことはですね、

「物語は構造を持つ」

 ということですね。
 物語は構造を持ち、データ化されうる。

 でも、「ゲームのシナリオを書くならデータ構造を考えろ!」と言うんじゃないんですよ。
 データは苦手だけどめっちゃくちゃ良い物語を書けるひとだっていますから、そういう人はプロジェクトでサポートしないともったいないので、この、物語をデータへと落とし込む役割の、どのへんを、誰が担うか、ということをチームとして考えて行く、という意識を持つための、今回のエントリーだと考えていただければ幸いです。

Follow me!

コメントは受け付けていません。