ゲームのプロトタイプを素早く作る方法

■なぜプロトタイプを作るのか

プロトタイプは「試作品」という意味です。いきなりゲームを作り始めると危険がたくさんあります。それは例えば以下のものです。

・そのゲームが本当に面白いのかがわからない
・そのゲームに多くの時間をかけて作ってよいかがわからない

これらについて詳しく見ていきます。

▼ゲームの面白さは作ってみないとわからない

ゲームの面白さは千差万別であり、作らないとわからないことも多いです。ただ、ある程度であれば、新しく作るゲームが面白いかどうかを推測することは可能です。

・過去に作ったゲームから推測する
　→経験が重要。経験が浅いと難しい

・参考になるゲームがあれば分析する
　→表面上だけの分析になりやすい。作ってみてわかることが大量に見つかること

ですが、まったく同じシステムになることはないので（パクリゲームでなければ）、これから作るゲームが面白いゲームかどうかを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