Mirrored Phantoms
Co-Producer | 22-person team | 5 month dev-cycle
In Game Screenshots
Game Trailer
Streamer Review
I was working with the Game designer Tianxing Jiang on the future development plan.
Mirrored Phantoms（幻镜诡影） is a first person horror game that was developed by a 22 people team in SMU Guildhall. I was the producer on this project.
We encountered many challenges during development. Early on, not everyone was on board with a horror game, so we experimented with different approaches—debating between a single monster or multiple monsters, and whether to focus on survival horror with resource management or a chase-and-run exploration style. With limited time, we had to manage the project's scope based on available resources and skills.
One technique to secure buy-in was our weekly show-and-tell. Every Friday, we shared our progress, motivating the team and showing our appreciation for their work.
After finalizing the art background, we created a mod kit for level designers that included walls, windows, stairs, doors, columns, beams, and other basic elements. Next, we developed indoor art assets—vents, pipes, valves, and iron fences—that replicate real factory objects. We tested these pieces in a ScaleTest level to ensure they fit together like Lego, giving our designers effective tools for building indoor environments. This approach saved us significant work and prevented many scale issues.
For SDs, we applied the same tool-building mindset. For instance, we produced documentation explaining how to use door checkboxes to keep them open or close them suddenly after a set time, how to configure enemy settings like teleportation points or patrol paths, and how to set up object physics so that enemies can hear certain sounds.
Due to limited resources and early focus on basic systems, software developers were too busy while level designers had spare capacity. Some level designers volunteered to create simple blueprint functions—like light switches and conveyor belt switches. Although well-intentioned, this led to issues. After the first playable, we discovered that the blueprints lacked a consistent structure and were scattered throughout the project. We then restricted blueprint work to one technically skilled level designer, expecting her to complete functions and facilitate communication between level designers and developers.
After the Vertical Slice milestone, programmers complained about her poor code quality and the extra work her functions created. Her work, especially on sound effects, was buggy and deeply integrated into core functions, making revisions very difficult. We had planned these functions as placeholders to be replaced later by developers, but as more features and sound effects were added, reworking became a major challenge that cost extra time.
In hindsight, we should have planned better. Early technical blueprint work was acceptable for testing, but needed prompt rework by developers. We should have involved developers earlier rather than waiting until vertical slice or alpha. Additionally, the technical level designer was not proactive in communicating between teams, delaying problem detection until developers raised their concerns. When tensions escalated, I organized a meeting where everyone could discuss the issues calmly. Once she joined the conversation, the team worked together to fix the problems. This experience taught us that poor communication can amplify small issues, and it’s crucial for a producer to identify and resolve such issues early.