How to Implement MVC in Cocos2d-x)

Preface:

As we all know, MVC is very popular now. Now, you just need to search for the shadow of MVC everywhere. At the beginning, it was in J2EE, followed by rails, and later. Net came out, not to mention iOS, where MVC is everywhere, and you must use MVC. But do the programs we write fully comply with MVC? Well, this is hard to say, depending on your understanding. MVC is too hot, so how to implement MVC cocos2d-x?

Model-View-controller (MVC) is very popular in Web application development. It is a combination design mode and is widely used in the development of graphic interactive user interface programs. Some web development frameworks, such as Ruby on Rails, Django, and ASP. net MVC. They are web development frameworks on different language platforms, but they all share the same principle-that is, separating the user presentation layer from the logic layer. Separation of concerns (SOC) is a very important design concept in modern software engineering methods-do not get lost in implementation details, when encountering a practical problem, different concerns should be divided, and these concerns must be isolated to achieve better code reuse and achieve robustness, adaptability, and maintainability. All these software attributes are crucial to the software quality.

Cocos2d-x itself is not designed based on MVC philosophy, but it does not prevent you from using MVC in your own game development. Implementation methods are certainly diverse, In this blog, I just want to share with you how I implement MVC in the cocos2d-x, at the same time, at the end, I will write a simple game demo, of course, which uses cocos2d-x + MVC.

Existing Problems

The cocos2d-x has such classes, ccsprite, cclayer, ccscene, all of which are subclasses of ccnode. Basically, when we use cocos2d-x to develop a game, we will use the following steps to achieve the game logic:

1. initialize the first ccscene through the application proxy class (that is, the first ccscene in appdelegate ),

2. instantiate one or more cclayers in ccscene and add them as children.

3. instantiate one or more ccsprite instances in the cclayer and call addchild to add them.

4. ccscene processes user input (such as touch events and changes to the accelerator), updates the cclayer and ccspirte attributes at the same time, such as changing the position of ccsprite, and enables sprite to run one or more actioins.

5. A game loop is running in ccscene (usually 1/60 updated). Then, cclayer and ccsprite make some updates and game logic in this game loop.

This process looks very simple and can be used to make games quickly. This is also why cocos2d-x is so popular, it is too simple. However, as your game logic becomes increasingly complex, your code becomes increasingly difficult to maintain. The most prominent problem here is that the ccscene class is responsible for a lot of things-at the same time to handle user interaction, as well as the game logic (logical layer) and Screen Display (Presentation Layer ). According to the SOC principle, this is obviously unreasonable. We should separate the duties so that the code can be easily maintained. At the same time, SRP (single responsibility principle) also requires that a class is only responsible for one thing)

Model)

MVC divides a system into the following components:

· Model, which is responsible for the logic processing Code related to the domain, either the logic layer or the domain layer.

· View, only for display on the interface.

· Controller, which processes user interaction.

Let's start with the model. Model represents the game logic. Because I am creating a platform game, some of the things I'm talking about are also related to platform games. The model in my game contains the following classes (of course, only some classes)

· Player,

· Includes some attributes, such as the player position and current speed (X axis speed and Y axis speed.

· Contains some processing logic related to the player, such as run, walk, and jmup.

· Contains an update method, which is called when the player cyclically refreshes each frame. It updates the player model.

· Platform,

· Includes some attributes, such as the platform position, width, and height.

· Contains some processing logic related to platform, such as collapse.

· Contains an update method, which is called when each frame of the main loop of the game is refreshed. It is mainly responsible for updating the patform model.

· Gamemodel,

· Contains some game world attributes, such as gravity.

· Contains some methods to execute the game logic.

· Contains an update method, which is called by game loop during every frame refresh, and then it can update its status, it also triggers other objects in the game world to update their status accordingly.

You may ask: you do not need to repeatedly define some attributes. You can obtain them directly from ccsprite, such as position, width, and height. I want to say: yes or no. Yes, it is because they are similar and can be used. That's because the model may use different units of measurement, such as meters rather than pixels. (For example, box2d does not use pixels as units ). In my model, I use meters. Of course, you can also use feet or other units. The rendering engine is transparent to the model.

View)

According to the MVC principle, view is only responsible for display on the interface. It is actually the simplest way to implement MVC in the cocos2d-x. If you have a model, you can use cclayer and then add some ccsprite or other coocs2d-x classes to handle display issues. The advantage of separating model and view is that you do not need to map the attributes of the model directly to the attributes of the view. For example, your player moves in the X axis direction, but you want it to always be 10 PX away from the left side of the screen. At this time, you can implement the cclayer, instead of moving the sprite. When displaying a model object, you must consider the unit. If you are using meters as the unit of measurement, you must convert the rendering to pixels. (You can define a ptm_ratio like in box2d.) How can your model deal with the view? You can get the view from the Controller, or you can make the game model into a Singleton, and then use the static method to take charge of it.

Controller)

Controlller is responsible for connecting the view and model. It is mainly responsible for processing user input. Since we need to instantiate the model and view, I find it very appropriate to do it in the controller. I inherited the Controller class to the ccscene class, and then an initial controller class, which is instantiated by appdelegate. However, there is a problem here. The touch event is handled by the cclayer, and its role in my design is view. However, I do not want the view to process user input. Therefore, I need to pass a view reference to the Controller (instead of directly passing the view, but through Delegate ), then, use delegate to execute the Controller's touch event processing code to process touch events in the view. Now, my controller class can process user events from view. Then, it can operate the model based on the user input, either by modifying the attributes of the model, or calling the model method. After the model is updated, our view also needs to be notified and updated. Therefore, I have done this in game loop. In fact, it is a controller. The Controller is only responsible for calling the update method of the view, and then the rest is handed over to the view.

Another thing...

The game not only updates the view based on changes in the model status, but also needs to play music and sound effects. Since the Controller is responsible for processing user interaction, it certainly knows when to play what sound effects. However, there may be exceptions in some cases. If a player falls onto platform, but the controller does not know, this part of logic is determined in the model. Can we play sound effects from the model ?... No, we cannot do this. Because this destroys the SOC principle, the model should only be responsible for the game logic. So what should we do? In the next blog, I will show you how I did it. I bet you will think about it, right?

 

Reference Source: http://www.cnblogs.com/andyque/archive/2012/03/11/2390074.html