The background,

Vivo Game Center is a vertical app store that provides users with a variety of download channels for games. With the enrichment of mobile game categories in the Game Center, the number of users in each category is also increasing, and the core concerns of users with different game preferences are also different. From booking, testing, launch, update and maintenance, the operation of different game life cycle nodes needs to be highlighted differently.

In view of the different business scenarios mentioned above, in order to serve the vast number of Vivo game users, operators need to carry out fine operation and present different visual styles to different users. For example, for users in the indie game category, if the platform provides the disclosure of activities, walkthroughs and other content, users will be able to promote more downloads and consumption. Activities, strategies and other content are presented in different visual styles. The operation needs to verify the effect through experiments to determine the final delivery plan. These requirements all need to be redeveloped. Limited by the long release time of game center APP, the expected effect of operation is often not good.

Therefore, we hope that the system has the following capabilities: through the abstraction and reuse of different visual styles, quickly and flexibly adjust the layout of the page, to different groups of people, and finally to determine the best delivery scheme in an experimental way.

How can these system functions be implemented? The answer is modularity. Here is a look at the modular practice of the game center.

What is modularity

So-called modularity, in fact, it is a modular design idea, that is, it refers to the same or different function, performance, specifications of the product, for functional analysis, and design a series of functional modules.

Through the diverse selection of modules to customize products, can meet many different needs of the market. Then the game center modularization is for the same or different functions of the game center visual style, business scene analysis, and design a series of functional modules. Through the diverse selection of modules, quickly and flexibly set up different pages to meet the needs of different users.

Modularity has three capabilities: componentization, configuration, and experimentation.

• Componentalization, that is, the page layout is divided into multiple components, these components are abstract, and then achieve the purpose of reuse. Components are combinations of UI styles and data, and componentization cuts UI styles into separate, reusable areas.

• Configuration, that is, through the splicing of different components, can quickly build a variety of pages. Components are the basic unit of a page, so each page is made up of several components. Components are abstract and output is unified, and can be flexibly adjusted in order and location according to different requirements.

• Experimental, that is, through the multi-layer experimental framework and DMP system, different pages can be quickly put on the mobile phones of users with different characteristics, so as to achieve the purpose of multi-version operation. The multi-layer experimental framework is the ABtest framework implemented internally by Vivo. DMP system is the data management platform, which can be simply understood as a data pool, used to receive data from all parties, and then use these data after fusion, processing and optimization.

As you can see, the three functions correspond to three concepts. Componentization corresponds to components, configuration corresponds to pages, and experimentation corresponds to solutions. They are contained relationships, that is, a scenario contains several pages, and a page contains several components.

Before modularization, the front page of the game center was composed of advertising banners at the top, navigation bars, game listings, and interspersed components. An interlude component is an AD made up of visual styles and data that is inserted horizontally into the list of games for marketing purposes. The definition of interspersed components is actually componentization, but at the time, the distinction was made between componentization and game lists. The visual style of interspersed components is relatively simple, only featuring topics, videos, hot words, activities, forums, etc. As shown in Figure 1, the small editor recommends the hot Tour station, and the first recommendation is 1*4 game thematic interspersion, similar to the nine-grid (eight hot search words) for hot words interspersion.

(Figure 1: Before modularization)

Interspersed components in accordance with a certain law interspersed in any position in the game list, but the advertising banner and navigation bar is fixed, the whole page layout is chaotic, fixed shape, not easy to change. If the top of the banner moved to the small series recommended below, only through the version of the solution. Changing “more” to “Swap” in the top right corner of the feature, or changing the list of games to a description of their content, also requires a release.

Modularity allows for flexible ordering, dynamic changes to the visual style of components, and dynamic configuration of even the list of games. You can quickly build a page using a sequence of components.

Through the FRAMEWORK of ABtest and DMP system, different pages can be quickly presented to the corresponding groups in the way of putting plans, so as to carry out multi-version operation. Figure 1 and 2 are the comparison diagram recommended before and after the modularization of the home page, although there is no big change from the big style, but before the modularization of the style is relatively single, and after the modularization of the game list is arranged in the single game big picture, king Kong bit, small speakers, thematic, new tour appointment, download list and other components.

(Figure 2: After modularization)

Different components can meet different business scenarios. For example, the single game big-picture component, supplemented by recommendations, can quickly promote new and hot games, meeting the needs of different users for different game nodes; The new game booking component can be used in more ways to meet users’ needs for pre-subscription content or real-time updates for individual games.

Three, how to achieve modularization

As you can see from the previous introduction, modularity through the way of components quickly build pages and put them into different labels of the crowd, powerful and flexible configuration, for us to save a lot of development costs, so how do we realize the bottom?

3.1 Model abstraction and unification

Based on the component layout, we can abstract the component into two parts: visual style and data; Visual styles can be simply understood as UI styles, the presentation presented to the user, and can be summarized as templates.

The template defines the most basic form of the current component, such as whether the current component is a slider or a fixed form. The template also defines some variable styles, that is, defines which positions of the current template can be configured, such as the length, width and height of the template, the combination of styles (2*2,1*4), the number of lists, etc. The degree of dynamic configuration depends on the template definition.

The so-called data is divided into recommended data and manual scheduled data by source. Recommendation data comes from algorithms and big data, while manual scheduling is configured in the background by operators. Due to the complexity of the logic behind the recommendation data, this article only discusses manual scheduling data. Labor scheduling is a four-dimensional data set. In addition to the “business” of the data itself, it is time-sensitive. The display of advertising space in the game center is time-limited. For example, the banner at the top of the home page of the game center is not the same as that displayed yesterday. Second, it is “spatial”, that is, different users may see different data; In addition, it is action, that is, the event that occurs after a click. Clicking on a component, for example, can bring up a hover window or switch to another page.

Thus, modularity can be simply understood as a combination of templates and manual scheduling. In a common sense, a component is like a class, and the different components on each page are the objects of the component, which instantiate some data and behavior. Through the componentization approach, we not only solve the end-to-end and server-side coupling, but also realize the reuse of components across different pages.

Scheduling data is divided into three levels (material, promotional materials and scheduling). Of course, the lowest level of data is pictures, videos, recommendations, comments, etc. Of course, game information also includes game icon, background picture and simple video, but the picture here does not refer to the game icon, but is more refined than the icon and used for advertising material pictures, which are collectively referred to as materials. The material consists of the upper level of promotion materials.

What are promotional materials? Promotional material is actually based on a certain purpose, according to a certain form to display the collection of content. For example, banner is actually composed of a picture and the associated content behind it. The picture is to attract users to click and promote the associated content behind it. Promotion material with time space and action properties becomes scheduling. Materials, promotional materials and schedules are all abstracted uniformly.

As shown in Figure 3, promotional materials include banners, special topics, activities, web pages, etc. The schedule has capsule banner, swim information, grass machine, heavy update and so on; For example, the grass machine is composed of web pages (content links) and time; The whole structure presents an inverted pyramid structure.

(figure 3)

The scheduling data of each resource bit in the original game center are placed in different places, such as the top banner scheduling, online game banner scheduling have their own tables to save. In such cases, the number of database tables may be large, making unified extension more complex. If I need to increase the display of different data for different groups (DMP system) for both the top banner and online game banner, I usually need to add a DMP field in each table to represent the label ID of the current schedule to be displayed to users.

After modularization, we treat all resource bits in the game center as modules, which can be regarded as scheduling data. We only need two tables to display 3d scheduling data: scheduling data table and specific material table associated with scheduling. Therefore, when designing the schedule, we store the material information (Material_id and Material_Type as shown in Figure 4) in the schedule, and store DMP or other unified information in the schedule. The advantage of this is that a unified process can take effect for all schedules.

(figure 4)

3.2 Unification and visualization of background business processes

Such a complex business process, certainly not with the background. After the unification of material, promotion material and schedule, we will standardize the background configuration process.

The specific configuration process is shown in Figure 5 and 6. Figure 5 is a background configuration process that is bottom-up. Figure 6, for your convenience, is a top-down structure. At the user level, a specific solution is displayed. The solution consists of several pages and is displayed according to the user’s portrait. That is, the number of configured pages is not necessarily the number of displayed pages. A page is made up of several components, consisting of templates and data…. Layer by layer, the modular structure can be understood as a whole.

(figure 5)

(figure 6)

Before modularization, configure the home page banner schedule, need to go to the home page banner TAB column, in all the banner schedule inside to join the relevant schedule, and then select all the banner schedule inside the home page data, and configure the banner schedule of other pages, Also need to do related operations in a similar directory structure, the banner between each other is split, cannot be common; For operation, configuration workload has also increased a lot.

After modularization, operation becomes very simple. At the component level, through database configuration, we can pre-store template information in the database. At the data level, we store all banner data in the promotion material management and bind them to the schedule for reuse. On the service component management page, select a template based on the application scenario of the component and configure the scheduled data.

As shown in Figure 7, the current heavy update scenario is associated with manual scheduling (if it is associated with a recommendation, it is the recommended code), and the entire business component is configured after the style is configured. Then add the component you want to configure to a page in page management and set the corresponding DMP. After components are configured, you can scroll to preview the overall page effect.

(figure 7)

As shown in figure 8. Finally, the page can be reused to different delivery schemes. After the operation background passes the audit flow and online spot inspection, it will be displayed in the user interface. The current configuration process is bottom-up, logical, and complies with the configuration habits of the operation.

(figure 8)

3.3 Front-end business process abstraction and unification

At present, the home page of the game center and the new tour area have been transformed into modular pages. The home page is a very important distribution channel for the game center. Modularization requires a variety of page forms, and dynamic backtracking should be possible if the modularization transformation is not recognized by users.

Therefore, there are three types of home page modular pages:

• Pure modular pages,

• Intersperse modular pages and

• H5 modular page

A purely modular page is one in which all elements are composed of componentized data. The so-called interspersed modular page, its page structure is in accordance with certain rules in the game list interspersed with a number of components, and modular before the page organization structure is exactly the same, but the implementation of the background is not the same.

There are also two different forms of lists in interspersed modular pages, game lists and mixed data flow lists. Interspersed pages are the most efficient way to show a game on one screen.

Finally, the H5 modular page can be considered as a page composed of H5 components, which is provided by wukong website of our company. The process of obtaining different schemes and different pages through the multi-layer experimental framework and DMP is not described here. Here we take a look at the most complex interspersed page flow of the whole process, and how we abstract and design in such a complex process.

(figure 9)

3.3.1 Process unification

From the diagram above (you don’t need to pay too much attention to the business logic of each step in the flow chart, the flow chart is just to show the complexity of the original process), we can see that the user request, it needs to go through N steps. Such lengthy steps, if written in a service, would result in logic chaos, poor maintainability, and poor scalability, so we can divide and conquer. In Figure 9, we color-coded the steps to make a simple process generalization.

The summarized process is shown in the figure below. We can summarize the submission asynchronous thread pool as a two-step process of getting the component list and the mixed data list.

(figure 10)

After generalization and abstraction, the whole modular page acquisition process can be simplified into four steps: initialization, component list acquisition, construction and merge, as shown in the figure;

(figure 11)

As stated in the Pyramid Principle, readers must read and understand each sentence, look for connections between each sentence, and think back and forth as they read. If you have a pyramid structure and your ideas start at the top of the pyramid and work their way down, the reader will find your text easier to follow. This phenomenon reflects the basic law of the human mind, so reading code is the same logic. Good code is a comment on a piece of business logic that gives you a sense of the main business process by reading the code. During the construction phase, different policies can be combined to capture different scheduling data. Policies are decoupled from components. When a new policy is added, the original service logic does not need to be changed. The different policies here can also be captured using the factory pattern approach.

The logic of presenting components on the home page is complex, especially for interspersed modular pages. As mentioned above, interspersed pages are made up of a list of games and business components, with each business component interspersed within a list of games. Data list If it is a game data list, then each game is arranged in proportion, and the underlying data required to promote the material in the component is the de-duplication of the game. Like games according to the online games, stand-alone and the proportion of independent games to show, if the current game on a component, then the game needs to be filtered, and make up for a game is a logic, such as online games are filtered, so complement the game list, secondly to fill with online games, again with the following on the top of the game. There are two kinds of de-refactoring logic: one can be filtered by previous games, and the following games can be filtered. The other can only replay the game below, not the game above.

(figure 12)

In the acquisition of scheduled data in business components (as shown in the figure above, which also contains game information), there will also be acquisition of ABTest information (different users show different game information), game blacklist and whitelist filtering, installed filtering, exposed filtering, additional information processing, component data assembly and other processes. Each scheduled data acquisition is handled by a different Handler. Each Handler has its own processing logic, and with so many schedules and their extensions, it would be a disaster to not have a single set of processing logic. New people can miss a lot of details when they schedule data in a new component. In addition, there are some common logic between promotion materials. If these logic is not deposited into the domain model, the logic cannot be reused and will be scattered in various handlers, as detailed in the orange steps in the figure below.

3.3.2 Unify the process of promoting materials

On the one hand, we will unify the process of acquiring and handling promotional materials. In fact, the process shown in the figure below basically contains all the step logic that promotion materials need to deal with (unimportant steps have been ignored). Once unified, we can sink some common logic into a unified method call. For example, we can mask the logic of acquiring promotional materials by adopting a factory approach to design patterns based on manual scheduling, recommended scheduling, etc. Of course, in order to improve performance, we use the unified cache method and common scene code to obtain the manual scheduled data. Then use different filtering strategies to filter out games or content that make it into the black and grey list. Use the list data to remove duplicate data from components after processing additional information.

(figure 13)

3.3.3 Logical abstraction and precipitation of the model

On the other hand, we precipitate the logic of unified processing of components and promotion materials into the corresponding domain model, as shown in the figure.

(figure 14)

The filtering process of duplicate data are for the components, then at the component level, there will be a lot of repetition logic, such as each component need on the last returns the number of data processing, the number of different components to return is not the same, so this part of logic is written in the component model in this field will be more appropriate. Such as exposed and installed processing, this logic can be handled at the component level, but also at the Handler level. At the level of promotion materials, there are also some general logic, such as the topic composed of 1*4 games and the topic composed of 2*2 games. Behind them, there is a logic of access to the recommendation system and the bottom, which can also be deposited in the field model of the topic to deal with.

Write at the end

At present, many business development students, especially after they are familiar with the business, usually fall into a mistake: business is basically CRUD, no technical content. But in the process of development, often lack of corresponding thinking, resulting in repeated development. So how do you make business development more attractive and technical?

In the process of modular transformation of game center, the abstraction and reuse of components are utilized to enhance the componentization, configuration and experiment capabilities, and quickly support business requirements. Meanwhile, the business code is constantly improved through unified standard process and domain model knowledge, and the maintainability and expansibility of the code are improved. As the business grows, even today’s perfectly sensible architecture becomes bloated and difficult to scale, but the methodology for doing business well remains the same. Therefore, business development students should think more about how to make the business deep and general, improve the ability to quickly realize business value.

Author: Vivo Internet Server Team — Chen Wenyang