You might already notice that I wrote a lot about design patterns and examples of use for them in Unity. I am genuinely interested in writing clean code and designing project architecture. This brings me huge enjoyment and satisfaction, especially when the team is following project guidelines and everything looks so perfect. 😍
Being a programmer means that you need to improve your skills constantly. So today let’s summarize things that I wrote on this blog so far in term of Design Patterns! 🔥
What is Design Pattern?
The first thing that you need to understand is what “design pattern” means. So design pattern stands for a programming concept which solves conceptual problems. It can be related to creating new objects, making the code more independent or modular, or even split your project into different layers of responsibility.
Each design pattern has its pros and cons which a programmer should know and understand. So let’s don’t waste any more time and let’s get to the design patterns that I’ve written about on my blog!
The state machine is one of the most used design patterns in game development. It is useful for a variety of purposes like AI, animations, game controllers, game logic, dialogs, cutscenes and many, many more.
The idea of a state machine is fairly simple. You have a machine that can run different programs – or states in our case. This gives us a lot of flexibility as creating a new state is super easy, and the only thing that you need to worry about is to how to inject or enable newly created state.
To see how you can implement this design pattern you can go to the post How to implement State Machine in Unity. 🔗
Our next contender is even easier to understand and implement. The factory design pattern is related to the creation of new instances or objects from a blueprint. In Unity, we are mostly using prefabs, as they are already set up with all components that we wanted an object to have, but that’s not the only solution here.
So from the code perspective, this design pattern only require to implement GetNewInstance() method from us.
But there are limitations for this pattern. Creating vast quantities of objects that are destroyed continuously can result in an unstable game or even with game crashes due to memory fragmentation. To prevent this from happening you can use an optimization technique called Object Pooling. This is essential when you are creating a game with a lot of bullets, enemies or obstacles.
In case of implementation, you can base your code on factory design pattern and add logic for returning objects to pool. With that, you are reusing existing instances without the need to create too many objects.
Example of that is available on another post, How to implement Object Pooling in Unity. 🔗
The singleton design pattern is often overused and often hurt the project in the long run. I always try to avoid using it entirely or at least minimize the use of it as code starts to couple too much around singletons.
The benefit of using the singleton design pattern is that you can be confident that you have only one instance of a class, which is excellent for systems responsible for localization, file management or networking.
I have multiple versions of the singleton design pattern implemented in post Singleton in Unity – Love or hate? 🔗
Not many people know about Command design pattern. It can be really useful, especially as it isn’t that hard to implement!
The whole idea of this pattern is based on two elements:
Command – which is something like a request. This element store information that will be executed by the command invoker.
Command Invoker – stores all command waiting to be executed at the right time. The Invoker can also process commands right away if we wish so.
Using this design pattern we can easily create Undo and Redo mechanic.
If you want to read more about it and see the implementation, I’m inviting you to read Command Design Pattern post. 🔗
The last one for today will be MVC or Model – View – Controller. This design pattern separates code into three layers as the name suggests.
Let’s start by explaining what each of these layers does!
Model – these are just classes or objects that stores data. It could be an object with just a few variables, or it can represent enormous JSONs. Most importantly they just store data and information.
View – they are responsible for displaying information to the screen. It could be just UI, or they can be objects on the scene. In the end, what matters is that they are just responsible for displaying things that are given to them.
Controller – here you can find the logic of the app or game. They are responsible for handling interactions with the user and moving data around our app.
Of course, I’m trying to simplify it as much as I can, while still having the essence of them.
There is a lot of different implementation of the MVC design pattern available on the web, but many of them require a lot of knowledge about programming and different techniques about how to do things.
That’s why I decided to implement in the most accessible form I could while still maintaining code structure and layers of responsibility. You can find it in
As stated at the beginning, being a programmer is a continuing process of learning new things and gaining experience. That means that you can’t stop pushing your skills into new territories where you can challenge yourself.
To each of the posts attached above, there is a public repository with an example, but you can also find all of them at my bitbucket profile!
I hope you enjoyed it and see you next time!