Unity — Game Architectures — Part 1

6 min readJul 6, 2020

Unity is a powerful suite of tools (Project IDE, Code IDE, run-time) for game development.

▶ Enjoying The Content?

https://SamuelAsherRivello.com/sign-up/

We all start projects with the best of intentions. But during development we often find our projects do not meet our expectations for organization, scalability, and for our quality of life as developers.

Using established architectures, like the Mini MVCS Architecture For Unity empowers you to create and maintain Unity projects which are faster to develop and easier to maintain.

New Course — Now Available!

MVC Architecture For Unity 2022 on Udemy

QUALITIES OF MVCS:

• Sound philosophies — Built on top of the best design principles and design patterns — championed by software experts

• Proven solution — Follow industry-leading practices and solve the biggest challenges with the greatest of ease

• Language-agnostic — Translate your new training and skills across many platforms and programming languages

OVERVIEW

I have explored many architectural approaches to game projects. Architecture is a hot topic in Unity — especially related to scaling up to larger Unity game projects.

In earlier explorations, I created the same bowling game with 6 different architectural approaches and created my first MVCS framework that was quite heavy with MonoBehaviour usage.

After years more of experience, I pared down the concepts and complexity and started from scratch. Now I have released the the Mini MVCS Framework for Unity.

My architectural background includes many frameworks. Highlights include heavy usage of Robotlegs (I am a project contributor and creator of the official diagram), PureMVC (I am a technical editor for the O’Reilly book), and PushButton (I am the author of related articles on Adobe, now archived).

I am a Unity Game & Tools Developer with over 20 years of game development experience. I am available for hire (Remote, Contract).
SamuelAsherRivello.com

What are the qualities of good gaming architecture? Most architects applaud solutions that are flexible, readable, D.R.Y., testable, orthogonal, and “refactorable” (at an acceptable cost). I will discuss the philosophy of design in a future post, but for now, I simply list the major pros and cons of each approach. While there are many ways to approach game design, I champion the MVCS pattern.

Mini

Here is my Mini MVCS (Model-View-Controller-Service) architecture for Unity.

I created this from scratch for fun, for learning, and for teaching.

Mini MVCS (hereafter called Mini), is specifically designed for the unique aspects of game development in the Unity platform (Scenes, Prefabs, Serialization, GameObjects, MonoBehaviours, etc…)

It requires no MonoBehaviours. There are pros and cons to this approach.

Enjoy!

Details

Unity 2022.2

Features

A light-weight custom MVCS Architecture — For high-level organization
A custom CommandManager — For decoupled, global communication
Project Organization — A prescriptive solution for structuring your work
Code Template — A prescriptive solution for best practices

Mini

The high-level architecture is taken from the industry-standard MVCS.

Project Organization

I used my own Project Organization for the project structure.

Mini installs the required files into the Packages folder. It installs no files into the Assets folder unless you choose to install the Samples.

Samples

The samples include several standalone uses of Mini. Use the samples as inspiration and education. Want to see more samples? — Leave a comment below.

Code Organization

Mini is opinionated but flexible. Not every area of concern needs all 4 framework parts; M, V, C, S. Quite often, the S (Service) is not needed. In the language of MVCS architecture, we call each part an ‘actor’. This is not a Unity-specific term.

In the most simple use cases, you will use one actor per area of concern. However, there is no limit to how many actors you can have. In fact, you can have many unique MiniMVCS instances in your project which are coupled or not coupled to meet your needs.

Example Class Structure

MiniMVCS
├── Model
├── View
├── Controller
└── Serviceor MiniMVCS
├── Model
├── View
├── View
├── View
├── Controller
├── Controller
└── Serviceor App
├── MetaGameMiniMVCS
|   ├── Model
|   ├── View
|   ├── Controller
|   └── Service
|
└── CoreGameMiniMVCS
    ├── Model
    ├── View
    ├── Controller
    └── Service

Areas of Concern

Here is an overview of general MVCS fundamentals as it applies to MiniMVCS.

MiniMVCS — This is the parent object which composes the following…

Model — Stores data. Sends Events
View — Renders audio/video to and captures input from the user. Observes Commands. Sends Events
Controller — This is the ‘glue’ that brings everything together. It observes events from other actors and calls methods on the actors. It observes Commands (from any other Controllers) and sends Commands
Service — Loads/sends data from any backend services (e.g. Multiplayer). Sends Events
Context — While not officially an ‘actor’, this has an important role and is referenced by each of the 5 concepts above. It is the communication bus providing a way to send messages (called Commands) and to look up any Model(s) via the included ModelLocator class.

MonoBehaviours

The MonoBehaviour class is fundamental to Unity. Beginning developers create most/all classes as children of MonoBehaviour. Veteran developers know the pros and cons and use MonoBehaviours only when appropriate.

When working on my older articles of Unity — Game Architectures — Part 2 and Unity — Game Architectures — Part 3, I used many MonoBehaviours. However, MiniMVCS purposefully requires none.

By default, the MiniMVCS class, the Model, the View, the Controller, and the Service implement interfaces yet extend no MonoBehaviours. Interestingly, you can make them all extend MonoBehaviour if you like. It's flexible to meet your needs.

For more backstory, checkout “When To Use MonoBehaviours And Not” on the Unity Forum.

Unit Test

I included Unit Tests (with limited coverage). In some cases, I used TDD to develop sections and in others, I added tests for academic (teaching) reasons. Generally, I recommend using Unit Tests for game projects and providing a coverage strategy

Coverage Strategy