Project structure

Project structure

Hello, colleagues. It's time to move from the description of the blog to the description of the project. In this article I will talk about the structure of the project:

• The order of files and folders, why exactly so, what other options are there
• General code architecture
• Tips for organizing code in projects
• Initialization procedure

File Order

In general, at work we used two approaches to organize files in the project: sort into folders by file type or by semantic community (ala asset or game mechanics). Are all the scripts in one folder, and all the textures in another? This is sorting by file type. If all textures, materials, animations and scripts belong to the same game mechanics and are in the game mechanics folder, then this is the second type of order in the project.

For a long time we stuck to the first option, but in practice sooner or later you come to the following conclusions:

• In the development process, you are not working with files as such, but with game mechanics (with files that relate to it). It's terribly inconvenient to search for a script in one folder, edit a shader in another folder, far from the first one. You seem to be working on one brick of the project (on one game mechanic), and the files are scattered throughout the project. It's terribly inconvenient.
• If you download ready–made assets from the Asset Store, then they are downloaded exactly as described above - a separate folder of game mechanics, inside which everything that relates to it: scripts, textures, animations, sounds.
• So and so you use both approaches, but at different scales. Globally, folders are formed according to game mechanics, but inside these folders there are Scripts, Sources, Prefabs folders.

The Council. From the very beginning to the end of working on the game, adhere to some kind of order and do not stop following it. Unsorted files and ill-conceived architecture accumulate each time and complicate the development process more and more. You just don't want to figure it all out anymore. Robert Martin's book "Clean Code", as it seemed to me, first of all teaches you to adhere to order. And what kind of order, it's up to you to decide. Stick to it.

The structure of code

All Unity projects are a monolithic application. Internally, we can use different approaches, for example, MVC and its varieties or ECS (DOTS is built into Unity).

Advice. Do not forget to use namespaces, it helps a lot to organize the work of the code. Another option that I did not lean towards is AssemblyDefinition. As for me, this method is inconvenient because of the sensitive settings. And you may not understand for a long time why the code is not compiled, and who should refer to whom. It sounds like an excuse, but I didn't come up with this method, I just use namespaces.

The project has a common namespace IndieBroGames, inside which there are others. For example, IndieBroGames.Common contains my accumulated database of scripts, the database was formed in the process of working on other projects, includes my work, modified versions of other scripts and other people's experience. This namespace has no project-specific dependencies and is used unilaterally in each project.

And there is the IndieBroGames.Soulskiller namespace, which the scripts of this game belong to. This namespace can use scripts from IndieBroGames. Common. Here, a specific implementation of game mechanics related only to this game is being formed.

Under IndieBroGames.Soulskiller are the rest of the namespaces, which are sorted... by game mechanics, like folders in which these scripts lie. For example, the behavior of opponents is based on a state machine (we'll talk about this later), where the state machine is located in the IndieBroGames.Common namespace.StateMachineSystem, and the states of the opponents are inherited from the abstract class State.

Initialization procedure

The beginning of the game's beginnings is the first scene for initializing the kernel from the IndieBroGames namespace. Common. In fact, Core is the point at which all major systems are initialized, and it is also a facade for accessing all these systems.

The core includes a save system, localization, asynchronous scene loader, pause mechanics, and some other things.

The second scene is the initialization of the project core and the selection of presets – localization language, volume and vibration.

The core of the project, by analogy, contains things that need access during the game. Only those things that relate to this project.

After all initializations, the scene with the shelter of the main character, the hunter of evil spirits, starts.

Completion

What did you say wrong? What other ways are there to streamline a project? Thoughts, criticism? Write, let's read it.

Developer page | Project page | YouTube | e-mail | Support