Basic technologies:

• Unity
• Zenject
• DoTween
• UniRx
• UniTask

Structure

Non-code assets are placed by type into corresponding directories by default. If this becomes inconvenient, individual features can be moved into the Features folder. Code is divided into:

• Gameplay – core game features.
• Infrastructure – game management logic.
• Services – non-gameplay features. This separation is a recommended convention and does not have to be strictly followed.

Bootstrap

The game should start from the Bootstrap scene. In the editor, running any scene always triggers a start through Bootstrap, thanks to BootstrapLoader. Execution begins in the Bootstrapper.

Problems

• Responsibilities: The idea was that each feature should have a minimal number of entry points. Therefore, features originally started from a single controller and expanded. I liked this idea, but controllers were supposed to evolve into full facades - in practice, however, they ended up containing a lot of business logic. Maintaining facades isn’t always pleasant, and they’re not always necessary. I’ll now write objects with clearly defined responsibilities, and if a feature becomes too complex to work with, I’ll write a facade.
• GameManagement: There is a state machine for managing the game, but its usage may not be intuitive. It would be better to have a GameplayManager to handle the game states.
• States: It was a mistake to divide gameplay into separate states like PlayState and DeathState. Instead, it would have been better to use a PauseController and DeathController.
• MonoBehaviours: It feels like MonoBehaviours need more manual control, especially in the UI, which tries to avoid relying on the GameObject’s active.