Postmortem: Identity

Identity is an over-the-shoulder 3^rd person stealth game, made in Unreal Development Kit. In the dark climax of the information age, individuals have lost the ability to publicly protect their identities and they must take care to safeguard them. Players must use stealth and an identity-stealing ability that allows them to copy the digital identities of others to fool guards and shut down the server primus. A 14 person development team at SMU Guildhall created the game over a six month period. This postmortem outlines the key issues on what went right, what went wrong, and what was learned.

Figure 1: Main Menu Screenshot

What Went Right:

Early Playtesting and Often

Leading up to this project our team had no experience creating a stealth game before. As a group we made it mandatory to play as many stealth games as possible. At times this gave us valuable insight, but it didn’t show us the player experience that we were striving for. At Proof of Concept Tech we started testing Identity on our friends, family, or anyone willing to play.  When we watched people test we could see the answers right in front of us. The early playtesting allowed our team to solve a wide variety of issues. Testing gave us a reality check on gameplay issues and kept us from missing any obvious errors.

Create Your Own Unique Forms of Transparency

We had our normal scrum, sticky notes on the walls with tasks, and product backlogs. As development progressed we felt that scrum wasn’t the most effective way to communicate what we had done or the most fun way. We started doing “Show Us What You Got” which is a rendition of Show and Tell. “Show Us What You Got” was held at the end of every day. It allowed the team to show off on a giant screen what they had been working on. It gave people a sense of pride but more importantly it gave the team a definitive direction on what we were building.

To retain transparency from Lead meetings in a unique and engaging way, the creation of our Open Source Newsletter was born. Having vital information on decisions, calendar dates, and daily recaps in a single document stream lined our transparency across all disciplines. We wanted to have fun in all aspects of the development and themed the newsletter to match our game. Additionally, we positioned meme’s at the end of the newsletter that pertained to that day’s work, which helped people scroll all the way down.

Figure 2: Open Source Newsletter Header

Strong Artistic Unity

Having a unified artistic vision for the game paid off significantly for our team. We had an art team with a great set of skills and a like-minded vision. This allowed the art in our game to really stand on its own. The artistic unity of the Art team prevented them from having to rework a lot of assets. We were also able to use the art style to give our story line a significant benefit. We were soon able to answer what it would be like to really live in this environment.

Figure 3: Vertical Slice Room, CEO Office

What went wrong

The 3^rd vs 1^st Person Debate

As students we were developing our project under certain constraints. We had planned our entire game out for 3^rd person to fulfill one of these constraints. Towards the end of our planning we were told we could make our game 1^st person if we wanted. We debated 3^rd vs 1^st person for two days, the equivalent to a week’s worth of development time. Since we had planned the game out for 3^rd person we ultimately decided to stay with it. This proved to be extremely difficult given the amount of animations that were required and low familiarity of the process.

Choices in Early Stage Development are Critical

In early development we had discussed implementing a cover system. The intent of the system would have the player feel like they were interacting with the environment and feel more “stealthy”. Similar to the 3^rd vs 1^st person debate we spent some serious time discussing this issue. We just didn’t know what the extant of a cover system would take to create. This was a costly mistake to the player experience that we wanted to create. We had players tell us that they just felt like they were walking down a hallway and there was no tension to it. We were unable to pivot our development fast enough to address this issue, and tried different methods other than a cover system to remedy it. We feel that the overall project could have really benefited from a true cover system.

Figure 4: Player with Stolen Identity

Never Underestimate Review Time

We had set our sights big on this project. This project was the culmination of our time at Guildhall. Having our review time planned out with when, how long, and by which discipline we thought we were good to go. The review and polish time that was really required between our Level Designers and Artists was significantly longer than originally anticipated. We were able to fix the issue with more review planning but it cost us in early milestones with crunch time. The silver lining in this situation was the implementation of a system based on round robin Art and LD reviewing.

What We Learned

What You Intend Isn’t always Conveyed

We made a team design moto of; if it isn’t conveyed to the player then it doesn’t exist. With our early testing we immediately began to realize what players understood versus what our intentions were. We created this moto for our team and stuck by it during the rest of development. It allowed us to think critically and constructively about the issues we were trying to solve.

Planned Specialization Can be a Gift and a Curse

During development we identified critical paths and selected people to fill those key roles. For instance, we had a programmer become extremely familiar with animation implementation. This allowed for much faster implementation of various features. However, this is a double edge sword and we recognized this fact. The great Coke-a-Cola spill of 2014 showed our greatest fears come to life. We were able to recover within a day but the incident only exemplified the fragility of the system.

Figure 5: Animation Draft, Created by Christina Rhoades and Ricardo Orellana

Integrate Review Systems Proactively

Wanting to create something that was better than anything we had done before kept us extremely busy. Our team created a plan for how much time we wanted to have for reviews versus how much time we actually had. In hindsight, we realized that the round robin review system should have been implemented much sooner than it did. It would have prevented crunch time and stress when close to our major milestones delivery dates. We learned that the sooner you can implement a process the better.