What do we need?

Yes, in the last article of the cycle here we decided on the concept of the game, gameplay and software tools. It’s time to talk about the architecture, the organization of the gameplay, what and how it will happen. In order to decide on the organization of all processes in the game, it is necessary to understand which functionality should be implemented in general. We already talked about this in the last article, in the gameplay section, but let’s quickly mention it here:

• Story mode – a set of linearly connected levels, each of which has some story dialogues at the beginning or at the end, or at the beginning and at the end.

• Endless mode – a mode in which the waves of enemies are endless, which are constantly made more difficult by strengthening enemies or increasing their number.

• Online mode is a mode in which two players meet in the same game space and jointly build a defense using a shared space.

• General technologies – the previous two points require the creation of an additional menu of technologies. Since the state of the tech tree is local to and tied to each playthrough of the story mode, there is some ambiguity as to where to get the Endless Mode and Online Mode tech. To solve this problem, we will create a section of common technologies, where all technologies ever discovered, in any playthrough, will be studied.

This is about the obvious. Menu, settings, etc. – self-explanatory.

Scenes and chapters

Now, after clarifying the abstract sections of the game, let’s move on to something more concrete – to the scenes. The Unity manual says the following about scenes – “Scenes contain the objects of your game. They can be used to create the main menu, individual levels and other purposes. You can think of each scene file as a separate game level. Within each scene you can place objects of the environment, barriers , scenery, piece by piece creating the design and the game itself.” The abstract sections of the game may not coincide with the set of scenes in the game. For example, game settings can be placed in the same scene in which the menu is located and simply opened by pressing the appropriate button. So you won’t have to create a separate scene for settings. The opposite happens when one abstract section of the game occupies several scenes. Let me depict my idea schematically, and then I will explain everything

Yellow blocks are scenes, and green blocks are purely logical entities. As you can see, some logical entities consist of several scenes:

• Endless Game – This section involves playing a level where the enemies never end, but what about choosing the level itself? After all, we can’t just click “Infinite Game” and expect the program to figure out where we want to play. At least you need to choose a card. The task of presetting the game requires a scene dedicated to this process – the level creation menu. Only after the preliminary setup, the player can enter the Level and start the game. The scene on which the direct gameplay takes place will be called the Level. First, there will be more than one level, but the structure of all +- will be the same, so we mark them as one scene. Second, the levels for Story Play, Endless Play, and Online Play will be different, so we’re splitting them up. Obviously, an Online game will require a different level architecture to support two-player online interaction, just as a level in an Endless game will differ from a level in a Story game. Together we have two scenes for one logical entity.

• Online game – here we will have to provide both the opportunity to join someone else’s game and to create our own. For each task, we will allocate a scene and another scene for the level. We get three scenes for one game section.

• Story game – for this section, we will need a menu in which we can choose a level for the game and conduct the necessary research, discover new technologies. All this functionality can be put in one scene – the Walkthrough Menu, making the map and technology tree just different tabs on the scene. You will also need a scene for the level.

Also, one scene contains several logical entities:

• Menu – in the menu we can implement all the necessary menu functionality, while adding settings as a subdivision. We will not have to go to another scene to change the settings – we will simply open the subsection immediately in the menu, change the parameters and save them, after which we can collapse the settings.

And so there remains a logical essence that requires one scene:

• General technologies – a section in which all studied technologies are collected. Used for Online mode and Endless mode

Connections and logic of transitions

Now that we’ve decided on a set of scenes, let’s define their relationships. Usually – first the diagram, and then the explanation:

In general, the schemes are extremely clear, but I will describe them in a few words:

The menu, as a logical entity, is naturally the starting point in the entire game – it contains transitions to all other sections of the game. Each chapter has a central or entrance scene. For an online game, this is, for example, a game selection lobby. For the Story game, this is the walkthrough menu, and for the Endless game, this is the level creation menu.

In the future, in each chapter of the game, the movement between scenes occurs according to the internal logic of the chapter, but between chapters, transitions are made only through one scene, which we defined as the input.

The transition diagram immediately gives us an understanding of which buttons should be present in the scene to provide these transitions. The highest minimum, which can be expanded in the future:

• The main menu – here we need to provide buttons for the following transitions:

  • Story game

  • Endless game

  • Online game

  • General technologies

• Story Game (Walkthrough Menu)

• Endless Game (Level Creation Menu)

• Online game (Game search lobby)

• General technologies

We implement the structure in Unity

Undoubtedly, this is far from all that should be provided. Also, in the Main menu, it is necessary to provide the ability to open settings, for example. We haven’t said anything yet about transitions in other scenes and a bunch of other little things. However, we already have a general scheme of scenes and logical partitions of the game, which gives us the opportunity to implement this scheme in Unity right now, by going into our project, creating the necessary folders (logical partitions) and scenes.

Result

We already have a ready-made general structure of sections and scenes of the game, as well as a diagram of transitions, from which we determined the minimum number of buttons in the interface of the scenes. In the future, we will look at the architecture in more detail and focus on each section separately, and then on each scene. The lower we go, the more we specify the necessary functionality.

PS

I apologize to those who were waiting for a new article – the delay happened due to problems with health and employment. I will try to write faster in the future and hope that the next article will not make me wait as long as this one. At the end, I will ask you to subscribe to our main resource in VK here. There we share our work from music to 3D animations, and your subscription will help us a lot. Thank you in advance.