Bodybuilders Post-Mortem

After the showcase, the team discussed both the showcase and the project. The following topics were agreed upon in a group meeting by those involved or affected.

What Went Well

During the showcase, our questions ensured that we received valuable data on both the upsides and downsides of the game, and the playstyles that players enjoyed. However, our questions were vague enough, (i.e. “What was the highlight?”) that our playtesters didn’t feel boxed-in and had the potential to offer insight further than what narrow questions would be able to explore. This combined with monitoring the gameplay allowed us to adapt the difficulty of some levels through means such as platform distance, and add some quality-of-life improvements (such as preventing players from jumping on passthrough platforms if they move upwards through them fast enough, as jumping results in them losing potential height). The contingency of a second build was a large factor in the night’s success for three primary reasons. The first was that it narrowed the scope of the game into a more digestible set of powers that had been well-received in previous playtests. The second was that having two builds would allow us to trial each and experiment with different aspects of the gameplay. The third, which ended up being very important, was that it minimised the impact of bugs caused by late feature implementation. Throughout running the stall, we were very transparent with those who were interested about the development process, discussing some design choices and the game’s direction with those who were interested, retaining enough interest to keep them around until they got a turn to playtest as well. Throughout the semester, we found that pursuing experimentation and expansion of new ideas and features to be useful to the success of the game. The augments we devised at the start of the semester, a mid-semester tangent with lasers and networks, and improvements made to serendipitous additions such as the scaler augment allowed for Bodybuilders to feature several unique and exciting features. Making a broad range of levels, in the forms of both a proof of concept, and a more concise build allowed for us to test each mechanic in context, and the menu infrastructure made it easy to manage all of this.

What Went Wrong

Most of our problems stemmed from the late addition of new assets. Because many art assets were added later in development, and some of them such as the animations needed to be integrated with important and complex scripts, we were unable to check for bugs before the showcase. This was, however, offset using a second build that only utilised about half of the features, limiting the potential for failure in this regard. The stall we had was in the far back corner, and while we still had many playtesters, we were less noticeable than games on the front side of the stalls. This potentially could have been mitigated if we got there earlier. However, many bugs were found in the last few hours before the presentation, so fixing these took priority over taking a spot. More decorations and marketing materials could have been used. An artistic, informational page and team descriptor could have made the game more approachable, while business cards and T-Shirts could have helped with visibility. While Raviv was sent to recruit more players, many of them were elderly and not in the age demographic of teens to 30s that we were aiming for. Having some kind of merch or pamphlets could have also helped with roaming player recruitment. Throughout the semester, project work was not without its problems. There was no overarching schedule to the semester, and while impromptu meetings were held by some of the development leads with others, people who didn’t take notes would often forget to work on things. There was also very little that could be done if a teammate wasn’t fulfilling their quota. Due to many GitHub clashing issues that crippled the project, we enforced a rule where we would not work on one another’s assets. This, unfortunately, meant that you could only ask people to do the work. The only way of knowing if it would be in by the next week would be if they were keeping people up to date on Discord or Trello, or actively posting assets on GitHub. The development methods also could have been improved. Animation tests at an earlier stage may have resulted in a more optimised approach compared to the one that was used in the end. Communication and a lack of 2D scripting knowledge and research during the creation of the enemies also resulted in bugs until very late stages of development. Precision and transparency about where things were going wrong could have quickly solved some of these issues. The initial level set was primarily there as a proof of concept, displaying all the mechanics in the game. However, this would overload the player and leave the parts feeling contrived, as many were needed and then never used again. Ideally, we should have narrowed the scope much earlier than we did to create a more cohesive and digestible experience that could have had some testing before the showcase, though in this case, the late switch fortunately worked. In terms of artwork, we ended up using a much simpler style than the overgrown underground storm drains, subways and facilities that we had initially planned for. This was largely due to a lack of early experimentation and modularisation of art assets, meaning that many assets had to be rushed towards the end by different artists, leaving some noticeable transitions in visual style and a deviation from the original goal. The late asset generation also resulted in a huge crunch period for both the artists and those implementing the features and could have been averted if team members were more proactive with the tasks outlined in the weekly meetings.

What Would We Do Differently?

For future showcases, communicating with event managers or being the first in to secure one of the best positions will probably assist in creating more player traffic. Shirts and more promotional materials such as business cards, or maybe even themed keychains or other long-life themed items could help keep playtesters and viewers interested. During the development period, testing for research of potential methodologies, and testing of implemented assets was lacking, causing both problems in the development pipeline, and surprise backlog. In the future, creating a mock-up level and creating various iterations of art styles, with the use of modular art assets would allow for us to quickly lock down an art style and then advance with it more easily from an early stage. More extensive bug testing and reports would have also saved a great deal of time throughout the debugging process. Researching and testing methods of implementing animation, the render pipeline, and scripting for 2D enemies would have also saved plenty of time for artists and implementers. For sound implementation, FMOD should have been used instead of Wwise, as while Wwise has more features, it has a limit on the number of usable sounds unless you have a license, which prevented many sound effects and musical elements from being used. Production could have been scheduled beforehand, with an idea of how much progress should be occurring each week, meaning that work would be more focussed, and people will be held more accountable to the tasks laid out for them. Communication should have also happened more frequently, but in smaller groups of only those required. This “Cabal” methodology would cut down time wasted for those unaffected by an idea or change, while ensuring that those affected are all on the same page. If a team member was being unreliable and had taken a job vital to the project, but was providing no updates or signs of progress, it would have also been advisable for someone with time to step in and ensure that the job was done. Developing and polishing a smaller number of assets would have been much easier and saved a lot of time. However, it allowed us to explore many mechanics and get feedback on them. We should have narrowed the scope on the favoured ones earlier though to save production time in the lead up to the showcase. Overall, Bodybuilders felt like a very successful experience during the showcase, but the process taken to get to that stage could have been smoother.