Last semester I had the pleasure of working with an extremely talented team on what I consider to be the best game I’ve ever made, Showstopper. It’s been a while since I updated about the game, but if you’d like to see the game in its finished state, you can go here to the project page. The following will be a postmortem on this project as a whole.

The development of Showstopper, at its core, was a lesson in justification and experimentation. A lot of game development could very easily be boiled down to those lessons, but I think they are particularly apt when discussing this project. Our team knew from week one that what we had was special and had value to many players; the rest of the semester was spent trying to transform that solid base into an architecture worth living in. However, my personal growth with the capstone process is very much tied to the general idea of learning and becoming more capable in all hats that I wore.

My roles on the project were to:

• maintain the vision of the game
• design creative solutions to problems we faced
• guide the team to constant iteration
• program the game to actually work

This means that I had a direct hand in every aspect of the games development, and besides art, I was actively contributing to them all, as well. I helped our artist develop the art style that fit the game best, our programmers figure out what needed to be added and how we should do it, and our producer maintain the team and game’s development. “Guide” is the word that probably fits best with what I actually accomplished on the team, as designing the game and making it play well was mostly done tangentially to that main goal.

Most of this postmortem is about my personal progress as a developer and how the team and process worked as a whole, but I wanted to do a quick postmortem on the game itself. In terms of what went right, I think the game is an extremely fun and unique concept that we pushed to its limits for a 12 week prototype. Week after week, we were improving the feel of the game and getting extremely positive feedback from testers about the entire experience. The crowd favor system and the different play-inspired rules were really fun and creative ways to add depth to what could have been a one-note mechanic.

As for the things that didn’t go so well, I think we were trying hard to prepare for the future of the game and let the current state fail in small areas, which is what our professors alluded to being the reasons the game did not continue forward. A lot of our development was architectural; we wanted there to be a good base so that development was easier later on. This led to us not having as much content in the game as we would have liked, as well as small things like a between-round score count. Many faulted us for choose a game that they saw as animation-heavy so I felt it was worth noting, but our vision of the game didn’t really need animations until the second semester.

Now, back to discussing the capstone experience as a whole. In terms of what went well, I would say that the overall process of the game was impeccable. We were consistently on schedule with our production timeline, and we were always iterating to make sure the game felt theatre-y and cohesive. The game constantly improved, and the team was composed of a slew of experts that were able to lead us to those improvements. At the end of it all, we fully believe we made an entertaining and engaging experience for players. As for the team’s growth, it felt like we used every sprint retrospective wisely and always kept our takeaways in mind. I was really impressed with how the team managed to handle a programmer uninterested in learning Unreal, as we were able to rectify the issue quickly and got everyone on board to the point that we were all happy to have learned the engine.

In terms of areas that weren’t as good, the team boiled it down very well to “we hit goals on time, but they weren’t goals that challenged or inspired everyone.” Tasks would get done, but the team never felt inspired to make more or challenge themselves to push the game forward. The team is soft-spoken and therefore never felt compelled to bring this up with me, but I definitely saw it and could have said something sooner. Developing games in the context of school has run its course for most of the team’s motivation, and I often felt like I was the only one putting my all into the project. Meetings would get cancelled randomly because no one felt like we needed to meet to discuss anything even if we could have just done work together, which created a strange distance to the team. In the future, I think I would like to have meetings that were more consistent and push the team to come together and collaborate.

Instead of further discussing the game, I think it’s important to discuss where I’m at. Showstopper is by far the best game that I’ve made before. The core mechanic of the game, as one of my professors put it, undoes so much of what I know about gaming in interesting ways. It’s a solid mechanic that I feel is well-justified and fleshed out to make a game that feels like it was firing with everything it had. It is a strategic endeavor with two players and a chaotic funfest with four. No matter the fate of the game, I was extremely happy every week at QA seeing people enjoy the game, and I was deeply moved when multiple people messaged me after the game was cut and said they were surprised.

In terms of what I’ve learned, it’s difficult to understate how much of myself I put into this project. On most projects I’ve worked on, I have unintentionally been a Product Owner, designer, and programmer, but this project had me actually performing every aspect of those roles correctly. While burnout started to set in as the semester came to a close, I feel like I have grown in all three roles and I am sure that I enjoy them and am capable in them. I absolutely love the process of designing a game and being part of its implementation, and I also have learned so much about justification for my actions and actual iteration (both of which we don’t necessarily have time to learn in the waterfall-style speed of other production classes).

When we started with Showstopper, all we had was a mechanic that we knew was interesting and open. Justification was something that was key to making this game shine, but also would be the guiding light towards the project’s future, as we were unsure of exactly where to take it. The theatre, in my opinion, was the perfect context for the game as it not only made the mechanic make sense, but it also opened our eyes to so many possibilities that played well into our core design pillars. Making the fights fun to watch meant that players could fight for crowd favor in interesting ways, and the need for variety was met by the endless amounts of plays we could pull from for show objectives. It was absolutely not perfect, but I think it was a creatively-fulfilling experience that I had never really had before.

As for the iteration part, previous production projects didn’t have the time frame to allow for actual iteration, and they require the project to be complete after just a couple weeks with no real time to breathe. So much of Showstopper, from its crowd favor system and platforming to its visual effects, came from constant testing and creative iteration. Our hangup with moving Showstopper past Step 2 was that we didn’t know where the game would end up with all of our ideas, but every week we were able to hone the direction of the game more and more. Being able to get feedback and make changes accordingly was something the school tries to encourage, but doesn’t give much time to do until capstone. I think Showstopper would have suffered, as every previous game does, without the time to grow and improve.

Something less discussed in terms of skill improvement is team skills, but I felt like my role on this team really forced me to grow into the designer I want to be. As the Product Owner, I have to know the vision of the game and stay firm to it. However, I prefer to be a designer that guides the team but is flexible to the wills of the collective. That wishy-washy behavior can’t always work, and my team this semester was certainly not the type to give much feedback on major developments. I saw a lot of growth in this area of myself, because this type of team environment meant I had to be mostly on my own for the game’s trajectory. I wasn’t fully alone, as I took the opportunity to ask professors and other students for help, but my decision making skills were truly pushed. My team relied on me to know what was going on, but also to be able to guide us whenever we hit road blocks. I feel like my leadership skills were constantly put to the test, but I feel more capable than ever because of it.

I don’t at all think I’m the first to develop these skills in the way I did, but it’s important to note what I’m learning as I move forward into the industry next year. There are thousands of talented people making video games out there, and if I’m about the become one of them, it’s important that I have prepared myself adequately. The Capstone process has greatly readied me because it requires me to understand my own thought processes so that I can learn from events, whether they go well or not.

Of all of the skills and lessons I’ve encountered this semester, this is probably the most important one, especially as a game designer. It isn’t about whether you can take a cool idea and make it into a cool game. Learning from small QA feedback, major mechanical changes, or even the cutting of our game is the essential skill of a designer. Every decision I make moving forward is now informed with previous rationale. Understanding that game development is just learning what works is something I desperately needed in order to feel prepared for a future in the industry. No one gets it right on the first time every time.