The Challenges and Illusions of Developing AAA Games —— Part 2

Continuing from the previous article, "The Challenges and Illusions of Developing AAA Games - Part 1," let's discuss the drawbacks of large-scale teams and game development projects.

Challenges and Considerations for Large-Scale Game Development Projects

This part overlaps with the Pipeline section so let's supplement it a bit.

1. The game directory is getting bigger and bigger, and the speed disadvantage of the previously well-functioning SVN is showing. Synchronizing a version may take more than 30 minutes. Is it time to upgrade to Perforce or use GIT? The efficiency of the new version of SVN should be much higher, but it's also a bit ridiculous to store a large amount of version management data on the user's local machine. I used GIT for a version before, and it mysteriously ran out of memory, so I never used it again. It is said that Git local storage + P4 team collaboration is good, but with larger versions, the maintenance overhead is not small. Perforce's speed and stability are top-notch, and its features are powerful. Large projects I've participated in have always used Perforce, but the free version only has 20 user licenses, and more require purchasing, which is relatively expensive.

2. The compilation time is getting longer and longer. Products like Incredible Build can help, and upgrading the computer and equipping it with an SSD can also be helpful. However, overall, the iteration speed will be affected. Especially with Incredible Build, it can only parallelize and speed up compilation, not linking, and incremental linking is precisely the most commonly used feature in a programmer's daily work. No one frequently compiles the entire project; usually, it involves modifying a few files, compiling, and linking for testing. The length of linking time affects the iteration speed of programmers. Additionally, I dislike those who casually include a bunch of external libraries. Although we shouldn't reinvent the wheel, heavyweight external libraries can bring certain impacts in terms of compilation time, maintenance costs, and even legal issues with licenses, which require careful consideration. Different engines will perform differently on this issue. For example, many engines use a lot of scripts to significantly reduce compilation and linking time. However, the tricky part of this issue is that it is rarely foreseen in advance. Often, when you encounter it, the project has already expanded to a relatively large scale, and there is no way to modify it.

3. The learning cost of large versions has increased dramatically. Newcomers can no longer get started in a short period, and for the development of new features, they often need to read through many related modules before starting. Impulsive colleagues might ignore existing features and redevelop a basic function, often resulting in an even inferior version, further contributing to code bloat. Some colleagues with poor development habits may add fuel to the fire by copying and pasting code, or those with limited skills may manually obfuscate the code, making it difficult for others to decipher its meaning easily. Planners frequently change requirements, and when the old code cannot meet their needs and they are reluctant to delete it, patching it up leads to a continuous decline in readability. All of these factors make many projects that last 4-5 years a nightmare for programmers. Modifying a single line of code in a file can cause a crash elsewhere, fully demonstrating the meaning of the butterfly effect to future generations.

4. Due to the reduced compilation speed and the increase in version size, the development efficiency of programmers has dropped sharply. In the early stages of prototype development, we were full of confidence, saying that there might be several solutions for this system, and we should spend more time making them all to compare their effects. However, in the later stages, we become much more cautious because there is not enough time to implement everything. To compensate for the decrease in efficiency, more programmers are needed, and more programmers bring management pressure and communication costs, resulting in diminishing marginal utility as more people are added. Depending on the maturity of each team and the management skills of the leader, each team has a certain scale. Once this scale is exceeded, adding more people will not improve development efficiency.

The Dangers of Well-Intentioned Leadership in Game Development

Having talked about the issue of project scale, let's discuss management issues.

Since it is a star project within the company, the leaders will undoubtedly attach great importance to it. They will provide you with more resources, more financial support, and more help. However, many times, help from outside the team can be harmful. The more attention a project receives, the more it is noticed by leaders at all levels, the more goodwill it receives, and the more likely it is to suffer from indigestion.

1. Assigning "Expert" Assistance

Leaders may offer to provide experts to assist with various aspects of the project, such as creative direction, technology, or project management. While their intentions may be good, these experts may not always be the best fit for the project. They may be out of touch with the current situation, lack the necessary skills, or struggle to cooperate with the team due to language or cultural barriers. In these cases, their presence can lead to confusion and even hinder the project's progress.

2. Offering Suggestions for the Game

Another common issue arises when leaders offer suggestions for the game itself. The lower the technical barriers of a task, the more likely it is to be criticized. This can lead to an increased focus on areas such as UI, original art, scenes, planning, and client performance, while more technical aspects are left untouched. While leaders may have valuable insights, their opinions may not always align, making it difficult for the team to implement their suggestions effectively. In the end, the quality of the game may suffer as a result.

3. Chasing New Competitors, Technologies, or Directions

Perhaps the most significant challenge arises when leaders become enamored with new competitors, technologies, or directions they believe represent advanced productivity. They may encourage the team to adopt these new approaches, even if they are not in line with the project's original design. This can lead to constant refactoring, delays, and an endless chase for the next big thing. Over time, the project may become bogged down, much like the mythical behemoth trapped in a tar pit, never quite reaching completion.

To be continued......