jeudi 20 août 2015

Unity Design Pattern - Singleton Example (Part 2)

Ok so now we are going to add another option to our menu: "Quit" . We would like a confirmation by the user wether he actually wants to quit or just cancel his request.

We have now a "setup" function to initialize our popup properly, I implemented a general one and a basic one.

In our example we have a "validate" and "cancel" button but it could work for any two choices scenario.

So here is the setup function for our popup :






























It is not a completely safe script as we don't check if there actually IS a text component for the button when we change the label (that would mean the user has modified the original popup prefab). Of course if one want to add buttons, input fields... in the popup one should redesign the all "setup" function(s).

and this is how the GameHandler looks like:







































Note that in unity when you deactivate an object he gets kind of lost (you can find them by script using Find() ) unless you have a reference on a script. With the singleton you always have access to the instance of your object (just by knowing the name of the class) even if it is deactivated which is kind of helpful.

vendredi 7 août 2015

Unity Design Pattern - Singleton Example (Part 1)

     I was finishing my game willing to add some popup messages to help the user understand the application and guide him through the different functionalities. I actually found myself implementing a singleton pattern for my "PanelPopup" Class that is handling the buttons and information message displayed for an Alert-like popup. It seems legitimate to use such a design now that I think of it: a popup model will be used/called by many different objects/class of the scene to ask a confirmation by the user or to display some information/alert messages. I will use one instance of the popup and rearrange its settings (buttons and messages that are displayed) regarding the current context it is being used.

This is the raw class i had at the beginning (simple but unsafe):


    At this point I actually did not care about its uniqueness , I just wanted to be able to access an instance of the popup without having to carry a reference in every single script or class that would need to use it (that is the advantage of a static field variable). You should create the instance of your class in Start(), Awake(), OnEnable()... or any other initialization function you can use for a MonoBehaviour script.

Then I added the necessary features to the class in order to guaranty the uniqueness of its instance:



Then let's have a closer look at our PanelPopup Inspector and our scene hierarchy:

Popup root object, referencing the buttons
and the information text that are displayed.

Organisation of the Popup Object

Rendered View of the UI Panel element.



Now let's say we have a script that needs to show a Popup/Alert message to display an information (and later ask a confirmation from the user) :




This is the actual setup of my scene at this point :


Rendered View of the Application Handler


And finally when we hit "Save" Button we have our popup that shows and then hides when we hit  "Ok".

(I know it is an ugly display but that's not quite the point here :p)



    Now what if we want to use the popup for other messages, with another button and in another context. We don't want to have to access and set the components every time, we could save a lot of time and lines of code! To do so let's add a method to the PanelPopup class that will allow us to setup the component just by calling one function (cf Part2).