ゲーム産業におけるプロトタイプ作成のベストプラクティス

translation projecthorseshoe

注意1: 文の流れ等が悪く、論理的に乱暴であったり無礼に見える箇所もあるかもしれません。それらは私の能力不足によるものです。そう感じる方がいらっしゃいましたら素直に謝ります、ごめんなさい。
注意2: 本レポートの内容に関する一切の著作権は原典を公開しているProject Horseshoe に帰属します。日本語への翻訳に際して許可を求めましたが返答が無いため、本翻訳記事は仮公開とし、著作権者からちょろっとでもコメントがあれば引っ込める予定です。
注意3: また、もちろん誤訳の可能性があります。ご指摘いただいたものは修正したいと考えておりますので、コメントまたはTwitter (lye_) にてお知らせください。
注意4: コンセプト、コンテキスト、フィーチャー、コンテンツ、メカニクス、動詞という6種の用語の意味については、記事末尾の用語集をご覧ください(http://d.hatena.ne.jp/LYE/20090321/1237618551 より引用)。

原典:
Group Report: Concept Sketches for Game Design: Best Practices for Prototyping within the Game Industry
http://www.projecthorseshoe.com/ph08/ph08r4.htm
                                                                                                                              • -

グループ レポート:ゲームデザインのコンセプトスケッチ: ゲーム産業におけるプロトタイプ作成のベストプラクティス

参加者:

  • Steven Bachelder(Gotland University)
  • Lisa Brown (Entertainment Technology Center Carnegie Mellon University)
  • Jason Booth (Conduit Labs)
  • Aki Jarvinen (IT University of Copenhagen)
  • Giles Schildt (independent)
  • Drew Murray (Insomniac Games)

ファシリテーター:

  • Ron Meiners (Hollywood Interactive Group)
検証テーマ: プロトタイプ作成が各開発担当者にもたらす利益とは


本レポートでは、プロトタイプを作成する理由その作成方法について、デザイナー視点から議論を重ねた。
これは、このプロセスをスタジオマネージャやパブリッシャ視点から押さえた情報が非常に少なかったためである。

ゲーム開発プロセスにおけるプロトタイプ作成のベストプラクティスを定義するには、文書化や資金調達などといった多くの懸案事項についても触れなければならない。私達の経験からいって、プロトタイプよりもゲームデザインについてまとめた 350ページの書類のほうがパブリッシャには売りやすいからだ。制作サイドからすればそれは不条理で危険きわまりない。詳細な仕様をデザインドキュメントにまとめたところで、最終成果物は全く違うものになる。そして相違点が判明し、それがパブリッシャと開発会社の間で深刻なトラブルの種となることもある。プロトタイプはこういった課題の解決策となりうるものだ。

本項では、「プロトタイプ作成プロセス」を検討するべき理由、そして効果を最大限に引き出すために行うべきことと作成後の利用方法について、両方のターゲットグループの視点から説明していく。なお、ここでのターゲットグループにはデザイナー、プロトタイプ作成担当チーム以外の開発者、品質管理部、スタジオマネージャ、パブリッシャが含まれる。

全員が享受できる利点

このプロセスについて調べた結果、プロトタイプには各グループが享受できる利点がいくつかあることを発見した。これらは「プロトタイプは優れたコミュニケーションツールになりうる」という点に集約される。

利点の一例: (訳注:ここでのSolution:ソリューションはゲームのデザインコンセプトのような意味)
  • プロトタイプをプレイすることで全員がゲームの楽しさを体験することができ、また同じソリューションに向けて業務を進める意識を高めることができる
  • プロセスの初期段階でフィードバックを集めてサイクルを繰り返す(イテレーション)ことが可能になる
  • ソリューションに対する熱意を生み出し、かつアイデアを中心としてチームの足並みを揃える助けになる
  • デザインの意図するところの理解を助け、デザインに関する議論を解決しやすくする
  • リスクを軽減できる (ソリューションに対して大量のリソースを投入する前に実施できるため)
プロトタイプを試験的デザインドキュメントとして使う

プロトタイプを作成できるということは、本質的には「提示する (ゲームの機構的 = フィーチャー) デザインが必要最小限の労力で実現可能である」ことを証明することだ。突き詰めれば、プロトタイプはゲームメカニクスのコンセプトスケッチとも考えられるだろう。ここで言うゲームメカニクスとは、ゲーム中にプレイヤーが繰り返し (または特定の状況で) 行うアクションなど、ゲームプレイの中心的要素のことだ。ゲームメカニクスのスケッチは、適切な形式と規模で作成すれば「成功の予感を表す、楽しいミニゲーム」になる (Daniel Cook氏の初期プロトタイプに関する考察より)。
ほとんどのパブリッシャとスタジオは、「ゲームの主要な要素を見る」ことを目的としてコンセプトスケッチを作成/承認するが、そういったケースではまず「ゲームメカニクス」にスポットは当たらない。そして理由は定かではないが、多くの場合プロトタイプは「使い捨て」される傾向が高い。コンセプトスケッチは極めて重要であると考えられているにもかかわらず、だ。私達はこのような扱い方は間違っており、 開発プロセスのコストを大幅に引き上げる間違いの元だと考える。
では開始する前に、改めて私達の言うプロトタイプ作成プロセスの定義を見てみよう。

プロトタイプの定義：
  • 体験することのできるデザインドキュメント
  • 作成に時間をかけず、あるゲームデザインの要素をプレイ/テスト可能にしたもの
  • ゲームの一部分を切り出したものでも、ゲーム全体の営業用素材でも、小規模制作物でもない(どちらかと言えば、ゲーム本体に実際に組み込む、細かな要素である)
  • 制作プロセスの初期段階でのみ作成されるものではなく、デザイン要素をゲームに組み込む前に毎回行うもの
  • 時間とリソースを抑えて作成できる、開発上の疑問について「テストが実施できる」成果物
プロトタイプを作成する理由と方法: ゲームデザイナー

このワークグループの目的は (訳注:通常はデザイナーが) ゲーム開発パイプラインの関係者全員にプロトタイプを売り込めるようにすることであるが、まずはデザイナにとってのHow & Why を見ていくことにしよう。
ゲームデザイナーにとってプロトタイプ作成のベストプラクティスとは? この質問については、すでにかなり深いところまで掘り下げられているので (『Game Design Workshop』 (Fullerton 他著)など)、ここでは基本的な要素についてのみ言及する。
第一に、「作成するプロトタイプはどのような質問に対する回答であるのかを認識する」ことがある。
プロトタイプ作成プロセスの効果を最大限まで引き出すには、作成する前にデザイナー自身が明確に「質問」を認識し、テスト可能な目標を設定していることが不可欠だ。先述の通りプロトタイプは小規模制作物ではないため、作成に使える時間は非常に少ない。また携わる人員も、少なければ少ないほど良い。
プロトタイプを作成する際には、「どのメディア/プロトタイプ作成ツールを使うか」というのも重要だ。メディアやツールは、手早くイテレーションができる必要がある。これは各人のもつスキルセットにもよるが、例えば高いプログラミングスキルを持つデザイナーならばデジタルプロトタイプが最も手軽で素早く作れる手段になる。しかし、場合によっては紙で作ったプロトタイプの方が良い場合もあるし、例えばPowerPointの達人なら物凄く凝ったプレゼンテーションでコンセプトを表現することも可能だろう。
プロトタイプ作成支援に関する懸案事項のうち、特に大きなものの一つは作成したプロトタイプが「使い捨て」されてしまうことだ。作成したプロトタイプの実験結果が成功であれ失敗であれ、適切に文書化しておけば後に非常に有益な情報になる。また、プロトタイプを作成するたびに簡単なポストモーテム(事後分析)を開いてテスト目標が成功/失敗した理由について議論しておけば、実際にゲームプレイメカニクスを作りこんでいく段階で非常に役立つ資料になるだろう。こういった文書は特に凝ったものである必要はないが、上手くいった事例や失敗した事例について簡単にまとめておく価値は十分にある。
またプロトタイプは適切な相手に見せる必要がある。作成したデザインの (イテレーション対象となる) 基本要素は、その要素を初めてプレイする人物に見せるべきで、(コアなゲーマー率の高い)同僚のゲーム開発者に見せてもあまり意味がない。

プロトタイプを作成する理由と方法: 開発チーム

ここまでは順調だ。デザイナーにとってプロトタイプ作成の価値は長く知られてきたことだからだ。ではチームのその他のメンバー、実際に開発にあたるメンバーはどうだろう? この項では開発チームについて見ていこう。彼らはプログラマ、アーティストなどから構成され、青信号が出たプロジェクトのゲームを実際に作成していく。「プロトタイプ作成」が彼らにもたらす利益とは何だろうか?
プロトタイプは「使い捨て」だという意見もあるが、実際のところプロトタイプ作成プロセスは最終的に開発チームの作業のムダを省いてくれる。「ゲームメカニクスをプロジェクトの初期段階で体験する」ことと「デザインドキュメントを読む」ことを比較すれば、どちらが開発の基本的な方向性を示してくれるかは明確だ。
またアーティストやサウンドデザイナーにとってはコンセプトアートや音楽を「どういった感情を喚起するものなのか」を明確に示してくれる。これは「World of Goo」の開発会社がプロトタイプ作成に関する取り組みの結果から示したガイドラインでもある。
さらに、開発チームが早い段階でゲームメカニクスを体験できるため、デザイナーへのフィードバック(特にシステムの妥当性について)を早い段階で上げることができる。デザイナーの示すメカニクスが、使用するシステムで実現不可能である場合などは、プログラマーが早く問題を報告することでデザイナーはデザインを手直しできる。
また開発チームがプロトタイプを触ることで、今後チューニングが必要になるであろう箇所を初期段階から認識することができる。これはつまり「今後パイプラインから何が来るのか」をプロセスにかかわったメンバー全員が予測できるということだ。
開発チームがプロトタイプ作成プロセスを支援する方法のひとつに、「作成したプロトタイプをツールとして使用する」というものがある。これは実際にプロトタイプをプレイし、デザイナーの書いた書類を読み、フィードバックを提供する際にその両方を使うということだ。プロトタイプのプレイ中に問題になる箇所が見つかったら、問題を速やかにデザイナーに通知する必要がある。
ただし、開発チームにとってプロトタイプは「今後の予測」を立てる上で有用なツールではあるが、その「もろさ」についてはしっかりと認識し、許容してもらう必要がある。具体的に言えば、プログラマーには「電子的に作成したプロトタイプのコードはほぼ確実に書き直す必要がある」という認識を持ってもらう必要があるということだ。デザイナーは「とにかく動く」ようにプロトタイプを作成しているのであって、「きちんと動く」ことは考えていない。それよりはプロトタイプを雛形や、デザイナーが伝えようとしているメカニクスを表現するデザインドキュメントとして捉えてもらうほうが良いだろう。

プロトタイプを作成する理由と方法: 品質管理部門 (QA チーム)

プロトタイプは開発チームだけでなく、気の遠くなるようなテスティングを担当するチームの資産でもある。
デザインドキュメントと比較した場合の利点は次のとおりである:

  • プロトタイプはゲームデザインの意図をより体感的に(tangibleに)伝えるため、デザインの意図に沿ったテストを行えるようになる
  • (情報などのキャッチアップが容易であるため)チームのメンバーを手軽かつ迅速に増員できる
  • 開発が開始になったら、QAチームはプロトタイプを活用してテストプランの作成を開始できる (ただし次の事項について考慮が必要)
    • プロトタイプは繊細で壊れやすい - そもそもが「突貫工事で壊れかけ」であるから開発ビルドのような激しい扱い方はできない
    • プロトタイプはゲームプレイとデザインの意図、そしてその将来性の理解を促すスケッチである - それ以上でもそれ以下でもない
プロトタイプを作成する理由と方法: プロジェクトマネージャ/スタジオマネージャ

これまでは、開発スタッフよりも上流工程の担当者になればなるほど、プロトタイプ作成に価値について懐疑的になるというのが一般的だった。この項では、効率的な予算の管理責任を担うリードマネージャーやプロジェクトマネージャーが「開発サイクルにおけるプロトタイプ作成」を支持するべき理由について確認していく。
プロジェクトマネージャーがプロトタイプから得られる利点:
プロセス管理者視点から見た場合:

  • プロジェクトスコープをより正確に把握できる(プロトタイプを作成する目的はゲームの将来的な方向性を示すこと)
  • 進行中に新メンバーを迎える際にゲームのコンセプトと開発タスクを説明することが容易になり、情報のキャッチアップが容易になる

ビジネス的視点から見た場合:

  • プロジェクトの早期段階で潜在的なリスクを認識することができる
    • 将来的に開発プロセスで発生する予期不能な事項(サプライズ)を潰せる
  • パブリッシャの担当者にゲームを売り込む際に、販促ツールとして利用できる
  • プロトタイプ作成手順をうまく機能させれば、開発するゲームのコンセプトが機能すること、および面白いことを証明する材料になる
  • 開発スタジオのスタッフのモチベーションを高め、チームの士気を向上させる効果がある
    • 自分の仕事には意味があり、自分は「クール」なものを作り出す作業に携わっているのだと実感する助けになる

プロトタイプ作成タスクを成功に導くには、まず「プロトタイプ作成タスクが真剣に取り組むべき仕事で、重要である」ことを全員が認知する環境が必要である。このような環境では、プロトタイプの作成は空き時間に担当するタスクではなく、会社の事業において重要な意味を持つタスクである必要がある。そのような環境を整備することはクリエイティブな雰囲気を生み出すだけでなく、ほぼ完成したスケッチにより新しい、洗練されたアイデアを生み出す土壌にもなりうる。
またそういったクリエイティブな議論や発言は公式にサポートされるべきだ。企業は開発の各担当者に対し、開発終了やマイルストーン到達のタイミング以外でも、プロトタイプ作成作業に対する士気を高めるような報奨制度 (訳注:原文は Reward System、ただ金銭的なものに限るわけではないと思います。) を設ける必要があるだろう。プロトタイプ作成プロセスを開発プロセスのフロントエンドに組み込む上で、これは欠かせない。プロトタイプ作成にはスケジュールと目標があるべきで、またリソースとツールも揃っていなければならない。そして最後に、プロセスとコストは適切に管理されている必要がある。だが一方で、「実験的な試み」というプロトタイプの本来の意義は維持されなければならない。だからこそ、量的な目標ではなく(デザインと開発の品質に関する)質的目標が必要なのだ。
また、プロセスにプロトタイプ作成タスクを組み込むと言うことは、すなわちそのスケッチの「所有者/担当者」が必要になるということだ。これを実現するにはプロトタイプの「所有権/担当権」と「アーカイブ処理」について管理方針を設定する必要がある。このように管理することで、企業は作成した IP (知的財産物) のライブラリを構築し、R&D (開発研究)レポジトリとしてアクセス可能にできる。蓄積されたプロトタイプは特定のプロジェクトで問題解決の役に立つ可能性がある。また、マネージャは、パブリッシャから届いた「新しいコンセプト」のリクエストへの回答に使うことも可能だ。
マネージャの場合、プロトタイプの作成をやめて製作に移行するタイミングを知ることは非常に重要だ。Daniel Cook氏の意見を引用すれば、これは特に MMO や RPG のような「コンテンツが大量にある」、多数の側面からプロトタイプを作成することが難しいゲームで顕著だ。またタイミングについてはパブリッシャとの関係や、そのプロジェクトにおけるプロトタイプの役割を交渉する際にも影響してくる。

プロトタイプを作成する理由と方法: パブリッシャ

冒頭で述べたように「開発タイトルに対するパブリッシャの興味を引くこと」は、おそらく最も難しい課題だろう。しかしながら、プロトタイプがパブリッシャにとって有益である理由は本当に大量にある。彼らの視点から見たとき、プロトタイプはリスクを軽減するための決定的な要素と捉えられるべきだ。
まず第一にパブリッシャは、ゲームメカニクスのスケッチ、フィーチャーセット(訳注:ゲーム内でプレイヤーが接触できる/接触されるもので構成される要素。また、プレイヤーがゲーム内で行ったアクションから予測されるゲーム側の反応を定義するものでもある (破壊可能な環境、感情を自然に示す NPCなど))、「面白さ」の要素についての評価を早い段階で行える。
加えて、プロトタイプを通じてコンセプトが受け入れられた場合には、潜在的なフィーチャーセットを低コストで増強していける。大量のフィーチャーセットをデザインドキュメントにまとめて、作った文書をその後永久に放置することと比較すればその効果は明白だ。また、プロトタイプ作成という手順を踏むことで「仕上がってくるゲームの方向性を絞り込める」ため、必然的に成功を収める可能性も高くなる。
これらの要素からは、パブリッシャにとって有益なプロトタイプを作成する際に基準が必要になる理由が見えてくる。第一に、繰り返しになるが完成品の一部分をスッポリ切り抜いたもの(原文:vertical slice)とプロトタイプの違いを理解する必要がある。パブリッシャは、各プロトタイプの目的/目標 (「ゲームデザインに対する <ハテナ> とその回答」とも言い換えられる)について開発会社と同じくらい注意を払うべきだ。


第二に、開発会社がプロトタイプ作成体制を整えて適切に管理している場合、パブリッシャはそれと平行して作業に当たるべきだ。例えば、マイルストーンのリストにパブリッシャによるチェックの項目を加える、など。これによりパブリッシャはより頻繁に開発プロセスを覗くことができるようになり、ゲームデザインを様々な側面から見て「変えたい要素」や「変えたくない要素」について具体的な意見を聞けるようになる。またそれ内容は、パブリッシャが絶対に譲れない要素や優先順位を把握する上での判断材料にもなる。


最後に、パブリッシャ側でプロトタイプのライブラリを作成することは非常に高い価値を持ちうる、という点がある。このライブラリに最高/最低のエクスペリエンス/デザインなどと分類してプロトタイプを保管しておけば、別のプロジェクや別の開発会社にサンプルとして見せるなどの用途で役に立つ。そして万一プロジェクトがキャンセルになった場合にでも、プロトタイプには「失敗見本」という価値を見出すことができる。

結論: プロトタイプを活用して成功を導くために

まとめ：

デザイナー:
  • 自分のデザインの意図するところを固め、プロジェクトメンバーに伝える手段として使う
  • アイデアの信頼性を高める手段(時にお気に入りを抹殺する手段でもある) として使う
  • 作成するプロトタイプが「どのような質問に対する回答であるのか」を常に明確にする
  • 出てきたフィードバックは迅速なイテレーション(繰り返し)を通じて次回分に取り入れていく
  • 作成を担当するチーム人員は最小限に抑え、時間とリソースを節約する
  • ジャンルごとに存在するプロトタイプの落とし穴と可能性を特定できるように努める
開発チーム:
  • プロトタイプをプレイしてデザインの意図するところを理解し、ゲームデザイナーと共通のフレームワークを確立する
  • プロトタイプはデザインドキュメントとして扱い、実現不可能なフィーチャーについては赤フラグを立てる
  • コードの美しさ向上に注力せず、コードの書き直しを期待せず、テンプレートと考える
QAチーム:
  • プロトタイプをプレイする際には、それが「コワレモノ」だと認識する
  • テストケース作成資料として扱い、それを基にテストケースを作成する
  • デザインの意図するところをゲームデザイナーに質問する (質問を受けたデザイナーは、それをデザインのイテレーションに役立てられる)
マネージャ:
  • プロジェクトの計画とリスク特定に役立てる
  • スタジオ内およびパブリッシャ間でプロトタイプ作成体制を整備して、クリエイティビティを高める(ただし、パブリッシャのコストを抑えるためスケジュールは厳密に立てる)
  • 「いつ」、「なにを」プロトタイプにするのかについて分析を続ける。また、それがジャンルによってどう異なるかについても分析する
  • プロトタイプをコミュニケーションツールとして捉える:チームに新メンバーを迎える際にプロトタイプに触れてもらうことで、キャッチアップを容易にする/ ゲームの紹介資料としてスタジオ内の別チームに見せる/パブリッシャの担当者にゲームを売り込むためのツールとして活用する
  • 「プロトタイプの作り(込み)すぎ」が発生しないように注意する
パブリッシャ:
  • プロトタイプは完成品の一部分をスッポリ切り抜いたもの(原文:vertical slice)ではなく、「面白さ」の要素を示す証拠のように扱う
  • 量的ではなく(デザインと開発の品質に関する)質的な評価を心がける
  • 各プロトタイプの目的/目標 (「ゲームデザインに対する <ハテナ> とその回答」とも言い換えられる)を理解しようと努める
  • あなたが開発会社に対して「なぜ今これが表示されるの?」という質問を投げたとき、相手が回答に困るようなら、自分自身が求めるゴールの方向性に合わせて助言を行うべき
  • プロトタイプの作成タスクをマイルストーンに組み込む(またはマイルストーンにする)
  • 素早くプロトタイプを作成してもらうことで、指示したデザインの不備や欠陥を開発チームが指摘できるようにする
    • これはパブリッシャ<->開発会社の間の信頼関係を高める働きがある
  • プロジェクトで作成したすべてのプロトタイプをIP(知的財産物)ライブラリとして管理する
    • 万一プロジェクトがキャンセルになった場合にでも、プロトタイプには「失敗見本」という価値を見出すことができる
                                                                                              • -

ゲームのプロトタイプ作成に関する書籍:

Cook, Daniel (2005)
『Common Game Prototyping Pitfalls』
Lost Garden (オンライン)
http://lostgarden.com/2005/08/common-game-prototyping-pitfalls.html


Fullerton, Tracy & Christopher Swain & Steven Hoffman (2004)
『Game Design Workshop: Designing, Prototyping, and Playtesting Games』
San Francisco, New York & Lawrence: CMP Books


Gabler, Gray, Kucic & Shodhan (2005)
『How to Prototype a Game in Under 7 Days: Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester』
Gamasutra (オンライン)
http://www.gamasutra.com/features/20051026/gabler_01.shtml


Kosak, Dave (2006)
『Game Prototyping: How the Skunkworks Work』
Gamespy (オンライン)
http://pc.gamespy.com/pc/spore/698263p1.html


Saffer, Doug (2007)
『Designing for Interaction: Creating Smart Applications and Clever Devices』
New Riders


Waugh, Eric-Jon (2006)
『GDC: Spore: Pre-Production Through Prototyping'』
Gamasutra (オンライン)
http://www.gamasutra.com/features/20060329/waugh_01.shtml


Zimmerman, Eric (2005)
『Play as Research: The Iterative Design Process』
Brenda Laurel (ed.): Design Research. MIT Press

                                                                                              • -

用語集

コンセプト(Concept)

ゲームのスタイル、全体的な設定、キャラクタや人間関係を含めたメインストーリーの基本要素を説明する短いフレーズ。

コンテキスト(Context)

直訳で文脈。ゲーム内の環境とも言い換えられるかもしれない。最も重要な目的は「プレイヤーをゲーム世界に引き込む」こと。「設定や、入力に対する出力に説得力を持たせる」要素。

フィーチャー (Feature)

訳者の理解としては、Mass Effect の会話システムなんかが分かりやすい例だろうか。プレイヤーに「もっとプレイしたい」と思わせることを目的とする。ゲームプレイのメイン要素。

コンテンツ(Content)

キャラやアイテムなど、ゲーム内の物/人など。プレイヤーに「もっとプレイしたい」と思わせることを目的とする。ゲームプレイのメイン要素。

メカニクス(Mechanics)

ゲームデザインの脳にあたる部分。ゲーム内で実行された「動詞」をルールセットで内部的に処理して出力する。

動詞(Verb)

ゲーム中にプレイヤーが実行するアクション