SuperCrush Post Mortem

By Matt Worrell

SuperCrush is a 2-D twitch platformer built it the Unity 2D engine. The game has momentum based speed and wall jumping. The story is about a schoolboy who imagines himself as his favorite comic book superhero, the Crimson Knight, to free his crush from the bully, imagined as the Crimson Knight’s arch-nemesis, Doctor Shocker. 

What Went Right

Played to the team’s strengths

Early in pre-production, the team decided to develop SuperCrush around the strengths of the team. We assigned our most experienced team members with larger roles and ensured each department was capable of their portion of the game’s vision. This proved to be a vital decision as we learned soon into development, working on a team is challenging and if we had chosen to a more challenging vision the game would have suffered greatly. 

Personal Talks

At the start of production, the team did not mix well. Team members were frustrated with each other and were not communicating their issues. Therefore, the team decided to host individual talks bi-weekly. These talks led to venting and mentoring from the lead, which helped team members relieve stress. Team members also had the chance to see issues from other team member’s perspective, which improved team camaraderie and respect. 

Scope

The majority of the team had not worked on a game before, no one had worked in Unity, and no one had worked on a team game. Therefore, we knew learning would take a lot of our development time. With that time sink, we designed a game the team was confident and comfortable with making and cut a lot of the original story. Because of this SuperCrush was scoped well and always ahead of schedule, many wish list items made their way into the game. 

What Went Wrong

Lack of Central Authority

While SuperCrush did have a lead and a game designer, without a higher authority figure to critique work, the team viewed peer criticism as suggestive rather than constructive. Assets needing to be changed were not because no team member had the assigned power to tell others their work was not to the quality of or did not fit with the rest of the game. With a central authority giving constructive criticism instead of peers, team members would have been more active towards change.

Little Iteration 

Throughout production, team members were resistant to show work before it was fully completed. This led to the creation of assets that did not coincide with the game’s vision. Earlier unfinished iterations of assets would have led to levels, art assets, and technical designs that better fit together toward a more unified vision. 

Resistance to Cutting

Due to few iterations of assets, team members attached themselves to their work to the point where they would change or cut their assets. Early, less polished, iterations that team members could critique and change, would have ensured asset’s final forms fit with game. However, some assets fit with early versions of the game, but did not change with the game. Therefore, cutting those assets that were not fitting, instead of desperately trying to make them fit, would have saved time and improved quality. 

What we learned

Gameplay is Everything

We worked in tandem with two other teams and were the first of the three to understand our gameplay. Because of this, we were able to polish our gameplay elements and find the fun of SuperCrush. This discovery led to assets changing to center around the understood gameplay. The extra time created from understanding gameplay early, let us we had time to implement wishlist items late in development like the grading system and speed geared levels, which was largest part of the game’s success. 

Playtest are Paramount

The team learned late that playtest are very important to design. Playtest showed the team that levels and assets that had made sense and felt correct to the team did not translate as imagined. This led to alterations in color, level designs, player speed, and a wide assortment of adjustments the team did not foresee having to address. Overall, the playtest improved the game’s quality tenfold and while the team was confident in the amount of playtest conducted, the quality gained from each called for even more. 

Design is a Process

Game development is an iterative process. This is something the team learned through development. The team consisted of new peers starting a long venture into graduate school together. This first chance to showcase their talent led to team members withholding assets until they were to the quality of impressing their new peers. While the assets were well done, they did not fit with the vision. Team members realized this and starting showing their work earlier and built their work with the team. 

Conclusion

SuperCrush was a success for the team because we accounted for unknown time sinks, like learning to work in a team, and cut bits of the game accordingly. Prioritizing gameplay first allowed us develop to around it and avoid rework. Playtest showed the team that communication to the player is not black and white and developers should playtest early to avoid having to change items late. We also learned that game design is a process and things will always change. Therefore, we need to account for that change and iterate often. SuperCrush was a success winning the classes’ best overall game, but could have easily failed if the team had not scoped the game and adjusted to the ever changing environment in game development.