Hello, my name is Courtney Wilcox.  I created all of the assets for the Platformer Game and a third of the assets designed for my class group’s representation of Limbo with a Portal 2 sound design.  The purpose of a postmortem, in general, is to take time to look at the overall production, design, and implementation of various game development elements.  The postmortem is an outline of things that went right, went wrong, and how a game development team can make improvements and implement them for future projects.  In my postmortem, I will focus on the specific successes and challenges I encountered during the design stage of my audio assets, the implementation of those assets into both Unreal Engine 4 and Wwise, and a an outline of tools and personal workflow techniques to implement into future projects for continued success and growth.

 

 

Unreal Engine 4 and the Platformer Game

          Aesthetic Confusion: The UE4 Platformer Game presented many creative opportunities as well as many technical challenges.  When beginning the game, I originally wanted to create audio assets that were hyper-realistic to that of a city in shambles.  My aesthetic direction was summed up as city, dirty, ruined, war, and trouble.  I tried to incorporate a lot of concrete, gravel, metal twisting, destroyed sounds.  While I intended to go in this direction with the UE4 Platformer Game, that was not the aesthetic that I ended up with.  Since this was the first video game I had ever worked on, I struggled to keep a clear aesthetic in mind.  As the project progressed, I found that some of my assets fit the original idea, while others, specifically some of the Robot’s movements, were a little more cartoon like than originally desired.  Though my direction of aesthetic and sound design varied, there are many assets in the Platformer that I was extremely pleased with such as the car sounds in the opening cinematic and the platform lift loops.

 

          Mission Completed: I achieved the goals of my game in terms of implementation, timing, mix and completion.  The implementation was a challenge.  I learned that Unreal Engine 4.8.3 is extremely volatile and that saving almost every five minutes was necessary.  Timing of the animation and the cinematics was simple.  I spent a lot of time prior to coming into lab making sure that the assets would line up so long as I put them in the same start spot as I did when creating the assets.  The only place I had an issue with timing was the second helicopter cinematic, when the Robot is getting close to the end of the game.  I had trouble finding the right time to begin the playback of the audio asset and I am still not happy with the flow of that asset within the game.

 

          Schedule: The schedule for the UE4 project was awesome. It gave me enough time to dive into the sound design of the assets. I was able to think about the elements I wanted to include in the asset designs and I had plenty of time to implement them in lab. The quality expectations were more than reasonable. I was able to focus more on my own personal sound design development and growth using the Unreal Engine. For example, because my first assignment was to create ambience for the Platformer, I took the concept of my original aesthetic idea and designed city ambience that included people murmuring, police sirens in the distance, wind, traffic sounds, the car alarm for the crashed truck and fire coming from the truck. With time in my favor, I found that the car alarm and fire asset should just be stingers within the ambience. I was able to remove them from the ambience loop, make them their own assets, and reimport my new assets to deliver a nicer sounding opening sequence to the game. I felt like I grew as a sound designer, because of the opportunity to just be creative and take the time to learn Unreal Engine 4.

 

          What Went Right, What Went Wrong?: There were plenty of things that went right in working on this project and there were a few things that went wrong. Implementation was the majority of what went right. I got the chance to learn the engine and I could adjust settings to make my assets work properly. I feel comfortable working in the Unreal Engine. There are also two audio assets that I take pride in from this project that I will attribute to what went right. The first one is the sound of the engines for the vehicles in the opening cinematic. I took the time to record my own vehicle revving the engine and though it doesn’t sound as beefy as what the cars in the visual might actually sound like, the organic sound of a normal car’s engine just makes the cinematic special. The other audio asset that I was pleased with is the platform lift sound. I used the buzzing of an electric razor that I recorded at home and added my own personal recording of my printer’s print head cleaning itself. The asset has a slight washing-machine effect, but it sounds natural, because it creates the sound of metal chains being pulled up and down. The part of the project that went wrong was the frustration I ran into while trying to create assets for the Robot animations. I just couldn’t seem to stay with a clear aesthetic. Had I better outlined the aesthetic and stayed with it, I might not have run into the frustration of designing my assets.

 

          Lessons Learned: I learned a few things from working on this project.  Going forward, I will clearly define an aesthetic and stick with that aesthetic to avoid creating assets that don’t fit the game.  I also learned that sometimes software programs can be finicky and you just have to work around the bugs.  Not always ideal, but definitely something to remember.  I look forward to working on more projects where I can express my creativity.

 

 

Wwise Limbo Project

          Overall Design: For the Limbo project, my group and I decided to reference Portal 2.  After doing some research, we came up with the aesthetic ideas of industrial, abandoned, apocalyptic, and desolate.  We wanted to create a world in Limbo that felt as though you were unsure if everything was real or if you were just another test subject being tested, like in Portal 2.  When deciding how we wanted to go about designing the sounds, we knew we wanted things to sound “glitchy”.  Achieving this meant running Foley through distortion and adding sound elements to specific objects that didn’t necessarily fit what the object was.  For example, there are low synthesized booms in the rotating of the platform, which a creaking wooden board would never make.  This was definitely a project that pushed all of us to think outside the realm of typical hyper-realism, or realism in general.

 

         Mission Failed, Kind Of: When it came to achieving goals such as implementation, event timing, mix balance and completion, the only part we achieved was completion.  We were able to get all of the assets into the Limbo project before presenting it to the class.  However, there were mix balance issues, events triggering at times we didn’t want them to and implementation frustration.  Specifically, implementation was difficult on day two of working in Wwise, because there were so many events that had to do with one single action.  It became difficult to determine whether a single or multiple events should trigger the sound.  There was a lot of trial and error that ate up time we didn’t have.  The event timing issues were mainly centered on events triggering in multiple locations in the game and the location where we needed the sound to actually play.   The specific example of this was the boy climbing up onto the cart and wooden platform.  After some advice from instructors, we were able to determine which event the asset should be placed on so as not to trigger the sound too many times.    However, on the day of the presentation, the event with the audio asset was being triggered in different locations of the game and its proper placement.  This was highly frustrating because my group members wanted me to fix the issue.  The problem, we think, was code related, requiring knowledge that I lacked.    The mix balance was another issue, but given more time, I believe we could have resolved this issue.  We were down to the wire and we had to leave things the way the were.

 

          Tick, Tock, Tick, Tock: As mentioned before, the schedule was rough for this project. Unlike the Unreal Engine 4 project, we only had a total of 10 hours to work on Limbo. It would have been better to have had more time. Wwise was, and still is, new to me. In hindsight I would have benefited from obtaining the software and doing some personal research on the functions in Wwise. This way, when I came back for day two, I could have possibly had a better work flow and a better understanding of what Wwise could do in terms of playing assets, routing play, stop, pause, resume actions, processing power, etc. This was an instance where I learned that I could either get frustrated at the timeline given to me or I could learn that timelines are always going to be too short and take from this ways to learn how to use all of my time, both in and out of the office or class, to prepare myself and learn how to use the time available in the best possible way. Had I a better understanding of Wwise and the Limbo project, the time I spent trying to figure out functions would have been minimal. This would have provided me more time for implementation, mixing and debugging.

 

          Go Team Go!: I loved the group that I had for this project. We had some issues collaborating towards the end of the project, but the overall dynamic and hard working attitude of each member made this group special to me. This was the first time I worked with a group, where from day one, wanted to push ourselves and each other to make something special. I enjoyed working with a group rather than by myself; I was able to bounce ideas off of other creative people. This not only helped my own creativity, but it kept me on track with the overall aesthetic. It also took a load off when creating multiple assets. Knowing that your team members are doing their work and will have it to you on time was fantastic. However, the downside of the collaboration came at the very end. I had been working with Wwise, while my group members were testing the game or editing sounds that needed to be recut. Unfortunately, on presentation day, we experienced an issue with an event that triggered not only at the spot we needed it to play, but also in random other spots in the game. In the end, the issue could not be resolved and it had to stay the way that it was. Overall the group experience was very special and I hope that I get to work with more people that are as passionate and driven as the members on my team.

 

          What Went Right, What Went Wrong?: For as much as I’ve outlined earlier what went wrong or felt frustrating, the game we created was unique.  We came up with the idea of this world being questionable in terms of its realism.  The ambiences and music define bringing Portal 2 into Limbo.  My two teammates created the ambience and music assets, and I implemented them.  Not only were they perfect for the aesthetic choice we made for the game, but also the implementation was creative.  We were able to figure out how to have ambiences play when triggered; stop when the trigger stopped as well as how to get another ambience to trigger using Play and Stop actions.  We were also able to make the music pause when the little boy dies and when you enter the menu.  This was not something that we learned when first learning the software.  Making the music work the way we wanted it to was something that we were able to push ourselves to do, especially after receiving advice of instructors and adding some creative ingenuity on our part using Play, Stop, Pause and Resume actions within certain events.  We still didn’t get it to pause and resume exactly the way we wanted it to, but given the time we had to do it, we are extremely pleased with the outcome.   

 

          Lessons Learned: The biggest lesson I learned was that you won’t always get the amount of time to work on a project that you want and what defines your success or failure for a project is how you use that time. Going forward, I want to prepare myself before each day of work by finding ways to improve my workflow, understanding the software better, and making a to-do list that will outline my specific goals. I also learned that things will change when implementing, meaning that just because a sound asset sounds great by itself, it doesn’t mean that it will work once it’s implemented. Going forward, I want continue to practice making assets for actions and movements. This will provide me the experience so I won’t have to replace sounds over and over again. I would also like to spend time each day before I leave the office or class to work solely on the overall mix. That way when I am troubleshooting or giving the game a final run through for audio purposes, I will already have a well-mixed game and can fine-tune the mix at the end. This was a great project to work on and to collaborate with others. I know I will take a lot of the experience from this project and apply it in the future.