Earlier the approaches to design graphical applications used the same designing principles as designing of web and other types of applications [1].
Designing of multimedia applications require special approaches for interface designing. Classical Model-Driven Development methodologies needed to be adopted for development of applications that need component-oriented [2], service-oriented [3,4], agent-oriented [5], and other architectural styles [6.7].
Also modern multimedia applications support complex UI, and usual software designing approaches based on UML diagrams cannot effectively reflect all the details of multimedia applications.
Special approaches, considering the peculiarities of different GameObject structures, various types of game scenes (2D, 2.5D, and 3D scenes), and the assessment of script quality attached to GameObjects, may be adopted for designing of multimedia applications [8]. The same problem is actual for the designing of VR? AR, and mixed reality applications [9].
The modern game industry is constantly developing, offering more and more complex and innovative solutions in the creation of game applications. One of the key aspects of effective game development is choosing an architecture that provides flexibility, scalability, and ease of code maintenance. The basis of a game application is a game engine, which is an environment for developing and prototyping game applications with its own features and programming language. Among the popular game engines, Unity Engine, Unreal Engine, and Godot Engine are most often singled out (Fig. 1) [10].
Designing the architecture of any application can pose certain challenges and problems, in particular:
1. Choosing an appropriate architectural pattern: Game engines do not impose strict restrictions on the architecture, which can lead to difficulties in choosing the optimal pattern. Common patterns such as MVC (Model-View-Controller), MVVM (Model-View-ViewModel) or ECS (Entity Component System) have their advantages and disadvantages depending on the project [11]. 2. Initial architectural decisions can make it difficult to scale the project in the future. The wrong choice can lead to the need to rewrite the code when adding new functions [12]. 3. Using the available functionality of game engines without a designed architecture and without using best practices leads to the creation of tightly coupled systems, which complicates their testing and refactoring [13]. Using SOLID principles and design patterns such as Dependency Injection, Service Locator can help manage these dependencies. 4. An architecture that complicates testing can significantly increase development time.
Automated testing such as unit tests can be difficult to implement in Unity due to game engine dependencies [6]. 5. Some architectural patterns can negatively affect performance, especially in projects with a large number of objects and components. Optimization and proper pattern selection are key to maintaining high performance.
Integration with external systems such as databases or web services can be difficult depending on the chosen architecture. It is important to plan these aspects in the early stages of development.
Different developers may have different approaches to architecture, which can make team collaboration difficult. It is important to establish clear standards and principles of architecture at the beginning of the project.
To solve these problems, it is important to spend time planning the architecture, regularly reviewing and updating it according to changes in the design, and taking into account the experiences and best practices of other developers.
Today, there are a large number of patterns and implementations of their combinations. In order to choose the most suitable architecture, it is suggested to consider what challenges developers have to deal with.
The first is getting dependencies from another class. This is usually solved by setting up relationships between components in the development environment, using the Singleton pattern, static fields, or events [14]. The disadvantages of this approach become noticeable in the process of filling the project with objects and logic. An alternative is Dependency Injection (DI), which allows you to pass a reference to an object through a dependency injection mechanism [15].
Another challenge is maintaining the structure of the project, minimizing problems with the initialization order. For this, you need to clearly control the life cycle of the application, as well as game objects. The State pattern is suitable for defining life cycle stages, since each stage is a separate state of the application that we can enter and exit.
In addition to dependencies, developers often face the question of how to use the same functionality in different parts of the project? If the logic is global for all users and 100 users make requests to one service at the same time, then at best only a few will get the result. This problem is solved by the Service Locator pattern in combination with the State pattern to ensure sequential execution of requests in the order determined by the state [10,11,6].
Let's take a closer look at the states and description of the game cycle of the application.
For any application, such as an educational app or a game, the session life cycle typically follows this structure (see Figure 2): Bootstrap is an entry point, a place where services, dependencies are initialized, resources necessary for launch are loaded.
GameLoop is directly the game process, interaction with the application, in which all game or business logic takes place.
Dispose is the state of the application before exiting, unloading resources, services, etc. The most critical points in this scheme (Fig. 2) are between the states of the life cycle and can be called "transitional processes". This means, for example, the order of initialization of services, verification of obtaining dependencies, the order of unloading resources from memory. If these processes are left unchecked, we get incorrect program execution or even errors that block the execution process.
Transition processes
For the correct operation of the application, we need to control these states, have a convenient mechanism for transition between them, have an initial entry point in which the necessary dependencies are initialized in a controlled manner using services. And access to the services themselves is implemented using Dependency Injection.
In order to interpret the game cycle into a mathematical model, it is possible to use the Theory of Category. Consider the main analogies:
• Objects and Morphisms: In category theory, systems and their interactions can be modeled using objects (components, services) and morphisms (functions that describe interactions between these objects). In the context of Unity, this can be used to define the relationships between various game components, such as the Service Locator, DI, Factory, and State Machine. • Functors and Monads: Functors (structures that map objects and morphisms of one category to another) and monads (a type of functor that allows sequentially combining operations) can be used to model and manage data flows and dependencies in a system. • Sets and Subsets: Game elements (objects, components) can be represented as sets, and their properties and characteristics as subsets. This allows you to clearly define and manage dependencies and relationships between components. • Operations on Sets: Operations such as union, intersection, and difference of sets can be used to describe interactions between components. For example, combining sets can represent the integration of different services into one system. Application in Unity: • Service Locator: This can be represented as a centralized system responsible for tracking and providing access to various services (objects), using the principles of category theory to manage dependencies. • Dependency Injection: This can be interpreted through set theory, where dependencies between objects are represented as relations between sets. • Factory Pattern: Used to create objects, which can be viewed through the lens of category theory, where a factory is a functor that maps parameters to objects. • State Machine: This can be modeled using set theory, where states are represented as sets and transitions are represented as relationships between them.
• Scene Management: Category theory can manage scenes and transitions in Unity, treating each scene as an object and transitions as morphisms. • AI Systems: AI behaviors and decision-making processes can be modeled using functors and monads to manage state and behavior transitions. • Performance Optimization: By formalizing interactions and dependencies, category theory can help identify and optimize performance bottlenecks. • Scalability and Modularity: These theoretical approaches promote modularity and scalability, making it easier to update, test, and maintain the system. • Real-World Examples: For instance, consider a Unity project where the service locator pattern is used to manage audio, saving/loading, and networking services. Each service is an object, and interactions between services are morphisms. Using dependency injection, the audio service can be easily replaced without modifying the networking code.
Complexity: Implementing these concepts can be complex and may require a steep learning curve for developers unfamiliar with category theory.
Tools and Libraries: Utilize libraries and tools that support functional programming and dependency injection to facilitate the implementation of these concepts.
Integration: Ensure these theoretical approaches integrate well with Unity's existing architecture and components.
By combining the theoretical approaches listed above, it is possible to develop a flexible and scalable system for Unity that optimizes the management of dependencies and data flows in complex projects. The formalism provided by category theory and set theory can help in designing robust and maintainable game architectures, enhancing both development and performance.
States and state management are typically implemented using the Game State Machine pattern. A "State Machine" is a mathematical model used to describe the behavior of a system. It consists of a set of states, transitions and actions. A state represents a specific behavior or condition of a system, while a transition defines movement from one state to another. Actions associated with states or transitions represent the logic to be performed upon entering, exiting, or staying in a state [9].
Figure 3 shows the sequence of launching a software application (in particular, a game). The first step in implementing the State Machine is to define the states. Each state will be represented by a separate script (logic) that inherits from the IState interface, which declares 2 main methods: entering a certain state and exiting it.
The next step is to create a GameStateMachine class to manage state transitions and perform appropriate actions.
The GameStateMachine class can have different states (for example: `BootstrapState`, `LoadLevelState`, `LoadProgressState`, `GameLoopState`), which can be treated as objects in a category. The transition between states through the Enter() and ChangeState() methods can be analogous to morphisms that transform one object (state) into another.
One of the key aspects of category theory is the composition of morphisms, which in this case can be represented as a series of transitions between states. For example, going from
Game GameStateMachine -Loading screen -SceneLoader ...
LoadLevelState -Loading of a game level -Creating and loading game resources -Initialization of needed dependencies LoadProgressState `BootstrapState` to `LoadLevelState` and then to `GameLoopState`. The composition of these transitions (morphisms) creates a "path" through different states of the game.
In category theory, functors are mappings between categories. One can consider the interaction between different components of the system (for example, between `GameStateMachine` and specific states) as a functor-like relationship, where the behavior of one component determines the behavior of another.
A system of states can be considered as a category where states are objects and transitions between them are morphisms. Within a larger system (for example, the entire game), such a state system can be considered a subcategory.
In category theory, each object has an identical morphism that reflects the object in itself. This can be implemented as the ability of a state to remain unchanged if there is no transition to another state.
Consider the following formula (1), which describes the transition from BootstrapState to GameLoopState via LoadLevelState:
(1) This equation can be interpreted as a composition of two morphisms:
1. BootstrapState->LoadProgressState. This morphism corresponds to the transition from BootstrapState to LoadProgressState.
LoadProgressState to GameLoopState.
The composition of these two morphisms gives the BootstrapState -> GameLoopState morphism, which corresponds to a direct transition from BootstrapState to GameLoopState.
This example demonstrates how category theory can be used to describe and understand transitions between states in a system of game states.
This mathematical model is a simplified representation of the system of game states. A real system can be much more complex, with more states, transitions, and interactions.
Category theory provides a powerful toolkit for modeling and analyzing systems of states, but understanding and applying its concepts requires some knowledge of abstract mathematics.
Designing the structure of a service-oriented application (SOA, Service-Oriented Architecture) in Unity requires an understanding of both the basic principles of SOA and the specifics of Unity as a game engine. The main idea of SOA is to create modular, independent services that can be easily replaced, updated, or modified without affecting other parts of the system [10].
SOA defines a way to make software components reusable and interoperable through service interfaces. Services use common interface standards and an architectural pattern so that they can be quickly integrated into new applications. This relieves the task of the application developer who previously redesigned or duplicated existing functionality or had to know how to connect or ensure compatibility with existing functionality.
Each service in an SOA contains the code and data needed to perform a complete, discrete business function (such as checking a customer's creditworthiness, calculating a monthly loan payment, or processing a mortgage application). Service interfaces provide free communication, that is, they can be called almost without knowing how the service under them is implemented, which reduces the dependency between applications.
Below are the key considerations for SOA design in Unity:
• Definition of Services: Functional elements of the application can be separated as independent services. These can be, for example, the game save system, sound management, network interactions, advertising management, etc. • Service Interfaces: It is necessary to clearly define the interfaces for each service. This will allow replacing service implementations without the need to change the code that uses these services. • Dependency Checking and Dependency Injection: Using the Dependency Injection pattern will help manage dependencies between different services and components. This can be implemented through constructors, setters, or through special frameworks (Zenject [15], VContainer [16]). • Projecting to the Service Manager: To manage services, it is necessary to create a central service manager (Service Locator), which will be responsible for initialization, storage, and access to various services in the application. • Design of Modular and Flexible Architecture: Each service must be designed so that it is selfsufficient and can function independently of other parts of the system. This will provide high flexibility and simplify testing and project development.
• Deployment and Updating of Services: Methods of deployment and updating of individual services should be able to update services without stopping the entire system. • Testing: Each service is designed taking into account the possibility of its testing.
Automated testing is a key element in maintaining high code quality and system stability. • In Unity, SOA can be implemented both with the help of built-in tools (for example, through MonoBehaviour components) and with the help of external libraries or frameworks. The main thing is to keep the focus on clearly defining the roles and responsibilities of each service, as well as on the flexibility and extensibility of the architecture.
Additional Considerations for SOA Design in Unity:
First of all, we need to create two scenes: InitialScene -where we will manage the loading of the app, resolving dependencies, taking saves, and other preparing actions; MainScene (it can be level, menu, lobby scene whatever that can be after loading scene). The next step is to set up the DI container. In our case for Unity, we need to import the Zenject package. After importing we can set up Project Context, and Installers for every scene. This allows as then bind needed components and inject dependencies where we need them. Also, we need to add a SceneContext component for every scene and create and assign installers to this context. Inside these installers we can bind the Service locator to have access from any place, only need to define it with the [Inject] attribute.
Based on the previous explanations about categories Scenes are also objects and switching between them is a morphism. Switching contains a few steps (states) that we manage by StateMachine. That is why the state itself needs to contain two main methods (Fig. 4) Enter() and Exit() something can happen when we go to the next state and if we exit we first need to clear memory, unsubscribe, and dispose. Sometimes we need additionally to have the ability to loop or update something inside the script for these purposes we can use other interfaces to extend our functionality. We defined states [17] and separated needed logic for loading and play sessions (Fig. 5). In the Bootstrap state we register all our services. Then go to the next scene through LoadLevelState. Usually, we have some stored data on the client or server, for this purpose, we can use LoadProgressState and load if exists or create new data if needed. To store data locally or on the server we can create a SaveData service and register it in the BootstrapState. Then every needed logic we as a service and use it from any place.
In the course of the study, the key provisions of the theory of categories were analyzed, which became the theoretical basis for the development of the application design methodology.
It was proposed to interpret the life cycle of the application as a set of states of the program, which go from one to another with the help of the "State Machine". The composition of these states can be represented as a composition of morphisms, a mapping of one state into another, which follows from the theory of categories.
The described interpretation enables a controlled scaling of the project architecture and improves the understanding of the execution of processes and logic in the application. New logic we can represent as a service and need only register it to use somewhere. This type of architecture allows us in a comfortable and faster way extend or change our logic, only by replacing the service. The next step for improvement will be to manage the realization of the services interface for example by Strategy pattern.
The proposed technique is a theoretical foundation for the development of flexible architectures of multimedia applications. It takes into account the specifics of component-oriented and serviceoriented architectural styles, as well as the peculiarities of the functioning of game engines.