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

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

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

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

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

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

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

・過去に作ったゲームから推測する
 →経験が重要。経験が浅いと難しい
・参考になるゲームがあれば分析する
 →表面上だけの分析になりやすい。作ってみてわかることが大量に見つかること

ですが、まったく同じシステムになることはないので(パクリゲームでなければ)、これから作るゲームが面白いゲームかどうかを100%判定する方法はありません。

▼そのゲームに多くの時間をかけて作ってよいかがわからない

ネタゲーならともかく、製品としてしっかりとした作りのゲームにするには、最低でも「2週間~2カ月」かかるのではないかと思います。(経験論ですが……)
また、規模が大きくなれば「数カ月~1年以上」かかることもあり得ます。

そのような長期間かけて作るゲームが面白いかどうか、作るまでわからないというのは、とてもリスクが高いです。

■プロトタイプ段階でしっかり検証する

作ったけれど面白くない、では長い時間が無駄になります。そして作ってしまうと厄介なのが、

・なんとかしようと何回も作り直すと、仕様変更と仕様追加でソースコードを悲惨なことになる →無理な変更でバグが出やすくなり、モチベーションが下がる
・作った部分をなんとか再利用しようとして、整合性を埋めるのに多くの時間を費やすことになる

ということです。
こうなってしまうと悲惨で、出口の見えない泥沼のようにズブズブと開発を続けてしまい、そしてモチベーションがなくなると未完成のまま世の中に出ない……、という結果になってしまいます。(経験者談)

■プロトタイプを素早く作るには

前置きが長くなりましたが、プロトタイプ(試作品)を作ることで「面白くなるかどうかわからない」という問題を回避しよう、というのがこの記事での主題となります。

プロトタイプを素早く作るには以下の手順で考えます。

1. ゴールを設定する
2. 目的にあったゲームエンジン、ライブラリを選ぶ
3. アーキテクチャの構築期間を厳しく制限する
4. ゲームのコアとなる部分を優先して実装する

これらについて考えていきます。

▼1. ゴールを設定する

何をしたらプロトタイプは終わりなのか、ということを決めます。

・期間を決める(プロトタイプ作成期間は通常1~3週間程度)
・楽しいと思わせるゲームのコアを見つけたら終了とする
・作成するステージ数を決める(3ステージなど)

これらは設定したら終わりではなく、部屋の壁に張り出すなど、目立つところに書いておくと忘れなくてよいと思います。

▼2. 目的にあったゲームエンジン、ライブラリを選ぶ

使い慣れたゲームエンジン、ライブラリを使います。プロトタイプではゲームを試作することが目的なので、新しいツールを使うなど、技術的な挑戦は別の機会に行った方が良さそうです。
ただし、それがゲームのコアに直結する部分であれば、新しいツールに挑戦するのも良いかもしれません。

ただ、できるだけ使いまわせるところはそのまま使うものとします。

▼3. アーキテクチャの構築期間を厳しく制限する

プロトタイプは日々仕様が変わります。というのも、「どうすれば面白くなるのかを試行錯誤する」ためです。
ただそういった作業をする上での注意点ですが、細かい部分の最適化は後回しにした方が良いです。無駄なコードな冗長なデータ構造であっても、固定化せずにそのまま使うようにします。

そして、プロトタイプは「使い捨てのコード」を書きます。

・モジュールを分割したり、わかりやすい設計にするのは後でよい
・1つの巨大なプレイヤークラスがあってもよい

アルゴリズムは完璧を目指さず「それっぽい」ものをひとまず採用すれば問題ありません。
以下は、簡単にそれっぽく動く敵の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

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

5

しゅん

ゲームプログラムの記事まとめ

ゲームプログラム に関する記事をまとめています
1つのマガジンに含まれています