What kind of team is more likely to succeed in making games?

[[147743]]

I have been observing some teams making games recently, hoping to draw some conclusions about “what kind of teams are more likely to succeed in making games?” Although I did not come up with any rigorous data results, it also gave me a better understanding of how a game is made.

In the past two years, with the rise of mobile games, a large number of mobile game companies have emerged in China, including a large number of mobile game development teams. Based on my own simple understanding, I can divide game development teams into three main categories.

One is the R&D team in large companies, such as the R&D teams of large companies like Tencent and NetEase.

One is a R&D team whose core personnel come from large companies.

One is a research and development team whose core members are not from super large companies but are related to the gaming industry.

Why is it classified like this? Here we mainly summarize it based on several typical R&D processes. Large companies have their own set of strict rules and processes, and the same is true for game development. Each position has a clear division of labor, and there are also multiple job classifications. Compared with small and medium-sized companies, developers in large companies usually only need to be responsible for their own work, but what about small and medium-sized companies? Developers usually need to take on multiple roles, or need to take the initiative to participate in the work of multiple modules.

Borrowing a diagram made by teacher Sun Zhichao, we can simply read from the diagram a common working state of people engaged in the three main positions of programming, planning, and art in development work.

According to my own conversations with many developers, one of the most troublesome things in the process of making games is that the leaders often propose to modify the game content, causing the entire team to work overtime overnight to make corrections.

Changing requirements is always painful

Mr. A, who is currently working in a large company, said that before he came to his current company, he was involved in the development of mobile games in a company with 200 to 300 people. His previous employer was an ordinary R&D company that switched from web games to mobile games. The boss of the company entered the game industry with his own capital during the web game era. He was not a serious game developer and could not say that he was very proficient in many aspects of game design, but he often thought he understood design, which later brought a lot of trouble to their actual development work. For example, their games often had a small change every three days and a big change every week. He said that every time he saw the boss come to the project team to experience the game, he knew that he had to work overtime again.

I asked him, doesn't your company have several project teams? Is your boss like this for every project?

He said, of course not. There is a project in the company that he is the core leader of, but other projects also need to report to him at every stage from the project establishment. The result of each report is almost always a change. Of course, these project teams have fewer changes than the project teams led by their boss, but because of this environment, many planners will develop an execution mentality, always thinking that it is right to follow the boss's ideas. Why does this happen? Because those who do not execute well usually leave after a short time.

He asked, how can we make a successful game in such an environment? He smiled. His previous company had not produced a successful product in the two years since it transformed into mobile games. The result of each modification was always that the game became more and more chaotic.

After working there for more than two years, he switched to the big company he is working for now.

He said that the comparison between the two was really profound. For example, in his previous company, the planner would propose a requirement, and the programmer would object that the implementation would not work well. The planner would then ask to make it first and see. Then, after the programmer was done, the planner would say that the effect was not good and should be changed, especially on the UI interface (he was a front-end programmer).

For example, planners often say that the model needs to be detailed and have various streamers. The programmer says that the model has too many faces and too many bones, which makes the program inefficient. The planner will also say this first, and then the program will not run, and the artist will suffer, and the model will be changed again to reduce the number of faces and bones.

[[147744]]

If it were today's big companies, what would they do?

His current project team is that the planning team first produces the documents, and then all the documents are handed over to the UI design team. In addition to the visual design, the UI design team also uses the UI editor. Basically, 80% of the changes that need to be made are solved between the planning team and the UI team. The program is only changed at the end, and the changes are generally not big.

Another problem is that the previous company process was chaotic, and it was completely ruled by people, rather than strictly following the company's rules. Whoever had a good relationship with the boss would take their time, and there was no concept of target version time, and they often made demands without thinking. Now the company sets the requirements first, then the project manager arranges the time, and then does it according to the time point. Basically, everything is done according to the bill of lading, order tracking, and order settlement.

Planning finally doesn’t have to bear the responsibility of art

Many planners have reported that when they are working on functional documents, they often need to submit art references and even materials to the art department. However, many artists will directly modify and adopt the references, but rarely design the best features or more prominent effects.

Mr. A said that his company was similar in the past, where it was not common to find artists with excellent independent design capabilities. Now the planners of this company just make demands and provide some similar game screenshots, allowing the artists to design for reference. They do not need to provide all the materials, and can still design very different performance effects.

Regarding the communication between planners and artists, the author has previously interviewed Chen Wei, who is responsible for the management of the art team of Tencent's game distribution platform. He said that when connecting with planners, planners will usually provide reference art, but the artist should ask clearly what part of the picture the planner wants to refer to and what details of the picture need to be referenced, such as composition, lines or colors, etc., instead of directly making a highly similar imitation.

Good communication between artists and planners can not only improve the art quality of the game, but also reduce the probability of rework when making a more complex game that requires a large amount of art resources.

Regarding the modification requirements mentioned above, in a development team with strict processes, planners need to have relatively high requirements for game design capabilities. Therefore, most of the designs will be proposed after careful consideration, which will also reduce the need for later modifications.

Game stage review

Even the first-tier domestic companies need to modify their games. This is different from the random modification requirements mentioned above. This is about planned modification. For example, during the game production process, large companies set a time for stage review. When the stage review comes, they can openly propose modification suggestions. This suggestion must also be based on the actual needs of the game. In the end, it also needs to be approved by the PM and the main planner before it can be determined whether to modify or not.

What if it is a small demand? For example, some small bugs, you can submit a bill for modification at any time.

What about those people in the middle?

The above mentioned are perhaps the two most extreme types. There is also a group of teams in between, with clear development processes but not very strict management. These teams usually have one characteristic: the core members of the team have experience working in large companies.

Because of my deep experience, I can better understand the pros and cons of large companies. For example, too much follow-the-book process will also cause a certain waste of time and energy, and for small and medium-sized teams, occasional brainstorming may generate more unexpected good ideas.

The author has also talked with Mr. B, a planner in such a team. He said that several key managers of their company came from several large domestic factories, and they all had a certain amount of experience in large factories before starting the company. Now the company also has several relatively successful projects in operation. Although the products are not hot-selling, the income is still relatively stable.

Mr. B said that before he came to this company, he had also worked in a company with less "rules". In comparison, the project development here follows the basic process common to a large company, but because the positions are not as detailed as in a large company, everyone has to take care of other work to a greater or lesser extent, such as helping the artist find materials. After all, in a small or medium-sized team, it is impossible to ensure that every link is strong.

The key to being better than before is that they have a boss who is more knowledgeable about R&D or market operations. Although their boss is not good in every aspect, he has at least established a relatively basic R&D process for the company. And because he has worked in a large company, he has good connections and can get some more substantial data analysis. In addition, several key members of the team are capable, which has saved many detours in the entire R&D process, and he has also learned a lot from it.

He said that maybe because their boss came from the grassroots level, he is more likely to accept the opinions of team members. Moreover, if their boss proposes changes, as long as they can explain why it is unreasonable to do so and there is a valid reason, their boss will respect their opinions.

However, because it is a company that they founded with great difficulty, the bosses are more persistent in the project than those in big companies, and their team is also crazy about working overtime.

Success is not accidental

In fact, the people who know best how well a game is done are actually the developers themselves.

Judging from the market performance this year, the products that performed very well were almost all produced by relatively strong manufacturers. We all say that this year is a year of great success, and many unqualified teams will be eliminated. The market has reached a certain level of quality games, and even strong teams may not succeed, let alone those teams that just want to try their hand at operations?

During this year's CJ, we interviewed several senior executives in the industry, and most of them said that the trend of the domestic game industry will return to relying on products. When marketing is done to the extreme, quantity is becoming increasingly difficult, and product quality becomes the key to competition.

A development process in the sense of popular science

(1) Core concepts

(2) Selection of human resources and market assessment...

(3) Brainstorming, core gameplay; numerical, art, and programming intervention; solving technical difficulties and producing a demo

(4) Determine the version plan; including the development cycle, etc.

(5) Overall design plan; develop core systems, and art needs to support basic resources

(6) Then comes the *** cycle: design, development, testing, modification → design, development, testing, modification

(7) Complete version development, partner and operation plan setting;

(8) Internal testing (data feedback for operational preparation), public testing (providing resources for public testing, pre-paid public testing to see market response), official launch, traffic guidance, and large-scale promotion

(9) Market, channels, volume purchase, publicity, etc.

(10) Continuous game updates (enriched gameplay, new systems added during the life cycle), user feedback modifications, cooperation with operational activities, mid-term server mergers, server connections, cross-server mergers, etc.;

A development process in the sense of planning

The game framework and art style must be determined first.

Early stage:

The game style, positioning, game combat mode, and core gameplay need to be determined first; for example: martial arts themes, arpg, outdoor PK (relative to pushing maps), combat action settings, the core gameplay is equipment replacement, martial arts system with a certain advanced system (mounts, pets, magic weapons, wings, artifacts, etc.); card games are card decks and equipment;

When art is involved, especially for mobile games, it is necessary to perform stress testing based on the basic core design;

Programming intervention, building a framework (basic 2D or 3D game, what technology to use, resource allocation to computer/ipad hardware; on the server side, consider compatibility and server-to-server, cross-server mechanism settings, etc.)

With numerical intervention, the data model will be developed; including what formula to use for combat calculation, attribute setting, attribute calculation formula, growth curve, cost performance curve; for example, if you are making a big R, short-term game, the growth curve of each system may be a √ curve. If you are making a long-term game to suppress the impact of payment on the difference in combat power, the curve is an inverted hook; there is also the setting of the game rhythm; the ratio of the specific gap between player attributes and the actual strength gap; the simulation of the gap between each attribute situation, the simulation of the gap between each recharge situation, etc.; there is also the proportion of each attribute in each system;

Mid-term:

The system needs to do more detailed positioning;

The system needs to communicate with the numerical side to connect the consumption system with activities, dungeons, server launch activities, etc. to form a loop;

There is also the supplement of specific gameplay, including consumption induction (collection in the system stage); please note that the so-called supplement of specific gameplay must be after the positioning of each system;

Later stage:

Specific development; numerical verification; gameplay verification; early process adjustment; answering a few questions: how to do duration (online flat-to-high ratio), retention, payment rate, arpu value, recharge range, etc.;