Art Of Play は，記録的な時間で，適切なツール，コミュニケーション方法，およびチームワークを使用してデモを構築する方法に関するヒントを共有している。

　作業デモでは，ゲームプレイのメカニズムをテストし，完成したゲームがどのようにプレイされるかの感触を得ることができる。これは，本格的な制作に入る前にコンセプトをテストするための有用な内部ツールであり，クライアントの承認を得たり，潜在的な投資家を獲得したりするために必要なステップでもある。

　過去10年間で，Art Of Playは70以上のゲームと150以上のデモを制作し，その試行錯誤の中で何がうまくいくのか，何がうまくいかないのかを探してきた。この記事では，あなたが迅速かつ効率的に固体のデモを構築するのに役立ついくつかのヒントやトリックを共有し，また，落とし穴を回避するための方法をいくつか示したい。

　もちろん，最初のステップは，コンセプトを思い付くことだ。アイデアはどこからでも，そのような過去のプロジェクトのポストモーテムからやってくることもある。何がうまくいったのか，何がもっとあったらいいと思ったのか，何を変えたらもっと楽しくなるのか，自分自身に問いかけてみてほしい。アイデアはまた，他のゲームをプレイしたり，他のメディア（本，映画），または単に生活からやってくることもよくある。

作業デモでは，完成したゲームがどのようにプレイされるのか，どんなゲームデザインのドキュメントよりもはるかに多くの感触を得ることができる

　たとえば，Lemmingsは，DMAデザインの創設者の1人は，ゲームを考えずにAmigaでDeluxe Paintを学ぶために作ったかわいい小さなピクセルアートのアニメーションから始まった。アニメーションが完成すると，彼はそのキャラクターがゲームの中でどのように機能するかを想像し始めたのだ。

　アイデアは，紙の上や会議の中では素晴らしいものに聞こえることもあるが，小さなプロトタイプを作るまでは，そのアイデアを固めることができないことが多い。ときには金鉱を発見することもあるが，多くの場合，うまくいかないことや，解決すべき問題を見落としていることに気づくこともある。いずれにせよ，それはゲーム開発プロセスの重要なステップであり，作業と有用なデモにその最初のコンセプトを回すのは，科学とアートの両方だ（※原文： a science and an art。artは芸術のみでなく人文科学・社会科学などを含む）。

科学：物事の技術的な側面

●ツールを知る
　ゲームデベロッパは，ゲームを作成するために使用するツールチェイン，つまり最新のフレームワーク，プラグイン，シェーダーについてよく話す。しかし，それと同じくらい重要なのは，スタジオ内だけでなく，クライアント，パブリッシャ，投資家とのコミュニケーションのためのツールやシステムだ。

　我々の多くは過去にスタジオで働いたことがあるが，そこでは終わりのない，ときには不要と思われる会議に時間を奪われていた。現代のソフトウェアやツールを使えば，チーム全体が同じ部屋にいようが，異なる大陸にいようが，常にコミュニケーションを取りながら，効果的かつ効率的に仕事をすることが，かつてないほど簡単になっている。

Art Of PlayはNickelodeonとRise of the Teenage Mutant Ninja Turtles: Bumper Brosで提携していた

　自由に使えるツール（技術的なゲーム制作ツール，チーム管理ツール，コミュニケーションツール）は，すべて同じツールボックスの一部であると考えてほしい。あなたとあなたのチームがどのツールやチャンネルを使うかを早い段階で決め，それらに固執し，内側から操作することを学ぶことが不可欠だ。

　Slack，Basecamp，Discord，Eメールの間で焦点が分かれていると，物事が混ざり合った中で迷子になってしまうだろう。重複したメッセージが送られてきたり，最初に見たときや投稿したときに情報がどこにあったのか覚えていなかったりする。コミュニケーションの種類ごとに1つのチャンネルを設定し，それを守るようにしよう。

気が散って物事のスピードが落ちることはないので，チームには効果的に仕事をするために必要なスペースを与えよう

　複数のタイムゾーンにまたがって仕事をしている場合は，必要なときに必要なだけ会議を計画することが重要だ。リアルタイムが必要ない場合は，BasecampやDiscordのように，各チームメンバーの都合の良いときにメッセージを投稿したり，確認したりできるコミュニケーションツールを利用しよう。全員が同じタイムゾーンにいる場合でも，物理的に同じ場所にいる場合でも，過度なリアルタイムコミュニケーションの必要性を避けることで，物事を動かし続けることができる。

　プログラマなら誰もが，複雑なプロセスを頭の中で処理しているときに，中断されてしまい，「ゾーン」に戻るのに10分もかかってしまう感覚を知っている。毎日，気が散るようなことをしていても物事のスピードは遅くならないので，チームに作業やコミュニケーションに必要なスペースとツールを与えよう。

●リデュース，リユース，リサイクル
　完璧さを避け，できるだけ仮置きを使うようにすることで，早期にアセットを作成するための時間と労力を削減できる。しかし，チームの作業を減らし，再利用するには，アセットを最小限に抑えることは，注力すべき分野の1つにすぎない。時間が経つにつれて，コンテンツと経験のライブラリが蓄積されていく。あなたが作成するプロジェクトのたびに，完成してリリースされたゲームであろうが，小さなプロトタイプであろうが，中断したものであろうが，あなたは何か新しいことを学び，おそらくアセットを作成して新しいコードを書いたことになるだろう。

　どんなに小さなプロジェクトであっても，すべてのプロジェクトの後には，それを分解してチームと議論することをお勧めする。何がうまくいき，何がうまくいかなかったのかを知ることで，それがあなたの集合的な「経験のライブラリ」の一部になる。それらの経験は，今後のプロジェクトについて話し合うときに，スピードアップのための略語として使うことができる。「XYZプロジェクトでやったABCのようにやってみませんか？」プロジェクトの数が増えれば増えるほど，以前のプロジェクトでの経験を参考にしたり，アイデアを引き出したりできるようになる。

Art of Play の Invader Zim. The Doom Game

　コードやアセットについても同じことをしてほしい。もし，別のプロジェクトで使用できそうな新しいコードを開発した場合は，フレームワークやツールセットの一部になるようなライブラリやモジュールに入れておくことを検討してみよう。何度も何度も車輪を再発明しても意味がない。以前のプロジェクトからコードを再利用するたびに（うまく書かれていて，効率的に新しいプロジェクトにロールバックされていれば），効率を上げ，次のデモを構築したり，次のマイルストーンに到達するのに必要な時間を短縮できる。

何度も何度も車輪を再発明しても意味がない

　アセットについても同様だ。通常，ゲームの最終的なアセットを再利用することはできないが（続編や同じIPの別のゲームを作っている場合を除く），少なくともデモ開発の初期段階では仮置きを再利用することが可能な場合がある。

　仮置きのグラフィックスやオーディオを作成したり，ストックライブラリを見て回るだけでも膨大な時間を使うことができる。内部ライブラリを構築することができれば（それをうまく整理しておけば），必要なものをすぐに手に入れることができ，より早くビルドを始めることができる。

●完璧は良いものの敵
　デモはゲームではない。それはリリースを意図されていない，そしてそのようなものは高度に洗練されている必要はない。物事をきれいにしたり，クライアントや投資家を感動させるために機能や派手さを追加したりする誘惑はよくあるが，一般的には，メカニクス，レベル，またはシステムが，できるだけ早くテストでき十分に動作するレベルに到達することに焦点を当てるべきだ。

デモはリリースのためのものではないので，高度に洗練されている必要はない

　何かがうまくいかない場合，早い段階でそれを発見して，それを変更するか，それを中止して，別のアイデアに転換できるようにしたいものだ。スタートアップの専門用語では，「fail fast」ということだ。すべての段階で完璧を求めていると初期のビルドに多くの時間とリソースを費やしすぎてしうが，あなたが方向転換したら無駄になってしまうだろう。完璧を目指すための時間はある。その時間は，あなたが洗練され，テストして，あなたが自信を持って勝てるゲームにできるとを確信したしっかりとしたデモを作ったあとにできるのだ。

　お役所仕事を避け，コミュニケーションを合理化することでリソースを節約できる。集中力を維持するのと同じように，完璧を目指すことを積極的に避けることで，チームの機敏さを保ち，目標に向かって前進できる。

　シンプルな仮置きアセット，基本的なレベルレイアウト，テンプレのテキスト：これらはすべて，迅速かつ簡単に作成でき，デモを構築してテストするという主要なタスクに集中できることを意味する。あなたが作業デモでロックされたアイデアを持っていると，あなたは焦点を変更し，各領域を完成させることを開始できる。

アート：クライアントと物事のチーム側

●創造的思考
　ゲーム開発は，まさにテクノロジーとアートのマリアージュの縮図だ。どんなに技術的なスキルが高くても，チーム内のクリエイティブな思考を奨励し，育成する必要がある。

　クリエイティブなロープをどれだけ持てるかは，プロジェクトによって大きく異なる。クライアントの仕様に合わせてゲームを開発しているのであれば，クライアントはゲームデザインのドキュメントで非常に具体的な詳細を指示しているかもしれない。逆に，あなた自身のIPに基づいてゲームを開発している場合，デモは，投資家やパブリッシャを誘致するためのツールとなる，あなたは世界のすべての創造的な自由を持っているだろう。間違いなく，あなたはこれらの中のどこかに落ちるだろう。

Spongebob Squarepants . Code A CharacterはArt of PlayがNickelodeon Internationalのために作ったものだ

　あなたとパートナーだけのチームであっても，複数の場所にスタッフがいるオフィスであっても，イノベーションを奨励し，創造的な思考をサポートし，チーム全体がアイデアを出し合い，それを試すことができるようにすることが重要だ。


　人を分類するのは簡単だ。「Jackはデザイナーです」「Sallyはコーダーです」というように。しかし，最高のアイデアは，人が既成概念にとらわれない発想をしたときに生まれることが多く，それは自分の専門分野の枠を超えた発想を意味する。ゲームの大まかなコンセプトであっても，小さなサブメカニックやレベルデザイン，機能のアイデアであっても，チーム全体でアイデアを出し合えるようにすることで，より幅広い経験を活かすことができ，最終的には最良の解決策を見つけるチャンスが増えるのだ。

　コアなアイデアができたら，それをコンセプトからデモに変えていくのはチームだ。そのためには，スタジオのセットアップが迅速なイテレーションとアジャイルな作業環境を可能にすることが重要だ。つまり，ツールセットに戻って，適切なアセットを確保し，お役所仕事や承認プロセスに煩わされることなく，チームが作業を行えるようにすることだ。

●お役所仕事を最小化し，小さくする
　お役所仕事，内部政治とすべてのステップでの承認の必要性は，高速デモを構築するための死刑宣告だ。官僚主義の一定量は，通常（あなたがクライアントの概要に基づいて作業している場合はとくに）必要とされているが，最小限に抑えることは，誰もが自分の仕事で取得し，物事を動かすことができることを意味する。

内部政治とすべてのステップでの承認の必要性は，高速デモを構築するための死刑判決だ

　これは，一般的に少人数のチームが大規模なチームよりも有利な点だ。物理的に同じスペースで仕事をしていても，分散して仕事をしていても，10人以下の少人数のチームであれば，全員が同じページにいて，他の人が何をしているのかを把握し，常にコミュニケーションをとることが比較的容易になる。

　時間が経つにつれ，チームの全員を個人的に知り，それぞれの長所と短所を知ることができる。チームの他のメンバーをよく知り，彼らがどのように仕事をするのが好きなのかを知ることができれば，会議に費やす時間が減り，より速く動くことができるようになる。

　大規模なチームでもアジャイル化は可能だが，その性質上，チームを管理し，役割を割り当て，全員を同じページにまとめておくために，より多くの時間と労力が費やされることになる。そこで，先に述べたコミュニケーションシステム，ツール，構造がより重要になってくる。

　小規模チームのもう1つの利点は，その性質上，各人が複数の役目を果たす必要があるため，プロジェクトの往復の量を減らすことができるということだ。コーダーがコーダー，アーティストがアーティストという大規模なスタジオでは，あるコーダーがアセットのリクエストを出して，そのアセットがアートチームによって作成されて納品されるのを待たなければならないことがあるかもしれない。

　小さなスタジオでは，そのコーダーはおそらくある程度のアートスキルを持っているだろう（アーティストはおそらく初歩的なコードスキルを持っているだろう）。これは通常，少なくとも仮置きアセットを作成したり，物事を動かすための小さなコードの微調整をしたりするには十分すぎるほどのものだ。どのスタジオにいても，スキルセットの幅を広げることを考えてみてほしい。複数の役目をする能力を持ち，チームが同じことをできるようにすることで，あなたはより強力な立場に立つことができ，車輪を回し続けることができる。

Art of PlayのExtreme Cardboard Racing

●クライアントの大きな期待
　30日であろうと3か月であろうと，期限を決めておくことで，プロジェクトを軌道に乗せておくことができ，機能のクリープや肥大化を防ぐことができる。どのような性質の仕事でも，あなたが割り当てた時間を埋めようと拡張していくという卑劣な習性があり，新しい機能を追加したり，より洗練されたものにしたりするのは簡単だ。しかし，その結果，プロジェクトがゴールラインに到達しないこともある。もしあなたのゲームが次のDuke Nukem Foreverのようにならないように，そして実際に合理的な期間内に日の目を見ることができるようにしたいのであれば，締め切りに向かって作業することがプロセスで必要になる。

　締め切りが決まったら，自分には制限があり，達成できることにも限界があることを認識しておく必要がある。つまり，あなたのクライアント（そして我々は可能な限り広い意味でこの言葉を使用している ― あなたの "クライアント "は潜在的な投資家かもしれないし，あなたとあなたのチームだけかもしれない）に，デモは単なるデモであり，完成したゲームではないことを認識させる必要があることを意味する。

　それは最初に何が含まれているかについて厳しい決定を行うことを意味する。 ― そして，拡張が何も含まれていない ― デモでは，その後，明確にあなたのデモとあなたの完成したゲームの間にどのような違いがあるのかを伝える必要がある。

締め切りがある場合は，制限があることを認識する必要があり，達成できることには限界がある

　デモには複数の役割がある。何よりもまず，それはあなたのコンセプトが楽しいかどうかをテストできるが，それはまた，コミュニケーションツールでもある。あなたの最終的なゲームの機能のサブセットに制限されているので，あなたのゲームにユニークなもののコアにデモを集中する必要がある。あなたは，ユニークなゲームメカニクス，または新しい制御システムを持っているか？　群衆の中からあなたを際立たせるのは，あなたのアートスタイルか？　あなたのレベルデザインは，このジャンルの他のゲームの上にあなたのゲームを昇格させているか？　

　あなたのデモがゲームのユニークな部分に焦点を当てている場合は，別のコミュニケーションツールを使用して，ストーリーの残りの部分を伝えることができる。あなたのクライアントには，最初からデモには何が含まれているか/含まれていないかを知ってもらい，ギャップを埋めるための補足的なコンテンツを検討する。ゲームの種類や範囲にもよるが，ストーリーボード，コンセプトアート，モックアップビデオなどが考えられる。

　どのような手段を使う場合でも，時間をかけて戦略を計画し，最初からみんなが同じページにあることを確認するようにすることで，エンジンを円滑に回し，あなたがやりたかったことがデモで正確に再現できているか確認できるようになる。

まとめ

　迅速かつ効率的にデモを構築するには，基本的には3つのことに集約できる：ツールの適切なセット（開発，およびコミュニケーションのための両方），正しい考え方と習慣だ。経験豊富なチームは，独立して作業することができるが，コミュニケーションを取って協力し合うことができる。

　これらの3つのことが揃っているところでは，チーム全体が順調に進み，不必要なお役所仕事を最小限に抑えて，成功するデモを作成するという全体像に集中できる。すべてのステップを完璧にし，細かい部分を磨こうとするのではなくだ。

　プロトタイプやデモの数が多ければ多いほど，経験値が上がるだけでなく，「金鉱を掘り当てるチャンスも増える」のだ。Angry Birdsは，Rovioが開発した52本めのゲームだった。最初の51本のゲームは「失敗」ではなかったが，Angry Birdsのような大成功ではなかった。とはいえ，これら51のゲームのそれぞれがAngry Birdsが可能になるまでの経験とシステムを構築してきたのではないだろうか。

　クライアントや投資家に見せるために期限までにデモを作る場合でも，2013年にRovioがそうであったように独自のIPを開発する場合でも，コンセプトからデモまでを可能な限り早く効率的に行うことは，勝利の方程式にたどり着くまでのプロセスを繰り返すことを意味する。仮置きグラフィックスや磨きがかかっていない状態でもプレイして楽しいデモができたなら，それをフルゲームにして鳥を飛ばせる準備ができていることを実感できるだろう。

---

Ash Nicholls氏は，メルボルンを拠点とするスタジオArt of Playのディレクター兼創設者である。彼は， Marvel, Nickelodeon, Sony Pictures，Lucas Artsなどの業界の大物と10年以上の仕事の経験を持っている。Billy Deakin氏はArt of Playのリードデベロッパであり，世界中の何百万人もの子供や若者に向けて教育的で楽しいゲームを開発している。

GamesINdustry.biz ACADEMY関連翻訳記事一覧