ビリヤードゲーム制作 最終報告 ポストモーテム - アプリ名「Ferret's pool billiards」

こんにちは!

インディゲームを制作するディベロッパー「Studio Itachi」のZiggyです。
去年末にカジュアルビリヤードゲーム Ferre's pool billiards をリリースしました。

2022年末にゲームを出して、2023年1月いっぱい反省会をやっておりますが、その最終回となります。
このプロジェクトの今までの記事はこちらです。

さて、当初立てた目標はこんな感じでした。
こちらを踏まえて、振り返っていきたいと思います。
・BGMを自分で作る(今回の主題1)
・モデリングを頑張る(今回の主題2)
・2022年内にリリースする(結構怪しい…)
・Figmaを使って画面構成のイメージを最初に固めてみる。
・StudioItachiの看板キャラにできそうなモデルを作る。

■良かった点1:目標達成!

目標達成にこのブログも一役買っていたと思います。
キリの良いところで状況をまとめていた時に目標の再確認ができていたので、その影響もあって達成ができたと感じます。

プロジェクト途中で進捗レビューしていたような感じですね。
大事な工程でした。

では、それぞれ見ていきます。

> ・BGMを自分で作る(今回の主題1)
BGM2曲とジングル1曲を作りました。
なんならSEも録音したものを編集する形で作成しました。
音楽制作は全くの未経験だったので、0を1にしたというところが素晴らしい成果だったと自負しております。

> ・モデリングを頑張る(今回の主題2)
こちらも頑張りました。自分で考えてモデリングしたのは初めての経験でした。
そのおかげでだいぶ課題も見えてきたので、来年かけて勉強していきます。

> ・2022年内にリリースする(結構怪しい…)
間に合いました!ふたを開ければ9日も余裕ができていましたが、気力的にも内容的にもこれ以上手を付けられずリリースしてしまいましたw
ほぼほぼぴったりのスケジュールでしたね。

> ・Figmaを使って画面構成のイメージを最初に固めてみる。
これはやったのですが、、、改善点の項目で記載します。

> ・StudioItachiの看板キャラにできそうなモデルを作る。
まー、モデリングはしたので、看板キャラにしてもいいですけどね!
Twitterのアイコン変えようかとも思いますが、、、(面倒で…)

■良かった点2:ファイル管理の課題はある程度クリアした

本作は3本目なのですが、どうにもファイル管理、とりわけディレクトリ管理で悩んでいました。
今作では、Assets/ 以下を下記の構成にしました。
Assets/
 ├_Models
 ├_Music
 ├_Scenes
 ├_Scripts
 ├_UI
 └以下プラグイン等のフォルダ

このように先頭にアンダースコアを付けて各プラグイン等のフォルダと分けることで運用しやすくなりました。
今後ですが、1文字目についてMが二つ、Sが二つあってぱっと判断できなかったので、それぞれ_3D,_Music,_Scenes,_Programs,_UIにするとより分かりやすそうだなと思いました。
UIは2Dという名前にしたいけど、3Dモデルで使うテクスチャは入れたくないので変えてませんが、、、HUDにすれば3Dの下に来るけど、メニュー画面とかも入るし、HUDという呼称自体、今の時代は一般的ではないような気もしているので変えなくていいかー。
次回やろう。

■改善点1:UIが適当

終わってから考えれば必然、やる前は考えもしませんでした。
UIが適当すぎて、全然思ってもいなかった形になりました。
Figmaである程度レイアウトは作っていたものの、ある程度しか作っていなかったことが原因ですが、もっと手前の段階におおもとの問題があって、デザインコンセプトを策定していなかったことが非常に良くなかったです。

つまり、デザインを決定するよりどころがないので、Asset Storeの素材をそのまま使うことしかできず、改造もできないのでUIが適当な感じになってしまいました。

UIは勉強します(すでにしてます。ターゲットを具体的にして、ペルソナを意識したコンセプトを策定、そこからレイアウトやモチーフ、色、フォントを決めて設計していくと…)


ゲーム中の画面下部にあるボールの数字だけはぼやけないようにしたかったな。。。

改善点2:プレイしてきてステージごとの感情の起伏がない

これはわかってたことです。
アイテム系やストーリー系の仕様を排除したのが要因です。
このゲームは自分がビリヤードをやりたいがために作ったゲームなので、ビリヤードをやる部分以外はスケジュール通りに進めるために排除しました。

にしてもやっぱりこんなに平たんになるんだなぁと学びになりましたねぇ。
演出やストーリー、見た目はほんと大事!

■改善点3:処理落ち対策が不十分だった。

これはバグの懺悔のところでも書いた通りです。
処理落ち対策は当初全く考えていませんでした。
for文多用しだしてからなんか怪しいカモとも思っていましたが、
実挙動が落ちててもどうせPCのせいだろうと思って放置しました。

また、Update()内でFindを使ったりGetComponentも多用していたので、
実機で落ちてたらこのあたり完全すれば何とかなるだろうと思っていました。

そう思い込んで全部挙動が完成してから実機テストをした結果、実機でも落ちていてFindやGetComponentを排除してもまだ落ちている状態で期間も少ないとなってしまいました。

ここから学べることは、以下の教訓です。
・早いうちに実機テストを行う。
・実装段階からUpdate()内でFind、GetComponent、Camera.main、ループを使わないようにする(どうしてもFindが必要なシーンではtagを使う!)

■改善点4:命名規則が必要

適当にその場で思い出した(考えた)命名規則でファイル名や変数名を付けていたため、かなり滅茶苦茶でわかりにくくなっています。
変数名もクラス名もメソッド名も滅茶苦茶なのでコードが読みにくいし、ファイルの名前も滅茶苦茶で何に使っているファイルかもわからない始末です。
一番ひどいのがMaterial63.matとかいうファイルがあることですね。しかもこれ、つかってます。

ちなみに、サウンドは問題になりませんでした。
数が少なかったのと、一気に作成したので命名規則がぶれてなかったからだと思います。

■最後に

次回作の必須事項としてコーディング規約の制定があります。
まあ、最低限は命名規則さえちゃんとやっとけばいいと思います!

あと、次回作からはきちんと自分以外の人が楽しめるゲームを作ろうと思います。

Unityの勉強を始めたころは本当にゲームが作れるようになるのか不安でした。
そのなかで1作目を作って、結構何でもできそうだと思えるようになりました。
2作目は計画段階でのミスがあって中途半端な作品になりましたがblenderやGPGSの勉強をして、それを経て3作目である今作は思い通りのもの作れる、と自信を付けた作品になりました。

一歩ずつ進んでいかないとゲームの完成が難しいですからねw

今企画考え中なので、作り始めたらまたブログで発信していきたいと思います。

もし記事が面白いなぁと思いましたら、Twitterのほうをフォローしていただけると嬉しいです!
日々のゲーム制作の進捗や、ブログの更新告知、たまにふと思ったことなんかを呟いていますのでよろしくお願いします。