Circla制作終了時点から振り返る開発の反省点【ゲーム2作目】
はじめに
本記事は、けめる2作目のゲーム作品となるCirclaの開発全般を振り返り、その反省点をまとめることで、自身の制作をより効率的にしようと試みる記事です。
※読み手のことは考えてません。ほぼ自分用です。
クラス設計
時間かけすぎ
今作では、クラス設計に数時間を費やしてから開発をスタートしました。
2作目でまだ不慣れなことも大いに影響しているはずですが、もうちょっとラフな設計だけして取り掛かった方が良かったように感じました。
結局予定とは違う設計になってしまう部分が多く、少し無駄だったように感じます。
SOLIDが意識しきれていなかった
SOLID原則を守ることが大変なことを改めて理解しました。
Single Responsibility
- ❌クラスの責務を大きくしすぎてしまい、後から困るケースがあった
- 音ゲーの判定、ノートの生成、ノートの削除等を1つのクラスに任せたが、ちょっとデカすぎた
- 後から
RotNote
(WASDで拾うノーツ、アーツ)を追加した際、結局同じようなコードを書くことになってしまった→RotNotePresenter
の誕生
- 後から
- 音ゲーの判定、ノートの生成、ノートの削除等を1つのクラスに任せたが、ちょっとデカすぎた
- ❌オーディオ関連の処理が一元化されておらず、あちこちのPrefabに紐づけてしまったため、管理が面倒だった
- ✅ViewにSoundをすべて任せるべき(
SetCurrent()
やOnEnable()
部分で音を再生するようにするなど)
- ✅ViewにSoundをすべて任せるべき(
Open/Closed Principle
❌とにかく守れてなかった
Judgements
,Records
,Presenter
,etc...Judgements
,Records
を途中で直せたのは偉かった(この記事の内容)
- 「守れない=バグ」と言っても過言ではないということを理解した
⭕️
Mod
あたりの設計はかなり良かったと思う- 開発終盤にOCPに注意できてよかった
❌なんでもかんでもenumにして痛い目見た
- ✅enumとswitchの合わせ技はもっと慎重に!
DI
- ⭕️自前でやったけど悪くは無かった
- ❌もうちょっとMonoBehaviourに依存してもいいクラスもあった(一々DIするほどでもないやつ)
バグ
UniRx, UniTaskの購読破棄ができてない系
- ❌すごく多かった
- ✅C#クラスに
IDisposable
は絶対実装する!ちゃんと適切なタイミングで破棄する!
- ✅C#クラスに
input関連
- [Menu] 同時押しで音が増えるバグ
- ✅ストリームを
Merge()
して解決
- ✅ストリームを
- キーボードとマウス操作を両立させるのが結構面倒だった→適当に実装してバグだらけに
- ✅パッケージレベルでUI集みたいなのを作ってもいいかも
- ❓
performed
よりstarted
の方が良かった?(要調査) - ❓そもそもUniRxのObservableでinputをラップする必要は薄かったかも
- 同時押し対策等はUniRxだと楽だが...それ以外は要らなかったかも
以下編集中...