Building a Solid Foundation: Exploring the 5-Layer Architecture of Forbidden Archives in Unity 3D

Lisez ce devlog en Français

In Unity 3D game development, code architecture is a critical element for maintaining a coherent structure, enabling easy maintenance, and adding new features. In this initial devlog, I will introduce the five-layer architecture chosen for Forbidden Archives. It clarifies the roles of each component and facilitates communication among them.

Although the Entity Component System (ECS) architecture has performance benefits, I chose not to adopt it because of its complexity, given my lack of experience.

The Framework layer is a horizontal layer that includes generic functionality and reusable utility classes that can be used in any game or application. It is independent of the game context and does not have any specific gameplay logic. It provides tools for file manipulation, mathematical functions, data transformation, etc., and the classes are designed to be reusable in future applications.

The Model layer serves as a facade for the game, providing an abstract representation of the game’s data and functionality, irrespective of Unity3D’s specific low-level aspects. It does not contain any concrete implementation or logic, but instead offers a well-defined abstraction that other layers can use to communicate consistently.

The System layer contains the game’s gameplay logic and employs the “Framework” and “Model” layers to implement game mechanics. Systems that need to maintain state inherit from “ScriptableObject,” enabling system reference by UI elements or gameobject instances.

The Data layer includes concrete implementations of the interfaces defined in the “Model” layer. The classes are ScriptableObject and employ Unity3D-specific types for storing data like game objects, characters, levels, etc. It provides a concrete representation of game data, which can be displayed in the user interface. This layer also contains some assets that are as close as possible to the data that requires them.

The UI layer comprises everything that needs to be displayed on the screen, including user interfaces and prefabs instantiated and populated by the Data layer elements. It does not contain any significant business logic but acts as a link between the MonoBehaviour and the Systems.

While the separation between the Model and Data layers may add complexity, I hope it will improve System layer implementation. I will revise or adapt this architecture if new functionalities or technical constraints arise, and I will publish another devlog post to explain the changes and the reasons behind them.

The layered architecture enables the separation of game component responsibilities and facilitates communication among them. Each layer has a clear and well-defined role, making code understanding and maintenance easier.

The architecture outlined in this devlog was designed based on the game’s requirements and current development stage. However, as with any project, it is expected to evolve over time. If new functionalities or technical constraints arise, this architecture may need to be revised or adjusted. In such cases, I will publish another devlog post to discuss these changes and the rationale behind the decisions made.