『Papers, Please』の「ストレス」を与えるゲームデザインが、なぜ上手くいっているのか
大前氏：
『Papers, Please』も『Obra Dinn』も、どのようなプロトタイプだったのか想像するのが難しいゲームだと思うのですが、アイディアを思いついた段階で「このゲームは成功する」と確信できていたのでしょうか？
ルーカス氏：
たとえば『Papers, Please』の場合は、プロトタイプは「机の上で何も書いていない書類を動かすだけ」のものだったんです。でも、「書類を動かすことだけでも楽しい」ということに気づいたので、これを軸にゲームが作れると確信しました。
それから書類に対して矛盾や問題を発生させることを思いつきましたが、これだけでは、単なる「間違い探しゲーム」になってしまう。そこでプレイヤーが会話できるキャラクターを設定したんです。
対話できるキャラクターが生まれると「このキャラにはこんな書類が作れるな？」という風にどんどんと書類やキャラクターが増えていったんです。
大前氏：
ゲーム性とキャラクターたちの相互作用によってゲームが肉付けされていったわけですね。
ルーカス氏：
そうなんです。でも、この「肉付け」はプロトタイプの段階で物語もゲーム性も決まっていなかったからこそ実現できたものだとも思います。
『Obra Dinn』のときも、最初は船を動かすのに最低限必要な数の乗組員しか、登場キャラを設定していなかったんです。でも、実際にストーリーを構築していくとキャラクターがありえないほど増えてしまって……。
大前氏：
ゲーム制作として考えると、少し怖い手法かもしれないですね。
ルーカス氏：
そうなんです。言い換えると、私の作り方では、制作過程に“謎”があるんです。
その謎の答えがすぐに見つからなくても「必ずそこに何かがある」と信じて、「ここにあるものを使ってどうやったら上手くいくか」を考えることに集中すべきだと感じます。
大前氏：
たしかに『Papers, Please』や『Obra Dinn』を見て、このゲームがどのように作られているのかを想像したときに、これはとてもミステリアスだと感じました。少なくとも、伝統的なゲームの作り方ではないですよね。
ルーカス氏：
おそらくそれは、いわゆる“伝統的なゲーム”の制作過程には、私の作り方でいう“謎”がないからだと思うんです。
伝統的なゲーム作りでは、レベルデザインからキャラクター、カットシーン、武器の種類など、作る要素を最初に仕様として定めますから、「このゲームがどのように構築されているか」をはっきりとたどることができます。
ただし、普通はそうやって作ったほうが見通しは立ちやすいはずです。
大前氏：
実は、2021年にリリースされた『COGEN: 大鳥こはくと刻の剣』というゲームの監修を担当したんです。ディレクター的な側面もあったので、ストーリーや設定にも関わってますけどね。
このゲームはステージ制の2Dアクションゲームだったので、ゲーム制作のプロセスはかなり明確でした。いろいろ実験をしたり、後から実装した機能を削ったりすることはありましたけど、「どういう順番で何を作ればいいのか」ということについて、手探りになることは少なかったように思います。
一方で、『Papers, Please』の「楽しさ」は書類をガサガサと動かして、ハンコを押すことだと思うんですが、それよりもあのディストピア的な雰囲気や、役所仕事的な煩雑さに「ストレス」を感じることの方が多いですよね。
ルーカス氏：
ええ。実際、その「ストレス」は私がプレイヤーに感じてほしいと狙ったものなんです。
大前氏：
あの「ストレス」があることで、実際『Papers, Please』のゲーム体験は大変ユニークなものになっていると思います。でも、一般的なゲーム作りの考え方で言ったら、「ストレス」はできるだけ削るべきですし、あのストレスをゲームに残すためには、本当にはっきりとした理由がなければ難しいと思うんです。
昔ながらのゲームなら、プレイヤーにゆっくり練習させて、慣れてきたら次のステージに挑戦できる。でも、「Papers, Please」では、ゲーム内の日付が変わるごとにどんどんルールが追加されていきますよね。
だから、プレイヤーは「これまでにやったのと違う！」というストレスを感じながら、プレイを続けなければならない。なので、プレイしていると本当に昔ながらのゲームとは全く違った感覚を覚えるんです。
ルーカス氏：
じつは、そこも狙いのひとつなんです。『Obra Dinn』や『Papers, Please』のような実験的なアイディアを軸としたゲームの場合、プレイヤーとは「まっさらな状態」で接することになります。プレイヤーは次に何が起こるかがわかりません。ですから、逆にその期待感をうまく利用することができるんです。
たとえば、『Papers, Please』では「書類をチェックするだけのゲーム」と思わせておいて、急に爆破テロを発生させる。するとプレイヤーの脳内で変化が起こるんです。
大前氏：
プレイヤー自身が思い描いていたゲームとは違うものをプレイしている……と気づかせるわけですね。
ルーカス氏：
そうですね。ただし、私はストーリーとゲームシステムは必ず「セットで実装しなければいけない」と考えています。全てのゲームシステムには理由が必要で、理由もなく「人々を裸にする検査スキャナ」を実装することはできないのです。
「爆破テロが発生した」とか「密輸が発生していて調査しないといけない」とか、ストーリーとゲームシステムをうまくコントロールすることで初めて組み合わせることができるんです。
またその上で、これは私がよく使うトリックのひとつなのですが、ゲーム内のすべてを明確に定義していません。自分自身ですべてを説明せず、プレイヤーの頭の中で物語をくつがえしたり、新たな展開が生まれるように仕向けたいんです。
大前氏：
そのようなトリックはゲーム体験として非常に重要だと思うのですが、プレイヤーをそのような状態にしてしまうデザイン面での工夫があるのでしょうか？
ルーカス氏：
具体的な工夫というよりは考え方となるのですが、その人自身の視点で私のゲームを遊んでもらい、普段感じることや考えることがないような体験をしてもらいたいと思っています。
たいていの人は国境検査官ではないけれど、国境検査官をテーマとして扱うことは私にとっても興味深いことですし、そのゲームを誰かに体験してもらうことはもっといいわけです。
意思決定をするプレイヤーが、どのようにして特定の状況に引き込まれて、どのようにしてその人なりの打開策を導き出すか、ということが重要なのです。
大前氏：
まるで作品を通してプレイヤーと対話しているようですね。
仮に私が同じことに挑戦しようと思った場合に、なにか参考になるルールやコツのようなものはあるのでしょうか？
ルーカス氏：
私の中でも大変参考にしているのは、ノーティードッグで学んだ「フォーカステスト」と「プレイテスト」の概念です。
まず「自分はゲームを作っている」ということ、そして「人々に楽しまれるゲームを作っている」ということに意識をフォーカスしなければなりません……ですが、実際にこの意識を持ち続けることはなかなか難しいんです。
そうして自分が作っているものを客観視することは、ゲーム作りにおいて最も重要な資質のひとつだと思います。自分では素晴らしいと思ったアイデアが、実際にプレイするとなぜ上手くいかないのかを理解する必要があるんです。
これは多くのデザイナーが陥る罠なのですが、その素晴らしいアイデアやシステムのつながりはデザイナーの頭の中だけにあって、プレイヤーの頭の中にはないからです。ですから、デザイナーは自分のアイデアに固執せずに、大胆に変更する勇気を持たなければいけません。
その勇気をもつためにも、やはり客観的に「もし自分がプレイヤーならこのゲームをどう遊ぶだろうか？」という視点が必要になってくるのです。
小規模開発者なら、このような理解と感覚を持つことはさらに重要になってくるはずです。大きな開発会社ならテストチームも用意できますが、小規模では難しいですからね。
大前氏：
ありがとうございます。話が少し戻るのですが、先ほど「すべてを説明しない」とおっしゃっていましたよね。
プレイヤーに伝えるべき情報とそうでない情報を線引きすることは非常に難しいと思うんですが、一体どのようにして情報量のバランスを維持しているのでしょうか？
ルーカス氏：
実際のところ、そこは私も苦労しているポイントですね。
たとえば『Obra Dinn』では、ゲーム内でプレイヤーが知っている情報を把握できるツールを用意しました。
そのおかげで、「プレイヤーが十分に理解できない」と判断したタイミングでヒントを追加したりできるんです。
大前氏：
それは面白い機能ですね。
ルーカス氏：
実際、ゲームデザインにおいて「デザイナーの脳内にあるアイディアがうまく反映できてるのか、そうでないのか」を判断するのはとても難しいんです。
なので、私の場合はツールを利用してデータを視覚化することで、自分が望んでいたものと一致しているかどうかをチェックしているんです。
大前氏：
だからこそ、自分がデザインした通りのゲーム体験が実現できる、ほどよいバランスを見つけ出せるわけですね。
ルーカス氏：
『Papers, Please』の場合も同様で、一日の終わりに発生する収入と支出をデータ化しました。日々発生する情報を精査することで、ゲーム内で重要な経済システムを調整することができたのです。
Web上でゲーム画面を確認できる!? 驚きの自作ローカライズツール
大前氏：
『Obra Dinn』では、ローカライズやナレーションがたくさんあったと思いますが、そのどれもが絶妙でした。ただ、個人的にボイス収録は一種の「引き返せなくなる分岐点」だと感じています。
基本的にはゲーム開発の終盤で収録を始めるのかと思いますが、引き返せなくなるようなことがないように配慮したりされたのでしょうか？
ルーカス氏：
ええ、おっしゃる通り開発終盤で実施しています。ただ、『Obra Dinn』に関してはすべてリモートで収録してもらったんです。
キャストさんがみんな自宅スタジオを所有しているので、仮に修正が必要になっても個別に指示を出すことができる柔軟性があったと思いますね。
また、ゲーム性からして長くても30秒程度の会話しかなく、深いキャラクター性や濃い会話、大きな物語の展開がなかったことも大きかったですね。演出の観点からみれば、“頭部を切断されて叫んでいる男性”や“誰かに怒鳴りつけている男性”の声が必要そうだといったアイディアひとつで完結し、いくつかの手がかりを含んでさえいれば、セリフのクオリティの精度はそこまで重要ではありませんでした。
その一方で、演技力のある声優さんのバリエーションを確保するのが大変でした。ひとりあたりのセリフ数は少ないとはいえ、キャラクター数は膨大でしたから。
大前氏：
なるほど。仕様変更に対する柔軟性を確保したうえで、現実的な味付けもできる、素晴らしい方法だと思います。
この手のアドベンチャーゲームを作るうえで、非常に陥りやすい罠だと思うんですが「何が起こったのかをプレイヤーに直接的に伝えるような説明的なセリフ」ってあまり好きじゃないんです。その点、『Obra Dinn』でのセリフ回しはとても巧妙だと感じたので、気になっていたんです。
ルーカス氏：
ありがとうございます。
大前氏：
それからローカライズについても、多くの工夫が見て取れます。文字だけでなく、ゲーム内のグラフィックやアートワークも翻訳されていますよね？
ものすごい作業量だったと思いますが……実際にはいかがでしたか？
ルーカス氏：
ローカライズ作業は悪夢でしたね（笑）。ただ、苦労してでもやる価値はあると感じました。さまざまな難しい問題が噴出しましたが、それを解決することも面白い作業だった、といま振り返れば思います。
Unityではローカライズ用にアセットを再生成できるパイプラインがありますからね。それを利用して、ローカライズしたグラフィックを含む言語パックを3つ用意したんです。
大前氏：
ご活用いただきありがとうございます。ローカライズを管理するうえでも、何かツールを開発したり利用していたりするのでしょうか？
ルーカス氏：
基本的に自前で用意したツールを利用していますね。それから、会社所属でない個人ローカライザーに協力を仰いだことも大きかったと思います。そうすることで、彼らがローカライズをスムーズに進めるうえで欲しているものや助けになるものについて知ることができたんです。
たとえば『Papers, Please』でもやっていたことなのですが、ゲーム中の選択肢や文章といったローカライズに必要なものすべてを自分の目で確認できるように、ウェブページ上に再現するツールを作ったんです。
大前氏：
すごいですね！ ウェブ上で全て確認できるんですか？
ルーカス氏：
そうなんです。JavaScriptで構築しているので、日本でもアメリカでもイタリアでも、さまざまな国のローカライザー相手にオンラインで完結できます。
大前氏：
ゲームのローカライズで難しいことのひとつは、「ローカライズしたテキストがゲーム内でどう見えるかわからない」というところですよね。その問題も解決できたのでしょうか。
ルーカス氏：
おっしゃるとおりです。
なので『Papers, Please』向けに作成したツールでは、ローカライズされた実際のゲーム画面と全く同じ画面を見られるようにしていました。
一方、『Obra Dinn』はゲーム自体が重かったのでウェブ上では再現できませんでした。その代わりに、文法類をテストできるツールを用意したんです。
ゲーム中のテキストをひとつひとつスクリーンショットして、それを全部ローカライザーに送付するんです。たしか数千枚を超えていたと思います。
翻訳されたCSVファイルが返ってきたら、それをゲームに組み込んでスクリーンショットしなおして、また戻す。そうするとローカライザーが自分でチェックできますよね。
とくに日本のローカライザーは「自分の手で改行したい」と言っていました。そして、この手法なら私の負担になりすぎない範囲で、すべての文章を確認してもらうことができます。
ローカライズ専用のビルドを用意して、翻訳に支障がないようにゲームの遊び方を教える……なんてことをするよりもずっとずっと効率的でした。
AIが教えてくれない「未知の問題への解決策」がユニークなゲームを生む
大前氏：
ルーカスさんはゼネラリストとして活動されているわけですが、AIに関してはどのようにお考えでしょうか？
ルーカス氏：
簡単に答えが出せる問題ではないですが、少なくとも今のところ、自分のゲームでAIツールを使おうとは考えていないですね。
というのも、今取り組んでいるゲーム『Mars After Midnight』では「プロシージャル生成された顔」が軸になっています。もちろんAIを使うことで人間の顔や火星人の顔、ロボットの顔など、あらゆるバリエーションを生成できるでしょうが“AIっぽさ”がどうしても残ると思うんですよね。
たしかにAIはこれまでに見たことのない驚くべきものを作り出すことができますが、いまだ人間による命令（プロンプト）に依存している状態です。その意味では、私が次作で利用しようとしているプロシージャル生成も似たようなもので、人間による「入力」に依存しているわけです。
そこで改めて振り返って重要だと私が考えるのは、「人々の心にどのような感情を与えられるのか？」ということです。「火星人」という設定だけに目を向ければ、他のクリエイターやAIが作る火星人と大差はないのかもしれません。でも、そこには私のクリエイティビティによる差異が、必ず生まれると信じています。
ですから、少なくともいまはAIについて、私は大きく心配していることはありません。私の領域で万能に機能するChatGPTのようなものはまだ現れていませんしね。もちろん、ローカライザーや翻訳者、プログラマーといったさまざまな人たちがAIに仕事を乗っ取られるかもしれない、と危惧しているのも理解できますし、本当はもっと心配するべきなのかもしれませんが……。
大前氏：
では、作業の効率化を図る目的で利用する場合に、ChatGPTなどのAIツールが助けになると感じるでしょうか？
ルーカス氏：
現時点では、AI技術が私の手助けをしてくれるとは感じていません。というのも現行のAIツールは、「既存の問題を解決する」ことに長けているように思えるからです。今のAIは以前から存在する解決策を引っ張ってきて教えてくれるだけなんです。
私は、他の人が解決済みの問題には興味がなく、自身のスタイルとして未知の問題に対する解決策を追求しています。そして、その解決策こそが最終的にユニークなゲームや製品を生み出すことに繋がると考えているからです。
大前氏：
なるほど。結局は「人の手が必要」になるところにこそ、クリエイティビティによる差異が生まれてくると。
ルーカス氏：
そう思います。たしかにAIは手間を省いてくれるとは思いますが、私はそうした手間も含めて解決策を探すような仕事が好きなんです。だから、単純に私の性格的にAIを必要としていないだけなのかもしれません（笑）。
