The repo demonstrates a variety of different implementations that result in the same solution, a simple Asteroids game in Unity.
Unity projects involve a confluence of design philosophies from the engine team, plugin apis, and single or team of game developers. It's fascinating and instructive to walk in another developer's shoes and understand how they solve problem in a completely different way, sometimes equally valid, other times with notable drawbacks.
This repository demonstrates some simple theses extended out to a variation of the classic Asteroids game. By making the same game with different implementations, it becomes easy to compare and contrast aspects of the approaches.
Implementing such a simple project is absolutely NOT sufficent to draw conclusions on the validity of an architecture when extended to a large project. To be fair, it is very hard to take ANY repository and draw conclusions on how its architecture would apply to a different game.
My hope is that looking at the source code of various implementations invokes some curiosity and expands the reader's knowledge-base. I also plan to use it as reference material for instruction related to design variations.
I am happy to accept pull requests, please follow the general code standards for consistency.
The implementations can be found in the Assets/Implementations folder.
Entity component uses the Entitas Entity-Component framework and breaks all features into Systems. It uses a pure ECS meaning components have no functionality, only data. Unity's GameObjects are simply used as views, core logic is almost completely decoupled from the "Unity way".
The philosophy of entity component is to make systems highly decoupled and easily testable. Currently there are no unit tests to validate that philosophy, but they may be added in the future.
This is an example of a prototype architecture that uses the core systems of Unity, including a MonoBehaviour component approach, UnityEvents, prefab instantiation, and configurable properties in the inspector.
Components were created as needed, with the core philosophy being don't write code until it's needed, but if it's not extra work keep behaviors flexible and tweakable.
This architecture, or you might call it an anti-architecture, avoids object-oriented principles and uses Unity sparingly.
Almost all code is in one class, specifically one update loop. It is not very customizable since tweakable parameters are all magic numbers. Gameplay objects are generated in code rather than prefabs.
This architecture demonstrates the use of inheritance to reuse common code in systems that can be represented hierarchially. It includes a game state system and an entity system that leverage inheritance.
There are dangers with adding too many levels of inheritance because it makes the sharing of functionality very rigid, so the entity system used here would probably not be suitable for a non-trivial project. However, when used sparingly inheritance can enforce strong compile-time constraints and more elegant scoped code-sharing than with interfaces alone.
I'd like to add a few additional architectures that are popular.
- Data oriented, decoupled from Unity like the Entitas example but not using ECS
- Dependecy Injection/Everything is a binding (Zenject?)
- MVVVM or MVC