Beer Hunter Post Mortem

This post aims to respond to a number of questions at part of a reflective post mortem for my previous studio unit project. In a team consisting of four members including myself among peers, we were briefed with the task of creating a prototype adhering to the rule that “no one gets hurt”. This allowed us almost total creative freedom, providing that it was 3D from a third person perspective and that there were no fatalities or injuries involved with any character or living entity including the player.

The idea that we settled on as specified in our design document is to “compete with another player in a race to get wasted, find the last beers before they do, all while avoiding anyone or anything that could slow you down. The first one to pass out wins”. The game is played as a split-screen versus with beers located within highlighted fridges during a party inside a populated frat house. The introduction of a pee mechanic is also integrated using toilets spread throughout the level.

Two significant events occurred that I feel were important with relevance to me, the first being our pitch to the animators. After we had settled on the direction of our project and had a completed high concept document, it was required of us to pitch our idea in an attempt to recruit artistic members into our team. Interestingly enough, we were met with very positive responses from most of the animators despite our presentation lacking in visual aid and delivery preparation.

I am convinced that our pitch was a success given the amount of interest we had from those wishing to work with us. I personally believe that in this case however, it was only our idea that held us. While we certainly had more than enough material to present, I believe that more time spent organising that information and sorting the important details from those considered minor would have been exceptionally beneficial had we been pitching a different game.

The second significant even has to do with my mindset regarding prototype quality code, I found myself working at a much slower pace than what was required in the beginning of the project. The reason for this was my tendency to start writing not production quality code, but code that was still adaptable and modular enough to be considered overkill during a prototyping stage. Although it never took me long to adapt to writing “hard code” that gets the job done quickly, it feels illogical.

A majority of the assets added by myself were script and audio related. The first and most major contribution of mine was the third person camera, an extension of a first person camera script created for a previous project of mine. The script allows the player to simultaneously look around using the mouse or a controller and independently control the horizontal and vertical sensitivity, rotational extents and axis direction in first or third person mode.

Other contributions of mine include assisting in scripting the UI, input manager, fridge and toilet with our other programmer among  performing various tweaks and bug fixes throughout the codebase. I later made changes to the in-game instructions and provided some basic ambient audio and sound effects. The ambience heard while playing the game was made by taking the chorus of a song, adding reverb and enhancing the bass line. I then layered ambient chatter over the track and turned it into a seamless loop using Audacity.

I felt as though our production style was quite sufficient as each team member knew what their roles were and when to ideally have them completed by. We were openly flexible with the swapping of roles and having the same task be completed multiple peers. Some more time spent on documentation would have proven advantageous as we did encounter times where production was halted from not having the answer to a particular gameplay mechanic related question.

Our software stack comprised of Unity 3D, git and Google Drive. I personally found this combination very effective, particularly the use of git with our Unity project as it complimented our production style well. There were never issues when merging project builds and as such we were independently able to perform each task at our own pace without any noticeable conflicts. The same can be said for our documentation, Google Docs excels in this area for the same reasons.

I was absent during the play testing session, however there were a few things I observed after watching over the video recordings of the session and evaluating the feedback left from each user. Almost all users reported their confusion when initially playing the game, some having no idea how to play at all. The flaw highlighted was that regardless of the fact that this was a prototype, we underestimated the requirement of having clear goals, guidelines and instructions in place for new players.

The next observation I made relates to the NPC’s attempting to slow you down by obstructing your path. Despite this being a core mechanic, many users found that it hindered their gameplay experience in excessive quantities when racing against their opponent. Interestingly enough, I found many similarities across all of the responses demonstrating just how essential the play testing process is for bringing obvious flaws to attention, which would otherwise go unnoticed by the developers.