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.
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.
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.
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.
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.
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.
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.
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.
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.