-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Welcome to RoGap, please check the pages on the right of this window!
The following are the architectural layers we used in our game development.
These are the enterprise business rules of our game. they are least likely to change when we change anything from the outer layers. Examples are the player and the enemy.
This contains our game-specific business rules. it encapsulates all the use cases in our system and maintains communication between the game’s building blocks and the external frameworks. changes to how our game operates will likely affect the source code in this layer. Examples are movements and attacks.
This is a set of adapters that convert data that is most convenient to the entities and use cases to the format that convenient to the external frameworks and the UI, and vice versa. while focusing on the design patterns for our architecture, it is this very layer that holds the MVC design pattern that we are using in our development. also, this layer maintains the persistence of our game, no code in the inner circle knows anything about the database. Examples are the controllers and presenters.
We used simple data structures such as hashmaps, and function calls. we do this carefully with respect to the dependency rule using interfaces for dependency inversion and making the most of the outer layers as the innermost.
The outermost layer is generally composed of frameworks and tools such as persistence. We do not have lots of code in this layer other than the simple code that communicates to the next circle inwards, and it is the most flexible to change. This layer is where all the details go. We keep these things on the outside where they can do little harm. Examples are UI and the database.
Finally, our dependencies point inwards only, from the low level towards the high-level details. The name of any component declared in our outer circle (which are the mechanisms) is not mentioned in the inner circle (the policies). These range from variables, to methods. We implemented interfaces where possible, with input boundaries being implemented by the interactors while the output boundaries being implemented by the presenters. The outermost layer consists of the concretions and the innermost are the abstractions. Therefore, all our source code dependencies point inwards with respect to the dependency rule in clean architecture.