These pages shall give an overview on how the overall system works. The SW architecture organizes the SW components (See SW Component Design) in a hopefully understandable way. Overall decision on SW architecture shall be explained here, while the details of components and of SW units can be found under SW Component Design and, of course, the Doxygen-generated classes list.
Here are the available architecture topics on subpages:
The Game Startup : How the components work together during startup
Handling State : How SW states are represented abusing the animation system
Networking : What networking options we have and how to use them
On Unity SW artifacts in general
The image below shows my simplified understanding of the types of SW artifacts you come across while scripting for Unity:
Unity SW artifact hierarchy
Each SW Component making up the program may make use of the building blocks above. Starting from the top:
Game Objects are the virtual objects present in any scene of the game. They may not even be visible, but are the central means of invoking scripts by attaching so-called Behaviours to them. Game Objects (GOs) can be made a Prefab asset, which means their current composition and values are saved to disc as a kind of template.
MonoBehaviours are, as mentioned, the base class of scripts attachable to GOs. They offer a range of Callbacks to be implemented, such as the Update() function, which is called for every active MonoBehaviour on every object each frame. Attached to GOs, scripts are called "Components".
StateMachineBehaviours are not attached to objects, but to the states of a state machine, which can be visually designed within the Unity Editor. This allows to compose and visualize state-full behaviour easily. The state machine instance itself lives, again, as a Component on a GO.
Classes and Data Structures are your usual C# object-oriented SW. They are at some point used Behaviours to allocate functionality nicely without having the overhead of making everything a Behaviour subclass. Also Behaviours are instantiated by the engine and have no own constructors, while your own classes of course can have those.
Scriptable Object (Instances) are your own subclasses of the "ScriptableObject" class provided by the engine. You can create and save instances of these classes to disc during build time. The can serve as data containers which can be drag-n-dropped onto behaviours for reference. This also allows usage as a means of communication between components.
Helpers & Editor Extensions are your custom C# helpers, like extension classes, as well as various capabilities to extend the Unity Editor with own scripts! This encompasses custom menu entries or custom views for your components in the Unity Inspector. Editor extensions have to be placed in "Editor" folders in the asset hierarchy.
Engine Features are used across all levels. Most prominent is the Unity Inspector feature, which allows setting member variable values for provided and custom components and ScriptableObject instances from Unity directly.
These member variables are "serializable", i.e. Unity knows how to save and read their values to disc to provide the above capabilities. Note that all serialized members are instantiated by the engine, e.g. when the owning object is created. Constructors are not used this way.
There are of course many more engine features, such as Mecanim-based state-machines, which shall be mentioned where they are used.
Overall SW Architecture
The below are the main SW components, each of which may be represented by one or more classes and behaviours.
1.8.13