Hey There
Let’s talk about design patterns.
In software development they used as effective ways to increase the projects scalability, performance and code readability. They can also help with decreasing the memory footprint of an application.
A design pattern describes a general solution to common development problems and can be applied to all sorts of projects.
Our coding methods in this project are heavily influenced by the design patterns the Unity engine already enforces.
For example, every class that inherits the MonoBehaviour class is automatically integrated into the game loop and allows for the definition of the Awake(), Start(), Update(), FixedUpdate(), etc. functions.
Right now, we have implemented two predefined design patterns, that both help us to preserve a good coding style.
Singleton
There is one class in particular that serves a very important purpose in our project. It is responsible for the connection and communication between the Unity game and the cube hardware and is called HardwareInterface.
This class always only has one instance that is used by a couple of different scripts. As it handles the connection to the hardware, it has always stay active, no matter which scene the game is currently rendering (Title menu, level).
We are using a public field that can only be set privately.
The only time it is instantiated is when the first GameObject with this script attached is loaded. If any other GameObject has the script attached, it will be destroyed on load.
The DontDestroyOnLoad() method prevents the active instance from being destroyed on scene switch.
Event Queue
In the same class we are also utilizing the Event Queue design pattern.
This is used here to simplify the execution of specific code when a certain event occurs.
We defined two events, one for when the cube has just been connected and one for when it has been disconnected.
Using the following public methods we can easily add actions to the event queue that are executed when the event fires.
The parameter Action allows passing a function to be added to the queue.
Within the function that actually establishes the connection to the cube we now need to fire the event upon successful connection.
Now we can easily define actions that should be executed when the given event occurs. For example, this line in the Singleton creation logic now guarantees the cube LEDs to change to black (off) whenever the game connects to the cube.
That would be it for now, we hope you had fun reading.
See you next time!
Simon & Manu
Icon made by Freepik from www.flaticon.com
Hey GyroGame,
your blog was a good and interesting read. One thing i was wondering is the creation of the singelton. Is the creation of a singelton you showed the preferred way to do it in unity? I ask because im used to creating singeltons in their constructor with an if/else to check wether its already created.
Anyway great blog. Until then…
Stay cool. Stay organized.
– Your Fridgify Team
Hey there,
You are indeed correct about the creation of the singleton. Unfortunately we messed it up a little originally.
We have since fixed our code and updated the post according to the change.
Thanks for pointing it out!
Cheers,
Manu
Hello there,
your blog post is as far as I can tell really interesting. But I’d like to have, is a little explanation on the design pattern itself (general usage) for example: A Singelton is used in general that it ensures that there is only one instance of a class object (and this can be applied also globaly). I mean you mentioned it: “This class always only has one instance that is used by a couple of different scripts.” But just for your class and not in general, because if someone doesn’t know what a Singeltion exactly does you would need to look it up by yourself. Perhaps this is just my opinion but I thought I’d let you know.
Additionally it would be nice to see a UML diagram with something like before and after the implementation of the design pattern, to see if there were some major chances or what did the design pattern for you or how it interacts with other classes. That would be great.
But all in all your post is awesome. I really like to code examples. It makes it easier to understand and you have a good overview of the general idea. Keep it up!
Have a good one.
Cheers
Hi,
I like your post, it explains your changes very well. The only thing I miss is a class diagram, or bettwer two: before and after.
MAPHYNN
Hello Team GyroGame,
since we are also working with Unity, we had to implement the Singelton pattern aswell. At first we had problems getting started adding this pattern to our project, but then it worked. It looks like you didnt had those problems.
Your blog looks pretty interesting but im missing a class diagram. Best would be two of them to show to status before and after.
Keep up your good work
Team LogicGame
Hey guys,
looks like we thought alike, we also chose Singleton for our project. Looking at what you did, well it looks good. Nothing to criticise.
MAPHYNN said they wanted to see class diagrams, but we know Unity doesn’t work like that. So good work overall, let’s see what your final product will look like.
Stay classy.
Ted’s Team