ゲームアーキテクチャの草案

プログラミングを行う上でアーキテクチャというものを決定しないと大変なことになります。
どこになんの処理を書いたのか忘れたり、機能拡張ができない！なんてトラブルが多発することに。

今自分が行いたいものを整理していきましょう。

シューティングゲームでやりたいことはいくつかありますが、
プログラミング的にはそう多くはないでしょう。

ということでマインドマップで要素を書き出しました。

まだ深堀が必要です。例えば↓のようなサイトを見てゲーム処理内容の過不足を見つけていきましょう。
https://dixq.net/rp/

さてアーキテクチャの話。

現時点でゲームに必要な要素は多くないのではという判断をしています。そのため、以下のようなシンプルな仕組みで設計が耐えうると思います。

UnityのGameObject自体が、マイクロアーキテクチャ思想とマッチしそうなのでその構造を活かすイメージを持つと↑のような絵なのかと思います。

自機やステージ管理オブジェクトは、イベントを発行することで各モジュール間は通信を行う想定です。

アーキテクチャとしては、レベル2かレベル3の実装になると思います。
https://logmi.jp/tech/articles/324456

詳細は以下。

・Unityのマイクロサービスアーキテクチャのような構造とマッチさせたい。
そのために、GameObjectに紐づくComportからInterFaceを呼び出しすモジュール化を行う。
Componentはイベント通知を発行して疎結合で処理を行っていく仕組みにする。
・そこまで大規模にならないし、すべてコードに書き出していくようなことはしない。個人開発では無理。

しかしこだわりたい要素もあります。

・チープな演出はしたくない
→何をチープとするのか難しいが決めないといけない。

・重い動作はいや。
→弾と敵は多くなってしまうので対策が必要。

・自機や敵、ステージ、アニメーションの追加は変更の余地を残したい
→アーキテクチャ的には問題なさそうだが…？

・楽しいと思えるポイントを作りたい
→売りになるものは何か考える

シューティングゲームの要素という横軸と、行いたい処理をどう実現するのかという縦軸、こだわりたい要素の補助線の3つを深堀していくとゲームの全体像が見えそうです。

まだ問題定義は終わらない…。

アインシュタイン曰く、「私は地球を救うために１時間の時間を与えられたとしたら、59 分を 問題の定義に使い、１分を解決策の策定に使うだろう」