What Went Well:

• In preproduction, we made defining our team's goals and culture statement a top priority. I emphasized to our leads the importance of defending the team's desires and protecting a game's vision, which I displayed in both dev rooms. With our diverse group of 22 developers from around the world, it was vital that our game reflected the team's multicultural heritage and desires. ​

• The transition from prototyping to full production went smoothly. Our backlog and delivery schedule was well estimated by tracking key initial velocities. As co-producer, I addressed initial frustrations with one-on-one meetings, defending our deliberate approach while respecting and adapting to developers' concerns. 

• From start to finish, conflict resolution was swift and respectful. Our studio fostered a safe environment for team members to voice concerns openly. We adjusted our open-door policy to address negative feelings promptly and implemented strategies to manage conflicts beyond our immediate control.

• Our sub-teams did an impressive job responding to expert feedback from stakeholders and our industry partners. Producers and leads distilled observations into actionable developer tasks, leading to iterative refinement and higher-quality combat and animations in the game.

• As we made the transition from Beta to RTM, I made the decision to migrate our task tracking off the product backlog in Jira and into two living systems: a detailed bug Kanban board in Jira and a high level priorities Kanban board on Monday. The former helped capture and assign the wide breadth of key bugs. The later helped display major progress points to our stakeholders and the entire team through digestible visuals and brief summaries. 

​

What Went Wrong:

• In later milestones, we continued to focus on design improvements over quality of life improvements. Last-minute game system changes were approved, diverting focus from internal QA, leaving many significant bugs undiscovered until late stages. This led to a more stressful environment toward the end of the project.

• We only used a formal Go/No-Go framework once in development, never appropriately using that process again. This would have been beneficial on many occasions for making feature cuts and justifying scope reduction. As production neared the final two milestones, we relied less on actionable data and more on gut feelings, impacting decision-making processes.

• We did not have enough eyes on our final boss dragon encounter. The dedicated multidisciplinary team performed well within their constraints, however putting more expert playtesters on the final level may have helped with polish and direction. While I don't regret prioritizing the first 5-10 minutes of gameplay, a holistic approach could have significantly improved the final product's quality.

• We did not promote a culture of performance-mindful design. Given the strong emphasis on lights and shadows in our gameplay and the use of dramatic, realistic foliage in our art style, all our levels suffered from immense performance drain. Collaboration between the performance engineer and designers was limited in the early stages.

​

​Even Better If:

• We took steps to identify and address our knowledge and talent gaps. We rarely framed the question "Do we have someone who can do this task well?" Ultimately, many devs had to halt progress late in production to learn something new. Front-loading learning outcomes saves time down the road. 

• We held weekly meetings between the performance team and the world team to avoid and capture simple FPS drains. 

• We had an in-depth list of console commands that could help with rapid systems testing including noclip (let the player fly through walls), god mode (ensure the player cannot die), an AI "kill all" command, and a jump-to-quest command. Though some of these (e.g., a level loader) were eventually added, an earlier implementation would have helped with faster iterative design and testing. 

• We held regular and structured co-producer meetings. Even though both producers participated in daily scrums with the other leads, we could have done a better job had we set aside a time and space for a thorough conversation. This would have ensured we were always on the game page. 

• We removed department leads from the critical development path.  Features would be delayed as the deliverable was tied to a lead rather than a sub-team developer. Though our leads are talented in their own right, their focus was often distracted. I will strive to better alleviate lead overload in future projects.