That’s Not How it Happened
| Dates | Summer 2021 ~ Spring 2022 |
| Role | Lead Designer |
| Team | USC Games (team of approx. 35 members, in-person and remote) |
| Development Software/Tools | Unity |
| Summary |
|
Project and role overview
That’s Not How it Happened is a game that tells the same story using differing character perspectives and gameplay genres. After the family inn burns down, George, Alan, and Zoey each retell their experience, using beat-em-up, visual novel, and click-and-point adventure styles respectively. The director of this thesis project, Meny Menczel, was partly inspired by the multi-perspective narrative of the film Rashomon. I applied to join his project because I had also watched the film and was intrigued by how its structure could be adapted to a game. I had worked exclusively as an engineer on my previous team, Crescendo, so I was looking for a role where I could exercise more creative freedom. Talking with Meny, he found that the role of Lead Designer fit my motivations most.
As Lead Designer, I managed a team of 5 designers to plan the gameplay specifics. I also wrote design documents and communicated asset requirements to the engineering, art, and sound teams. Further, I exchanged feedback with the usability team to iterate on design issues.
Design process
My primary tasks in the first semester of the design process were to determine the mechanics of each gameplay section and create design documents that could be relayed to the other teams.
My main concern was the ambitious scope of the project. The main characters, overall narrative, and gameplay genres were already set in stone by the time I joined. Considering the strict deadlines and the short target playtime of 15~20 minutes, each gameplay segment would need to be succinct and mechanically simple. Communication with engineering would be vital since I knew from my experience on Crescendo that even managing 1 set of mechanics, let alone 3, was challenging.
As a first task, I had each design team member testplay a game from each of the 3 genres. The goal was to compare our experiences and determine the core characteristics of each genre. Because of the limits on scope that we had, I aimed to distill the gameplay styles to their defining components. For example, for the beat-em-up, we discussed games such as Double Dragon and Streets of Rage. We found that the narrative we needed to nail was that of power and confidence. To do so, we needed to make sure to implement juicy elements like hitstop and screenshake, as well as make sure that the player does not get ganged up on and defeated easily. Thus, this first task helped the team get on the same page and identify our guiding goals. I also found that the project helped for teambuilding. My team consisted of 4 undergraduate students, some of which had not worked on a large team before. By having each of them present their gameplay experiences, it served as a self-introduction of their thought processes and eased them into talking with each other. So, despite only taking a couple hours, I found this testplay task to be highly effective.
Another early task was to create a “list of questions” as an outline for design documents. For example, under beat-em-up UI, a question would be “what does the health display look like?” Under that, you ask more detailed questions such as “what shape is the health display?” If a bar, you could have questions such as “does the bar drain from the right or the left?” or “does the bar scale linearly?” These are all questions that would arise if you were the one implementing the health bar. By continuously asking questions, you effectively create a tiered bullet-point list whose answers can be converted into a design document. Said document thus anticipates questions that engineering might have about the implementation, saving time otherwise spent messaging and waiting for the other side to respond.
In the last semester, focus was on finalizing asset requirements, responding to playtest feedback, and polishing for release. At this point, engineering, art, and sound teams were working at full throttle to implement the game. I spent most of the time communicating with the respective leads to be on the same page about the desired assets and to cut where necessary. I also met with the usability team that recruited students and conducted weekly playtests of our current build, and used feedback to iterate on design and balance. The design team conducted our own playtests as well, filing bug reports and fixing them immediately when possible.
The game was completed on-time and presented at USC Game Expo. We also published to itch.io and Steam, with the Steam version gathering 98% positive reviews.
Takeaways
Overall, I believe that the design team accomplished the project’s goals of presenting a multi-perspective narrative through different gameplay genres. I was fortunate to work with a very talented team. I was especially impressed by the engineering group, which not only juggled the various gameplay systems, but went above and beyond to provide design feedback. We were able to complete all assets on time without major cuts or bugs. Gameplay-wise, there are certainly things that could have been improved. In particular, I learned how hard it was to design point-and-click puzzles: they can’t be so hard as to stump the player (especially considering we had strict goals on playtime), but they still need that “eureka” moment that provides satisfaction. In the beat-em-up section, I wish we had at least considered placing a wall of breakable crates instead of an enemy in the first screen, as a tutorial of how to punch. But at the end of the day, I think that we were able to wrap each gameplay genre in a fun package that compliments the main narrative, which was the primary goal.
As the lead designer, this project challenged my communication skills, as I was constantly in touch with my design team and with the other leads. It helped me discover new team ideation techniques such as the testplay presentations and list of questions. Finally, I gained crucial experience working on a large team and creating design documents shared across groups.