foreword
Because I used to make up logic in some relatively mature framework structures, I don’t think there is any special problem. Recently, after reading some semi-finished code logic, I really realized the importance of framework design. Let me say here that I am relatively familiar with some MVC structures. First look at the introduction of the traditional MVC model.
Introduction
MVC first existed in the desktop program. M refers to the business model, V refers to the user interface, and C refers to the controller. The purpose of using MVC is to separate the implementation codes of M and V, so that the same program can use different forms of expression. For example, a batch of statistical data can be represented by histograms and pie charts. The purpose of C is to ensure the synchronization of M and V. Once M changes, V should be updated synchronously.
MVC programming model
V is the View view refers to the interface that the user sees and interacts with. For example, a web page interface composed of html elements, or a software client interface. One of the benefits of MVC is that it can handle many different views for an application. There's no real processing happening in the view, it's just a way of outputting data and allowing the user to manipulate it.
M is the model model, which means that the model expresses business rules. Of the three components of MVC, the model has the most processing tasks. The data returned by the model is neutral, and the model has nothing to do with the data format. Such a model can provide data for multiple views. Since the code applied to the model can be reused by multiple views, it reduces code duplication.
C is the controller controller means that the controller accepts the user's input and calls the model and view to complete the user's needs. The controller itself does not output anything or do any processing. It just receives the request and decides which model component to call to process the request, and then decides which view to use to display the returned data.
Understanding the use of MVC in games
I have participated in many projects, many of which claim to use the MVC architecture, but they are very strange in use, either the M layer is lost, or the M layer and the C layer are mixed together. On the contrary, it increases the amount of code and affects the execution process, resulting in cumbersome and confusing logic.
That is, you may want to use the MVC architecture, but actually use the V + C mode, that is, the View layer is used to initialize the display components. The Ctrl layer does the logical processing of the page, because there is no management of the model layer, and when the data is required to be driven, the data is stored in the Ctrl layer or somewhere else. In this way, it is not only necessary to provide some methods in the Ctrl layer to return the data to other places for use, but also to find other corresponding data locations.
So for the use of MVC in the game, I think it may be better to understand that the Model layer here is called the Data layer, that is, the Model represents an open data layer. All changes to the View layer are data-driven.
For example, for the control of the UI page in the game, the simple diagram is as follows:
The data module is public, just like some global variables, and can be accessed. In this way, for example, if the View of a module is affected by the data of multiple modules, we can control it very conveniently. For example, if our third-level page needs to be displayed, but there is a problem with the second-level page, we can even directly get the desired data from the data layer of the corresponding module to update the View of the third-level page.
This mode can well deal with some cross data, and the problem of mixed code logic and difficult maintenance caused by the incompatibility of parent-child level data.
Endnote
Now most projects are developed at a very fast pace, and many people have the idea of making functions first, and then slowly changing them later.
Most of the actual situation is to keep digging holes, and the functions realized are difficult or impossible to expand at all. Later, a lot of time and energy are spent filling the holes. If they can’t be filled, they will change jobs. And who can guarantee that we are not jumping another shit mountain.
So in general, before writing code, it is better to consider the function points of similar games as a whole, and make a rough structural plan before starting.
Moreover, the game architecture is only the processing of the relationship between the game function points. It is not that I can use the xlua or et framework and other game frameworks to start the game directly. These network frameworks are just encapsulation of some general function points, and have nothing to do with the function points of your own game.
that's all.