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

Introduction

In the foreign video game industry, there is a category of games called AAA games. The definition on Wikipedia is:

In the video game industry, AAA (pronounced "triple A") is a classification term used for games with the highest development budgets and levels of promotion or the highest ratings by a consensus of professional reviewers. A title considered to be AAA is therefore expected to be a high-quality game or to be among the year's bestsellers. [5][not in citation given] For a title to remain AAA post-launch, it must be either commercially or critically successful.

In short, AAA games are high-budget, high-promotion, and high-quality games that are generally expected to achieve great commercial success.

Developing AAA games is the ultimate pursuit of large game development companies, and they invest a lot of resources in developing AAA games every year. Currently, single-player games are not very prosperous, and the main driving force of the single-player industry still relies on products with a number behind their names, and the number increases by 1 every year.

Similar practices are also common in China, and every major developer has its flagship product, which we can consider as China's AAA games. Undoubtedly, the emphasis on AAA game development will make these companies invest resources and attention in these products from top to bottom. However, an interesting phenomenon is that many major projects often encounter difficulties in completion or take many years, like a bottomless pit, attracting companies to continuously invest, but with slow progress.

The same phenomenon keeps reappearing in many projects. There must be something wrong here, leading to a disproportionate input-output ratio. Let's analyze a few reasons:

Productivity Illusion Created by Efficiency of Initial Game Development Prototype

In the early prototype stage of a project, often 1-2 programmers can create a lot in a short period, which can cause the team to underestimate the difficulty of developing the entire game. There are several different situations here:

1. Using Commercial Engines: In the early stages, if you are using a commercial engine like Unity, CryEngine, or Unreal, you can start by applying the built-in framework or demo based on the type of game you want to create. The marketplace offers you a direct choice of prototypes. Excluding the learning cost, a rough game prototype will appear in a short time.

2. Using Mature In-house Engines: If you use a mature in-house engine, you can refer to the previous successful projects quickly bring a large amount of available code and resources, and simply piece together a demo.

3. Developing New In-house Engines: If you are developing a new in-house engine, the team size is small at the beginning, the engine scale is also small, there are fewer systems, no need to consider multi-person collaboration, and no need to consider whether various systems can work harmoniously. A simple hack can complete the prototype. With less burden, it naturally runs fast.

Soon, an exceptional demo is produced, leaving the leaders highly impressed. This small group of individuals proves to be reliable, using minimal time and resources to create an impressive prototype. It's easy for management to assume that this is a top-notch team and that by investing more money and expanding the team, they could rapidly develop an AAA game that brings in a fortune. 

However, as an experienced developer, it's crucial to resist such over-optimistic thoughts. While your team may be talented, your industry knowledge extensive, and the full support of the company behind you, along with a multi-million dollar budget, none of these factors guarantee a successful game. Success is not owed to anyone, and even the most promising product prototype can ultimately fail.

With a smaller scale, there's often less need to create everything from scratch, making it possible to modify existing demos and utilize them. The small scale also means that team coordination is more streamlined, with minimal politics, compatibility issues, and everyone working towards a shared goal. Communication costs are low, as there's no need to book meeting rooms - a simple shout can lead to seeing the desired feature in the game the next day.

Due to the limited scale, there are fewer interconnected systems, which means it's less likely for a feature prototype to take an extended period to complete, integrate into the version branch, sort out various processes, fix crashes, and ultimately cause delays.

In a small-scale project, everyone's opinions are more easily respected, fostering an entrepreneurial spirit within the team. Additionally, expectations tend to be lower, so any progress made is seen as impressive. Small demos often have art resources quickly pieced together, further contributing to the overall efficiency of the prototype phase.

When the demo is finally completed and the project is approved, everyone is enthusiastic and ready to give their all. But then, you notice a small issue with the engine.

The early benefits provided by commercial engines will soon vanish, and you'll have to work on each desired feature individually. At that point, you may realize that you're not familiar with the engine, and making modifications feels clumsy; or the engine has numerous features you don't need, which adds extra burdens; or the engine was sold with inflated promises, and upon receiving it, it doesn't live up to expectations; where is the 24-hour support promised by the engine developer?

If it's a self-developed engine, there are just as many concerns. The makeshift features in the program are not suitable for multi-person collaboration between planners and artists. Do you want to change it? There are numerous hard-coded parts designed for the demo, but you need data-driven features. After becoming data-driven, you can hand it over to content developers for maintenance. Programmers certainly can't resist this temptation; there are many unfinished camera features in the demo, with low priority, and you let the leaders imagine them during the presentation. You don't plan to let players imagine them too, right? On one hand, the promised features are incomplete, and on the other hand, idle planners and artists start twiddling their thumbs. The pressure from all sides is palpable, isn't it?

After the demo is completed, it usually takes a significant amount of time to reorganize the team and restructure the architecture. This downtime is not uncommon in every project, but it is often hidden and not easily noticed.

Challenges of a Growing Team

As a team expands, it inevitably encounters various challenges due to the diverse nature of its members. These challenges include:

- Inefficient communication due to some team members' inability to express themselves effectively.

- Incomplete feature development as a result of differing understandings among team members.

- Highly skilled individuals who struggle to cooperate, preferring to work independently.

- Team members who avoid working overtime, showing little concern for meeting deadlines.

- Those who consistently work excessive overtime, causing discomfort within the team.

- Individuals who are unwilling to learn and struggle to keep up with the project's demands.

- Overly eager learners who promote untested technologies, creating chaos within the project.

New employees joining the project can increase communication costs, as everyone's background and habits may differ. Some may join for the experience, others for learning, some to put out fires, and some may be assigned involuntarily by their leaders. Building a cohesive team culture, organizing learning activities, and continuously interviewing new members can be a time-consuming process.

Addressing Development Pipeline Challenges

1. Relying on scene resources from other games is no longer viable. Should we establish a suitable outsourcing process and secure funding for it?

2. Designers are frustrated with using XML. Should we limit their use or have programmers create a graphical tool to assist them?

3. Hardcoding the UI is not an option anymore. Should we consider using Scaleform? However, it might be challenging to quickly retrofit previous work.

4. Manual building has become unmanageable. Developing an automated build, daily build, automated unit testing, automatic data conversion, build permission management, automated smoke testing, automated deployment, code review system, and distributed compilation may take longer than a month, but it is necessary.

5. The art team has reported that the development progress for a specific level is falling behind, requiring multiple people to collaborate. Since the editor isn't designed for group collaboration, a temporary merge solution should be created for emergencies.

6. The company has various internal technical review processes that can be complex. As a significant project, we should respect these processes, prepare documentation, and explain our rationale.

7. After much overtime work, everything is finally in order. Seeing the programming, design, and art teams working independently and efficiently in parallel brings satisfaction. However, this may not be the only challenge faced.

To be continued, please stay tuned for the next article: The Challenges and Illusions of Developing AAA Games —— Part 2