Webgame front-end architecture and division of labor

From: http://blog.csdn.net/txiejun/article/details/5924108

Front-end architecture and Personnel Division of Flash web game
→ Front-end masterProgramThe architecture and module division are closely linked with the division of labor and personnel, which are largely determined by the project itself. Looking at the scale and difficulty of the vast majority of flash web games in China, I think there are about 2-7 front-end as personnel, and the main program is effective.CodeGenerally, there will be no more than 10 million rows. In this case, the Division of Personnel should be divided by functions and modules, so as to avoid the maintenance of the same Code by multiple people as much as possible. Each person performs his/her duties to reduce the maintenance and collaboration costs. This model is very suitable for startups with insufficient manpower, imperfect systems, and efficiency.

→ The division of labor should be different based on different game types. The strategy class focuses more on interface development, and the division of labor should focus more on the UI. The MMORPG class focuses more on the main architecture, and the update-driven class is like our underwater world.CommunityA game needs to publish new content every week. It also requires a large number of mini-games and scenario functions, so more modules and mini-game programmers are needed.

→ Next we will take our company as an example to discuss in detail. When we have the most companies, we have a total of five as programmers. The division of labor is like this: one master architecture and one master UI, 1 game, 2 scenarios and module programmers. The main architecture is responsible for the FMS sever at the same time. The main UI is also responsible for front-end personnel management and file management. The mini-games are continuously developed at an average speed of two single machines or online games per month, it is the most independent part, and the two module programmers are responsible for the weekly release of new scenes and new module functions, their workload is actually quite large.

→ Let's first 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 the architecture and propose feasible implementation solutions; 2, build a program architecture (non-document level) at the AS level, develop front-end 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.

→ The points mentioned above cannot be completely described, otherwise they will not be called "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!