デザイナーダイアリー：「ハムレット」(Designer Diary: Hamlet: The Village Building Game)
本記事は、BGG上に掲載されたDavid Chircop氏とJohnathan Harrington氏の記事である「Designer Diary: Hamlet: The Village Building Game」の翻訳である。
日本語版が発売されることが発表された「ハムレット」に関するデザイナーダイアリーである。まず、David Chircopは本作品のデザイナーだ。代表作として、「The Pursuit of Happiness」や「ペトリコール」がある。Davidは、ボードゲームだけでなく、ビデオゲームの開発にも携わっているようだ。現在は、自身の会社であるMighty Boardsの経営者でもある。もう1人のJohnathan Harringtonは、本作品のデベロップを担当している。あまり詳細な情報は見当たらないが、Mighty Boardsの「Posthuman Saga」や「Vengeance」の製作に携わっているようである。
本記事の特徴的な点は、デベロップ担当者であるJohnathan Harringtonによる詳しめのデベロップ過程が述べられていることに尽きる。ゲームのデベロップについて興味がある人にはうってつけの記事であろう。
元記事は以下のリンク先を参照されたい。ヘッダー画像は、BGG上にアップロードされている箱絵を引用させていただいた(クレジット: @Rraiji)。
この投稿には、2つのダイアリーが含まれている。1つは、「ハムレット」のデザイナーであるDavid Chircopのもので、もう1つは、このゲームのデベロップ担当のJohnathan Harringtonものだ。この記事の目的は、デザインに対する2つの異なる視点とアプローチを示すことである。
この投稿の初めから終わりまでに、ほぼ時系列で「ハムレット」のプロトタイプの写真を散りばめている。だから、ゲームが発展し、大釜の中でぶつかり合うにつれて、どのように変わっていったかを全てみることができる。楽しんでくれ！
直近の更新：Kickstarterの支援者たちに向けて「ハムレット」の発送が始まった。そこで、「Hamlet: Founders' Deluxe Edition」は、SPIEL '22(※いわゆる今年のエッセンシュピールのこと)において、数量限定65ユーロで購入することができる。
デザイナーダイアリー：空間感覚に関すること
ゲーム製作にちょっと手を出し始めた頃から、村を発展させること(a village builder)は、常に、私にとって形作るのに魅力的な素材(prospect)だった。成長期における私のゲームに関する体験は、概ねRTS(※リアルタイムストラテジー)というジャンルに深く根付いている。まさに「The Settlers」、「エイジ オブ エンパイア」、「ウォークラフト」のようなゲームだ。間違いなく、私はこれらのゲームを愛してやまないが、私が最も愛していたのは、戦闘やテックツリーではなかった。最も愛する部分は、町役場と数人の農民が提示される冒頭の20分間で、ゼロから物事を形作り始めるところだった。
ワーカーの管理、ワーカーの移動、あとはワーカーが長い距離を歩きすぎないように森に近いところに木こりを配置するといったことを楽しんだ。あまり考えないで、必要に迫られることもほとんどないまま、自分の村が自ら組織化し始めるという営みを楽しんだ。要は、お互いに隣り合った家、木材製造エリア、採掘エリア、後で拡張することができる場所に配置された農場といった感じだ。これら全てにおいて、マップのランダム性、エリア間の距離感覚、エリア間の分離、メカニクスの必要性、非常に系統立った物事に対するちょっとした欲望がメカニクスの必要性と組み合わさって、最終的に、"場所(place, ※空間と訳してもいいかもしれない)"を生み出すことができた。ユーモアがあって、馬鹿で、子供じみていて、品性を欠いているけど、物知り顔な小学校高学年(tween)だったDavid(私)が、後に愛称を付けるような場所である。
その後、少し離れてみて(zoomed out)、自分の村が活動しているのをただ観察することにした。村人が、かわいらしい建物から別の建物へ物を運びながら歩いている。
これが、私が気に入っていたところだ。他の村を発見すること、より強い軍隊を作るための競争、防衛とそれに乗じた(opportunistic)反撃といったようなゲームによくある他のアーク(arcs, ※盛り上がり要素といった意味で捉えておけば足りる。)は、個人的にあまり重要ではなかった(secondary)。私は、村を稼働させた状態に持っていった後に、セーブしたところまで戻して、もう一度始めることで、再度村を発展させて、今度は何ができるかをみることが多い。
長い間、個々の建物という要素と道路を手で置いていくという要素を実験していた。これは、(※メカニズム的には)機能するが、かなり手間がかかるし、机にぶつかると容易に全てが台無しになってしまう。この時点では、共用の村というコンセプトはまだない。
これこそが、「ハムレット」の根底にある最大のひらめきといえる。きついAAAゲームの作業がありつつ、断続的に4年間のデベロップ作業を経た2021年3月、私は出版したいと思う「ハムレット」を製作することができた。2021年10月までに、このゲームの"完成"版と思えたものができた。このゲームは、バランスが取れていて、引っかかるところがなく(smooth)、合理化されていて、短時間で、競争要素があって、ルール説明が簡単なもので……最高にみえるじゃないか。このゲームには、村づくりを行う優れた人を育てるという要素があった……。うん、もちろん、"でも"と続くんだ。
2021年11月、「ハムレット」のKickstarterを延期することにした。アートを作り直したかったし、映像にもう少し時間をかけたかった。(※キャンペーンの)ページだって洗練させたかった。私は、完成だとして終わらせていたゲームが、ある意味で十分に満足できる出来とは思わなくなった。Kickstarterのおかげで手に入れた追加の数か月を使って、腰を据えてその原因を解き明かすことにした。
デイヴィッド・リンチの著作「大きな魚をつかまえよう―リンチ流アート・ライフ∞瞑想レッスン」において、当初のアイディアに専念すること(servicing the original idea)に関する彼の主張を思い出す。製作は、必ずしも"最善の"決断をするわけではないが、まずもって当初のアイディアを活かす形の決断をする。ゲームや映画のような、削減と抽出(reduction or distillation)が伴う創造的な過程を必要とするメディアにおいては、こういったひらめきを固守すること(adherence to the inspiration)は、より重要となるだけでなく、押し通すことが難しいものとなる。
Kickstarterが遅れたことで与えられた追加の時間を使い、Mighty Boardsのオフィスにある"ハムレット"ルームに閉じこもって、数週間、座っていた。ほとんど誰とも話さなかったので、奇妙な時間を過ごした。それに、みんなは邪魔になるのを怖れていたと思う。その時、ゲームを遊べた人たちと考え、数回の議論を重ねた後に、私の親しい友人たちや仲間のデザイナーであるGordonと深い議論をした結果、その問題を突き止めた(pinpointed)。合理化と無駄な部分の削減を行なったある時点までは、「ハムレット」はどんどん改善されていったが、"場所"を作るのをやめてしまっていた。分かるかと思うけど、私が愛称をつけていたような場所がなくなっていたわけだ。
ある時点までは、「ハムレット」は、限られたスペースを使い切る(consuming)というテーマの素晴らしいゲームだった。そのため、建物はそれを反映している。
愛称のある場所
こんなことが起こった理由を解明することはそれほど難しいことではなかった。このゲームを合理化していく過程の中で、このゲームにあった距離制限の大部分を削除して、多くのぎこちない部分(clunk)を取り除いた。こうすることで、全てのワーカーが、かなり簡単にほぼどこにでも行けることになり、お互いに隣接してないと効果が発揮されない建物の重要性を落とすことになった。もし、どこに置くかが重要ではないとすると、魅力的な空間パズル、様々なタイルと建物、それらの効果の種類の多さをもってしても、ほとんど象徴的(symbolic, ※ただあるだけくらいの意味合い)になる。空間感覚は、"どこに"という問題から生ずる。これをどこに置こうか？ 木材はどこにあるのか？ もし、そういった"どこに"が重要でないとすれば、場所は存在しないこととなる。
移動は、ボードゲームのメカニクスにおいて最も古く、最も基本的なものの1つであるようだ。それに、移動は、修辞学的に(rhetorically, ※表現方法としてくらいの意味合い)最も効率的なものの1つでもある。ある場所から別の場所に駒を移動させる。このことは、誰もが馴染みのある、はっきりとしたイメージを生成する。また、このことは、残念なことだが、特にユーロゲームにおいて最もイライラするものとなることが時々ある。
ボードゲームにおいては、実際の空間を区画にして抽象化することが多く、頻繁に駒を動かすことによって、計算の練習に発展することがままある。このことは、"1つか2つの空間に動かすことができる"というように、数個の空間に制限されていれば、問題ない。それに、このことによって、テーマに合致する時間や空間をはっきりと描くこととなる。「イスタンブール」における店から店への移動、「マンション・オブ・マッドネス」における邸宅内の部屋から部屋への移動なんかがおそらくそうだ。また、エリアコントロールゲームにおけるもっと大きい空間、街から街へ、エリアからエリアへにおいても当てはまる。
しかし、それらの中間はどうだろうか。
以下が、その私の思考過程となる。
リソースがテトロミノで、プレイヤーが望む建物を建設できる時のものだ。これは、ちゃんと機能するゲームだったが、私がこのゲームを作っているのと同時期に、とても似たようなゲームが販売されたことから、見送ることにした。
ワーカープレイスメントは移動のない横断である
私は、いつも、ワーカープレイスメントがこの移動の問題に対する自然な反応となっていると推測している。ワーカープレイスメントの古典的傑作のほとんどは、私が「ハムレット」で生み出したかった場所の大きさに近い空間を精密に示していた。「Stone Age」、「Caylus」、「アグリコラ 」が思い出される。これらのゲームは、移動を省略し、制約を変化させつつ、場所と場所との間の距離というよりも空間の"支配"をすることで横断を見せてくれる。「ハムレット」には距離が必要だった。実際、移動それ自体よりももっと距離を必要としていた。そのほかに(必要なものは)何があるだろうか。
次に考えるのは、ロンデルやマンカラのゲームがある。これらは、わずかな移動の要素を再導入したワーカープレイスメントゲームだ。それに空間を数える算盤(abacuses)を巧妙に避けるための制限がある。これらのゲームは、素晴らしい中間の落とし所といえ、大抵の場合、制約が伴う距離感を示す巧妙な方法となる。しかし、これらのゲームは、可能となるアクション間の順序と距離が注意深く計算された上で、重くデザインされて厳しいシステムとなる。「ハムレット」は、主として、全ての村が完全に異なった箱庭ゲームであり、建物の場所は全て新規に出現する経済(emergent economy, ※新興経済が直訳であるが、プレイヤー同士の村で作られる経済くらいの意味であろう。)とプレイヤーの配置に係る決断に基づいている。
こういった種類のゲームは、通常、先行きが見通せない(opacity of plan)という問題もある。こういう場合、一連のアクションを正しく計画していくためには多大な努力を割く必要があり、結果として、移動/アクション選択のメカニズムがかなり前面的に出てきて重点が置かれることになる。「ハムレット」では、移動が重要となるが、新規に出現する経済、格子状にはなってないが有機的な村づくり、空間パズル、道といったかなり多くの移動する要素が既にあるので、計画の見通せなさを動かすことはできない。
この時点で、直接的ではない、空間を制限する"能動的な(active)"モードに目を向けた。おそらく、ゆっくりと構築できるように、計画が少しでも明確になるように、中くらいのサイズの空間が意味をなすようにと。私が目を向けたのは、鉄道ゲームやネットワークビルドのゲームだった。
「ブラス」や「Steam」といったゲームは、「ハムレット」でいうところのワーカーといった"能動的な"要素を用いることなく、ゆっくりとしたネットワークの発展を通じて空間感覚を実現している。そして、結果的に、そのネットワークを通じて商品の移動をしている。
これが新しいタイルを用いて作った最初のプロトタイプだ。とても気に入っていたよ。
ロバの導入
「ハムレット」という非常に固有のケースにおける解決策は、多くの偉大なデザイナーがワーカープレイスメントを思いついた際に、過去に実践してきたように、移動とアクティブな要素を切り離すことだった。そして、より受動的でゆっくりと構築するように、空間感覚と移動感覚を導入するこにした。
今では、「ハムレット」には、村人とロバという2つの異なるワーカーがある。村人は、素早く能動的にアクションを行って、障害や制約を減らすことで生まれる、スピード、敏捷性、選択の明確性といったあらゆる良いことをもたらす。ロバは、ゆっくりとしたネットワーク構築を行い、リソースを移動させる。そうして、ゆっくりと長期的な計画の立案や距離感覚から素晴らしいものが生まれる。
そうすると、この2つのシナジー(synergy, ※相乗効果)は、「ハムレット」における戦略だけでなく、頭の中にレトリック(rhetoric, ※独自の表現といった意味合いかと。)を形作る。村人の直接的なアクションは、資源を運搬するために構築し、洗練させ、完遂させるのに必要なロバのネットワークに左右される。そして、ロバのネットワークを成長させるには、村人の進出・拡大を支援する(fund)ための効率的な村人のアクションの計画立てによって左右される。こうすることで、満足できて徐々に発展する成長サイクルが形成されて、突然、タイルの配置が活気ある村へと変貌した。そして、それは私が愛称をつけることができるものだった！ 今回は、より創造性のある名前にしてみようか。
"DAVIDTOWN"だ！ なんて創造的な名前なんだ。
ここから先は、Johnにバトンを渡すことにしよう。私のデザインに対するアプローチとこのダイアリーは、かなり実験的なものとなっている。だから、Johnには、どのように私が創り上げた体験がゆっくりと洗練されていって今あるようなものになったかという過程に関して、もっと技術的な分析について口出しをしてもうようにお願いした。
David Chircop
・・・
デベロッパーダイアリー：労働安全衛生庁承認済み、正常に作動する「ハムレット」
Davidの明るい口調に騙されないようにしてほしい。彼は、大変多くの労力を「ハムレット」に注いだんだ。彼は、とても複雑で、その上に洗練された形でゲームの大理石を彫り出したんだ。結局、このプロジェクトに私が関わるようになった時には、やるべきことはその大理石をなめらかにして、輝かせることだけだった。このパートで話したいことは、そういうことになる。「ハムレット」のデベロップ過程における、私のテストプレイのプロセスを示して、私が上手くいったと感じたこと、若しくは上手くいかなったのであろうことを話すことになる。
ゲームのデベロップには多くのことが投入される。そして、外部のテストプレイは、ゲームデベロップの重要な部分に当たるのは間違いない。単にテストプレイを過剰に行い、成功を祈り、最終的に最善の結果が得られるようにと願うことに心を誘惑されかねない。しかし、多くの場合、これは非生産的だと思う。もっと重要なのは、各テストプレイで、答えられる質問をすることだと考えている。つまり、(他の人たちが回答者がその質問に答えられるように手助けできるように)質問を短くして、後から見てわかるように/文書化できるようにしておくことだ(もし、回答が曖昧/推測/大げさすぎて記録することができなかった場合、おそらくもっと良い質問があるはずだ。)。この投稿では、私(やMighty Boardsのみんな)が、どのようにしてテストプレイを最大限活用しているかを示すことができるといいなと思っている。
はじめに
「ハムレット」の外部テストプレイを3つの段階(waves)に分けた。テストプレイを段階別に分けることで、かなりの数のことが達成される。まず、作業量のマネジメントが可能となる。つまり、"とりあえず、テスト、テスト、テストが必要なんだ！"と言っても、最終的なテストが見えてくるわけではないし、そんなこと言われるだけでは達成不可能だ！ それってただの威圧じゃないか。2つ目に、各段階で固有の質問ができるようになる。そうすれば、(質問に答えてもらうという)目標が得られるだけでなく、終わりの形も見えてくるようになる(テストは、十分な回答が得られた段階で終わる。)。3つ目に、一括して大きな変更をすることができる。このことは重要だ。変更をするたびに質問と回答の両方に影響がある、つまり、テストプレイヤーの提案や懸念を適切なタイミングで(修正したデベロップバージョンの中でフィードバックを反映させて)処理することができる。それに、(次の変更は、ことテストの段階が終わるまでに施さないといけないから)自然に締切が与えられることになる。その結果、テストプレイとそこから左右される部分(例えば、デザイン変更、製造、グラフィックデザインとアートなど)の両方にマイルストーンを置くことになるので、プロジェクトがもっとマネジメントしやすくなる。
この記事から受ける印象ほど私たちは系統立てているわけではない。だから、これらの段階は、絶対にそうでなければならないわけではない。しかし、これらの段階については、それなりに正確に表されていると思う。さらに、この記事では外部のテストプレイだけを載せている。私は、一人で(たくさんの回数)このゲームを遊んだし、David(このゲームのデザイナー)やNick Shaw(ソロモードのデザイナー)もそうだった。その上、今までに、Mighty Boardsの全員(それに、隣の会社の友人や家族)が、「ハムレット」の何個かのバージョンをプレイしている。この投稿から得られる結論の中には、こういった内部のテストプレイヤーに対するものもある。けれども、マーケティングマネージャーから、この投稿は15分以内に読めるようにするよう言われてるから、外部のテストプレイについてだけ話すことにするよ。
さて、次のように、テストプレイを3つの大きな段階に分けた(各段階には小さい項目(tides)がある。)。
フォーカスグループ(※マーケティング・リサーチで、情報を収集するために集められた顧客のグループ)の段階
- 感情
- バランス
多人数の(mass)段階
- コンセプト
- 壊れてないか
ブラインドの段階
- ルールブック
- プレイしやすさ
フォーカスグループのテスト
内部のテストプレイを済ませると、会社の外部にいるプレイヤーに連絡をし始めることとなった。「ハムレット」は、アートの大部分がなくてルールも暫定的などといったまだ初期の段階であったことから、その影響の範囲を小さく(※声をかける範囲を小さく)していた。このゲームはまだ未完成だったので、大きいグループの人たちに、このゲームに対する悪い印象を与えたくなかった。そこで、知っていて信頼できるグループであることにこだわった。そして、回答してほしかった質問は2つあった。
最初の質問は、"このゲームはバランスが取れていると感じるか"というものだった。そして、質問を扱いやすくするために、"教会は多く与えすぎているか/少なすぎるか"とか、"どの旗を立てることが、平均的に最も多くのスコアを得ることになるか"とかといった個々の要素ごとに分割した。テストプレイ中にその場で用いることができるエクセルシートを準備していた(私たちはこういったテストプレイのセッションでプレイをすることがない。観察して、セルを埋めて、考え込むようにして首を縦に振るだけだ。)。
そのエクセルシートには、各ラウンドのワーカーの各アクションを記録する。そのアクションによって何点得られたのかとか、各アクションは何回選択されたのかとかを記録する。バランスの観点からすると、プレイヤー間のポイントの効率性、アクション間のポイントの効率性、初期のワーカー投資から得られる機会費用、その他の多くの指標を計算することができるようになるので、このシートを準備しておくことは本当に喜ばしいことだ。この段階で、内部でゲームを遊んだだけでは判明することがなかった多くの数値が変わった。各プレイヤーは、自分の方法論を守りがちなので、駒を動かす手番を追加で設けることで、どの数値を上げ下げする必要があるか分かるようになった。同じ段階で小さいアップデートを行うこともできるようになった。初回のテストプレイにおいて、旗を立てることが強すぎるのであれば、コストを少し上げたり、最終的な得点を少し減らしたりすることができ、その後、どうなるかを見ていればいい。個々に旗を立てても、全体的な結論が混乱するわけではないが、それでも、こういった小さな変更は、多くの人たちに見てもらうよりも前に小さなことを把握する機会を与えてくれた。とはいえ、個々の変更は、社内の変更履歴やフィードバックフォームで記録されていることから、その変更の経緯を追うことができる。突然何かが発生したら、原因が何か分かるようになっている。
2つ目の質問は、"このゲームをプレイしてどんな感情になったか"というもので、同じように質問を扱いやすくするように分割すると、"ロバについてはどう感じたか"とか、“つなぐことについてはどう思ったか"とか、"ゲームの長さはちょうどいいものだったか"とかといったものとなる。ここでもエクセルシートが役立つ。例えば、良いと感じたり直感的に理解できたりしたアクションと、選ばれたアクションの回数との間には明確な相関関係があった。このことは、文字どおりに当たり前のように聞こえるかもしれない。もし、建物を建築することが良いと感じたら、プレイヤーはそれを繰り返すだろう。しかし、そのアクションが選択された回数が増加することで、その後のテストにおいてアクションが良いと感じられ始めたかどうかを把握することができるようになるので、数値を得ることには価値がある。
また、プレイテスト後の議論だけでなく、Googleフォームを通じてテストプレイヤーからフィードバックも集めた。正直に言って、これを受け取ることでかなり驚かされた(floored)。この時点でのテストプレイの過程では、内部のテストプレイの感覚と外部のテストプレイの感覚が一致しないことがことが多いので、大幅な中断を余儀なくされるなが普通だ。内部のテストプレイは、よく知っている人たちに行ってもらう。そうすると、グループではなく人に対応することから、ルール説明はかなり容易になる。その上、ボードゲームの企業に勤める人たちは、ボードゲームをプレイすることに非常に熟知していることが多い。したがって、ゲームの重さに対する寛容さ(tolerance)の程度は、外部のテストプレイヤーに比べると広いものとなる(※原文は、寛容さは外部テストプレイヤーほど広くないとなっているが誤記と見て翻訳している。)。最後に、内部的には、コミュニケーションへの耐性が大きくなって(※コミュニケーションを厭わなくなって)、みんなが理解してくれるようになる。外部テストプレイヤーは、常に、ゲームに対する意図を汲んでくれるとは限らない。
「ハムレット」は、既に目標とすべき1つの大きなことを成し遂げていた。それは、エッセンシュピールにおいて初期段階の内部検討バージョンを公開していたことだ。それが良かったのか悪かったかについては、他の誰かに議論してもらうことにしよう。それを行って良かった点としては、会場の人たちにデモバージョンを見せている間に、このゲームに対してどのような感情を抱くかについて、既にかなり多くの情報を得ていたことだ(数値については、それほど多くの情報は得られなかったけど。)。しかし、つながりに対してプレイヤーが抱く感情の骨子は明確だったし、このフォーカスグループを始める前に、何が機能して何が機能しないかについて、既に良い考えが得られていた。
多数人グループのテストプレイ
この段階で注目していた最初の質問は、"プレイヤーは「ハムレット」を体験していたか"だった。この質問はかなり曖昧のように思われることはわかっているが、説明させてほしい。
当時、「ハムレット」は、私とDavidが一緒に取り組んだ最初のゲームだった。彼はかなり才能のあるデザイナーで、私はデベロップ全般についてそこそこできる人間だと思う。しかし、それでも、プロジェクトでは頻繁に行き詰まってしまった。彼は私に面白いデザインを提供するが、明確に逸脱したデザインだった。あるバージョンにおいて、私は、追加された経済要素を徹底的に整えた。別のバージョンでは、私は異なるバックビルドのメカニズムを提案した。別の機会には、個人プレイヤーボードのアイディアを語りながら断続的にプレイした。そういった感じだ。
私が取り除き、彼が他の何かを付け加えることをn回した後で、私たちの問題はコンセプトに関するものだということが明確になった。デベロップ担当として、私は「ハムレット」が機能的に動作するゲームになってほしかった。公正で、公平で、覚えやすくて、ルール的にとがったところ(overhangs)がないなどだ。しかし、デザイナーであるDavidとしては、「ハムレット」に関して構想を持っていた。彼は、共有とか、街が大きくなるにつれて物流が難しくなるような不規則に広がった街とか、全てが起こるべく時に起こるような有機的な成長とかをテーマにしたゲームを作りたかった。Davidが何とかこの構想を伝えることができた場合にのみ、私たち双方が喜ぶようなバージョンが完成できると思う。その時からずっと、デベロップ作業は本当にスムーズに始まるようになり、数値やゲームの流れといった簡単なほうの物事に集中できるようになった。
ということで、最初の質問はかなり明確なものとなった。ようやく私はDavidの意図を理解したが、外部のテストプレイヤーが「ハムレット」を手に取り始めた際に、果たしてその人たちもDavidの意図を理解できるだろうか。そういったDavidの意図が十分に伝わるように整理し、そういう体験に導いていれば、プレイヤーはそれぞれ自身の目標(ロバ、道路、精錬、建設など)を持っているかもしれないけど、不規則に広がる街によって課される負担を管理しながら、それら全ての要素について共用の共通ボードに楽しみを見出してくれるだろう。最初は、この点に関するフィードバックを得るのはやりにくかったが、最終的にはかなり有益なデータを収集することができた。
私たちが重視した2つ目の質問は、"どこかしらの点においてゲームが壊れてないか"だった。ゲームは、本当に劇的に壊れる可能性があるが、より微妙な方法で壊れる可能性もある。時として、このゲームはプレイ不可能な状態に陥ることがあった。「ハムレット」の初期バージョンは、プレイヤーが非協力的に(antisocially)プレイするとお金を得ることが不可能になるというゲーム状態があった。これは望ましくない状態だったが、ありがたいことに非常な早く気づくことができた。
しかし、時々、ゲームの状態が単純に楽しくなくなることもあった。ゲームがあまりにダラダラと長引いていないか、適切なペースでリソースをゲームに投入しているか、もっと多くのワーカーを追加することで望ましくない形で精神的な負荷が生じていないかといったものだ。これら全ては、ゲームにひびを生ずるものだが、収入を得る方法がないということがパンクしたタイヤに相当するならば、単純に楽しくない状態になることはむしろスローパンク(slow puncture)に近い。要は、空気が抜けているが、そのタイヤをかなり長く使った後でないと気づかないという種類のものだ。ゲームからゆっくりと空気が抜けているかどうか確かめる最善の方法(多分、唯一の方法)は、ストレステストである。つまり、タイヤがパンクするまで、できる限りあらゆる人たちとできる限り多くのゲームをプレイすることだ！ 外部のテストプレイを用いて達成したかったことはこういうことだ。この点は、非常にうまくいった。
ブラインドでのテストプレイ
ブラインドでのテストプレイの間に、関心を向けていた質問は2つある。最初の質問は、"ルールブックが理解可能なものか"である。「ハムレット」は核となる部分では単純なゲームだが、型にとらわれないメカニズムとプレイヤーの相互作用によって複雑になると思っている。優れたルールブックは、特に「ハムレット」において最重要なものとなる。優れたルールブックは、3の重さのゲームを2の重さのゲームに感じさせてくれる。もし、プレイヤーに対して核となる体験を明確かつ効率的に伝えることができれば、どんなプレイヤーもゲームを満足して遊ぶことができる(hold their own)と心から信じている。
ブラインドでのテストプレイの間に答えてほしかった2つ目の質問は、"ゲームプレイ中にリマインドする必要のある情報があるか"というものだ。これは、既に目を光らせていた事柄だが、私たちがテストプレイの場にいるという話の中(within the context of)だけのことだ(だから、(※その場で出た)質問には簡単にかつ簡潔に答えることができる。)。私たちがいない時に何が起こるか。プレイヤーは、容易に質問に答えることができるか。私たちはルールにとがったところがほとんど存在しないと感じるけれども、他人が同じように感じるかどうかを計測するのは良いことだろう。ボードゲームは、根本的にコミュニケーションが中心となる。ブラインドテストは、我々が(まだ)みんなのリビングに物理的にいなくとも、このゲームのデザインを伝えることができるかを確認するのに資するためにある。
この2つの質問に関して、新しいフォーカスグループを集めて、デザイナーである私たちにとって最も過酷なことをした。つまり、黙ったまま彼らにプレイをさせたんだ。最初の場面では、彼らが箱を手に取った瞬間から黙らなければならない。ルールブックを取り出して読んでもらって、彼らの学習過程を測定する。私たちは、彼らがルールブックに書いてあることを誤って理解してないか、(テストプレイ後のアンケートを通じて)どんな表現が誤解を引き起こしているのかを分析するために注目していた。第2の場面として、彼ら自身にルールブックを読ませるが、生じた誤解を明確化していった。そして、テストプレイ中、私たちは黙ったままでいて、ゲームプレイ中にどのルールが無視されるかをみることとした。
これまでのテストプレイの段階とは異なり、この2つの場面は、潮の満ち引きのように相互に関連している(these two tides ebbed and flowed with each other)。特に販売が差し迫ってきたボードゲームは、レビュアー、出版社、他のデザイナー、他のデベロップ担当者、更にはディストリビューター(※卸業者と理解して差し支えない。)といった多くの人の手にわたる。こういった関係者たちはそれぞれ異なる方法で取り上げたいと思っている。純粋に混じり気のない形の体験(※ルールの誤解などがない形でゲームを遊ぶ体験)をしたい人もいれば(そうであれば、私たちはその場を見てもいいかどうかを尋ねている。)、自分自身で理解したいが、未完成のもの(この場合、ルールブックのこと)にそこまで多くの時間を費やしたくないという人もいる。ブラインドテストにおける2つの場面が過ぎ去ったからといって、私たち自身が(明確性や記憶の保持のどちらかに係る)ルールに関するフィードバックを否定することは、間違いなく愚かなように感じてしまった。
今日に至るまで、私たちが物理的にその場にいるかどうかにかかわらず、いまだにブラインドテストからフィードバックを得ている。結局のところ、プレイヤーがリビングにゲームを持ち込んだり、BGGに良いコメントを残したりすることは、直ちに、私たちの糧となる非公式のブラインドテストになる。つい先週も、私たちの会社の良き友人と更に優れたデザイナーが、このゲームをプレイして、ルールブックに関するブラインドでのフィードバックをくれた。たとえ、世界の7つの海(少なくともその2つの海)の船の中でゲームが輸送中であったとしても。このフィードバックは初版では反映されることはないが、私たちは「ハムレット」に信頼を寄せているので、将来の再販におけるルールブックだけでなく、オンライン上のルールブックを改訂し続けるつもりだ(おそらく、将来的には、面白い拡張を見据えて？)。そうであっても、印刷された分に対する最も新しい変更点は、いまだに決定版のように感じている。私たちのDiscord上にいる素晴らしい人だけでなく、ブラインドでのテストプレイヤーのおかげで、ルールブックだけでなく、グラフィックデザインにも関わる多くのプレイヤーの体験を向上させる(QOL)変更点があった。そして、願わくば、こうしたことによって、このゲームのプレイヤー体験に対して、上質なミルクから作られたバターのような滑らかさを感じてくれたらなと思う。
おわりに
テストプレイは、本1冊とはならないまでも、1章分くらいにはなりそうなので、この記事では詳細には踏み込まなかった。けれども、この記事で、次のような重要な情報が提供できることを願っている。
全てのテストプレイでは、質問が必要だ(ただ、必ずしも、全てのテストプレイヤーが良い回答をくれるとは限らない。)。
みんなが回答を出せるように手伝ってあげよう(案内はしてあげるが、導いてはいけない。必然的にクローズな質問を伴うけれども、良い質問はオープンな質問のことだ！)。
段階ごとにテストプレイを行う。これらの段階の最後に大きな変更を行い続けよう(小さな変更は問題ないことが多い。油性マーカー(a Sharpie, ※アメリカ製の油性マーカー)でさっと書いて解決ならば、おそらく、そいつは大した問題じゃない。)。
一部を変更することによって変更を余儀なくされる部分(dependencies)と合わせるためにテストプレイの時期を決めよう。
時間のかかるゲームは高価なゲームとなる(時間だって費用だよな、仲間のデザイナーたち。)。
デベロップの作業量を管理できるようにしよう。
簡単な質問を用意しておこう。
複数の質問を用意しておこう。
記録可能な質問を用意しておこう(行きつ戻りつするからね(waves and tides, waves and tides)。)。
ということで以上となる。もし、私たちのゲームのテストプレイを手伝いたいのであれば、Discordに参加して、今のテストプレイの取りまとめ役と連絡を取ることができる。私たちは、同じように常にフィードバックを探しているよ。特に、テストプレイに関するBGGの長ったらしい記事を読んで楽しめるような類の人をね。
Johnathan Harrington
以上
※本記事のほかに、デザイナーダイアリーやインタビュー記事として以下のものがある。
この記事が気に入ったらサポートをしてみませんか？