はじめに
今回は2020年2月にへリリースした「脱出ゲーム Underground」の開発を振り返りたいと思います。
テンプレートを使わず一からの開発は初めてだったので、色々と大変でした。
<iOS>
<Android>
Undergroundという脱出ゲームを作りました〜！
無料で最後まで遊べるのでぜひ遊んでもらえると嬉しいです！
下記のリンクからスマホにダウンロードして遊べます。【iPhone版】https://t.co/n9lUjjij9x
【Android版】https://t.co/USGINxcY1K
よろしくお願い致しますー！！！！！！ pic.twitter.com/jlnVHoY619
— 高原さと,SatoTakahara (@ART_takahara) February 24, 2021
開発ツール
Unityを使って作りました。
開発者は僕一人です。
Unityなのでプログラム言語はC#です。
グラフィックはほぼ３D部分はほぼBlenderで作りました。
途中からテクスチャの一部にSubstancePainterも使うようになりました。
Blenderは当初2.83を使っていましたが、途中で2.90→2.91と随時バージョンアップしています。
あとはオープニングムービーの調整にちょろっとDavinciResolveを使いました。
PCはUnityの作業はMacBookPro、グラフィックなどの３D部分はWindowsで行いました。
MacBookだと３D作業はスピードがおそいので。
開発時間
企画からリリース後のアップデートまで含め、現時点で508時間かかっているようです。
iOS版のリリースまでは490時間、だったような気がしています。
開発の開始は2020年の8月くらいなので７ヶ月くらいかかりました。
フリーランスの仕事の合間に土曜日以外、毎日３時間くらい開発していました。
当初は２ヶ月で作る予定だったので、思ったよりかなり時間がかかってしまいました…
やはり「想定の３倍〜５倍の時間がかかる」という言説は本当だったんですね。
作業時間はTimeSheetというアプリで計測しており、上記はそのスクショ画面です。
純粋な作業記録目的で使用しています。
Apple Watchのバージョンがありスマホを開かなくても記録ができるので使うようになりました。
ちなみに自分は食事や睡眠時間など日常のほとんどの行動時間を記録していたりします。
カンバン系の作業管理アプリはスマホやウェブ画面を開かないといけないので面倒くさがりの自分には不向きでした。
開発に至った経緯など
去年の7月出したゲーム「Robot Mix Puxzzle」まではAssetStoreのテンプレートを改造する形で作っていました。
前回までで、とりあえずリリースまでの流れUnityの最低限の操作を勉強できたので、
「次は一から作ろう」ということで今回の脱出ゲームを作りました。
目標としては主に下記の３つがあったように思います。
- C#を覚える
- Blenderを覚える
- Unityに慣れる
ひとまず一から自分で作る体験をしてみることを目標にしてました。
特にc#は一からの勉強になったので割と時間を取られました。
脱出ゲームを選んだのも、システム的に単純なのでプログラムが複雑になりすぎず、勉強しやすいと思ったからです。
それでも想定よりもかなり時間がかかってしまい、エターナリそうな気配が開発後半は漂っていました。
なので終盤のボリュームはかなり削った部分が多いです。
というか、想定していた「これくらいは作れるだろう」というボリュームが思ったより多すぎた…
企画段階でかなり削ったつもりだったのですが、そこは初めての体験。見積もりが甘々でした。
なんとか完成まで持っていけたのは、2020年の書籍の執筆を乗り越えた経験があったからだと思います。
あれに比べれば楽だろうということで、なんとかリリースまで持っていくことができました。
忍耐力は2020年でかなりついたと思います。
売り上げについての予測
今のところ1日数百円〜数千円の売り上げという感じです。
まだリリースして２週間なのでなんともいえないところですが、
今はある程度収益がありますが、これが２ヶ月後、３ヶ月後となると、どんどん下がっていきます。
開発中にかかった費用は購入した３Dモデルが１つ２つ程度で、合計で5000円くらいです。
なのでコストはほぼ僕の人件費のみですね。
開発にかかった時間が５００時間くらいなので、50万円売り上げれば時給1000円です。
ただ、今のところの売り上げから見ると５０万は結構厳しいかも。
今回の開発はフリーランスの仕事と並行していたので、別にこれ自体で開発費をペイしないといけないわけではないです。
どっちかというとUnityとc#とblender を少し覚えられた、というのが大きいので、それだけでも自分的には＋かなーと思っています。
ただ長期的に開発を続けるには、収益は絶対必要なのでいつまでも同じことは言ってられないのですが。
収益源は広告のみです。
今回は初めて動画リワードも導入しました。
動画リワードは「広告の動画を見ると報酬としてゲーム内で何かが起きる」という仕組みです。
脱出ゲームでは「動画を見るとヒントが表示される」という仕組みで導入されていることが多く、自分もそのパターンで入れてみました。
企画
ここからは実作業とか作り方に関して振り返っていきます。
開発に関しては興味がある少ないだろうということで記事の後半に持ってきました。
まず企画です。
あまり深く考えなかった気がしますが、確か１週間くらいで考えました。
半年以上前なので何を考えていた忘れましたが、当初決まっていたのは
・脱出ゲーム
・暗い雰囲気
・砂漠が出てくる
くらいだったかなーと思います。
細かいストーリーを考えようとしていた形跡がありましたが、うまくまとめられなかったようです。
例えまとまっていたとしても、ストーリーを説明できる時間はなくなったので、多分無意味です。
なんとなくの世界観ができたところで、開発しやすいように攻略手順を先に考えました。
①鍵Aを拾う ②ドアAを開ける
みたいな簡単なものです。
面白い脱出ゲームにするには、プロトタイプを作りながら謎解きをもっと詰めないといけなかったと思うのですが、見切り発車で開発を始めてしまいました。
C#勉強
企画がなんとなくできたところで、C#を勉強し始めます。
流石に最低限の文法とUnityの操作を覚えないといけないからです。
昨年買っておいたUnityの本を引っ張り出してきます。
「UnityではじめるC#」という本です。
この中に簡単な脱出ゲームの作り方が紹介されているので、まず本についてる素材を使って、同じように作りました。
あとは、ぐぐりながらC＃の最低限の文法を覚えます。
2日くらいで脱出ゲームのサンプルと最低限の文法を覚えた、ことにしてプロトタイプの開発に移りました。
上記ようなUnityの本とかプログラムの本は、一冊買って前から順番にやるより、何冊も一気に買っておいて辞書的に使う方が自分には合っていました。
１p目から順番に覚えていくと挫折します（経験談）。
コンセプト・タスクリスト・プロトタイプ
脱出ゲームのサンプルを改造してプロトタイプにしていきます。
プロトタイプでは、ゲームの仕様が明確になっていて、「よし、あとはひたすら作ればいい」という状態を目指します。
基本的なシステムを明確なっていて、ゲームの一部が遊べるような状態になってればいい感じです。
プロトタイプを作るに当たって、自分はまず画面のコンセプトアートいくつか描きました。
こんな感じ↓です。UIの配置とかもイメージします。
画面の雰囲気の確認用に１枚だけ綺麗な絵を用意し、他はラフにしておきます。
描いた絵を元に、プロトタイプのグラフィック部分のタスクリストを書き出します。
自分の今持っている表現手法だとは絵を描くのが一番速くものを表現できるので、絵から機能を割り出していきます。
プログラムが得意な人はプログラムをいきなり書くそうです。
タスクリストと言っても、この時点では全体の物量を知らないので割と適当です。
次にゲーム内の全ての画面のイメージを書きます。↓
これでグラフィックの物量とゲーム全体の流れと必要な動きが把握できます。
２Dの脱出ゲームなので成立するやり方ですね。３Dだとできないです。
アニメーションを除いたゲーム内の全画面を絵にしました。
大体２００枚くらいです。
今思えばここで絵を増やしすぎたのが開発時間がのびた原因でした…
ゲーム内の要素を絵で考えるのはいいですが、必要以上に物量が増えてしまうのは考えものです。
全画面のコンセプトができたところでプログラムのプロトタイプのタスクリストを書き出します。
描いた画面のコンセプトをひたすら実装していきます。
サンプルで作った脱出ゲームがあるので、それを参考に作っていきます。
最終的にできたプロトタイプの映像です。
（めちゃくちゃな部分も多いですが）ここで一応ゲームの仕様は確定しました。
あとはこれをひたすら大きくしていきます。
プロトタイプで、全要素を仮素材で実装したかったのですが、途中で飽きてしまったので、これ以降は本番素材を作りながら実装しています。
今考えると、この時点で要素が多かったので削るべきでした…
ここまでで企画含め１ヶ月くらいかかったと思います。
グラフィック
プロトタイプが大体できたところで
本番グラフィックを作っていきます。
あとはひたすら作るのみです。
最初に描いた画面のスケッチを元に、ゲーム内の全グラフィックの要素を書き出します。
まずは部屋の外形を作り、各部屋のオブジェクトと仕掛けを順に作っていきました。
この時点では無謀にも全素材を０からモデリングしようとしていました。
序盤はBlenderの操作に慣れていなかったこともあり、操作に慣れているZbrushを割と使っていました。
Blenderに慣れてきてからはソフトを跨ぐのが面倒なので、ほぼBlender一本になりました。
Zbrushは直感的にざっくり形を作るのはいいですが、今回みたいな硬いモチーフが多い時はなかなか使いにくいです。
Substanceと連携した作り込みとかでも活躍するのですが、今回はそこまでの絵を求めてはいなかったので中盤以降は出番少なめ。
グラフィックの制作は想像以上に難航しました。
Blenderを覚えながらやっていた、ということもありますが、一番の理由は単に物量が多すぎただけです…。
途中から手作業で全て作るのは不可能だと悟り、cc0のモデルやマテリアルを積極的に使うようになりました。
大体スケッチと同じような見た目になるように作っていきます。
テクスチャの制作も全然間に合わないということで、substandePainterも途中から使い始めます。
Steamで買ってからあまり使っていなかったのですが、ここにきてついに勉強し始めました。
カメラも画面のコンセプトを元に作っていきます。
映像制作と同様にカメラに番号を降って切り替えながら作業しました。
グラフィックの制作に時間かかったもう一つの原因として、実機での確認回数が少なかったのはあるかもしれません。
blenderの作業画面だと、いろいろな角度から見れるのでどうしても細かい部分や見えない部分にまで意識が向いてしまいがちでした。
もっと映像制作のように、そのカメラからの見た目を意識して、見える範囲に焦点を絞って作れば良かった…
３Dは作りこみができたり、細かい調整ができて楽しいですが、絵に比べて最終的な画面を意識せずに作業してしまいがちなので注意したいと思いました。
なかなか絵と同じ感覚で３Dを触るのは難しいです。
ゲーム内でドアが開いたり、鍵が開いたりと言ったアニメーション部分はBlenderのキーフレーム アニメーションでやりました。
超フツーです。
アニメーションの枚数も無駄に多くしてしまい、アプリの容量が５００MBを超えてしまいました。
まあここは実装しないとわからないので、どうしようもない部分ではありました。
グラフィックが8割くらいできるまでに３ヶ月くらいかかりました。
ステージごとにグラフィック制作→実装→グラフィック制作と細かくやっていけば、ボリューム削減もし易かったのですが、
今回はステージという概念がなくUnityのゲームシーンは1シーンで完結してまったため、すごくグラフィックとプログラムを行き来しにくい設計になっていました。
プログラムと実装
グラフィックができたら、あとはひたすら実装していきました。
大まかな仕組みはプロタイプでできていたので、実装で詰まるところはそこまでなかったです。
基本は画面をタップすると何かが表示されて、何かが非表示になる。
これを繰り返しているだけです。
同じようなコードをめちゃくちゃいっぱい書いてたので思いの外コードの量が増えてしまいました。
もっと共通の処理をまとめたら短くなったと思います。
途中からは同じようなことをひたすら繰り返すのに飽きてきてしまいましたが
気合でなんとか乗り切りました。
ボタンの実装方法はかなり問題があったらしく、かなり操作性は悪くなってしまったようで、不評なレビューが多かったです。
UI・UXの部分だと思うのですが、正直作るので精一杯でそこまで考えが及んでいなかったです…
実装で悩んだ部分は保存に関してでしょうか。
保存はPlayerPrefsを使っているのですが、表示状態を記録するのに苦労しました。
最終的には全ての表示状態を保存して、ロード時に取り出すという力技で乗り切りました。
リリース後にMentaでコードを見てもらったときには、
「保存はjsonを使うといいよ」
とのことでした。
作業中も使おうとしたのですが、ちょっと難しそうだったので断念しました。次に作る時は使おう。
振り返ってみると、一つ一つの実装は難しくなかったのですが、思ったよりグラフィックが多くなったことにより物量的に大変になった、という感じでしょうか。
負担を減らすためには、シーンをステージ単位で細かく分けて、小さく作っていけるよう設計にすることだと思いました。
ステージごとにある程度ゲームが独立していれば、ボリュームの調整もしやすいです。
途中でやる気が尽きたとしても途中まででリリースできるし、リリース後にボリュームの追加もしやすいです。
ということで今作っているゲームはシーンごとにゲームが独立しているような形を目指して作っています。
まとめ
とりあえずリリースまで持っていけて良かったです。
今回の一番の反省点は作業見積もりですね。
企画で「こういうゲームを作りたい」と考えたときに、実現可能な物量にするのが大事だなーと。
完成しなければ0なので、面白くする以前に完成させないといけないです。
特に開発終盤は、どんどんやる気が無くなってくるので、「もういいや」となりかけました。
危なかった。
なんとなく想像したものを、なんとなく作り始めると確実に完成しないので注意しないとです。
企画してる時は、これくらいならすぐできるだろう、と思っちゃうんですね。
企画時は気が大きくなっているのです。
まず最低限な形で完成させて、それを作り込む形で開発ができたら一番いいですね。
というか世のゲームとかwebサービスとかはそうやって作られていますね。
個人開発を始めたばかりで、会社が数十人、数百人で作っているゲームと比較してしまうとなかなか厳しいものがあります。
最低限の形というのは、個人としてできるレベルのものなので、
少なくとも初めのうちはかなり小さいものを意識したいです。
あー
あとはUnityには結構慣れてきたのは良かったですね。あとは Blenderの操作もだいぶわかってきました。
これを次に生かしていきたいです。
次、というか今は３Dのブロック崩し的なゲームを作っています。
参考図書
