Producer | 22-Person Team | 6 Months of Development

Mirrored Phantoms is a first-person psychological horror experience set in a decaying mannequin factory. Players must try to survive a monster and navigate through the halls to find the pieces of the magic mirror that sent them to this twisted reality.

Game Trailer:

Postmortem

Mirrored Phantoms was a unique experience working with only one other producer for the entire team. As it was my second project ever, I still made my share of mistakes but learned some important lessons too:

Lesson 1: It is Easy to Overcorrect

When transitioning to Mirrored Phantoms, I wanted to ensure that the team felt empowered. To better align with Agile principles, I aimed to let the team self-organize. Early on, the lead team discussed what people wanted to work on and then created tasks to match. Instead of assigning tasks to specific teams, we left tasks unassigned with the idea that team members would choose their own. Unfortunately, this approach didn’t work as planned—some programmers repeatedly reported having no tasks, despite prompts to check the sprint backlog.

During my first project, I was eager to take charge, quickly assigning programmers to teams and giving each several tasks to work on. I set up a Monday.com board and used it as the primary tool for task management, constantly monitoring progress and creating new tasks when needed with input from the lead. However, the team often felt overwhelmed and pressured, as many decisions were made rapidly before we had time to properly align as a group.

In my effort to give the team freedom, I overcorrected by stepping back too much. I learned that it's crucial to strike a balance. Different team members thrive under different conditions—some prefer clear direction, while others enjoy selecting their challenges. Understanding your team and tailoring your approach accordingly is key to effective project management.

Lesson 2: Early, Clear Definitions of Roles are VITAL

A lot of the curriculum at Guildhall is based on people falling solidly into one of four disciplines: level designers, artists, programmers, and producers. For this project, there were a lot of level-based features that needed to be programmed, and our early solution was to have a level designer be the "technical designer" with the overall goal of programming some designer things. That was, unfortunately, as solidly as we clarified that. One of my biggest regrets is not doing more research about what a technical designer should do and clearly defining what this role is supposed to be doing.

This became an issue around our third milestone when we had someone with little programming experience programming things. This led to a lot of bugs that began to affect a considerable amount of the programmers, as the game began to have trouble compiling and building. After an emergency team leads meeting, we got together and talked about

Lesson 3: Managing Team Expectations

A key takeaway was the importance of clearly communicating to the team early on that many features would likely be cut as the project evolved. By setting this expectation from the start, the team could better understand that iterations and changes are part of the process, reducing frustration later. Ensuring transparent communication about potential cuts also helps align everyone with the bigger picture, making transitions smoother when features are reprioritized or dropped.

During the early days of rapid development, one of the most important lessons I learned was how to effectively manage the team's expectations. Over the summer, we held bi-weekly meetings with stakeholders to present our progress and discuss the evolving direction of the game. As the concept shifted significantly, many of the initial features the team worked on were ultimately cut. While these changes improved the overall quality of the game, they were understandably disappointing to those who had put time and effort into those features.

Looking ahead, it's clear that managing expectations not only with stakeholders but also within the team is crucial to minimizing the impact of these decisions. Ensuring that each team member has something in the final game they can point to with pride—a feature they contributed to—helps maintain morale and fosters a sense of ownership. When the team knows their work has a lasting presence in the project, it strengthens their connection to the game and boosts their overall investment in its success.

The Dev Team

Google Sites