ゲームのプロトタイプを素早く作る方法
■なぜプロトタイプを作るのか
プロトタイプは「試作品」という意味です。いきなりゲームを作り始めると危険がたくさんあります。それは例えば以下のものです。
・そのゲームが本当に面白いのかがわからない
・そのゲームに多くの時間をかけて作ってよいかがわからない
これらについて詳しく見ていきます。
▼ゲームの面白さは作ってみないとわからない
ゲームの面白さは千差万別であり、作らないとわからないことも多いです。ただ、ある程度であれば、新しく作るゲームが面白いかどうかを推測することは可能です。
・過去に作ったゲームから推測する
→経験が重要。経験が浅いと難しい
・参考になるゲームがあれば分析する
→表面上だけの分析になりやすい。作ってみてわかることが大量に見つかること
ですが、まったく同じシステムになることはないので（パクリゲームでなければ）、これから作るゲームが面白いゲームかどうかを100%判定する方法はありません。
▼そのゲームに多くの時間をかけて作ってよいかがわからない
ネタゲーならともかく、製品としてしっかりとした作りのゲームにするには、最低でも「２週間～２カ月」かかるのではないかと思います。（経験論ですが……）
また、規模が大きくなれば「数カ月～１年以上」かかることもあり得ます。
そのような長期間かけて作るゲームが面白いかどうか、作るまでわからないというのは、とてもリスクが高いです。
■プロトタイプ段階でしっかり検証する
作ったけれど面白くない、では長い時間が無駄になります。そして作ってしまうと厄介なのが、
・なんとかしようと何回も作り直すと、仕様変更と仕様追加でソースコードを悲惨なことになる →無理な変更でバグが出やすくなり、モチベーションが下がる
・作った部分をなんとか再利用しようとして、整合性を埋めるのに多くの時間を費やすことになる
ということです。
こうなってしまうと悲惨で、出口の見えない泥沼のようにズブズブと開発を続けてしまい、そしてモチベーションがなくなると未完成のまま世の中に出ない……、という結果になってしまいます。（経験者談）
■プロトタイプを素早く作るには
前置きが長くなりましたが、プロトタイプ（試作品）を作ることで「面白くなるかどうかわからない」という問題を回避しよう、というのがこの記事での主題となります。
プロトタイプを素早く作るには以下の手順で考えます。
1. ゴールを設定する
2. 目的にあったゲームエンジン、ライブラリを選ぶ
3. アーキテクチャの構築期間を厳しく制限する
4. ゲームのコアとなる部分を優先して実装する
これらについて考えていきます。
▼1. ゴールを設定する
何をしたらプロトタイプは終わりなのか、ということを決めます。
・期間を決める（プロトタイプ作成期間は通常１～３週間程度）
・楽しいと思わせるゲームのコアを見つけたら終了とする
・作成するステージ数を決める（３ステージなど）
これらは設定したら終わりではなく、部屋の壁に張り出すなど、目立つところに書いておくと忘れなくてよいと思います。
▼2. 目的にあったゲームエンジン、ライブラリを選ぶ
使い慣れたゲームエンジン、ライブラリを使います。プロトタイプではゲームを試作することが目的なので、新しいツールを使うなど、技術的な挑戦は別の機会に行った方が良さそうです。
ただし、それがゲームのコアに直結する部分であれば、新しいツールに挑戦するのも良いかもしれません。
ただ、できるだけ使いまわせるところはそのまま使うものとします。
▼3. アーキテクチャの構築期間を厳しく制限する
プロトタイプは日々仕様が変わります。というのも、「どうすれば面白くなるのかを試行錯誤する」ためです。
ただそういった作業をする上での注意点ですが、細かい部分の最適化は後回しにした方が良いです。無駄なコードな冗長なデータ構造であっても、固定化せずにそのまま使うようにします。
そして、プロトタイプは「使い捨てのコード」を書きます。
・モジュールを分割したり、わかりやすい設計にするのは後でよい
・１つの巨大なプレイヤークラスがあってもよい
アルゴリズムは完璧を目指さず「それっぽい」ものをひとまず採用すれば問題ありません。
以下は、簡単にそれっぽく動く敵のAIパターンとなります。
・ランダムAI：乱数で動くだけのAI
・ヒューリスティックAI：最短経路でなくてよい
・グリードAI：ひたすらプレイヤーを直線的に追いかけるだけの愚かなAI
もし、ゲームを作っていて迷う時間が長くなりそうになったら、以下の方法で削減できる可能性があります。
・ゲームプレイ・ゲームバランスの崩壊とはならないトリッキーなバグは無視する
・問題の原因となる機能をごっそり削る（要プランナー相談）
・外替え可能なアルゴリズムに置き換える。近似アルゴリズムを使用する
・強引に進めることも必要。正しい設計や高速なアルゴリズム、省メモリ設計や実行速度を犠牲にする
・ごまかす。プレイヤーに反応するAIは、そうでないAIよりもひとまずは賢く見える
・ハードコーディングする。エレガントなアルゴリズムよりも、長い配列のテーブルを使う方が簡単に実装できる
・とにかく隠す
ただし、削減できるとはいっても節度は必要となります。
・命名規則はしっかり守る
・安易にメンバ変数をpublicにしない。関数化すれば変数の書き換えタイミングや、共通化、配列の領域外アクセス時のチェックが容易になる
→結果的に開発速度があがる
→モンスターを殺すのにHpを0にするのか、それとも外部から破棄するのかを、後から見て思い出すのはなかなか面倒
・If-elseやフラグの多様による不適切な抽象化を避ける
・ステートマシンを使えば状態遷移を簡単に管理できる
▼4. ゲームのコアとなる部分を優先して実装する
ゲームは様々な要素が存在しますが、そのゲームにおけるコアとなる部分を見つけられるように努力します。そのためには、「このゲームのアイデアの本質は何か」ということを常に考えながら作る必要があります。漠然と色々なアイデアを試して偶然の奇跡を期待するのではなく、論理的に考える努力も必要です。
また、創造的なリスクを取り、技術的なリスクを回避するように努めます。
* このアイデアは誰もやったことがないからどうなるかわからない
* このアイデアは皆から評判が悪かったから試す必要がない
といったリスクの高いアイデアでも、自分のゲームに必要と感じたのであれば失敗を恐れずに試してみます。逆に技術的な面での新しいことはできるだけ避けます。
最も大切なのが「作業の優先度」です。検証したい機能を優先して実装するようにします。すべてを実装しようとすると、時間がいくらあっても足りなくなるので、「このゲームでの最も重要な要素」を優先して実験を行うようにします。
■最後に
プロトタイプは一度作ったら終わりではありません。定期的なプロトタイプ作成を行うほど、より精度の高いプロトタイプ作成を行うことができます。
以下は繰り返しプロトタイプ作成を行うためのヒントです。
▼振り返り・反省会を行う
良かった点・悪かった点について反省を行う。また次に生かせる点についても考える
▼迅速にプロトタイプを行うためのライブラリを構築する
実行速度を求められる最終的な製品のためのライブラリ、ではなく、ゲームのプロトタイプを高速に組むためのゲームライブラリを構築する
▼実装パターン、バグのパターン、時間を浪費するパターンを体系化する
ドキュメント化し、高速なスタートダッシュを行うことができるようにする
■参考ページ
＊ Common Game Prototyping Pitfalls
＊ Rapid Prototyping: Tips for Running an Effective R&D Process
＊ Quick and Dirty Prototyping: A Success Story