0から始めるゲーム開発 -2020年度②-

目次

1. 記事の概要と目的

本記事(②)では、今期の制作結果に対して課題の分析をします。
かなり細かい内容になりますので、概要で十分であれば①の記事をご参照くださいね。

2. 制作結果(進捗)

ここからが本題です。
まず、結論から言えばゲームは未完成です。
なので現在の進捗から制作の課題とそれに対する対策を考えていきたいと思います。

ゲーム制作は大まかに以下のスケジュールで進めました。
「完了予定」はゲーム制作開始時に暫定的に決めた日程です。
実際には適宜スケジュールを見直しながら進めているので、ズレ自体は然程重要ではありません。

行程 完了予定 実際の完了 状態 遅れ
α版開発 2020/8末 2020/8末 完了 なし
ゲーム設計 2020/9末 2020/9末 完了 なし
イラスト制作 2020/10末 2020/11末 完了 2mt
Live2dモデル制作 2020/11末 2021/1末 完了 2mt
アニメーション制作 2021/1末 - 進捗2割 -
プログラミング 2021/1末 2021/3末 完了 2mt
パラメータ整備 - 2021/4末 完了 -
シナリオ制作 2021/1末 - 進捗3割 -
製品ページ公開 - 2021/5末 完了 -
ボイス発注 - 2021/6中 完了 -
サンプル動画公開 - 2021/6末 完了 -
音声編集 2020/11末 - 未着手 -
組み込み① 2021/2末 - 進捗1割 -
テスト① 2020/2中 - 未着手 -
体験版リリース 2020/3初 - 未着手 -
組み込み② 2020/3末 - 未着手 -
テスト② 2020/4末 - 未着手 -
審査 2020/5末 - 未着手 -
リリース 2020/6初 - 未着手 -

少し補足すると、緑字は当初予定になかった行程です。
またアニメーション/シナリオ制作等は、体験版リリースに向けて優先度を切って進めているため、スケジュールが大きくズレる結果となっています。

3. 課題と対策

今回の結果ですが、一番重要なのは「今期中にリリースまで辿り着けなかった」という点です。

ゲーム制作で利益を上げるなら、一定の頻度で製品をリリースし続けるのが一番と考えており、個人的にベストなのは1年に1本ペースです。Minecraftのような大ヒット作を生み出せれば話は別ですが、そんな簡単に生み出せたら苦労はしません笑

まぁ実際、今の工数で1年に1本リリースというのは、かなりのハードスケジュールです。
本来はゲームのクオリティ/ボリュームや価格設定も考慮して決めなければならないでしょうし、ある程度経験がないと見通せない事は理解しています。が!少なくとも今の自分が100%のパフォーマンスを出し切っているとは思いませんし、もっと効率的に進めていたら1年でリリースまで辿り着けたのではないか?という気持ちは少なからずあります。

◆ 作業効率

上記を踏まえると、やはりこれが一番の課題になるでしょうか。
原因は経験不足から来るものが多くて分析し辛いですが、今にして思えば…という結果から見た反省点はいくつか思いつきます。

課題① 作業工程・順序

今回の工程は、イラスト制作→Live2d制作のような、『作業単位』で分けて進めました。
今にして思えば大きな失敗だったかも。と感じています。

仕事でもよく使うやり方なので、特に違和感を感じてなかったんですが、そもそも自分のゲームは自分で思っていたより、開始時点のゲームイメージが明確ではなかったんです。制作しながらイメージを積み上げたんですよね。別にそれ自体は良いんですが、イメージがフワっとした状態で、いきなり全シナリオ分のイラストやモデルを作ったら、そりゃ当然手直しが発生する確率上がるよな…って事です。

最初に100%のゲームイメージを固めて、そこから一切変えないって方法もあるとは思うんですが、個人制作でその手法は取りたくありません。良いアイデアは積極的に採用したいです。

対策① 工程管理の再考

上記に対する対策は、工程を「作業単位」ではなく「シナリオ/シーン単位」で分けるです。
最初は作業単位で纏めた方が効率的だろって思ってましたが、要は自分の進め方には合わないって事ですね…。手直しは本当に無駄です。加えて言えば、直したいけど既に作り込んであるから今更直せないみたいな部分も発生しています。シーン単位で制作すれば無駄が0になる、とは言えませんが、少なくとも今より効率的に進められる気がします。

※ただし作業内容によって使い分ける必要はあると思います。
例えばプログラムをシーン単位で作っていくと、逆に無駄が出そうな気がします笑
今回で言えばイラスト/Live2D/シナリオは、シーン単位の作成が良かったかもしれませんね。

課題② イラスト制作速度

イラストレーターがプロになる条件は「絵のクオリティ」だけではないですよね。時間さえ掛ければ、それなりの品質に仕上げることは誰にでも出来るでしょう。きっとプロの条件は「必要な絵を見極め、期限内に仕上げること」ではないでしょうか。
はい。前置きはさておき、要するに。書くのが遅いんですよ、本当に笑

まぁ実力の問題なので、腕を上げるしか無いんですけどね!笑
と言っても、そんなの最初から解っている事なので今更過ぎ…。
じゃあ、それ以外の部分に改善点はないんでしょうか?本当に?

対策② イラスト制作方法の再考

要は、実力が不足してるなら補う方法を考えましょうって事ですよね…(それはそれで悔しい)

自分はイラスト制作で、人体の構図が一番重要で一番難しいと感じます。
ただ真正面から見たイラストなら描きやすいですが、視点、角度やポーズが絡んでくると、頭の中だけでは処理しきれません。結果、何度も書き直して違和感を除去していきます。ただ、それって時間が掛かる上に、その時の感覚によるんですよね。後から違和感を感じることも少なくない。
だからチート手法を使っちゃえばよくない?って事に最近気づきました。

・3Dモデルを使って構図のアタリを付ける
これです!もっと早く気づけばよかった!慣れるまでは、これが良さそうです…
規約を見ると、vroidの著作権はモデル制作者に帰属するようです。つまり、自分で制作したモデルなら使っても問題なさそうですね。まぁアタリを取るだけなので、そんなに作り込む必要はないですけども。

・クリスタを使う
これ、前々から思ってはいたんですが今回で決意しました。乗り換えます。
クリスタにはデッサン人形とかもあるし、良さそうですよね(どうかな…)

自分はイラスト制作にgimpを使っています。無料なのに高機能で本当に素晴らしいソフトです。ただ今回強く感じたのは「自動バックアップがないとキツイ」「素材があればもっと早く書けるのに」という部分です。

gimpは自動バックアップ機能がない+保存中にバグった場合、ファイル自体が破損する可能性があるので、細目に別名保存しておかないと何かあった時に死にます。実際に自分は1から書き直しになりました…。それでも作業に集中して保存を忘れることがあるので、やはり自動バックアップ機能は欲しいです。

あとは素材です。gimpでもネット検索すれば使える素材が一応出てきますが、ライセンスとか確認しないといけないし、若干面倒もあります。その点、クリスタのアセットストアは本当に便利そう。各段に品質/スピードアップが望める気がします。

◆ メンテナンス性

まぁ今回の課題だとメンテナンス性は結局、作業効率に帰属するんですけどね…

課題③ Live2dモデルの複雑化

前提として、今回のモデルはかなり高可動、多機能なモデルです。ゴリゴリ作った甲斐あって、出来は凄く良いんですよ。ええ、出来だけは。

結論から言えば、めっちゃ手間が掛かったし、パーツ追加とかメンテナンスとかクソ大変なんです…。泣ける…。

対策③ 適切な原画制作

Live2dの複雑化を避けるというのは、モデリング方法も関係はあると思いますが、一番はやっぱり原画の作りだと思います。要はイラスト制作の時点で勝負に負けてたんですよね…

そもそもLive2d用のイラストは、普通のイラストに比べて圧倒的に手間が掛かります。当社比2倍。だって今回1イラストで1,000レイヤー以上使ってますからね…。Live2dもそれに比例して複雑になるので、簡単には修正できません…。

なので最初から、Live2d化を見据えて動かしやすいイラストを制作すれば良かったんですよ!いや、見据えてたんですけどね!ちゃんと理解出来てませんでした!

これはどんなモデルを作ってるかで変わるとは思いますが、簡潔に言えば、原画の時点で複雑なポーズにしてはダメです。めっちゃ動かし辛い。いや、可動域が狭いなら別に良いんですけどね。

『真正面の原画を横向きに動かす』のと『横向きの原画を真正面に動かす』の、どっちが難しいかって事なんですけど、そんなの圧倒的に後者じゃないですか…。

なので最初から複雑なポーズの原画にせず、ある程度動かしやすい原画を描いてLive2dで目的のポーズに変形するとメンテナンス性も良くなります。(正直めっちゃ難しいんですけど…)

課題④ プログラム設計

複雑化しないように頑張ったつもり、なんですが。気づいたら複雑化してました!てへぺろ(・ω<)
普段の業務でするような単純スクリプト設計とは難易度の桁が違います。アプリ開発マジ難しい。

色々設計を調べて、なるべくパーツ化して書いたつもりだったんですけどね。気づけば依存だらけ。疎結合?SOLIDとは何ぞや。MVCやらMVPやら、俄か知識で分けて書きましたが、結局俄かは俄かでしかないのです。

メンテナンスする時、処理を遡らないといけなくて、めっちゃ苦労します。(何度か書き直したので、最初よりは大分マシになったんですけどねTT)

対策④ 変数監視

調べて解ったんですが、そもそもUnityは依存度が高くなりやすいのです。だってオブジェクトにアタッチして使うのが前提なんだもの。気を抜くと、すぐに依存だらけになります。

※以下の記事は凄く神。もっと早く見たかった。
baba-s.hatenablog.com

とはいえ、プログラミング経験値の低い自分が、いきなりBESTな設計に辿り着ける自信…ありません。
そこで依存度を下げる効果的な方法として、変数監視が効果的な気がします(Rxってやつ…?)

変数の値変更を監視して、それをトリガーに処理を動かせば依存関係はかなり解消できそう。
今回、自分はこの方法を使うのを躊躇いました。負荷、高そうじゃない…?って

ただ結果を見ると。なんと結局一部だけ使ってるんです!使わざるを得なくて!本当、あほですよね…笑

なので、次回は最初から全体的に組み込もうと思います。コードもかなりシンプルになりますし、何より処理の動かし忘れがない!デバッグもし易いし、良い事尽くめです!

4. 締め

今回、成果の項目は設けませんでしたが、何よりの成果は楽しい+経験なのです。
この1年間、雨の日も風の日も(天気関係ないですが)悪戦苦闘しながらゲームを作ったこと。
この経験に勝る成果はありません!

そして本当に楽しかった。
イラスト技術、Live2dモデル制作知識、プログラミング能力、この辺りの向上を実感出来る楽しさ。
あ、いや、すみません。ちょっと格好つけました。てへぺろ(・ω<)

やはり自分が思い浮かべる最高のゲームを自分の力、自分の手で形にしていくのは本当に楽しい。
楽しくないわけがない!笑
しかも成功したら儲かりますからね!ԅ(¯﹃¯ԅ)グヘヘ

本当に充実した1年でした…。
いえ、まだリリースしてないんですけどね!達成感に浸るにはまだ早い!

という感じで締めたいと思います。
それでは!