Bernard Hwang

Level Designer

HookShot

Post-Mortem: HookShot

Post-MortemBernard HwangComment

HookShot is a top down racing game that lets players drive sci-fi cars that use powerful grappling cannons to sling around obstacle filled circuits. This project was my second freshman game created at Digipen and my first time as team artist.

3 Things that went Right

  1. Scientific Research
    Hookshot was the first project I worked on that built off of real-world sports. Before and during pre-production I made it a personal goal to try and learn and become involved in motorsports for the benefit of the project. Learning the shared nuances of racing helped give a stable vision that aided the game’s design.
  2. Lengthy Pre-Production
    HookShot is currently the team project that I spent the most time developing. As Acting Producer for the first few weeks of the project, I tried to learn from the mistakes made on my past project and set aside a large amount of time for pre-production. This assured the team would move into development with a solid design above all else, leaving nothing left to be haphazardly created in the final days of the project.   
  3. A Lot of Testing
    The team made it a habit to conduct playtests twice a week. Constantly seeking out outside perspectives, helped keep the project motivated to design. The influx of opinions gave the design team much to work with for the duration of the project. The back-to-back playtests allowed game components to have their own compartmentalized test.

3 Things that went Wrong

  1. Mixed Development Models
    The project went through many drastic changes throughout production. From engine changes, role swaps and design overhauls, there were many points in the project’s timeline that the project was in precarious position. A major change was the project’s unplanned transition from a waterfall to an agile model in the middle of production. Trying to incorporate frequent iterations without originally planning for them led to project conflicts and lack of team unity.   
  2. Poor Pipeline for Playtest Feedback
    The team did a great deal of playtesting, but the decision to do so was made weeks after pre-production. The project lacked a pipeline to efficiently set up playtests and take in information from the playtests. The team needed to designate specific goals for every playtest. The team came into the habit of playtesting merely for the sake of playtesting; the idea to conduct weekly playtests was a good one, unfortunately there was no forethought or planning before acting upon the idea.
  3. Crisis of Leadership
    The team lacked a definite leader from the start of development. Roles were assigned to each team member, but the responsibility of each position did not feel concrete. There was no clear understanding of which member did what, and in this confusion members would often overstep their bounds. When asked who led the team after the game had gone gold, the team did not have one clear response. The team needed to assign a project leader who could maintain consistency in team member’s responsibilities.

Outcome

Working on HookShot has taught me a few things.

  1. Gaining use out of user playtests requires careful planning
  2. Agile development favors small teams and ALSO inexperienced teams
  3. Team confidence is important to keep up