“Lessons Learned from Reducing Scope Mid-Development”

It’s every game developer’s dream to successfully build the game they first envisioned. One with all the cool mechanics, characters, and systems that truly make it unique. However, as every game developer with an ounce of experience knows, this dream is just that – a dream. Projects are nearly always over-scoped one way or another. Whether it’s due to ambitious planning or unforeseen circumstances, chances are high that there will be a feature you must cut if you want the game to ship. Is there a clearly defined, guaranteed-to-work way to reduce scope mid-development? No. But can you learn a series of best practices through your experiences? Absolutely.

I was the lead producer on SeaFeud, an underwater arcade racing game built in Unreal Engine 5 (UE5) by a team of 48 graduate students at the Southern Methodist University (SMU) Guildhall. The base-level undertakings alone were daunting. Would novel Unreal features like Lumen and Nanite support split-screen? Could we successfully pull off an underwater aesthetic? Would our game perform on a wide array of computers and graphics cards? All these questions were pivotal to making the game and sometimes, answering them took longer than we hoped. It wasn’t long into the process that we realized if we wanted to ship SeaFeud and respect its core pillars and competency, we’d have to identify and reduce superfluous feature scope.

The creative vision was defined by a very talented and imaginative game designer. He had bold ideas for mechanics and track designs. As his lead producer, I wanted to do all within my power to bring this creativity to fruition. Unfortunately, there are only so many allotted hours in a workday and we didn’t want to crunch at the expense of team health and enthusiasm. Our leads team reached the difficult conclusion that certain things would have to go.

Figure 1: SeaFeud Promotional Banner (SMU Guildhall)

When and how to decide to cut a feature

For SeaFeud, we used two methods to decide upon scope reduction: a “Structured Go/No-Go” process and “Calling it as it is.”

Method #1: Structured Go/No-Go Process

In a near-perfect world, a structured Go/No-Go process is a great way to mitigate risks and prepare the team for potential scope reduction. The lead or senior producer gathers a meeting of the departmental leads and producers and creates a calendar to prove the plausibility of a threatened mechanic, game system, or asset. From this timeline comes a set of defined conditions that must be satisfied (CoS). If all the CoS aren’t met by the end of the allotted time, that feature is removed from the game. The nature of these conditions can vary depending on production milestone and feature complexity. You don’t necessarily need to demonstrate full integration of a feature. Sometimes all you need is quantifiable proof that said feature works and that the team has the demonstratable velocity to get it in the final product without sacrificing overall quality.

In the case of SeaFeud, we gave our team a maximum of five days on Go/No-Go decisions. And most of them were timeboxed under nine work hours per strike team member. These dedicated mini sprints functioned well in honing concentration and reaching informed outcomes fast.

For my team, regardless of what was being scoped, one of two things would occur: the investigative strike team would either rally around a feature to meet the CoS or they would continue with other work, effectively making a preemptive decision to feature cut. In the case of the latter, by the time a scope reduction was officially announced, the team had already come to terms with it and moved on. Of the six major Go/No-Go decisions we had during production, the majority went the way I expected. But a producer should never get cocky and assume the role of “I told you so.” The team surprised me on more than one occasion and did the work necessary to keep a feature I had otherwise assumed would be cut. What’s key is giving the team the agency to defend those decisions.

Figure 2: Scuba Cat Character Concept by Yog Sun (SMU Guildhall)

Go/No-Go Example: Removing the Cat People

In the original SeaFeud design, the racing characters were a society of cat people that lived in sunken environments. One of our artists delivered beautiful concepts that the team and our game designer fell in love with. As we progressed from POCG to First Playable, however, the team was never able to firmly explain how or why this cat society functioned underwater. This became one of our first Go/No-Go decisions. In so many words, we told the artists “You have two days left to get this cat aesthetic working, otherwise, we’re changing the characters.” They ultimately failed to meet the set conditions of satisfaction and thus the cats were cut.

Our lead artist and art producer led the meeting with the art team to share the reasons for the decision. I chose to miss that discussion and focused my attention on supporting the game designer. He had loved those cats and felt that reducing their presence removed a core character element from the game. As his producer, I had to remind him of the Go/No-Go conditions we had agreed upon and that we had to respect the system in place. I made sure to acknowledge that his feelings were valid and that he could take the time he needed to process them.

It's interesting to note why the artists failed to meet the CoS. Even when allowed to fend for the cat people, most of them spent their time building more ambiguous and universal art assets that worked regardless of player character species. By the time they were told the decision, most of them had moved on and were invigorated by the larger challenges required for completing and shipping the game.

Method #2: “Calling it as it is”

As nice as a structured Go/No-Go process can be, there are ultimately those times when a producer must call for scope reduction with limited notice. A feature or mechanic may be so far behind or team member buy-in so low that setting aside time in the calendar and scheduling Go/No-Go meetings may cause more harm than benefit to development. It’s not the cleanest way to reduce scope, but it is certainly efficient. For me, this happened relatively late in our production cycle.

Figure 3: Coral Canyon track in UE5 Editor (Screenshot by Austyn Wiles)

Calling it as it is” Example: Cutting Coral Canyon

SeaFeud was originally planned to have four tracks, each designed and implemented by a sub-team of four or five level designers. While this created a strong sense of ownership among the sub-teams, coordination across them was sporadic, especially in the early milestones. The artistic themes of these tracks were therefore varied and required numerous unique assets. Our lead artist came to me one day and said, “Reed, we simply don’t have the artist pool or time to create all the assets the level designers are asking for.” It was clear that if we wanted consistent quality, one of the tracks had to go.

“Coral Canyon” was a terrifically clever and ambitious racetrack. It attempted to exploit unique gameplay features and had creative use of verticality and 90-degree inclines. Because of this, however, it required added work from the software developers and often fell half a milestone behind compared to the other tracks. In a collective dialogue with the game designer, the lead level designer, and the level design producer, we decided to disband the track team and remove it from the game. It was not an easy decision, but by freeing their demands from the Asset Request sheet, they allowed the artists to focus on three tracks instead of four. This resulted in the remaining three tracks having fleshed-out, beautiful aquatic environments.

When we committed to the scope reduction, I pulled the four level designers who had spent the previous six weeks working on it from the room. A subgroup of the leads and I presented them with a variety of options and put the “next steps” in their court. They could either (a) stay together as a team and try to build a fourth track that was a reverse of one of the other three, (b) stay together as a team and work within an existing art zoo using assets that already exist, or (c) disband and reallocate their talents to other sub-teams.

When faced with their choices, the team was relieved. They were experiencing a lot of their own struggles and felt their track was behind when compared to the others. They settled for the third option. Three of the four were assigned to other tracks and the fourth joined the audio team. Though they were sad to see their baby go, the level designers were happy with where they landed and were alleviated for the remainder of development.

Conclusion

In conclusion, I’m beyond proud of what we accomplished on SeaFeud. A lot of cool features, characters, and environments did not make it into the final game. But what we did ship was a complete and fun user-tested package. Sacrifices to the game’s width allowed us to better exploit its depth, without overworking those who made it. I know that my next project won’t be perfect. And that we will likely have to reduce its scope at one point or another. But when we do, I am more confident in my abilities as a producer to shepherd the team and the project through.