How to: Project Architecture for Unity3D or Spaghetti code? [closed]

Question

For more than 2 decades that I am writting code (several programing languages) and in all I had always used design patterns and several kinds of architertures..... Layers, separation of responsabilities, different class libraries, clients / servers, etc...

However, during this weekend just for fun and for curiosity I have installed Unity 3D and gave it a shot. Although I was able to open the files in Visual Studio, I did not understand the default file structure of the unity project.

I created nested folders in order to organize my code, but as soon as I was trying to create a class many questions arised:

• Where is the namespace? Why do I need to write them myself? Shouln'd they be automatic and taking in consideration the "folders" structure?
• How can I create/reuse/import different project class libraries?
• how to manage nuget packages?
• and everything that I have been doing all my life in programming.....

I found an article with some info, but that is it... nothing else.

I was wondering if someone could point me to the right direction regarding this subject.

Thanks.

Answer 1

Basics (traditional scripts)

In Unity C# is used as a scripting language, subject to many limitations and intended to be used in a pattern. Every Unity script derives from MonoBehaviour, which as you can read in the documentation implements specific methods. Moreover you can not use the new constructor but must use a factory method called Instantiate. Nonetheless you can use other classes as long as they are included correctly and used by any MonoBehaviour script class.

While the topic is subject to opinion, you can find opinion on how C# scripts are not well structured in Unity [1].

Namespaces and project structure

In the earlier versions of Unity the general consensus was that larger projects are tidier when the folder structure reflects types (e.g. images and categories, scripts per category, prefabs, textures, etc) while smaller projects are tidier when folders are named semantically according to your project (e.g. scenes or specific functionalities). Namespaces are entirely possible, you can define them anywhere. Nonetheless as you figured, there is already a folder structure in place and namespaces are not 100% pattern and should be used in large projects to avoid clashes as the documentation hints to.

Modern architecture: Entity Component System

More recent developments have led to an architecture called Entity Component System (check documentation).

An Entity Component System (ECS) architecture separates identity (entities), data (components), and behaviour (systems). The architecture focuses on the data. Systems transform the data from an input state to an output state by reading streams of component data, which are indexed by entities.

This more recent development has improved the project architecture. Not only project scalability has been improved but how you can recycle code or port it. Even so, you must follow Unity pattern and stick to interfaces. For example to Unity.Jobs has the interface JobComponentSystem, needed to implement behaviours. Ultimately it all amounts to sticking to the pattern. Modern projects should stick to ECS.

Answer 2

Where is the namespace?

Unity creates the "base" C# script from a template that can be found in

• Windows: C:\Program Files\Unity\Editor\Data\Resources\ScriptTemplates
• Mac: /Applications/Unity/Editor/Data/Resources/ScriptTemplates
• Mac (since 5.2.1f1): /Applications/Unity/Unity.app/Contents/Resources/ScriptTemplates

This base script does not contain a namespace by default, although you can add one by editing the 81-C# Script-NewBehaviourScript.cs.txt file to include one. This will however still be a static namespace that you hardcode into the template file. If no namespace is defined Unity will use the global namespace. I couldn't find the reason why they do this.. But above information is from this support page. You can still ofcourse add namespaces yourself.

Importing class libraries
You can import DLL's by adding them to your project's /Assets/Plugins/ folder. This Plugins folder is a "special folder" dedicated to recognizing DLL's. From this manual page:

You can add plug-ins to your Project to extend Unity’s features. Plug-ins are native DLLs that are typically written in C/C++. They can access third-party code libraries, system calls and other Unity built-in functionality. Always place plug-ins in a folder called Plugins for them to be detected by Unity.

You can only have one Plugins folder and it must be placed in the root of the Project; directly within the Assets folder.

NuGet
You can download and manage your NuGet packages through visual studio. by default it will download the package to projectName/Packages/packageName. Unity sometimes has issues detecting these packages here though, so you may want to move them to the plugins folder as well.

Architecture
What architecture/folder structure to use is down to personal preferences and opinion. However Unity is moving towards ECS (Entity component system). documentation for which can be found here.

An Entity Component System (ECS) architecture separates identity (entities), data (components), and behaviour (systems). The architecture focuses on the data. Systems transform the data from an input state to an output state by reading streams of component data, which are indexed by entities.