時空物語外伝イライザのゴールドラッシュ開発秘話？

Twitterで「イライザのゴールドラッシュのゴールドラッシュの企画段階の設計書とか公開しちゃおうかな～」的なことをつぶやいたので、記事にします。

有限実行、口にしたことの半分ぐらいは本当に実行してくるのが私の強みなのです(｀ω´)ｸﾞﾌﾌ

開発の流れ

ただまぁ、企画段階の設計書って画像1枚しか無いため、思い切って今回の開発全体の流れを記事にします。

今回はざっくり、次のような流れで開発を進めました。

1. ゲームジャンルを決める。
2. そのジャンルの人気アプリを3～4点ピックアップし、何が人気なのか、その要素を調査する。
3. 今作のゲーム要素を設計する。
4. 基礎ロジックを設計する。
5. 画面イメージ、遷移を設計する。
6. ひたすらコーディング＆デバッグ。

ちなみに前作「時空物語」はこの流れの内2番と3番をすっ飛ばして作りました。

そのせいでかけた時間や労力の割に、(商売として)いまいちパッとしない結果となってしまったのです。

※まぁ、かけた時間や労力の分、ファンは付いてくれたので報われてはいます。

このような経緯もあり「やっぱ企画、そしてリサーチって大事！」と反省し、今作では企画段階から丁寧に歩を進めていくことにしたのです。

企画、リサーチ、そして要素設計

まず企画以前の話ですが、「今作はミニゲームだ」と以前から決めていました。

理由としては、単純に「時空物語」に半年かけて疲れたから。なので少し箸休め的なものにしたいと(笑)

もう1つ理由を挙げるとすれば、やはり自分の開発者としての経験値不足を痛感したからですね。

なので小さい規模のゲームをしっかりと作り上げることで、自身のレベルアップを狙った訳です。

シナリオは最初から頭にあった

さて、ゲームジャンルを決めた経緯ですが、これは結構最後まで右往左往しています。

ただタイトルだけはこの段階で完璧に決まっていて、すでにシナリオの構想も完成形として頭にあったのです。これは本当。

なのでジャンルとしては「放置系育成ゲーム」か、クッキークリッカーのような「超インフレ系育成ゲーム」かなと。

で、色々アイデアを出していった結果、最終的にゲームジャンルを「放置系育成ゲーム」に決めた訳です。

参考資料：色々出したアイデア(ほぼ原文ママ)

これは単なるメモで、これを元に自分の脳内でブラッシュアップさせていった感じですね。

大人気アプリを徹底リサーチ！

で、ジャンルが決まったのでそのジャンルの中で特に人気の高いアプリを何点かリサーチしました。

この時、ただプレイするのではなく、そのゲームに含まれる要素をなるべく全てピックアップするようにしました。リバースエンジニアリングってやつです。

以下の図はニャベルの塔という超人気アプリをリサーチした時のものです。

ニャベルの塔 要素設計図(クリックで拡大します)

※リバースエンジニアリング自体は合法ですが、この設計図をそのまま使用して自分のアプリとかにしちゃうと問題がありますのでご注意ください。

何と言いますか、ユーザーという要素を中心にマインドマップ的な感じで要素をつなげていっているのですね。

UMLのユースケース図とマインドマップの合いの子のような図だと思ってください(笑)

そして私はこの要素設計を「なるべく多く」「そして分かりやすく」組むことができれば、きっと面白いアプリになるのだろうと考えました。

その結果が以下の図です。

イライザのゴールドラッシュ 要素設計図(クリックで拡大します)

※何度も言いますが、この設計図をこのまま使用するのはお控えください。

一気に膨れ上がりましたね(笑)

企画段階の設計書なのでいくつかボツ案も混じってますが、基本は現在リリースされているものと同じだということが分かると思います。

ユーザーが直接触る要素は少なめに、要素と要素をつなぐ線がなるべく交差しないように、そしてここに記した全ての要素がユーザーの目から見えるように、そういう点に気をつけながら設計してみました。

多分、どれが欠けてもユーザーのストレスに直結すると思うので、ここでしっかりと枠組みを作ることが大事でしょうね。

※なお、これは一般的な設計手法ではありません。私が私にとって理解しやすいように整理しただけの独自の方法です。ご注意ください。

基本設計開始！

とまぁこのように、ゲームの要素の設計が終わったら、いよいよ基本設計を始めます。

と言ってもチームで開発している訳ではないので、必要最低限のものだけ用意します。

それは「ロジック」と「画面イメージ」です。

基礎ロジックの設計

ロジックの設計については、本当にアプリの根幹となるものだけ、替えが利かないものだけ優先的に行います。

例えば今作で言えば「マナ湧き」と「マナ回収」の2つのロジックがそれに当たります。

戦闘計算式とかも重要なロジックではあるのですが、適当な数値を返すようにしておけばひとまずは「替えが利く」ので後回しにしちゃいます。

で、「マナ湧き」についての設計図がこちらです。

マナ湧き ロジック設計図(クリックで拡大します)

※これは単なるロジックなのでパクリOK！ヽ(ﾟ∀ﾟ)ﾉ ﾊﾟｯ☆

しかし・・・何だか地味に今の形と違うような気がするのと、「マナ回収」の設計図が見当たらないことからすると、どうやら私は途中からソラで書き始めたようです。

うーん、飽きっぽいのが悪い癖ですね(笑)

画面設計

ロジックの設計とは対照的に、細部までカッチリ設計しているのが画面イメージの設計です。

メイン画面設計図(クリックで拡大します)

戦闘画面設計図(クリックで拡大します)

妄想が形になっていくので、ある意味楽しい時間なのでしょうね。

とにかく、ピクセル数とかそういう細かいことは置いといて、大体の画面設計をここで終わらせます。

設計図と現在のアプリの挙動を比べてみると分かると思いますが、この段階でアプリの画面遷移がほぼ決まります。

個人で開発を行う分には、企画段階での「要素設計図」と設計段階での「画面設計図」さえしっかりしていれば開発自体は上手く行くと思っています。

ドキュメントの修正について

これは余談ですが、開発を行なっていく中で、使いづらいとかこっちの方が良いからといった理由で仕様が微妙に変わる場合があります。

今作でももちろん、微妙に変わっている箇所がいくつもあります。

そしてその際、ドキュメントの修正は行う場合と行わない場合があります。

何故ならそれは・・・、個人開発だから(笑)

自分が分かればそれで良いのです、そんなことより完成させる方が大事なのです( ｰ`дｰ´)ｷﾘｯ

・・・余談の余談ですが、別に会社でやっててもドキュメントの修正なんざ行われません。

本当に。むしろ会社の方が酷い。

開発スタート！

ここまで来たら完成は目前です。

あとはひたすらソースコードをやっつけていくだけ、コーディングにコツなんてものは存在しませんので淡々とこなしていきましょう。

ただ、1点だけこの段階でやってはいけないことを挙げるとすれば、それは「追加要素に手を出す」ことだと思います。

何故なら「追加要素」というのは、本来最初の要素設計の時に出ていなければならないモノのはずで、詰まるところ設計に漏れがあったってことです。

そしてそれはたとえ比較的容易に組み込めるものだったとしても、設計全体のバランスを鑑みた上で慎重に追加しなければなりません。

何故なら「要素設計」は「ユーザーのストレスの度合い」に直結する可能性が高いから。

ですので、もしこの段階で新しい要素を追加しようと思うのならば、最悪の場合、設計の段階からやり直すことも念頭に置いておかなきゃいけません。

そしてその覚悟も無いままに、この「新しい要素を追加する」という行為を3～4回ほど繰り返せばあら不思議、あっという間にエターナる作品(※)の出来上がりとなります。

※何らかの理由によって制作が途中で放棄された作品、の意。(参考：ニコニコ大百科「エターナる」)

※プロだって仕様が変わる度にウンザリした気持ちになるのです、アマチュアが仕様をコロコロ変えてたら終わる訳がねえ！(#ﾟДﾟ)ｺﾞﾙｧ!!

このように、制作・創作活動をしていると新しいアイデアや理想が次々と湧いてくるとは思いますが、設計が終わった段階でそれらは「次回作で実装する！」と割り切るようにしましょう。

それが制作を終わらせるための秘訣です。

びっくりするほど単なるウォーターフォール

とまぁ、たった1人でやってる割には驚くほど、単なるウォーターフォール形式のプロジェクトの進め方ですね！(笑)

もちろん1人でやっているので、不要な部分や無駄の多い(面倒臭い)部分は削ってますが、単なる思いつきだけでやっている訳ではないというのがご理解いただけたかなと思います。

設計という行為に不慣れな方やアマチュア(業務未経験)の方には少し難しいと感じるかもしれませんが、逆にこれらのポイントをしっかり押さえておけば、初心者デベロッパーでもユーザーに「良いんじゃない？」「結構面白いよ」と言ってもらえるアプリ・ゲームが作れることでしょう！

後はこちらの記事にも書きましたが、とにかく作品をリリースしまくって開発者である自分自身のレベルを上げていくことですね。

がんばりましょう、自分もまだまだがんばります！ヽ(ﾟ∀ﾟ)ﾉ ﾊﾟｯ☆