Help Understanding Design Patterns in Unity

I may have the wrong section but since this is related to learning/teaching, I figured this should be fine. If it's the wrong place, or there's a better place, I can re-post somewhere else.

I have a project for University, in which we've to use MVC and other design patterns. Up until now, I've been using Unity just to program on my own, so I haven't followed any patterns whatsoever. Not to mention that Unity already has it's own system where everything is Entity-Component.

I'm a bit lost, I can program in C#, which is what I use for Unity, but I have no idea how to set things out into an MVC pattern, could anyone link some useful tutorials, webpages or even take the time to explain how I'd do MVC in Unity?

 

You may get better mileage in the scripting section, as this relates to scripting/coding/programming.

Unity is already using the component pattern (amongst others), so - yes to a degree - coding for Unity will be different from coding a "program" from scratch.

There are some resources for patterns in C#, just google "C# Patterns" and you'll get a screen-full. As these are usually framed in the context of making a rolodex of dinosaur names, it can often be difficult to translate into terms or practical uses in the Unity-verse.

As a matter of fact, I'll move this to scripting and let's see what help we can get...

 

This article is one of the better ones I've seen. But in my opinion, and this probably isn't what you want to hear, you shouldn't use MVC at all. With the Component system so firmly embedded at the heart of Unity it makes sense to use that and to build upon it in development. I think of it not as writing a program, Unity Tech already did that, but as writing scripts for a program, which is probably why they call them that. If you come at it from the perspective of augmenting the Unity engine, then using the engine's system gives you the advantage being tightly integrated with minimal effort.

 

Interesting that you use MVC as your example. Did you know the original Gang of Four (GoF) had an entire section in their book explaining why MVC is not a pattern, but a design? The original design patterns were supposed to be much more abstract than MVC -- they described structures and interactions at a very broad level, trying very hard to avoid prescribing how those structures and interactions manifested themselves.

Let's take a for-instance: within MVC, a model may have several different views. Each of these views needs to be notified when the underlying model changes. Think about the interaction: multiple objects want to receive a notification when something else changes without requiring that underlying object to explicitly hold a reference to them. This happens a lot -- not just in MVC, and it was described by the GoF as the Observer pattern.

MVC has plenty of other examples.. A view might be made up of other, smaller views, an example of the Composite pattern; A view might need to be modified in some way at runtime, such as get disabled, it can be done using a DisabledView wrapper, an example of the Decorator pattern; MVC might want to change the way it reacts to input based on the state of the system, it can do this by swapping out the active controller, an example of the Strategy pattern; A model might want to remember its state and the corresponding commands that caused it to change so that it can be reverted to a previous state, an example of the Memento and Command patterns..

You see, the design patterns are all around us, we simply may have not noticed them before we named them.

You say

But I find that very unlikely. Indeed, just yesterday I was explaining that by the time I had enough experience to really wrap my head around design patterns, I discovered I had already been using them. This leads to a, perhaps, disturbing implication: design patterns will not magically transform you into a programming master. In my own experience, recognizing them has led to two primary benefits:

1. I can communicate abstract ideas about how code might be structured to solve a problem
2. I can quickly come up with alternative solutions and possible implementations based on my knowledge of how the patterns are related

So, let's talk about some of the design patterns you might see in Unity.

Composite is an obvious one right? Actually, I think there is some confusion here. The Composite pattern is described as "a container which provides the same interface as the components it contains". It's purpose is to reduce the difficulty of dealing with possibly zero, one or many references into dealing with always, just one. This is not really what the component system of Unity provides. There is a trap here because "composition" looks, sounds, and, to many, means something very similar to "composite". That doesn't mean it doesn't apply to Unity though. The composite pattern is very useful for building up complex objects. I wrote up two lengthy posts which talk about how the Composite pattern, Decorator pattern and AbstractFactory patterns could be used to create things as different as complex weather effects and customizable abilities with a large number of modifier effects.

A pattern that is often missed, but I believe is a core concept in Unity, is the Prototype pattern. The Prototype pattern is described as "a fully initialized instance to be copied or cloned". This pattern can simplify the creation of objects that either you need many identical, or slightly different copies of. Sound familiar? You can see it in the prefab system of Unity.

Have you ever used an object pool to reduce memory load in your game? This is an example of the flyweight pattern; the mesh, textures and logic of the pooled objects can be thought of as intrinsic data while the settings which control how that object will behave once you take one from the pool is the extrinsic data.

The Message System in Unity look very similar to the Observer and Command patterns to me, and probably use many other patterns under the hood.

The WWW class is just one example of the Façade design pattern, and I'm sure you can find this guy everywhere once you understand what it is describing.

Another member, @JoeStrout, recently created an in-game scripting language called MiniScript and followed up with a cool mini, meta programming game. I don't have any evidence to support this, but there's a good chance he used (or could have used) the Interpreter design pattern in his implementation.

Singleton gets a lot of attention on the forums because it is such a simple way to share common game components across your game. I would be very surprised if you've never used this design pattern, intentionally or not.

Though I have no experience doing so, nor links to explain how, I think the Builder pattern would be very useful for dynamically creating a complex physical structure such as a maze or building.

Hopefully I've convinced you design patterns proliferate our code more than you thought. The question is how can we use that knowledge to improve our programming? Some people believe patterns are bad because they obscure real problems or encourage over-engineering, but I think there is some faulty logic and personal bias at work here. This is like blaming weapons for killing.

I'm all out of time but maybe this is at least a little helpful for your assignment. If nothing else, it might give insight into what patterns actually are and do.

 

Heey @eisenpony thank you so much for this answer, it clarified a lot about applying all those concepts in Unity and some doubts that I was having before, do you produce some kind of materials or articles about Design patterns, Clean Code or/and SOLID? I really would love to read them.