This is a postmortem for a Guildhall student game called Lost in the Dark. Lost in the Dark is a horror exploration game designed in the Unreal Engine. It was developed by a team of 17 over the course of six months.
Lost in the Dark is a third-person exploration horror game for PC designed using the Unreal Engine. It was developed by a team of 17 students at SMU Guildhall over the course of six months. The team was split across art, level design, programming, and production. I held the role of producer on this project and worked closely with a team of leads consisting of a game designer, lead programmer, lead artist, and lead level designer. The following information was collected from the team's 360 postmortem at the Guildhall.
Candid communication developed towards the end of project
Designed a game in a genre we had little knowledge/experience in
Physical prototypes (ran a haunted house to test mechanics)
Team prototyped and iterated rapidly
Team unity, when things broke we stayed together and fixed them
Leads listened to their developers
Giving credit away to people that earned it (two claps)
Team was fun and hopeful even during period with low faith in game
Open and honest about mood in the room
Used each other’s skills to ease burdens across the team
Takeaway:
Very early in development there was another Guildhall team that was having an excellent start to the development of their game. This affected the morale in our room as we felt like we were losing a race. I held several talks with the whole team as a group where we committed to focusing on our own path, and not letting outside stressors interrupt our process. We put together a culture statement and worked towards meeting those standards for our team. When the team confidence in the game was low, the morale in the room remained high. For example, right before a milestone we had a game-breaking bug rear its ugly head. The team agreed to stay late to fix the bug and stuck together through a tough time. The biggest take-away was the ability of this team to respond to challenges by sticking together and placing the team first.
We were tempted to try every possible gameplay to fit our design
Needed to be more decisive with gameplay decisions
Candid communication could still improve
Could have been more honest early in the project
Stumbled on design in the beginning-middle of the project
Punctuality: people showed up late often
Could have been more prepared in scrum meetings
Team did not follow pipelines when the pressure was on
It was unclear whose role was responsible for designing the gameplay
Takeaway:
Lost in the Dark struggled with design for much of the development process. Our team had a very good idea of the high-level concept of the game but was unable to discern the gameplay that would fit that high level. It took many sprints of us generating numerous prototypes before we decided on a finalized direction for gameplay. We were unsure of the core loops we wanted in our game and were tempted to try out so many types of gameplay before deciding. In retrospect, having a more defined direction for the game constructed in preproduction would have set us out on a much better course. Instead, we spent so much time treading water that we were unable to capitalize on the high-level idea that had motivated us from the beginning.
Replacing activities like ill-received show-and-tells by giving credit away in different ways
Candid communication is everything
Good team culture and identity can make up for a lot of bad things on a project
Game needs to be nailed down early so we can start making the actual game ASAP
Cross-discipline communication needs to happen early and often
Micromanaging is bad
Keep doing your best despite the odds
Team pow-wows can be useful to discuss large problems and clear the air
Takeaway:
Emphasizing the team first helped get us through many pitfalls in the development of Lost in the Dark. From the beginning I stressed the importance of team culture, team norms, and team identity. Not everything stuck in the beginning, but over time we worked on holding one another accountable, being honest about someone’s work, and giving credit away when possible. Because our team culture and identity was strong, we were unphased when things started to derail. For example, towards alpha the character of our team became apparent when we had several demands from our stakeholders that went against our design. Though we were unhappy at the time about the changes, we worked hard to implement the changes as quickly as possible and iterate. The changes solved several conveyance problems we were having and ended up being a positive change in our game. The strength of the team to not fall apart when issues arose was due to the focus we placed on the importance of team throughout development and enhanced our ability to work through adversity.
Read more about:
BlogsYou May Also Like
