Pillars:

Mech-n-Tech:
The far-flung future. Mechanical systems are still recognizable to people from 2018, but they run vastly improved software.

Excitement:
Players should be excited when playing the game. We want interaction between players and we want to get players to hoot and holler. We want them yelling and shouting and having a fun time among friends.

Couch multiplayer:
The experience of racing against people and racing with friends is paramount. Players are always racing against someone, players are never racing alone. Racing alone is not the experience we are going for. Players should be interacting and playing with each other, not near each other.

Speed:
The game experience is all about speed and adapting to situations. Players will be going fast basically at all times. If players don’t want to be going fast we’ve done something wrong.

 Audio Designer

• Designed, synthesized, and implemented sound effects compiled from in-house audio sample library

• Attended meetings and supported team and sub-team as a lead

• Collaborated with outside composers in order to obtain music for the game

• Assisted audio programmer when needed in working on audio blueprints

• Coordinated quality testing sessions for audio

• Balanced all sound effects, music, and game modes to ensure the best player experience

One of my jobs was sorting through audio samples and songs, finding the ideal parts of the piece and synthesizing the proper sound effect or song for the game. In the screenshots in this section, I’ve shown the process for piecing together a piece of background music. Between the first and second screenshots, I’ve isolated what part of the song is ideal for looping and made it its own .wav file. Similarly, I’ve also taken the non-looping portion of the same song and set it up as its own .wav file. Between the second and third pictures, I’ve imported both .wav files into Unreal Engine 4. I made a cue for the BGM and placed both .wav files into it. The upper branch on the Concatenator is the intro to the song while the lower branch, which plays after the upper branch, is set to loop until the player leaves that level (race in this case).

The sound shown in this section is for a sandstorm feature that got cut just before the Alpha milestone for the game. The hazard and event portion of the Track sub-team came to us with the request for a sandstorm, so I searched through the sound library for potential sound layers for this effect. In my search, I stumbled upon a looping Zamboni sound effect that would serve as the perfect base for the effect. From there, I put together the various whooshing and whipping sounds that tend to happen in sandstorms and submitted the sound for approval from the hazard designers. The initial version of the sound was not approved, so I found a sound effect of rain hitting a tin roof, adjusted pitch and volume in order to simulate sand hitting the player’s vehicle. Upon submitting the sound again, it got approval.

The sound featured in this section is for the screaming “trail” sound of a firework launcher that was tested and implemented, but ultimately cut from the game. The process for this cue involved picking several sound samples, such as the whistle for a tea kettle, and combine them to create a sound that could mirror a launched “screamer” firework. Just making the sound wasn’t enough, though, since the player would hear it in passing, so I created a simulated doppler effect by using a custom curve for the pitch (showcased in the screenshot) in order to test the sound until it was ready to be implemented. After the desired sound was created, the original audio source files were condensed and consolidated in order to aid performance.

Personal

What Went Well

• Learned and became proficient in a role/side of the engine I wasn’t familiar with

• Successfully worked with external team members (composers)

• Created solid audio effects that enhanced the game feel

What Went Wrong

• Depended too heavily on feedback from others to help steer work

• Didn’t get much feedback until halfway through the project, which led to designing “in a bubble”

• Communication with external team members inconsistent (varying rates of response from composers)

• Composers pulled into project late in the project

What I learned

• External team members, particularly composers, need to be pulled into the project early

• Assertion (not aggression or passivity) is needed to function both as a lead and a strong team member

• Feedback is important and should be sought out early, but shouldn’t be a stopping point in the pipeline

• Assets and ideas should be tested in game as much as possible instead of in isolation

Team

What Went Well:

• The lock system for pushes worked well

  • Had a soft lock + a hard lock

• Team culture was largely positive

• Everyone was a part of QA which was extremely helpful

• Managed to have decent FPS

• Rapid prototyping worked well

• Being flexible in teams on milestones

• Having a Perforce Master was a blessing

• Game Designers checking in with sub teams was nice

What Went Wrong:

• Didn’t bring prototype into room

• Communication from other subteams when features were cut or added was nonexistent

• Waterfall practice happened between teams

• We were too strict with our swim lanes

• When check ins happened they weren’t tested well

  • Should have built it into the pipelines where someone checks your work

• Trust didn't exist between subteams for a majority of the development cycle

• Added features during locks

• Pipelines

  • We didn’t know who to go to

• Game Designers didn’t consult with the subteams until late into the project.

• Two way Game Design communication didn't exist

• Scale was unreasonable for the majority of the project.

  • Inconsistency with unit measurements early in the project led to maps equivalently the size of the US.

• Team Ownership very weak

What We Learned (Even better ifs):

• Be more candid

• Believe the best in others

• Read documents

• Discipline critiques are useful

• Display pillars around the room to refer to

• Get latest before pushing (to test your stuff with latest)

• Talk about problems

• Defining what a lead/producer/game designer is

• Be flexible – even across disciplines

• We all own the game