ゲームデザインの形成プロセスにおけるデザイナとユーザの役割

ゲームデザイン

このエントリは、昨日のエントリである

に関して、昨夜、Twitterで @nsiena と @zakkas783 と一緒に行った議論を自分なりにまとめたものである。

Twitterでの議論はid:nsienaが

としてまとめてくれているので、まずはそちらを参照していただくとよいかもしれない。

議論の始まり

まずは、前提知識の共有を。

NDSのRPGである『世界樹の迷宮』シリーズの特徴としては、タッチペンを使ってダンジョンを自分でマッピングできるという機能（システム）の存在がある。『世界樹の迷宮2』では、この手動マッピングに関して、レビューサイトで「途中で飽きる/面倒になる」というような不満が3件投稿されていた。

  • 序盤場良かったけど、中盤からは飽きる。
  • 最初は面白かったけど、だんだん面倒になる。
  • 前作でもマッピングを十分やったので、早い段階で飽きてしまった。

デザイナーがこの不満に対してできる（できた）こととして、僕は、3つの選択肢が考えられるとした。

  1. 機能をなくすor別の機能にする。マッピングの場合は本当になくしてしまう（マップを表示しない）と不満が出るので、たとえば、自動マッピングにする。
  2. 機能を改良する。たとえば、飽きないように工夫する。
  3. 機能の有無をプレイヤーのプレイ経験に応じて選択できるようにする。たとえば、手動マッピングと自動マッピングに切り換えられるようにする。

僕が推奨した選択肢は、3つめのものだった。これに対して、@nsienaが次のような疑問を投げかけた。

適切な反論である。実際、僕もその可能性つまり「自動マッピングでしか遊ばなくなる」かもしれないとは思った。この発言だけからは読み取りにくいが、@nsienaの選択肢としては、二つ目である「機能を改良する」に対応する。つまり、手動マッピングを楽しめるようなマッピングツールを提供する、ということである。

ここで@zakkas783が、機能改良の方向に関する発言を行った。

  • # 19:00:21 zakkas783: @nsiena ん。方向性としては、"マッピングをしやすくする"UI or 操作を提供するほうが理にかなっていると思います。 ex)L/Rボタンでマップに配置するチップが切り替わるとか >制約による演出
    • 19:29:19 nsiena: @zakkas783 @asatohan ゲームデザイナが何を楽しんでもらいたいのか、ビジョンが問われるところ。マッピングを楽しんだり、迷ったり、彷徨ったりしつつ、迷宮を攻略して行くのを楽しんでもらいたいなら、マッピングをしやすくするんでしょうね。
    • 19:31:52 nsiena: @zakkas783 @asatohan そうでなくて、シナリオを楽しんでもらうとかが主旨で、迷宮とかは演出にすぎないなら。難度の高い迷宮は考え物だし、自動マッピングで他のことに注力させるべきだし。たぶん、どっちも提供ってのは愚作策なんでないかしらん。

また、@zakkas783が、『世界樹の迷宮』シリーズではないけれど、Wizardryを実例に、自身の経験から、@nsienaの予測である「自動マッピングでしか遊ばなくなるような気がする」を裏付ける発言を行った。

  • # 19:02:21 zakkas783: @nsiena Wizardry(日本オリジナルのGB版)で類似した選択肢が用意されたこともありましたが、私は華麗にオートマッピングを選択しました。ユーザーはかくも楽なほうに流れる。
  • # | 19:04:29 asatohan: @zakkas783 ちなみにWIzの場合は、紙に書くか自動マッピングかの選択肢ですか？
  • # || 19:17:11 zakkas783: @asatohan # チョッピリ記憶違い･･･ PC用の｢Wizardry Chronicle｣とか、PSで発売された旧作リメイク｢リルガミンサーガ｣で切り替えができます。
  • # 19:17:19 zakkas783: @asatohan Offにすると、マップを表示するスペルを唱えたとき、｢今パーティが向いている方向･位置｣だけがテキストで表示されるようになり、迷宮内をテレポートするスペルを唱えたとき、｢北へ幾つ、東へ幾つ、上下へ幾つ｣移動するかをスピンで決定するようになります。
  • # 19:18:14 zakkas783: @asatohan Onだといずれも2Dのマップが表示されるようになります(といってもフィールドの罠等は見えない)
  • # 19:19:24 zakkas783: @asatohan 大昔(DOSやAppleII)のころは、マゾいことに切り替えもへったくれもなく、常にOff状態でありました。
  • # | 19:31:21 asatohan: @zakkas783 おー、なるほど、なるほど、参考になります。とりあえず分かるのは、世界樹みたいにシステム的に手動マッピングを支援する、ということではないんですね。これが手動をとるか自動を取るかどうかの重要な要因になるかは分かりませんけれども。

ここまでのまとめ

手動/自動マッピングの例は、議論の実例としては良いかもしれない。だけど、一般化して問題を整理してみよう。

まず、大前提として「あるプレイヤーは、ある機能をプレイ過程で不要に思うことがある」ということが観察できるというのがある。『世界樹の迷宮2』では、ある機能というのは手動マッピング機能に対応する。何人かのプレイヤーから、「プレイ過程でこの機能が不要になり、面倒なだけ」という不満が発生するというのは観察できる事実として先に述べた。

また、この（起こりうる）不満に対処するためにデザイナーができる選択肢として3つあることを示した。

  1. 機能をなくすor別の機能にする。マッピングの場合は本当になくしてしまう（マップを表示しない）と不満が出るので、たとえば、自動マッピングにする。
  2. 機能を改良する。たとえば、飽きないように工夫する。
  3. 機能の有無をプレイヤーのプレイ経験に応じて選択できるようにする。たとえば、手動マッピングと自動マッピングに切り換えられるようにする。

問題は、どの選択肢が適切なのか、ということである。

  • (a) どの選択肢が適切なのかという選択基準は何か。
  • (b) 各選択肢をいかにして評価するのか。
  • (c) 選択において、デザイナーの役割は何か。選択にどのような影響を与える存在なのか。
  • (d) 選択において、プレイヤー（ユーザ）の役割は何か。選択にどのような影響を与える存在なのか。

議論の続き

仮説の設定から、議論の続きを。

  • 19:59:32 asatohan: @nsiena @zakkas783 (2)機能（や難易度など）の有無の選択をプレイヤーにまかせたほうがいい場合と悪い場合があるように見えるが、どのような場合に区別できるかの実証や理論はない（ように思える）。
    • 20:02:20 nsiena: @asatohan 仮説: 「(2-1) ある選択肢が、別の選択肢の意義を失わせる、あるいは、減じさせてしまう効果を持つ時は、競合するものと考え、両方を提供すべきではない」を提唱してみる
      • 20:06:13 nsiena: @asatohan 仮説 (2-2) : 「(2-1)の場合、ゲームデザイナの企図の根幹として、どのような価値・体験を提供することを目指しているのかという前提条件に対して、より適合するものを選択するべきである」も併せて。
    • | 20:07:28 asatohan: @nsiena それはいい仮説。でも、たとえば、（ドラクエ９をイメージしながら）バトルのエフェクトをスキップできる/できないの選択肢だとどうだろう？ スキップできるとアニメーションの意義をなくしてしまうんではないだろうか？ 他にもムービーのスキップは？
      • 20:11:37 nsiena: @asatohan @zakkas783 むぐ、痛いところを。それは、仮説 (2-2) のゲームデザイナの企図に依存する、かな。何がなんでも視覚効果やムービーを見せたい、それが無ければ成立しない、というのであれば強制する。あくまでも演出であるとするなら、飛ばせるべきだねぇ。
        • 20:19:39 nsiena: @nsiena おっと。「(2-2) のゲームデザイナの企図」は、「(2-2) にも見られるゲームデザイナの企図」くらいかな。(2-2) が適用される、というように読めてしまったので訂正。

ここで@zakkas783が補足情報を提供してくれた。

  • # 20:11:54 zakkas783: @asatohan バトルエフェクトが長くてだれる 問題に関しては、FF8がエフェクト中に「応援｣や｢トリガーを引く｣などのアクションを要求することで、｢ダメージup｣などの報酬を与えていた。
  • # | 20:16:35 nsiena: @zakkas783 @asatohan なるほど。一方的に強要されて介入することが許されない、という状況を緩和する、と。プレイヤは、ゲームに対して適度に介入することができれば、少なくとも不満は減じる。一般に、そのアプローチで十分に解消できるようにできるかしら。限界はどこかしら。
    • 20:23:10 asatohan: @nsiena @zakkas783 やっぱり問題はここにあると思う。限界はどこかということと、どうやって検証するのか。現場にいないからあれだけど、実証的なデータが欲しいなあ。＞一般に、そのアプローチで十分に解消できるようにできるかしら。限界はどこかしら。

僕として、読み取れるのは以下である。

  1. 選択基準を見つけるために、仮説を設定していくアプローチは、最初の試みとしては、たぶん有効である。
    1. ただし、仮説の検証は容易でないかもしれない。
  2. 選択には、ゲームデザイナの企図が関わる。つまり、ゲームデザイナは、ユーザの要望をそのまま受け入れるような存在ではない、という位置づけが重要であるかも。

2つ目については、次のような議論になった。

  • # 20:19:10 asatohan: @nsiena とすると、言い方を変えただけかもしれないけど、ゲームデザイナが根幹として何を目指しているのか提供したいのかというのが、デザインを部分的に形作ると。そしてその部分の形成には、ユーザは参加できないと。
  • # | 20:22:22 nsiena: @asatohan @zakkas783 うんうん。ただ、部分的にとういうか、むしろ、デザインの支柱を定める、くらいに考えてる。デザイナの、これをやるべきだ、という強いメッセージが反映されるところ。それを失ったら、企図のレベルでの変更になっちゃう。違うかなぁ。
    • 20:36:50 asatohan: @nsiena あるいは、戦略としては、たとえば、デザイナーの根幹的な企図自体も、最も大きな可変性or選択肢として考えてはどうか。たぶんいわゆるソフトウェアプロダクトライン的なアプローチ。「デザイナーの目指したゲーム」と「デザイナーの目指さなかったゲーム」の二つを提供。
    • | 20:39:12 nsiena: @asatohan @zakkas783 それはありえると思ってる。元の企図に固執し過ぎては失敗する可能性も高いから。ただ、その場合は、似て非なるゲームをデザインしていると考えるのでいいかなー、と。 *1
    • 20:41:13 asatohan: @nsiena @zakkas783 まあでも、プロダクトラインは無理かなー。「手動マッピング強制orデザイナーの提供したいゲーム」と「自動マッピングorデザイナーの提供したくないゲーム」があってユーザが選択するとしたら、どっちにしろ後者が選択されるか。
    • 20:44:15 asatohan: @nsiena @zakkas783 ゲームを細かな機能orフィーチャに分割して、フィーチャのある組み合わせを一つのゲームとしてユーザに提供するのが困難に思える点に、ゲームの独自の特性があるように思える。気のせいか。
  • # 20:21:29 zakkas783: @nsiena @asatohan 特にコンシューマゲームでは"ワンショット"なので、ユーザーからのフィードバックは次回作でなければ反映できない、というメカニズムがあるため、ゲームデザイナの意図が大となる部分が多いでしょうな。
  • # | 20:29:17 asatohan: @zakkas783 @nsiena テストプレイヤー「・・・・・・」＞ユーザーからのフィードバックは次回作でなければ反映できない

※1 id:nsiena：「二つを提供」を読み落として誤読してた。デザイン上の意思決定対象に含めるという意味で「可変性or選択肢として考え」るけれど、「二つを提供」することは意図してなかった。

さて、僕として、読み取れるのは以下である。

  • ゲームのデザインの形成というプロセスにおいて、デザイナーがどこまで関与するのか、ユーザ（あるいはテストプレイヤー）がどこまで関与するのか、ということの理解が必要かもしれない。
    • デザインの全てがデザイナーにより形成されるべきではないかもしれないし、同様にユーザだけで形成されるべきでないかもしれない。
    • ゲームとはどのような人工物なのかという理解が、このデザイナーとユーザの関与のバランスを決める要因になるかもしれない。
  • デザイナの提供したいゲーム（デザイン）とユーザの要求するゲーム（デザイン）の間にはギャップが生まれる。これはある意味当然。
    • デザイナの提供したいゲームは、デザインのバリエーションの一つである。各ユーザは、自身に適したデザインのバリエーションの一つを要求・望む。
    • ゲームという人工物に対して、ゲーム開発技術・手法により、いかにしてバリエーションを管理できるのかという課題があるかもしれない。

終わり

以上、僕視点でまとめてみた。なお、このエントリで触れなかったけど、Twitterでは、他にも興味深い議論をやりとりしてたのでid:nsienaのまとめである

も合わせて参照していただきたい。