(GO) u3d design mode

The MVC pattern of UI development in Unity3d is similar to other modules in game development, and the UI typically needs to be developed several iterations until the user experience is approximately OK. It is also important that we want to accelerate the iterative process as quickly as possible. Using the MVC pattern to design, has been proven by the industry to be able to decouple the display on the screen, how to control the user's input to the display changes, and how to change the status of the application. The MVC pattern provides the following benefits:

(1) You can modify the appearance of the UI without modifying one line of code

(2) in different components can share the same set of logic code, used to create complex views;

(3) The implementation of the UI can be changed at a very small cost, such as using Ngui, but will be switched to Ugui in the future.

code example

Here is an example of how MVC is developed using Ngui, and it is important to note that we cannot provide the Ngui library in code, after all it is charged, so if you want to run it, you need to import the Ngui library yourself. The next content will be the code of this example as a benchmark, so you can read the code before you can download it.

General overview

This is a schematic diagram that describes the different parts of the MVC pattern in the code from a macro perspective.

Model

We are familiar with the model in the traditional MVC:

(1) Do not save any view data or view status

(2) can only be accessed by controller or other model

(3) events are triggered to notify external systems for processing and changes

The model here is implemented using plain old C # Objects (Pocos), which is the C # code that does not depend on any external libraries. This is the link address for Playermodel in the example, which represents the player's data, including the HITPOINTS,XP and level, accessed using two properties. We can add XP points, and model will raise a xpgained event. When the upgrade experience is gained, the Level property is updated and raise a LevelUp event.

View

A conceptual view is usually something that is rendered on the screen. The responsibilities of view include:

(1) Handling reference of user-drawn elements, including textures, effects, etc.

(2) Play animation

(3) Layout

(4) Accept user input

In this particular example of code, the implementation of view uses Ngui, so it's just a prefab in unity engineering. But this implementation detail needs decoupling. If you want to learn more about academic knowledge, you can also see the passive view. View does not know anything about other parts of the project, whether it is data or logic. So other code must explicitly tell the view what the explicit, what animation to play, and so on.

Controller

A controller is a bridge that connects model and view. It saves the state of the view and updates the view's status based on external events:

(1) The application status required to hold the view

(2) The process of controlling the view

(3) Show/hides/activates/deactivates/updates view or some part of view according to the status. If the controller can temporarily distable the attack button, because the attack is in the cooling state, cooling state once, controller will re-enable this button.

(4) Load/instantiate required assets, such as display particles, dynamic change sprites, etc.

(5) Handling events triggered by the user in view, such as a user pressing a button, handling a model-triggered event, such as the player gaining XP and triggering an upgrade, so the controller updates the level number in the view

This is the three basic elements defined in the MVC pattern. But in this example, we add another middle layer to further decouple the Ngui view implementation, which is called:

Viewpresenter

A viewpresenter located between the view and controller, as an interface, exposes a universal set of operations for a view, regardless of which library the view is based on (Ngui,ugui, etc.)

For example, a game button, in general, has the following feature set:

(1) Set the text in the label of the button

(2) Modify the background of the button

(3) enable/disable user input

(4) Notify when the user clicks the button

These are actions that are not related to the implementation of the UI, and can be found in any of the UI toolkit. Viewpresenter is implemented as a monobehaviour is attach to Ngui view prefab, so it can be obtained by gameobject.getcomponent in the controller for functional invocation. Because Viewpresenter is a bridge between game code and UI code, it cannot be completely independent of the underlying implementation of screen rendering. In this example, Viewpresenter needs to hold references to Ngui Widgets (such as Uibutton,uilabel, etc.) to interact with them. In fact, Viewpresenter is actually an implementation of the adapter pattern (Adapter pattern): We created an additional custom interface to access the app. These references must be set in inspector or other code.

Fortunately, this setup process can be partially automated, see Viewpresenter.autopopulatedeclaredvidgets (), although Viewpresenter and a particular UI system are coupled, But the advantage of creating an interface for a controller is that if you need to replace the GUI library, you only need to modify the implementation of the modified Viewpresenter without modifying the Viewpresenter interface and any logic of the controller.

It is called Viewpresenter because it is somewhat similar to presenter in Model-view-presenter mode, except that presenter can access the model, but Viewpresenter is not.

Viewpreseter can hold the status of some player logos, such as a view that stores different colors to prompt heath point (with health as a guideline for full blood, abundance, weakness, etc.), these values can be exposed as public properties, Run at run time with inspector for real-time modification. However, Viewpresenter cannot hold any state of the application logic, and logic is managed by the controller, Viewpresenter should not know at all what the heath level is representing low.

For example, if you extend Playercontroller to handle hit points, you can add a method to change the color of the label when it is in low health:

?

123456789101112131415

public< /code> class playercontroller {   //... void updatehitpointsui () { if ( player.haslowhitpoints) { Hitpointsviewlabel.showlowhealthcolor (); } else { hitpointsviewlabel.shownormalhealthcolor (); } }  }

If you want to create a very specific or complex UI and reuse it in your project, this approach may be somewhat over-engineered. In this sample code, it's easy to do this: the controller only needs to modify the properties of a Unityengine.color type in Viewpresenter.

Handling UI Events

Ngui provides a well-designed time system that can trigger this event in any monobehaviour that defines an event hander. This decouples the monobehaviour of the triggering event and the Monobehaviour that handles the event. Then, the powerful features increase the chance of structural confusion, because you can use any monobehaviour as the handler of events, and conveniently drag and drop some monobehaviour from the scene onto the handler of Inspector. This makes it easy to get a hard-to-track dependency when creating a complex view that contains several controls, and the complexity of the dependency graph can grow very quickly.

To prevent clutter in the code, we have followed a very easy principle: All view UI events can only be attatch to the view's viewpresenter for processing. Viewpresenter captures Ngui events and raise a. NET event as a response. The other code subscribes only to that. NET time. This is done because the specific implementation of the UI event needs to be decoupled from the Ngui because we use events in the code instead of Inspector events. In our view, this is a safer approach: it is easy to search the IDE for the code that handles the event, and more Type-safe: (If you delete a monobehavior that handles this event, you will only find that the control stops working in play mode), You can allow each parameter on the event to be set. Of course we need to encapsulate the Ngui event in the View presenter, but let's make it automated: Look at this code buttonviewpresenter.wireuievents ()

Create a complex view

Now that there are some modules that can be built to support, it is easy to create some more complex view by combining it by combining several UI prefab into a new view and creating a new viewpresenter for this combined view. Exposes the viewpresenter in the child view so that it can be accessed in the controller.

(GO) u3d design mode