Architecture simple 2D games on unity3d. Plan, fact and work on the bugs
Recently, the Whistling Kite Framework team released another game, this time the Snake, written in Unity3D. As with most game projects, when deciding how much detail you need to design an application, time was a critical factor. In our case, the reason is simple: development was carried out in his spare time from the main work, then the ideal approach to design would postpone the release for another year. Therefore, having made the initial division into modules, we completed the design and began to develop. Under the cut description of what came out of it, as well as a couple of lessons that I learned for myself.
Careful, pictures!
I just want to insert a reservation: everything described below is only a retrospective of events and an attempt to analyze what went well and what went wrong. The article does not pretend that it contains an indisputable truth, rather even the opposite - “bad advice”, which, perhaps, will save someone from the same mistakes.
First, a couple of words, in fact, about the application, so that it is clear what we designed and developed. Creating a snake, we tried to recreate exactly the good old classic snake, in which there was nothing but a snake, apples, walls and an infinite desire to move on. That is why we focused on the classic gameplay, knowingly excluding from it at this stage all the additional features.
')
One of the main advantages of our snake is a variety of management options that you can find in the settings. We tried to provide them all:
We plan to add two more:
Dialed in the party rating is recorded in the table of records. Record can be shared with friends via SMS, mail or any social network connected to the smartphone - Twitter, VKontakte, Facebook, etc.
We made the decision to start developing the snake, pursuing two goals:
The first, conceptual version of the architecture was created by us before the choice of unity. It is shown in the picture below. In this embodiment, we have identified the layers of the future application:
Historically, the most recent initialization layer was selected, although in the application it should have been launched first. The fact is that we first laid the initialization of objects into the objects themselves, but then decided to allocate it centrally.
The layers of the interface, logic, and controllers are almost the classic MVC pattern. At the same time, there was a desire to divide the processing of these layers even into different streams in order to ensure maximum smoothness of the interface.
The management layer was rendered separately, because we decided that various management options would be one of our main features, so it was necessary to make sure that the rest of the application did not depend on the option chosen.
All layers had to communicate with each other through dedicated interfaces, each layer contained its objects and performed its functions, often contained its own processing flow.
Good ideas:
Slips:
The next step was the choice of the platform, although, strictly speaking, the choice was made between unity and development on pure java. A cursory review of other existing engines did not arouse enthusiasm in studying them. We came to a rather expected conclusion: it is easier to write a snake at all without a platform, besides, it looked more interesting - who does not like to make their bikes? However, we chose unity, in order to familiarize ourselves with the platform, which is close to the status of the standard de facto in the field of game-deva. Yes, we received a solid overhead projector due to the fact that unity is a three-dimensional engine (at the time of its development, unity still did not have native 2D support), but we did a two-dimensional game, but the experience gained was worth it.
While choosing a platform, we jointly wrote a design document, and already on its basis a second architecture project was born, sharpened for the chosen platform.
This architecture consisted of several related diagrams, which I call the terms uml below, although, of course, they follow the standard, to put it mildly, not completely.
Entity-connection (it is clear that this is more related to the category of requirements for the system than to its architecture, but in the context of the article I cannot but mention it:
ERD notation, I think everyone is familiar. It presents all the objects of game logic and logical connections between them. Each such object generates one class that ensures the operation of this object.
Component and collaboration diagrams. For their perception, I will first describe a number of agreements:
General architecture - is of a general conceptual nature, being, in essence, a continuation of the diagram of stage 1. It displays:
Detailing diagrams contain:
In general, the concept has not changed much: there is also a separate component for initialization, then two main subsystems are highlighted.
After starting the application, the initialization component starts working first: it requests all necessary data from the storage and initiates the GUI subsystem.
The GUI subsystem should provide the user with the main menu, settings and records. At the start of the game, the control is transferred to the control subsystem.
The control subsystem should provide user interaction with the game world, first of all it is the management of the snake itself.
Separately highlighted components for logging and sharing records.
The game world consists of objects taken from the ERD. The key role is played by the party and the snake.
The party stores links to the snake and the current copy of the fruit, provides initialization of game objects and their interaction.
Snake handles the main game events: own movement, eating fruit and collisions with walls or tail.
The fruit is responsible for controlling its own lifetime.
Good ideas:
Slips:
After the start of development, no one has corrected the architecture. I just left separate notes in the appropriate section of the design document on how certain bottlenecks are implemented, but the main goal was to release the release. Well, we have achieved this goal, and I sat down to refactor in order to prepare for the development of the second release. Already at that moment I understood that first of all I had to transfer the game to an honest 2d, whose support had just appeared in the unity. And there was also an understanding that the result was far from ideal, primarily in terms of the division of functions into objects and their interaction, therefore, I set myself two tasks:
Based on this information, I planned to get a list of what needs to be changed. The results of such reverse engineering are presented below; in each section, I first briefly describe what this section is about, then provide one or more diagrams illustrating the solution built, and then describe in detail what was done and how.
The diagram below shows all the classes created during the development of the game. The diagram hides some of the methods that do not carry a semantic load or are so trivial that they are not worth mentioning. Also, often under the variable name (for example, textures) hides a whole block of variables (in this case, various textures).
All available classes are divided into four packages:
In the game logic package, the central place is occupied by the party class, which is a single game party. This class is responsible for the start and end of the game, for the calculation of the rating, for coordinating the events of eating an apple and the expiration of the apple's lifetime, and many other auxiliary functions. While this article was being written, I practically rewrote this class, leaving in it only calls to methods from other classes (actually, a snake and an apple). This is more in line with encapsulation requirements, but made this class even more like a controller in terms of MVC.
The second most important class Snake contains the logic of the movement of the snake, including the management of dependent objects of the class Snakechain. It is this class that control controllers transmit commands.
A factory is used to create fruit instances (FruitInstance), since In the future it is planned to increase the number of different types of fruits.
The package with interfaces contains separate classes that are responsible for the display and processing of the user interface, depending on the situation. In the same place pressing of iron buttons on the device is processed.
The controller package contains control classes. They are added to the snake and interact directly with the Snake object using the command pattern, and the snake executes the incoming commands in the same sequence, but separately along its steps. This was done to correctly process fast sequential commands, for example, to rotate 180 degrees along its tail.
The package with providers contains only one class that is interesting for this article - this is dataProvider. This class contains a set of static functions that are a wrapper over calls to standard methods for working with stored properties. At both previous design stages, work with the stored data was assumed only once: load them into memory and no longer access slower media. This approach did not take into account the issue of independence of scenes in Unity: as a result, when moving between the scenes of the main menu and the playing field, all the necessary data had to be re-read.
Below is a description of the initial state of the two scenes of which the game consists: the scene of the main menu (in the figure below left) and the scene of the playing field (in the figure below to the right). The initial state is determined by what was entered in the editor, before running any executable code. It is from these states that most of the sequence diagrams start below.
The main menu is created by two classes, Player and GUInavigator, attached to a single object on the stage, to the camera. Player is responsible for loading all the basic information about the player, and GUInavigator initiates the desired behavior from the interface pack and provides further transitions between interfaces.
The game scene contains much more objects. Most of them are static, representing the world of the snake: background, playing field, walls. Additional behaviors are attached to only two objects: the camera (GUInavigator, Player, party, fruitfabric) and the snake head (Snake, Controllerselector). The controllerselector is responsible for selecting the controlling controller according to the player’s settings.
The diagram below represents the procedure for starting the application (in that part of it that is controlled by the developer). Particular attention can be paid unless the alternative exit from the script and the transition to loading the game, if there is a saved unfinished game.
An application load consists of handling two events: awake and start. The awake event processes the player object: at this point, it accesses the DataProvider to load player information, and then calls its own method that is responsible for applying the current settings, such as muting.
The Start event is handled a little more complicated:
Next, we consider a sequence diagram illustrating the actions when starting a game. The starting point is loading the scene with the game.
In this diagram, it is worth noting an alternative scenario of loading a saved game — this is necessary for the case of interrupting a game, for example, with an incoming call.
The first trigger events are Awake for Player objects (loading all settings, similar to starting an application) and Snake (Init () method - initializing the tail by default from two segments). Then the Start event is triggered to select a controller (for example, FourButtonController is used), load the GUI and initialize the game. A little more about handling this event:
The game logic is centered around the processing of two events: update is processed in the snake by the movehead method, here the snake moves and controls the movement of its segments; and ontriggerenter, where the handling of collisions of the head of a snake with fruit, walls and its own tail.
Let us examine the collision event in more detail:
The movement of the snake is implemented as follows:
A lot of logic remains outside the scope of this article: it is logging, both internally and using external analytics; this is the work of the interface navigator, which encapsulates all the features associated with the two scenes; This work with data, with the device, display of advertising and many other features. If anyone is interested, I can write about it separately.
The main problems identified are:
What conclusions for future projects, I did, based on the foregoing?
If you see some other not optimal solutions, then please speak in the comments, we will be happy to discuss.
Just in case, at the end I cite all the links relevant to the article:
PS During the preparation of this article, some of the errors found have already been corrected, and probably new ones were introduced, because development does not stand still.
Careful, pictures!
I just want to insert a reservation: everything described below is only a retrospective of events and an attempt to analyze what went well and what went wrong. The article does not pretend that it contains an indisputable truth, rather even the opposite - “bad advice”, which, perhaps, will save someone from the same mistakes.
Functionality
First, a couple of words, in fact, about the application, so that it is clear what we designed and developed. Creating a snake, we tried to recreate exactly the good old classic snake, in which there was nothing but a snake, apples, walls and an infinite desire to move on. That is why we focused on the classic gameplay, knowingly excluding from it at this stage all the additional features.
')
One of the main advantages of our snake is a variety of management options that you can find in the settings. We tried to provide them all:
- 4 buttons - set a new direction of movement;
- 2 buttons - turn left / right from the current direction;
- Swipe - hold your finger in the right direction.
We plan to add two more:
- gyroscope - the tilt of the device sets a new direction;
- “bubble” joystick - shifting a finger from the first touch point sets a new direction.
Dialed in the party rating is recorded in the table of records. Record can be shared with friends via SMS, mail or any social network connected to the smartphone - Twitter, VKontakte, Facebook, etc.
We made the decision to start developing the snake, pursuing two goals:
- Having tried most of the "snakes" existing under Android, we did not find one that several team members wanted to play in, we decided to correct this situation;
- We first decided to enter the mobile market and use the Unity3D engine, so we chose a deliberately simple game to get used to it.
Architecture
Stage 1. Concept
The first, conceptual version of the architecture was created by us before the choice of unity. It is shown in the picture below. In this embodiment, we have identified the layers of the future application:
- Initialization layer;
- Interface layer;
- Logic layer;
- A layer of controllers;
- Control layer
Historically, the most recent initialization layer was selected, although in the application it should have been launched first. The fact is that we first laid the initialization of objects into the objects themselves, but then decided to allocate it centrally.
The layers of the interface, logic, and controllers are almost the classic MVC pattern. At the same time, there was a desire to divide the processing of these layers even into different streams in order to ensure maximum smoothness of the interface.
The management layer was rendered separately, because we decided that various management options would be one of our main features, so it was necessary to make sure that the rest of the application did not depend on the option chosen.
All layers had to communicate with each other through dedicated interfaces, each layer contained its objects and performed its functions, often contained its own processing flow.
Good ideas:
- Selection of the initialization layer: this was lost in later versions, which sometimes led to rather confusing sequences of actions.
- The correct general structure of the division of the application into modules: the boundaries later differed and the concept of encapsulation was almost forgotten (you can bring the picture "there is a bug" with cats, only replace it with "so it is impossible! How does encapsulation"
Slips:
- Separate layers of controllers and control: subsequently, controllers in terms of MVC were abandoned due to redundancy.
- Too high level description: it is not clear what code to write . Although this can not be called a pure slip, because at the time of this architecture was not selected yet engine.
The next step was the choice of the platform, although, strictly speaking, the choice was made between unity and development on pure java. A cursory review of other existing engines did not arouse enthusiasm in studying them. We came to a rather expected conclusion: it is easier to write a snake at all without a platform, besides, it looked more interesting - who does not like to make their bikes? However, we chose unity, in order to familiarize ourselves with the platform, which is close to the status of the standard de facto in the field of game-deva. Yes, we received a solid overhead projector due to the fact that unity is a three-dimensional engine (at the time of its development, unity still did not have native 2D support), but we did a two-dimensional game, but the experience gained was worth it.
Stage 2. Project
While choosing a platform, we jointly wrote a design document, and already on its basis a second architecture project was born, sharpened for the chosen platform.
This architecture consisted of several related diagrams, which I call the terms uml below, although, of course, they follow the standard, to put it mildly, not completely.
Entity-connection (it is clear that this is more related to the category of requirements for the system than to its architecture, but in the context of the article I cannot but mention it:
ERD notation, I think everyone is familiar. It presents all the objects of game logic and logical connections between them. Each such object generates one class that ensures the operation of this object.
Component and collaboration diagrams. For their perception, I will first describe a number of agreements:
General architecture - is of a general conceptual nature, being, in essence, a continuation of the diagram of stage 1. It displays:
- System components (rectangles);
- Storage subsystem (symbol DB, magnetic disk);
- Notes (yellow “leaflets”);
- Control flows (filled arrows);
- Data streams (dotted arrows).
Detailing diagrams contain:
- Components, objects (rectangles);
- Events processed by objects (hexagons);
- Actions performed on events (ellipses).
In general, the concept has not changed much: there is also a separate component for initialization, then two main subsystems are highlighted.
After starting the application, the initialization component starts working first: it requests all necessary data from the storage and initiates the GUI subsystem.
The GUI subsystem should provide the user with the main menu, settings and records. At the start of the game, the control is transferred to the control subsystem.
The control subsystem should provide user interaction with the game world, first of all it is the management of the snake itself.
Separately highlighted components for logging and sharing records.
The game world consists of objects taken from the ERD. The key role is played by the party and the snake.
The party stores links to the snake and the current copy of the fruit, provides initialization of game objects and their interaction.
Snake handles the main game events: own movement, eating fruit and collisions with walls or tail.
The fruit is responsible for controlling its own lifetime.
Good ideas:
- Allocation of two main independent subsystems: this was not taken into account during development, which initially led to a large number of unnecessary scenes.
Slips:
- Does not take into account the separation by scenes and work with the storage subsystem from the game scene
- It does not answer the question of how to implement the GUI subsystem and how the subsystems interact with each other.
- The Batch object took over the functions of the controller in terms of MVC.
Stage 3. Actual result
After the start of development, no one has corrected the architecture. I just left separate notes in the appropriate section of the design document on how certain bottlenecks are implemented, but the main goal was to release the release. Well, we have achieved this goal, and I sat down to refactor in order to prepare for the development of the second release. Already at that moment I understood that first of all I had to transfer the game to an honest 2d, whose support had just appeared in the unity. And there was also an understanding that the result was far from ideal, primarily in terms of the division of functions into objects and their interaction, therefore, I set myself two tasks:
- Create a general class diagram
- Create sequence diagrams for the main application scenarios.
Based on this information, I planned to get a list of what needs to be changed. The results of such reverse engineering are presented below; in each section, I first briefly describe what this section is about, then provide one or more diagrams illustrating the solution built, and then describe in detail what was done and how.
Overview of the created classes
The diagram below shows all the classes created during the development of the game. The diagram hides some of the methods that do not carry a semantic load or are so trivial that they are not worth mentioning. Also, often under the variable name (for example, textures) hides a whole block of variables (in this case, various textures).
All available classes are divided into four packages:
- Gamelogic - classes for game objects that exist on the irg field are presented here. In essence, this is the core of the game.
- Gui - here are classes that are responsible for building a static user interface: the main menu, settings, records and buttons on top of the playing field, in addition to the buttons for direct control of the snake.
- Controllers - this is the highlight of our application: a package with a variety of ways to control the snake. Each class fully contains everything you need for the chosen management style: from the interface buttons to the logic of calculating the rotation.
- Providers - this package contains auxiliary classes that provide functions such as reading and saving data, the ability to share a record, logging, analytics, etc.
In the game logic package, the central place is occupied by the party class, which is a single game party. This class is responsible for the start and end of the game, for the calculation of the rating, for coordinating the events of eating an apple and the expiration of the apple's lifetime, and many other auxiliary functions. While this article was being written, I practically rewrote this class, leaving in it only calls to methods from other classes (actually, a snake and an apple). This is more in line with encapsulation requirements, but made this class even more like a controller in terms of MVC.
The second most important class Snake contains the logic of the movement of the snake, including the management of dependent objects of the class Snakechain. It is this class that control controllers transmit commands.
A factory is used to create fruit instances (FruitInstance), since In the future it is planned to increase the number of different types of fruits.
The package with interfaces contains separate classes that are responsible for the display and processing of the user interface, depending on the situation. In the same place pressing of iron buttons on the device is processed.
The controller package contains control classes. They are added to the snake and interact directly with the Snake object using the command pattern, and the snake executes the incoming commands in the same sequence, but separately along its steps. This was done to correctly process fast sequential commands, for example, to rotate 180 degrees along its tail.
The package with providers contains only one class that is interesting for this article - this is dataProvider. This class contains a set of static functions that are a wrapper over calls to standard methods for working with stored properties. At both previous design stages, work with the stored data was assumed only once: load them into memory and no longer access slower media. This approach did not take into account the issue of independence of scenes in Unity: as a result, when moving between the scenes of the main menu and the playing field, all the necessary data had to be re-read.
Initial states
Below is a description of the initial state of the two scenes of which the game consists: the scene of the main menu (in the figure below left) and the scene of the playing field (in the figure below to the right). The initial state is determined by what was entered in the editor, before running any executable code. It is from these states that most of the sequence diagrams start below.
The main menu is created by two classes, Player and GUInavigator, attached to a single object on the stage, to the camera. Player is responsible for loading all the basic information about the player, and GUInavigator initiates the desired behavior from the interface pack and provides further transitions between interfaces.
The game scene contains much more objects. Most of them are static, representing the world of the snake: background, playing field, walls. Additional behaviors are attached to only two objects: the camera (GUInavigator, Player, party, fruitfabric) and the snake head (Snake, Controllerselector). The controllerselector is responsible for selecting the controlling controller according to the player’s settings.
Application launch
The diagram below represents the procedure for starting the application (in that part of it that is controlled by the developer). Particular attention can be paid unless the alternative exit from the script and the transition to loading the game, if there is a saved unfinished game.
An application load consists of handling two events: awake and start. The awake event processes the player object: at this point, it accesses the DataProvider to load player information, and then calls its own method that is responsible for applying the current settings, such as muting.
The Start event is handled a little more complicated:
- The GUInavigator in the initMain method initiates all the interfaces required in a given scene, each with a sign of inactivity.
- Next, he checks to see if the unfinished game has been saved. This is possible, for example, when the game is interrupted by an incoming call.
- If there is a game, the game scene is loaded, and this script is interrupted.
- Conditionally at the same time, Start events for all initiated classes of interfaces are processed — they are additionally initialized inherent to each specific interface separately (including the interface of records loads data on the table of records using dataProvider).
- The main menu interface is assigned a sign of active, and it is displayed to the user.
Running game
Next, we consider a sequence diagram illustrating the actions when starting a game. The starting point is loading the scene with the game.
In this diagram, it is worth noting an alternative scenario of loading a saved game — this is necessary for the case of interrupting a game, for example, with an incoming call.
The first trigger events are Awake for Player objects (loading all settings, similar to starting an application) and Snake (Init () method - initializing the tail by default from two segments). Then the Start event is triggered to select a controller (for example, FourButtonController is used), load the GUI and initialize the game. A little more about handling this event:
- Controller selector in the Start event, checks the player settings and loads the desired control controller.
- The GUInavigator in the initGame method initiates all the interfaces required in a given scene, each with a sign of inactivity. The definition of which method to call is based on the parameter set through the editor. Initialization and activation of the active interface is similar to the launch of the application.
- The Start event then processes the party object. First of all, it checks if there is a saved game.
- If there is a game, then party calls dataProvider for recovery, which, after reading the data, calls the party's Restorebackup method.
- He, in turn, calls the analogous method of the Snake object, and that one along the chain for all links.
- After data recovery, control is returned to the party object, it includes a pause and waits for the player to take action.
- If there was no game, then the party calls the fruit factory to create an instance and the game begins. By the way, the diagram shows that party is also responsible for setting a number of parameters for a fruit - now this is no longer the case: all necessary actions are encapsulated either in a factory or in a fruit instance.
Game Cycle: Snake Move
The game logic is centered around the processing of two events: update is processed in the snake by the movehead method, here the snake moves and controls the movement of its segments; and ontriggerenter, where the handling of collisions of the head of a snake with fruit, walls and its own tail.
Let us examine the collision event in more detail:
- When an event occurs, it is first checked who we are faced with: if it is an apple, then the Eatfruit method is called, and if the tail or wall, then Killme. In both cases, the collision information is reset to the logs.
- Apple case:
- Snake sets a flag to add a link and calls the party's Eatfruit method.
- Party increases the party's rating and calls its own createfruit method, also used when starting the game.
- In this method, the current fruit instance is first deleted, and then a new one is created through a call to the factory.
- Wall or tail case:
- The snake passes the event handling to the party object in the Endgame method.
- Party sets the pause mode and, through the interface navigator, takes the player to the screen with the results of the party.
The movement of the snake is implemented as follows:
- In the update event, the movehead method is called.
- Here the snake speed is checked: the moment of transition has come or not
- If yes, then check the flag of the need to add a link
- If necessary, a link is created that is analogous to the one following the head.
- Only the head and one newly created link are shifted.
- If there is no flag, then the head is displaced, and after it, along the chain, all links, by the method of adjust.
Conclusion
A lot of logic remains outside the scope of this article: it is logging, both internally and using external analytics; this is the work of the interface navigator, which encapsulates all the features associated with the two scenes; This work with data, with the device, display of advertising and many other features. If anyone is interested, I can write about it separately.
The main problems identified are:
- Replacing 3d to 2d. This does not follow from the diagrams, but it is obvious from the point of view of the preference of using tools for their intended purpose.
- The party object is too overloaded with functions: it controls both apples, and snake, and the handling of the completion of the game.
- The game interface is overloaded - it should be divided into two states: in the game and after the collision.
- There is no facade for working with device functions not provided for by the engine: in our case, for android, this is the overridden vibration method, the implementation of the share button (calling the system window to select an application) and the implementation of Google analytics calls.
What conclusions for future projects, I did, based on the foregoing?
- You need to know the platform before you take on something serious. This is obvious in general, but just in case I decided to repeat it, maybe someone will save the top MMO from experience without launching another killer.
- It is necessary to design the separation of an application (even a simple one) into components. At this stage, the main thing is to minimize the number of interactions and data flows.
- Thinking through the structure of classes, you need to immediately think about how objects will relate to the components and what functions (groups of functions) they will perform.
- On the one hand, you need to keep in touch with the planned architecture, but on the other hand, you need to be ready to change it when new conditions arise.
If you see some other not optimal solutions, then please speak in the comments, we will be happy to discuss.
Just in case, at the end I cite all the links relevant to the article:
- Unity3d
- The architecture diagram for stage 1 is drawn in yEd .
- Phase 2 architecture diagrams are drawn on the andoroid-tablet in DrawExpress Lite ;
- Phase 3 architecture diagrams are drawn in Visual Paradigm ;
- Discuss the application can be viewed in play.google .
- You can learn more about our team on our website .
PS During the preparation of this article, some of the errors found have already been corrected, and probably new ones were introduced, because development does not stand still.
Source: https://habr.com/ru/post/231087/
All Articles