Analysis of flash game architecture

 

First, let's talk about the front-end main architecture. The front-end main architecture has two main tasks:
1. Divide the front-end modules reasonably from the perspective of architecture and propose feasible implementation solutions;
2. Build a program architecture (non-document-level) at the AS level, develop frontend programming rules and interfaces, and standardize the division of duties of each part of the program. These two tasks actually involve a lot of specific work, such as the game startup process, determining which SWF files need to be loaded externally, and those functions can be detached from the main program for independent implementation, how to deal with front-end configuration files, how to deal with public materials, how to divide the MVC three layers, how to select the main program framework, how to communicate with the background of the main program, how to cooperate with the module, which code should be put in the main program, which code should be put in the module, how the main program can provide all the functions and data required by the module, and at the same time relative to the module self-protection and so on. In fact, I am only talking about some major aspects, specific implementation level, and a lot of detail work to be done. These tasks are very important at the beginning of the project, which directly affects the development and maintenance efficiency in the middle and late stages of the project.
I can't explain all the points mentioned above, or I won't say "talking about FLASH WEB GAME! I have only selected two core topics to discuss with you, that is, the front-end AS framework and module division. First talk about front-end frameworks: Many front-end frameworks are popular on the market, either for FLASH, FLEX or general. Whether or not we need a framework or a framework is required. This is completely a matter of benevolence and wisdom. From the final result, it is of little significance to argue over this question, I believe that anyone with more than five years of programming experience in a project with around million lines can use any combat strategy to break down the hill and build the project. But one thing is crucial: You must be fully aware of your architecture and the framework you are using, and be able to explain it to your front-end colleagues. What are the differences between good and bad architectures? The difference is that a good architecture will be easier in the development process. You don't have to worry about your code every day, and you don't have to write documents every day to prevent yourself from forgetting complicated logic, you can start writing code at any time, play a game at any time, and then come back to write the code. The difference is that a good architecture is more in line with industry standards, it is easier to be understood by traditional and Orthodox programmers. The difference is that you can describe your architecture ideas in a few simple words, using a few simple documents, you can let others take over your code and make yourself easier during personnel changes and work handover; the difference is that when you master a general framework or summarize a mature architecture, you can apply most of the projects in the future and constantly improve it, making development easier and easier, faster and faster!
In our project, the main program uses the pureMVC framework, while the main UI is self-written. The main program and the main UI are independent of each other and can be compiled and tested separately. The main program is pure code and compiled using the flex sdk, while the main UI is mixed with the AS and UI and compiled using FLASH. In this way, V in MVC is completely independent from the physical layer. The pureMVC framework, as its name suggests, is a "pure" MVC Framework. In my opinion, it just helps us implement the MVC programming ideas and routines. Other redundant functions are not at all, this makes it more universal and the most lovely place. Based on our experience, the single-core version of pureMVC can fully cope with projects with less than 10 million lines of effective code for the main program. However, when I chat with many front-end friends who have not used frameworks, I find that they are in conflict with these frameworks, or some of them do not have a deep understanding of the MVC model, how can we use the MVC framework? Some of my friends put their problems down to the Framework. After I used the pureMVC framework, it took me a dozen minutes to compile my project, project compilation is slow generally because the main program is too large due to the lack of proper module division. What is the relationship with the framework? If some new people miss learning such an excellent framework Due to misunderstandings and comments from these people, I think it is a real success!
Since pureMVC is an MVC Framework, it means you must first be familiar with MVC. This familiarity is definitely not a literal translation of MVC: models, views, and controllers. Instead, we need to really understand why we need to divide the program into these parts. When dividing the main program module, you must always be able to consider the issue from the perspective of MVC. When faced with a piece of actual code, you can quickly and accurately determine which part of the Code should be included in MVC. In the document of pureMVC best practices, which contains dozens of pages, we can say that the idea of MVC is flashing everywhere, not only explicitly explaining how to use the framework, in addition, the MVC perspective tells us what logic should be put in and what issues should be paid attention. This document has already had a Chinese version. If you are interested, you can check it yourself. I will not go into details here. I only talk about some issues that may not be involved in the text based on my own experience, but they will also be encountered in real development.
1. Does the model have other functions in addition to data storage during actual development? Yes, in fact, it has many responsibilities. It provides interfaces to the command and mediator to respond to user operations, perform data operations or Request Remote Data Services for data serialization and deserialization. After obtaining asynchronous data, it may also check data legalization. But in any case, it is always dealing with data, and it should also be the only pipeline in your main program that can directly deal with data. Other parts should be in contact with data, first, ask it to agree or disagree. After the model completes data processing, the command or mediator is notified by notification. But you cannot directly call mediator in the proxy. This is to ensure the independence, portability, and reusability of the data layer, and also simplifies your architecture. However, the advantage of portability is estimated to be a lot of Flash
Web Game friends have no chance to experience it for the moment.
2, Command! The system calls three "commands", hoping to attract everyone's attention. The use of Command reflects your understanding of the pureMVC framework, or even the depth of understanding of the MVC model. In the pureMVC framework, all parts of communication use Notification messages. The Proxy can send messages to the Command and Mediator. The Command can send messages to the Command and Mediator, and the Mediator can send messages to the Command and Mediator. How can this problem be solved? Are you dizzy now? It's normal. In fact, I am also a little dizzy! When your code is written to a certain scale, you will be dizzy. In fact, this design of the pureMVC framework is intended to make the various components of MVC decouple as much as possible, but this brings about a negative situation that the message sending and receiving mechanisms are too flexible and flexible is a good thing for small projects, but for large projects, it often means chaos or even disaster. What should we do? We can only rely on our self-consciousness to constrain ourselves and simplify our architecture. According to the suggestions in pureMVC best practices, my practice is as follows: use Command whenever possible to make Command the only bridge between Mediator and Proxy, and send notifications in Mediator and Proxy, the recipient must be a certain Command, which is then processed by the Command and the result is forwarded to the real message receiver. Even if the Command only plays a forwarding role, there are less than 10 lines of code, create a Command class. This not only makes your architecture clearer, but also conforms to the MVC idea. The existence of the Command class also makes the business logic of your architecture more encapsulated and scalable, why not? The only negative impact may be that you need to create and maintain more Command-class files. However, this impact is not a small one compared with the advantages.
3. I know there may be some friends who are writing code using flash ide. These friends are admirable, but I think anyone who is familiar with FLEX BUDIER, FD, or FDT, they will never go back and use flash ide to write code. -- No? Isn't it about pureMVC? Why did it go to IDE? This is because the issues I want to discuss now are related to IDE. If you are still using FLASH IDE, apart from writing documents at any time, it is really hard for me to come up with a good solution that allows you to easily master and maintain tens of thousands of lines of code at any time without document support. However, if you are using FDT, you can use "ctrl" without a document.
+ R "," ctrl + left mouse ", and tools such as full file search, instantly figure out the connection and logic between codes and find out where to modify them. OK. We finally got to pureMVC. If you are using FDT and start to use the pureMVC framework, you can find that when you write the main program, we still keep using "ctrl + left mouse" instead of "ctrl + r", which means you must review your understanding of the pureMVC framework. Please review your Mediator class, check whether there are a lot of public methods in it. If your objects are still referenced through the public method instead of through Notification communication, you do not need to continue using the pureMVC framework.
4. What is the impact of Singleton mode? Puremvc is a framework fully dependent on the singleton mode. The Singleton mode seems to be highly controversial in the as field. In this case, puremvc will certainly have a corresponding controversy. Most of those who disagree are on performance and team collaboration. They think that a single instance with too many references will cause performance problems, in addition, I am afraid that my Singleton category will be accidentally modified in team collaboration, leading to a strange bug. In terms of performance, I have never done more than 10 million projects before, and I dare not say anything about them, but there are absolutely no problems with projects under 10 million lines, if your 20 thousands or 30 thousands-line architecture begins to encounter performance problems with the primary architecture, it is estimated that there is a problem with your own code writing. In terms of teamwork, I think the FA of puremvc? The Ade mode is very flexible and easy to use. You can discuss it and develop a simple rule. For example, the module can only use fa? Ade can get data and send notifications, and cannot directly call other classes of the main program. As long as the architecture programmers do not make mistakes, the module programmers do not even have the chance to make mistakes. If they do, or is there a problem with your architecture thinking? Please review your code. What is the problem with the singleton mode? I haven't fully understood it yet, mainly because we haven't encountered such problems in our projects, I hope that my friends who have met me can tell me more about the volcano. I can also find out where the problem is, and I will be able to avoid such problems in the future.
Well, let's talk about the above four points in the Framework section. Let's get into the next topic: module division mainly includes "core module division" and "sub-module division ". The core modules are divided into the following ideas: they are necessary for game startup, are closely related to each other, and are often called by quilt modules, the idea of dividing sub-modules is that they are not necessary during the game startup process and can be re-loaded during the game. The sub-modules are basically completely unrelated to each other, the addition and deletion of a sub-module does not affect any other sub-modules. The sub-module may need to call the main program interface or obtain the data of the main program, however, the main program should never depend on a sub-module.
After clarifying the module division ideas, let's take a look at which parts should be divided into core modules and which parts should be divided into submodules. Generally, the core module consists of a shell SWF, configuration file package, logon to register SWF, main program SWF, and main ui swf, and public material package according to the game startup sequence. The sub-modules are much simpler, such as a specific game, a specific scenario, and trigger functions in a specific scenario. Next I will explain the core modules one by one. "One shell SWF": This is a small, but significant SWF; it is always followed by random variables to ensure that each user load is up-to-date; it defines some variables that need to be updated frequently and must be updated each time to ensure that users get the latest value immediately. It is best to have a simple background image in it, ensure that users enter the game website at an ultra-low network speed and do not face a blank space for a long time. It has security policy settings and is the cornerstone of our cooperation with many third-party platforms; it also defines the game startup process before the main program is loaded. "Configuration file package": Core Module version number, global text description, service Interface Definition, configuration information required by each core module, and some XML files. "Log on to register SWF": This is simple. Before loading the heavyweight SWF, load the log on to register SWF first to ensure that the user can open the logon registration interface immediately and effectively save server bandwidth. "Main Program SWF": This is the main program part I have paid a great deal to talk about. "Main UI": Why does the main program and main UI need to separate two SWF files? I have mentioned it before and I will explain it later. I will not talk about it here. "Public material package": a public material package is indispensable for a game, but it cannot be overly dependent. It includes global items and effects, such as expressions, special skill effects, and scene portals. It is best to use some simple animations in the public material package. The small size function is simple. It is strictly prohibited to add hundreds of K items to the public material package or small modules with hundreds of lines of code. The public material package is recommended to be less than K.
After reading the above explanation, you can think that there are so many core modules, which is too much trouble. Yes, in my opinion, the decomposition and control of the SWF loading process and the control of asynchronous programs are important indicators to determine whether an AS programmer is experienced and old enough, many friends who have transferred from other languages to AS and years of programming experience may be similar to AS programmers in terms of architecture, or even better than many self-taught AS programmers, however, this is often not AS good AS a veteran AS programmer who has struggled with CPU and SWF for a long time. The more rational the core modules are, the better the user experience is. The higher the efficiency of code compilation and maintenance in the future, but it will be troublesome in the early stage, in addition, the architecture experience and capabilities of architects must be put forward with higher requirements. The main program, material, and core modules are all stored in a SWF. Users must download the SWF at first, or get a bunch of core modules and multi-public materials, at the beginning, users must face the endless cycle of loading, and wait until all the core elements are loaded to perform some basic operations. In terms of architecture, this is the simplest practice, because complex asynchronous and SWF splitting issues do not need to be considered too much, it is very unfavorable in terms of user experience and long-term development and maintenance. Based on our experience, the volume of all resources loaded before user login should be controlled at around kb, and the total number of resources loaded before the user enters the game's home scene should be controlled at around 1 MB. Another friend who used pureMVC to compile the project for more than ten minutes has been mentioned above. It is estimated that he will get everything into a SWF. If the main program is changed and tested at will, it will take a dozen minutes to get started. Where can we start with development efficiency? Based on our experience, compilation of any main program, core module, and sub-module must be within 10 seconds, this is reasonable-my machine was a Dell brand machine that spent more than 3000 yuan in.
→ After talking about the main architecture, talk about the main UI. The main UI generally refers to the main human-computer interaction interface. The main UI here is distinguished by the mediator in the main architecture. After you read the pureMVC document, you will understand it, mediator serves only as a bridge between the true V and pureMVC frameworks. mediator in pureMVC does not actually implement any functions. The true functions are implemented in the main UI. However, the main UI has to be regarded as an integral part of the main program, because unlike other modules, it basically only needs to call the interface of the main program, and does not need to provide interfaces to the main program itself. As a user interface, the main UI must provide a large number of interfaces or send events to the main program's mediator. Therefore, the cooperation between the main program and the main UI must be very close.
Different game types have different UI solutions. The strategy class is very suitable for standard online games such as flex and MMORPG, and is very suitable for aswing. The game interfaces like ours in the underwater world are exaggerated and there are no standard rules or complicated interfaces, or suitable for your own development. I believe that anyone with experience in game projects should be able to understand that the UI is also the highlight of Flash development. It is very troublesome to handle many details and has a great deal of work in the early stages of the project. Taking our project as an example, our UI architecture is like this:
1. All interface components are directly dragged and dropped on the stage, and most of the functional code is compiled during release, basically using the new method. The advantage of this method is that it is convenient to edit the interface and intuitively grasp all the UIS on the whole, reducing the burden on running the program and avoiding many problems caused by addtostage. The disadvantage is that when the UI expands to a certain scale, you may need to have a computer with better configuration-ah, I am sad to say that, my computer that plays the World of Warcraft effect and has been with me throughout the UI development process.
2. The FLA hierarchy of the UI is like this: the first layer is the document class or a MC associated with the UI main class. We chose the MC method, the MC method is more flexible. The second layer is all the components in the MC. Most of these components are a group of components divided by functions, such as your personal panel, the component itself is also a MC. The third layer is all components in the component or shared components. The components are the background, buttons, and other components. The shared components include the scroll bar, flip components, and so on; the main layer is this layer. In fact, the shared component MC can be further divided by double-clicking it. Corresponds to the level of FLA. The AS structure is AS follows: the document class or the class associated with the main MC is the first layer, which holds reference of all interface elements; the second layer is the component CLASS corresponding to these interface elements. The component functions are implemented here. For example, the MC of the personal panel will correspond to the CLASS of the MyPanel, this CLASS implements all the functions of MyPanel. As for how the CLASS corresponds to the component, I use a loosely coupled proxy mode, that is, passing the MC corresponding to MyPanel as a parameter to the CLASS of MyPanel, this CLASS will have its own private variable record corresponding to the components in MC that need to be operated. Specifically, when it comes to function implementation, from the code perspective, it is as if the CLASS operates on its own private variables, rather than directly operating interface components. In this way, when the interface component modifies its name, the CLASS changes very little. In addition, this proxy mode can implement different components of a CLASS proxy, which is very convenient when the interface only needs to modify the appearance and does not need to modify the function. So where do these classes initialize and obtain the MC that they want to proxy? It is in the UI main class corresponding to the primary MC. For example, after obtaining the MC corresponding to the MyPanel, it will immediately public
Var myPanel: MyPanel = new MyPanel (myPanel_mc; the third layer of the Code is actually shared components. What's special is that my shared components, such as the scroll bar, are also written in proxy mode.
3. The full proxy mode creates a possibility for us to compile the code corresponding to the UI and UI separately. This is similar to FLEX's skin replacement mechanism, except that its components should be new and the layout should be controlled by code, and the skin should be one by one CLASS, the overall effect can be seen only after compilation. My components are dragged directly to the stage, and most of the layout is manually arranged directly in flash ide, the skins are named MC one by one, which can be seen basically before the overall effect is compiled. When FLEX changes the skin, the CLASS name cannot be changed, and when my UI changes the skin, the MC name and Hierarchy cannot be changed. The FLEX associated skin is completed during compilation, while the UI associated skin is dynamically specified when the Startup Program loads the SWF of the UI code and the SWF of the skin. One advantage of compiling skin and functional code separately into two SWF is that in actual development, we sometimes only need to modify the code, and sometimes only need to modify the interface, of course, even if you compile the code and the interface together into a SWF file, it can exactly match this situation. It takes a little longer to compile the file. But when you are faced with this situation: a game version update may not change, but the screen must be returned to the previous version. Are you dumb at this time? You began to roar to the planners: "Do you want to let us do it again ?" However, you still have to re-open the ready UI and change the latest UI back to the old version. At the same time, you do not dare to delete the latest UI, it is estimated that the next version will immediately replace the latest screen. But if your skin and code are compiled into two SWF separately, this is simple, you can just let O & M pull the skin SWF of the previous version from SVN and re-release it. All you have to do is just touch your mouth.
4. Let's talk about the UI data layer. Does the UI need a data layer? The answer is yes. Although you can get any data you want from the main program, although you only need data to display it most of the time, the UI will remember some data to write code easily. The data layer of the UI does not need to be as complicated as the main program. Each component has its own data variables, and the whole UI has another place to store public data.
→ After talking about the main program and the main UI, I will briefly talk about small games, scenarios, and modules. Let's talk about the mini-games first. The mini-games are relatively the most independent one. You may only need the main program to provide user data and send the scores to the main program after the game ends. Therefore, this part is relatively easy to manage, but it does not mean that mini-game development is simple, developing a game with excellent performance and user experience is not an overnight task. If you encounter a game with complicated algorithms, you may have a headache. In fact, for Children's Community games such as the underwater world, small games should take creative and simple routes. They are too complicated to develop, and children may not be able to play well.
Compared with games, scenes and modules are closely related to the main program and even the main UI. However, most of the time, they are in the process of data and sending events, or trigger the display and hiding of an interface. If the modification of a module often involves the main program, or many modules are doing the same thing and repeat the same piece of code, you must review the architecture at this time, check whether the architecture in some places is unreasonable. If the time permits it, you must change it as soon as possible. You must never let yourself go. A small cancer may eventually lead to cancer. Module and scenario programmers are actually very tired in our company, because every week we need to release a new version, and every time we catch up. In this case, the sense of responsibility of the scenario and module programmers is very important. If they are casual, it will directly lead to poor user experience, because most of the time, what users directly access is their work. The architecture is well written, and the final modules are all very bad, so there is no value for users! Therefore, an old and responsible AS module programmer who can quickly develop excellent user experience has a reason to earn a high salary because they can do it, some so-called pure architects may not be able to do this!