規模の大きな個人ゲームを作る時に大切だと思ったこと

ウィッチクライドを開発して感じたことです。

ウィッチクライドはこちら。

ウィッチクライド ～君の声が魔法となる～を App Store で

個人開発だと、思いついたまま適当に開発してしまうことがほとんどだと思います。なにしろ結局全部自分でやるので、業務管理なんか面倒なことはしないでしょう。せいぜい機能の○×表やリソース管理表くらいじゃないですかね。

しかし、ラン系のミニゲーム程度ならば、適当に作り始めてもなんとかなってしまいますが、ウィッチクライドくらいの作品規模になると、適当に作ると途中でわけがわからなくなる、というか気持ちが乗ってこなくなります。

アイデアを膨らませるために

ウィッチクライドの基本のアイデアはこうです。

「自分の声で魔法詠唱がしたい。魔法で敵を倒したい。」

魔法詠唱機能は、魔法作成フェーズと魔法実行フェーズとを明確に分けることを初期段階から考えていたので、認識エンジンの方向性についてはある程度ブレませんでした。

問題は、魔法実行フェーズ、つまりゲームでどう魔法を使うか？ゲーム性を持たせるか？というところについては、右から来る敵を適当に倒せばいいんじゃない？程度にしか考えませんでした。

ということで、ろくにゲーム性を検討せずに、ゲーム画面を適当に実装してしまい、結果酷いものが出来上がりました。それがこれです。

これはもう、次に何をすればいいのかも頭に浮かばず、完全に開発の手が止まりました。魔法エフェクトはとか敵とか主人公の動きとか、ノーデザインでプログラムで適当にやろうと思ったのが間違い。

そもそも魔法作成が必要なのに、そっちの画面を考えずに、いきなりゲーム画面出しても仕方ないのですが、画面遷移とか設計とか後回しでいいやとか思った結果、こんな適当なゲーム画面をまず作ってしまいました。

画面設計をしよう

途轍もなく当たり前の話ではありますが、プログラミングしながら画面デザインはできません。「とりあえず四角い箱動かせばいいや」はNGです。四角い箱を出すことすら面倒くさいです。

ということで、まず画面設計をする。これが物凄く重要だと感じました。Unreal Engineがブループリントという簡易画面設計ツールを用意しているように、画面の叩き台は最初に作っておくべきものなんですよね。

最低限必要な画面遷移と、各画面の画面設計をして、必要な部品をプロジェクトに取り込み、配置する。これを先にやらないと、気持ちが萎えます。

そんなわけで、まずは絵で画面設計とゲームデザインをしました。次に作ったのがこちらの画面。

右にモンスターを配置、左サイドの前衛キャラが防衛しつつ、魔法使いが魔法を撃ち込むという感じです。もうほぼ今の形に近いです。

もう少しデザインを詰めて、できたのがこちら。

キャラクターの絵柄やヒロインの位置など、デザイン面は大きく違いますが、ゲームコンセプトとなるベース部分はほぼほぼリリース版と一緒です。とりあえず、初期段階でここまで詰めました。

いきなり戦闘画面に行っても魔法が撃てないので、戦闘画面は一旦置いておいて、メニュー画面系も作りました。初期イメージはこんな感じです。

※ヒロインの絵柄がバラバラですが、なかなか納得がいかず、最終バージョンになるまで、何度もリテイクしました……。

デザインの差はあれ、ここはそれほど大きく変わる部分ではないので、こちらも基本は大差ないです。

ここまであれば、ゲーム性を確認できるまでの基本画面は繋がります。コード開発はそこからが本番、といった感じです。

ということで、まずは最低限ゲームが成り立つまでの画面設計をすることをお勧めします。特に多少規模が大きいゲームで画面設計がないと、どうにもうまくいかなくなります。

実際、ウィッチクライドの前に別のゲームを作りかけていたのですが、ゲームとしての全体像を最初に作らなかったために、途中で心が折れてしまいました。