迅速かつ醜いプロトタイピングによるサクセス・ストーリー

投稿者: | 2014年4月11日

を翻訳した記事となります。

━━━━━━━━━━━━━━━

去る11月、IGDAリーダーシップ・フォーラムにて、私は小さなPCゲームの開発手法として、「迅速かつ醜いプロトタイピング」に関する短い講演を行いました。ほとんどの開発者はすでに、ウォーターフォールやアジャイル方法論に慣れているので、その目新しい題材は好奇心を持って受け入れられました。

私たちのスタジオ「Boomzap Entertainment」は、言葉の最も簡単な定義としてはアジャイル(高速・柔軟な開発)です。それは、スクラムではなく、エクストリーム・プログラミングでもなく、または一般的なフレームワークにも従っていません。その代わりに、それは過去5年間で私たちのようなインディーズ・スタジオに最適なプロセスに調整されました。そのプロセスを私は「迅速かつ醜いプロトタイピング」と呼びたいと考えています。

プレゼンテーションの要約はこちらで読むことができます。

この記事では、私たちのスタジオが採用した「迅速かつ醜いプロトタイピング」を行う方法を深く議論・展開したいと思います。それは、この方法を使用するためのツールやトリック、その利点と落とし穴です。その中に出てくる例として「Awakening:The Dreamless Castle」を使用しています。このゲームはプロトタイピングを通じて開発したものです。

■なぜその作業をするのか

私たちのやり方がどのように作用するか、いくつかの状況をあなたに与えることとします。Boomzap Entertainmentは、東南アジアの小さなインディーカジュアルゲーム開発会社です。私たちの会社は100%の仮想スタジオで、マレーシア、シンガポール、日本、フィリピン、すべてにおいてレンタルオフィスすらなく、自宅で仕事をする会社です。

「Awakening」チームは完全にオンライン作業で、会議からアセットのドキュメント、ビルドプロセスすべてがオンラインで行っています。私たちは、他人の能力を判断する唯一の方法は、プロトタイピングに含まれるデータのみです(プロトタイプにすべての結果が含まれます)。

さらに私たちの会社は合計で19人ほどの小さな会社です。私たちは平均4~5のチームを持っていますが、これは通常プログラマ1人、ゲームデザイナー1人、アーティスト1人で構成されています。「Awakening」はアーティスト集約型のゲームであるため、ピーク時には7人体制(主にアーティスト)となっていました。

このように私たちのチームは小さいため、組織を階層化したり手続きを煩雑にする必要はありません。誰もが提案したり、アイデアにコメントしたり、そして承認や拒否を同じようにお互いに行います。これはまた、誰もがすぐに何かをビルドしてプロトタイプに組み込めることを意味します。もちろんチームの違う部分からの多くの抵抗に直面することはありません。

このコンビネーション(カジュアルゲームに取り組む小さなチーム+結果は専用の仮想環境に出力)は、私たちが「迅速で醜いプロトタイピング」をすることを容易にしました。

quick_and_dirty

■作業の進め方

迅速かつ醜いプロトタイピングには、3つの基本的なアイデアが含まれます。

  1. 私たちはできるだけ素早くプロトタイプを構築します
  2. 私たちは最後まで醜いアセットを維持します
  3. 私たちはゲームが面白くなるまで作りなおします、または破棄します

この方法はスピードと効率を完璧にするものです。デイリービルド、プレースホルダとなるアセット、そして迅速なイテレーションにより、すべての私たちのプロジェクトでは、作るためのルーチンを形成させます。「Awakening」もこの方法を採用しました。

■ステップ1:できるだけ素早くプロトタイプを構築する

私たちは、「Awakening」のデイリービルド、開発の最初の日からリリースするまでのデモ、を忠実に作りました。ビルドは社内プロジェクトのサイトとパブリッシャーのサイトの両方に投稿しました。この透明性により、パブリッシャーがサーバーを任意のビルドをやってのけ、それをプレイすることとなります。――悪いものも含めて。ビルドには常に変更ログを投稿しました。それはパブリッシャーとQAのために、ルームとパズルが毎日テストするかを知ることを簡単にするためです。

デイリービルドのサイクルを行うことの最大の価値は、すぐにアイデアをテストできるようになったことです。もし誰かが新しいアート・アセットやサブゲームを試してみたいのであれば、私たちは「ビルドに含めて、それがどのように動作するか見てみましょう」と答えます。これは、洗浄と繰り返しのプロセス――ビルドを念頭に置いて、翌日それをテスト、そして迅速なフィードバックを得ます。

私たちは仮想の会社であったため、各チームメンバーは、自分の作業のビルドを自分で全部やらなければならなかった。私たちはスムーズに作業を進めるために、いくつかの重要なツールに依存していました。チームのメンバーは、アセットを電子メールで送ったり、SVNにコミットしていました。

一日の終りに、プログラマは、SVNや電子メールからすべてのファイルを取り出し、バッチファイルからアセットのコンバートを行い、コードのコンパイルをしました。私たちはできる限りこの作業を自動化し、それにより人的ミスを最小限に抑えることができました。

スクリプティングおよびアセットのエンコーディングは、コアな技術としてはMicrosoft Excelを活用しました。原則として、Excelに置き換えられるものはそうしました――変数、ゲームプレイ・スクリプト、アセットのプロパティ、サウンド・エフェクト、テキスト文字列、それに名前をつけます。これらをコードから切り離すことで、私たちはプログラマの手を借りずに値を調整し、ビルドしてそれをテストすることができます。

Excelのスプレッド・シートは使いやすいように設計しました。各スプレッド・シートには、一番上の行に大きな「エクスポート」ボタンを持っています。それにより、LUAファイルにデータをエクスポートするマクロを実行し、ゲームエンジンでLUAファイルをロードする仕組みとなっています。これにより、アーティストやゲームデザイナーは、自分が作成したデータやアセットを自分だけで確認でき、プログラマが組み込みを行う貴重な時間を開放しました。

誰もExcelを脱出していない――私たちのアーティストは、スプレッド・シートで充実した時間を過ごしました。

悪いニュースはあります。誰もがビルドに自由に配置できるということは、遅かれ早かれゲームをクラッシュさせます。誰もが失敗します、意図的であるか非意図的であるかどうかは関係なしに。

これを避けるために、私たちは可能な限り手順を「サルでも分かる」ものにしました。ソース管理はそのための最高のものだった。誰かが壊れたアセットもしくはスプレッド・シートをアップした場合、私たちはすぐに以前の作業バージョンに戻すことができます。(それはまた、誰がそれをチェックインしたかを見つけることができます。しかしそれはその人を責めるためのものではありません)

また、誰もがデータやアセットをコミットする前に、変更点をテストすることを義務付けました。そしてプログラマーが公開するためのアップロードの前にテストをするようにしました。私たちがテストについて杜撰だったときは、デイリービルドは何度も失敗していました――そうそれは私たちが無理矢理に練習するためのレッスンだったのです。

■ステップ2:最後まで醜いアセットを維持する

デイリービルドのプロセスというと聞こえは良いですが、現実的に言えば、あなたは1日でどれだけの作業を完了させられるでしょうか? 多くのアート・アセットはカジュアルゲームでさえ、完了には数日かかります(例えば「Awakening」では1つのシーンをゼロから作ると1アーティストで1週間近くかかります)。

しかし迅速で醜いプロトタイピングでは、1週間も待てない。――もしアートが私たちが望むものでなかったらどうなるのか? もし楽しくない機能だったらどうするのか? 私たちに残された唯一の方法は、可能な限り迅速な「光」のように一貫して、デイリービルドを行うことだけでした。言い換えると、私たちは可能な限り、最後の最後まで、醜いアセットを保ち続けました。

「Awakening」のほとんどでは、私たちはアートのプレースホルダを使用し、エフェクト、サウンド、テキストもプレースホルダを使用しました。そのため最初のマイルストーンは、ゲーム全体を通しプレイできるものの、画面は白黒のオブジェクトが存在するだけでした。最初から最後まで城の中をすべて歩きまわることができ、白黒のオブジェクトをクリックして近づき、アイテムをピックアップし、イベントリが表示されます(そしてそれは醜いクリップアートの疑問符)。それはとても基本的なゲームプレイができるだけでした。

その白と黒のアートは、アーティストからの素敵なスケッチ線画ではありません。それらの多くは私が描いた本当にくだらないサムネイルで、私の命を守るため、とてもお見せできません。そしてファンタジー世界を想像してもらうために、それをマイルストーンとしてパブリッシャーへ提出します。

幸運だったのは、私たちのパブリッシャーは、私たちの仕事のプロセスを知っていたことです。そして(さらに重要なことは)、彼らに非常に早い段階でゲームをプレイする能力を与え、世界がいかに大規模かを見ることができ、パズルは理にかなっていることを確認し、そしてサブゲームが楽しいことを理解したことです。

私たちにとっては、プレースホルダを使用することで、最終的なアートが終了するのを待たずに仕事ができました。実際のアートが完了することを待たずに、スクリプトオブジェクトの相互作用を実装し、あるいはアーティストが進行中の作品をビルドに含めて、すぐにフィードバックができるようになりました。

このような最小限の依存関係は、私たちのような仮想オフィス環境では重要で、オンラインで誰かを待って、座って何もしないのは誘惑が強すぎたのです。

私たちは、それが受け入れられないのです。――ほとんどの場合、プレースホルダと連携する方法を見つけることができます。たとえ安っぽいサムネイルを自分がスケッチして作る意味があったとしても。

■ステップ3:ゲームが面白くなるまで作りなおす、または破棄する

デイリービルドとプレースホルダのアセットはにより私たちは非常に迅速に物事を変更することができ、それこそが迅速かつ醜いプロトタイピングのポイントです。私たちはゲーム内の何かについて変更したいと思った際、変更のコストは従来の環境よりもはるかに低いものでした。また変更する時間もはるかに少ないものでした。私たちはプレースホルダだけを扱い、わずか数日の作業で済ませることが可能でした。

最終的なアートを得たアルファ版の近く、その時までに、私たちは機能のほとんどをプレイテストし、小さなコストで100万回の心変わりを叶えることができました。

私たちは日々ビルドし、日々テストを行うために必要でした。毎朝、チームはデイリービルドをダウンロードし、それをテストします。そこで私たちは2つのことをチェックします。まず始めに、ビルドは動作したか?(本当にそれをやり、パブリッシャーに伝えたことは何か?)もう1つの方がさらに重要なことです。ビルドは楽しかったか? 新しいサブゲームや新しいアセットにより、私たちは本当に昨晩ゲームを面白くさせられたか?

「面白い」は常に主観的で、私たちのチームがゲームを客観的に見るには深く知りすぎていました。――だからたまに、全社的なプレイテストを組織的に行い、親戚や友人(ときにはパブリッシャー)にテストプレイさせます。

それはそれで、プロジェクトにあまり関わりのない人々を参加させて、新鮮な視点や意見を得るために、非常に有効でした。

会社組織を破壊しない程度に、今後、マイルストーンの前に大規模なプレイテストを組織するようにしました。

プレイテストはすべての側面から長いノートのリストの結果となります。リストは、デイリービルドでより長いものとなります。私たちが集中して作業を続けスケジュール通りに進めるために、タスクを集中管理することにしました。すべてのバグや変更要求は、スプレッド・シートにコンパイルされ、優先順位を1~4にランク付けしました。「Awakening」の開発中は、私たちはMicrosoft ExcelからGoogle Docsに以降することで、リアルタイムにリストを編集することができるようになりました。

未実装のタスクを残したり、プロパーのテストなしで無計画にタスクを削除しないように、タスクリストの所有者(通常はクリエイティブディレクターやプロデューサー)だけが、タスクのステータスを操作可能としました。私たちは「Awakening」用に非公式のタスクリストを保持しました。可能な限り最小限の言葉までノートを削り、再び、迅速かつ醜い(しかし効果的な)ものを保持することを目標としました。

アルファ版とベータ版の中間あたりでは、私たちのタスクリストには1000人以上のエントリがありました(!) そこには、主要なクラッシュバグからゴブリン・ヨングの箱の木の色の提案までありました。最も重要なタスクに焦点を当てたチームを維持するには、優先順位3と4(最も低い優先順位)となるタスクをすべて隠し、それを別のスプレッド・シートに移しました。

そうすることで、チームは最初の主要なタスクを解決しようとします。それがはるかに行うことが困難であったとしてでもです。誰かが優先順位4のコメントが機能していないことを悪く感じたので、私たちは続編で対応するというジョークで返しておきました。

■運用する

気づいたのは、私たちの最初のカジュアルなアドベンチャーゲームで、迅速かつ醜いプロトタイピングは、私たちのデザイン、アートスタイル、およびツールの最終決定の多くを助けてくれました。プロジェクトは、約3週間で構築した1レベルのデモ用のゲームとして開始しました。――それは完全なオブジェクト、サブゲーム、エフェクト、および1つの隠しオブジェクトシーンを持ったガーデンルームで構成されていました。

デモのポイントはパブリッシャーを見つけることで、これは「醜いことを保つ」ルールを破った唯一の時間でした。――庭のデモは、非常にきれいなものでした。それは「Awakening」の最終バージョンとくらべて、品質と機能は80%のレベルに達していました。また、短時間で完全な垂直スライスを構築することは、チームの能力を図ることも助けました。もし実際にゲームを構築できれば、作ることを設定できます。

私たちが署名した後、完全に開発を終えるまでは約10ヶ月かかりました。アルファ版の近くまで、アートは仮状態のままでした。まず最初に白黒のスケッチお城を用意し、それから約50%クオリティのアート(プレイ可能なラフとして)、その後のアルファ版で80%まで仕上げました。そして最後の段階で、ビジュアル・エフェクト、サウンド、カットシーンを追加しました。

最後の最後まで柔軟なものに保つことで、私たちは開発の最後の数ヶ月、ゲームの全体的なプレイアビリティを助けることとなり、変更を加える事を可能としました。

デイリー・プロトタイピングは、多くの”アセットの罪悪感”から私たちを解放します。それはゲームの主要な部分を変更したり、破棄することのためらいをなくします。そしてそれは良い動きとなるでしょう。「Awakening」はおよそ3週間、Big Fish Gamesでランキング1位を獲得しました。私は「迅速かつ醜いプロトタイプ」手法の柔軟性がこの成功に貢献したと考えています。

■成功するプロトタイピングのためのヒント

確かに、「迅速かつ醜い」方式には厳格なルールがありません。私たちは作業を進めながら、プロセスを微調整し、チームにとってベストなものをフィットさせます。もし、他のスタジオのために一般的な知恵を授けるのであれば、それは次のようになります。

▼ 1) プロトタイプの観点から考えることをあなたのチームにトレーニングします

実験をすることを推奨し、彼らのアイデアが失敗することを受け入れます。アーティストが作ること、進行中の作品を提出することを奨励します。そしてアイデアの最終段階で完璧にします。自分の考えをプロトタイプし、彼ら自身でテストできるよう、ツールの使いかたを熟知させるよう訓練します。

▼ 2) あなたの発表をトレーニングします。パーツが進行中の作品であることを説明します

プロセスの早い段階でフィードバックを(絶対に)引き出します。関与することを奨励するだけでなく、変更が不合理であるときにはそれを知らせるようにします。変更がすぐにできるとしても、余計な作業に時間を取らないようにします。

▼ 3) 作りなおしを停止するべき時期を学びます

マイルストーンの日付が変更されないと仮定し、機能やアセットが承認された時は断固として変えてはいけません。日々心変わりは起きやすいものです。それぞれの時間でやるべきことを目標とします。

■最後に

もしあなたが「迅速かつ醜いプロトタイピング」に興味を持ったなら、もしくはあなたが独自のプロトタイピング手法をひらめいたなら、私たちにご連絡下さい。――私たちは、これが他のスタジオでどのように活用されるのか興味を持っています!