![]() ![]() Hopefully, this example demonstrates the added complexity of the event-based approach. OnCoinsValueChanged?.Invoke(previous, _coins) To this: public class GameViewModel : ScriptableObject So the Model code changes from this: public class GameViewModel : ScriptableObject In my example, I did this by wrapping coins in a Setter that calls an event. To do that, you need to keep track of every time the coins value changes. ![]() In the above example, we need OnCoinCountChanged to run every time the coins value changes. In other words, you need to make sure that a specific method executes every time the bound variable changes. This system is a little more complicated because you have to bind the data to the UI. Void OnCoinCountChanged(int previous, int current) _model.OnCoinsValueChanged -= OnCoinCountChanged _model.OnCoinsValueChanged += OnCoinCountChanged Public void OnCreated(GameViewModel model) public class CoinCounterPanel : MonoBehaviour In an event-based system, the UI updates whenever an event occurs that changes your data. However, given that this code tends to be straightforward, this may not be an issue. Also, depending on the UI, the code might become very lengthy. For one, you may be wasting CPU cycles to set data that hasn’t changed. Additionally, you don’t have to worry about managing state, and your UI will always be in sync. This type of polling-based UI system is easy to read and understand. public class GameViewController : MonoBehaviour ![]() For example, if you have a coin counter in your in-game UI, just set the current number of coins in Update. This works by simply setting the UI to the most recent data every frame. If you have a simple UI, using a polling-based method is much simpler. Both approaches are valid so let’s look at the pros and cons. By the way, there are essentially two strategies for hooking up UI, polling or event-based. The view controller is in charge of binding all your UI pieces to their corresponding variables. The way I structure View Controllers is a Structured Prefab. If you haven’t read my previous two articles on the Main Loop and Structured Prefabs, I recommend you do so. By the way, your Model could be as simple as an object with a list of variables: public class DataModel : ScriptableObjectĪs for the view controller, it’s a MonoBehaviour at the root of our prefab. As a result, it’s easy to manipulate your data, which isn’t the case for databases or raw JSON. What I mean by that is that they interact well with the Editor ecosystem, especially the Inspector. It’s adaptable to any scenario.įinally, Scriptable Objects are first-class citizens in the Unity Editor. In other words, using an SO as your Model won’t force you into an awkward place down the line. Additionally, if you need to pull data from a spreadsheet or database, you could accomplish that by creating an SO at runtime and filling it with the retrieved data. Then, it’s just a matter of switching between them and viewing the result. For example, if you wanted to try several different UI scenarios, you could create a new Scriptable Object to represent each one. This feature allows you to test different scenarios with very little code. Scriptable Objects can either be created at runtime or in the editor. The advantage of using a Scriptable Object (SO) as your Model comes down to flexibility, testability, and ease of use. However, I prefer to use a Scriptable Object. There are several different ways you could achieve this, and to be honest, they’re probably all valid. The Model is nothing but a big data container. MVC for Unityįirst off, let’s talk about the Model. That’s MVC in a nutshell, so let’s look at how we can adapt this pattern for Unity UI. For example, you could quickly redesign the layout without touching the data or the functionality. This separation (theoretically) makes it easier to change each part independently. The Model holds the data to display, the View manages the layout, and the Controller handles the functionality. MVC is a pattern used to separate UI, Data, and functionality. In case you’re unfamiliar with the MVC pattern, I’ll summarize it. This isn’t the only way to structure your UI, but it has worked well for all my previous Unity games. This approach is based on the Model View Controller (MVC) pattern, but it’s slightly adapted for Unity. This article describes an approach to structuring UI in Unity. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |