今回は、ゲームのプロトタイプを素早く作る方法を紹介します。
■なぜプロトタイプを作るのか
プロトタイプとは「試作品」という意味です。
発売にむけて開発を行う「本制作」とは異なり、
- そのゲームが本当に面白いのか?
- そのゲームは作るに値するのか?
といったことを見極める、検証のための開発となります。
なぜプロトタイプを作るのかというと、「ゲーム開発はお金と時間がかかる」「ゲームの面白さは作ってみないとわからない」という2つの側面があるからです。
特に最近の中~大規模のゲーム開発は数年かけて行います。そして開発費は数億円から数十億円かかります。それだけの大きなゲームを作ったにも関わらず「面白くない」ゲームだった場合、莫大な損害が発生してしまいます。
そういったリスクを避けるためにも、プロトタイプの段階で、そのゲームが本当に面白いのか、時間とお金をかけて制作を行うことに値するゲームかどうかの検証が大切となります。
■プロトタイプを素早く作るための方法
プロトタイプを素早く作るために、重要となるのが以下の4つです。
- 目的に合ったゲームエンジン・ライブラリを使用する
- アーキテクチャの構築期間を厳しく制限する
- ゲームのコアとなる部分を優先して実装する
- 正しく適切なフィードバックを得る
これらを細かく説明していきます。
▼1. 目的に合ったゲームエンジン・ライブラリを使用する
プロトタイプの制作時間は限られているので、1からゲームシステムを構築するよりも、最近の優れたゲームエンジンを使う方が、開発効率が良いと思います。代表的なゲームエンジンとしては、Unity / Unreal Engine / CRYENGINE などですね。インディーズでも、Unity / Unreal Engine は人気ですし、プログラムの知識がなくてもゲームが作れる RPGツクール や GameMaker なども人気です。
ジャンルやシステムが明確であれば、こういったツールを使うと開発が速いです。ただ、弊社の場合は、長年の実績がある自社のゲームライブラリやアニメーションツール、データ管理ツールが存在するため、それらを使ってプロトタイプの制作を行うことが多いです。慣れない環境よりも、開発者の手になじむ環境を使うのがよいです。
▼2. アーキテクチャの構築期間を厳しく制限する
本制作であれば、できるだけ無駄のないエレガントな設計のゲームシステムを構築することが大切です。しかしプロトタイプ制作は、「何が面白いのか?」ということを検証するための開発なので、仕様が日々、変更・追加されます。むしろ、計画当初の仕様を変更・追加することなしでゲームを面白くするのは難しいです。そのため、プログラムには柔軟な設計が求められます。早すぎる最適化は柔軟さを失います。
具体的な例としては、通常、ジャンプアクションゲームを作る場合、プレイヤーキャラクターは、キャラクターの描画行うクラスとキャラクターを操作するコントローラークラスを分けて実装します。しかしクラスを分けると、お互いのデータのやりとりについてルールを決める必要があるため、実装に時間がかかって効率が悪いです。
そのため、プロトタイプ段階では、キャラクターを1つのクラスにまとめておきます。こうすることで仕様変更による修正が容易となります。もちろん、不格好で太ったクラスになってしまいますが、プロトタイプのコードは捨てる前提で書くため、多少汚いコードになっても問題ありません。
といったように、プロトタイプ段階では「シンプルに速く作れる方法」を採用します。これはアルゴリズムについても同様のことが言えます。例えば敵のAIを頑張って賢くする必要はなく、以下のようなものでも充分であることが多いです。
- ランダムAI:それっぽく乱数で動いていればOK
- ヒューリスティックAI : 最適な経路で動かなくてもいい
- グリードAI : ひたすらプレイヤーを追いかけ回すだけの愚かなAI
また、ローグライクのようなゲームを作る際に使われるプロシージャル(自動生成)のアルゴリズムも、プロトタイプ段階では、固定のコンテンツであっても面白さを検証するには、さほど大きな違いはないはずです。
ゲームのコアな部分に対して、技術的な挑戦が求められる場合は別ですが、そうでなければ、技術的なリスクを避け、ゲームのコアを創造するリスクを取るのが良いと思います。
▼3. ゲームのコアを優先する
そのゲームのコア(核)となる部分を優先して実装します。ゲームのコアとは、たいていは一言で説明できるようなものです。
以下は、BraidとICOの例です。
- Braid: 時間を巻き戻して、障害を乗り越えてお姫様を救うゲーム
- ICO: 少女と手をつないで、霧に包まれた城を逃げ出すゲーム
なお、余談ですがゲームのコアを見つけるには EMS Frameworkがオススメです。
「●●を□□して(手段)、××を△△する(目的)のゲーム」の部分をランダムに言葉を当てはめる、という発想法
プロトタイプが退屈でくだらないミニゲームにならないようにするには、ゲームのコアを優先する必要があります。逆にコアに影響しないものはできるだけ作らないようにします。例えば、オブジェクトのパラメータを最小限に抑える、レベルデザイン(ステージ)は数個にする、です。
▼4. 正しく適切なフィードバックを得る
フィードバック(感想)は、できるだけ開発に関わっていないチームからもらうと良いです。開発者はゲームの裏の裏までを知り尽くしているので、始めて遊んだ人が理解できない部分に気づかないことが多いからです。そのため、そのゲームをよく知らない人にテストプレイしてもらうのが一番です。
テストプレイ時の注意点としては、テスターに基本的な操作だけ教えて、後はテスターのゲームプレイをよく観察します。おそらく開発者の意図しないところで、詰まって先へ進めなくなっている部分があるはずです。それを見つけたら、どうやったら開発者の意図する方向に進められるかを考え、適切な修正を行います。
■最後に
プロトタイプ作成に役立つかもしれないヒントとして、1つの動画を紹介します。
これは「48時間で1つのゲームを作る」というGlobal Game Jam というイベントの第1回で、ゲームデザイナーのカイル・ゲイブラー氏(「グーの惑星」などを開発。ゲームプロトタイピングについてのプロフェッショナル)が行った基調講演です。
- 自分が開発するゲームにほれこむな (Never Fall in Love)
- ゲーム要素の調和が大切 (harmony)
- 効果的なオーディオも忘れずに (shhh..)
- まずゲームをプレイテストできるようにしよう (Make the TOY First)
- アーティスティックなテーマを絞ろう (Feel Something)
- 簡単にゲームに入れるようにしよう (Create a Low Barrier of Entry)
- 何が期待されているのかを自覚しよう (Adjust Expectations)
これらの7つのヒントはどれも素晴らしいものですが、個人的なお気に入りは、4番目の「Make the TOY First」です。
まずは、触ったりいじったりするだけで楽しい「おもちゃ」を作ろう。
そこには素晴らしいアートや、明確なゴール、巧みなレベルデザインは必要ない
本当に面白いものが作れれば、丸や四角形のような図形を動かすだけでも面白いものです。
Braidの開発者であるジョナサン・ブロウ氏は、「Indie Game: The Movie」でのインタビューで、「Braidのプロトタイプは7日間で作った。そこでゲームのコアはほとんど完成していた」というような話をしていました(うろ覚えなので若干違うかもしれません)
もちろん、最終的な商品としてお客様に提供するには、素晴らしいアートや世界観、ゲームシナリオは必須となります。事実、Braidは2年間かけてアートを構築しています。しかし、チープなグラフィックでも、根本となるゲームの面白さは検証できるのではないか、と思うわけです。
■参考
今回の記事を書くにあたって参考にしたページです。
- Common Game Prototyping Pitfalls
- ゲーム開発におけるプロトタイピングの落とし穴
- Rapid Game Prototyping: Tips for Programmers
それと、可能であれば、開発者全員がゲームデザイン・アート・プログラムのそれぞれの分野を理解していると開発がより速くなります。例えば、ゲームデザイナーがプログラムを理解していれば、プログラムを考慮した上での設計が可能となります。またアーティストやプログラマがゲームデザインを理解していれば、ゲームルールを理解しやすくする提案や修正が迅速に行われるからです。
そういった知識を身につけるにはどうすればよいのか? 本やWebにある情報で知識を仕入れることも大切ですが、個人的には先ほど紹介した「Global Game Jam」に参加する、または「Game A Week」をオススメします。Game A Weekとは1週間に1本ゲームを作る、というものです。ゲーム開発者はゲームを作ることでしか、その開発者としての経験を得ることができません。「Global Game Jam」も「Game A Week」も非常に大変なものですが、そのぶん収穫も多いです。
なお、Game A Weekは以下のルールに従うと効果的です。
- 毎週ゲームを作る。月曜日の12:00にプロジェクトを開始し、日曜日の23:59までにゲームを作り上げること
- 毎週ゲームをリリースする
- 作り終えたゲームは修正しない。ゲーム完成後に手を入れるといつまで経っても終わらない
- パターン化を避ける。毎週、異なることにチャレンジすること
- 振り返りを行う。良かったところ、悪かったところ、改善すべき点などを話し合う
Game A Weekを理解する上で、参考になるリンクは以下の通りです
- 一週間に一つミニゲームを作り続けるのに役立つひどいゲームをかろうじてましなゲームにする力
- Game A Week: Getting Experienced At Failure
- The guidelines for making a game a week, every week
- What one dev learned while doing a “one game per week” challenge