Recently, I wrapped up a contract as a sound designer on a AAA game project. I cannot get into the project details yet because it is still in development, but I can talk about what the experience was actually like, what surprised me, and what I learned from being dropped into a much bigger production than I was used to.
If you are curious about what AAA game audio work feels like day to day, especially from the perspective of someone joining partway through development, there are a few things worth knowing.
The first big challenge was impostor syndrome
When I joined the project, it was already well underway. I was not coming in at the beginning with the rest of the team. I was stepping into an established pipeline, established systems, and a team that already had momentum.
That can mess with your head a bit.
Even though I already had experience with Unreal and Wwise, this was my first project at that scale. Most of the games I had worked on before were smaller in scope. So the jump felt big. I did not know the team yet, I did not know the game deeply, and I did not fully know what my role would look like in practice.
That created a pretty heavy sense of impostor syndrome.
One thing I learned is that this feeling does not magically disappear just because you have some experience. You might think that once you reach a certain level, confidence becomes automatic. In my experience, that is not really how it works. New environments can bring all of that uncertainty right back.
What helped was doing the work before doing the work.
- Reading project documentation carefully
- Going through internal videos and reference material
- Learning how the game systems were already set up
- Understanding the audio pipeline before touching tasks
We were lucky to have strong documentation on the project, and that made a huge difference. The more I understood how the systems connected together, the more grounded I felt once I started implementing.
Asking questions is part of the job
The other thing I had to get over was hesitation around communication.
Nobody wants to look clueless. That is normal. You want to show up prepared, do your job well, and not stand out for the wrong reasons. So there is always that temptation to stay quiet a little too long and try to figure everything out on your own.
But on a big team, especially a remote one, that can become a problem very quickly.
I had help during onboarding, and that was huge. There was someone guiding us through the process and helping us get situated. Whenever I got stuck, I could ask him. But at some point he started pushing me to ask questions in the main team chat instead of keeping everything private.
That was uncomfortable at first, but it was important.
Once I started doing it, I realized a few things:
- No one knows everything.
- Even leads and directors do not have every detail memorized.
- Specialized knowledge is distributed across the team.
- Asking early is much better than staying blocked.
That was a big mindset shift for me. There is a difference between not being prepared and simply not knowing a specific thing yet. On a large production, there are too many moving parts for any one person to hold the entire game in their head.
Once I accepted that, it became easier to work with what I knew, identify what I did not know, and close those gaps faster.
The three stages I felt on the project
Looking back, the experience felt like three distinct stages.
1. I know nothing
This is the entry stage. Everything is unfamiliar. Systems are unfamiliar. Team structure is unfamiliar. The game itself is unfamiliar.
2. I know some things, and I know what I do not know
This is where things get more interesting. You start to understand the pipeline and become more comfortable with the tools and workflow. But you also begin to see how much depth is hiding underneath the surface.
I remember having conversations where it felt like I was finally getting it, and then something would break or an engineer would say a certain setup would not work because of technical constraints like memory usage or implementation issues. That is when you realize your understanding is improving, but the system is still much bigger than you thought.
Oddly enough, that is a good stage to reach. It means your mental map is getting more accurate.
3. High pressure team mode
Toward the end, there were periods of overtime and a lot more intensity. Long days, lots of coordination, and a very strong sense that everyone was pushing toward the same goal.
That part felt very different from working alone or on a small team. When a larger group is deep in delivery mode together, there is a kind of shared momentum that you really feel. It is intense, but it is also one of the more memorable parts of the experience.
What the day-to-day workflow looked like
One thing that stood out immediately was how structured the workflow was compared to smaller projects.
We had a production team managing task flow, which meant I was not spending time wondering what to work on next. That was handled at a higher level. Instead, I was given batches of tasks within three week sprints.
That system looked roughly like this:
- A new sprint begins with a set of assigned tasks.
- The team reviews the workload to make sure it is realistic.
- Each person works through their task list during the sprint.
- At the end of the sprint, tasks should be completed or clearly flagged if something is blocked.
That structure was helpful because it gave the work a clear rhythm.
From there, the daily routine was pretty simple:
- Keep team chat open all day
- Spend most working time in Unreal and Wwise
- Implement sounds in game
- Test them
- Make sure they triggered correctly and sounded right
- Capture examples for review
A lot of the day was just focused implementation. Open the game. Work through a task. Put the sound in. Test it. Adjust it. Move to the next one.
If you want more help building a repeatable process for this kind of work, I have a more detailed breakdown of my sound design workflow for creating almost any sound effect.
How review worked
The review process was also straightforward and practical.
Once a task was implemented, I would capture a clip from the game showing:
- A bit of context before the sound
- The sound event itself
- A bit of context after the sound
The idea was to show the full behavior, not just the isolated sound. That way the review could confirm a few things at once:
- Did it trigger at the right moment?
- Did it fit the gameplay context?
- Did anything break?
- Did it sound good in the actual game?
That clip would then be sent for feedback. If changes were needed, I would revise and resubmit. If not, the task could be closed out.
Meetings were minimal, communication was constant
Most of the actual work happened solo, which I liked. There were not endless meetings. Usually we had two team meetings a week, often one earlier in the week and one later.
Those meetings were mainly for updates:
- What are you working on?
- What have you completed?
- What is blocking you?
- Do you need help from anyone?
So on paper, it could seem like a quiet workflow. But because most of the team was remote, communication in chat was constant.
That was one of the biggest adjustments for me.
When I work on my own, I usually prefer very low distraction. Phone off. Door closed. Minimal interruptions. But on this project, keeping chat visible was actually necessary because fast responses helped unblock people, including me.
If someone had a question and I could answer it quickly, that helped them move forward. If I got stuck and someone else could answer quickly, that helped me move forward. On a remote team, speed of communication affects the speed of production.
So even though constant messaging can feel distracting, it was also part of what kept the whole thing moving.
If you are exploring more game audio resources in general, the blog archive has more tutorials and breakdowns on this kind of work.
What surprised me most
A few things caught me off guard on the project.
Loud sounds were much more aggressively processed than I expected
Some of the louder assets were heavily limited or crushed. Visually, the waveform could look extremely flat and dense. If you are used to being precious about keeping waveforms looking neat and dynamic, that can feel wrong at first.
But in context, it made sense.
For certain loud events, that kind of intensity helps sell the impact. If a sound is meant to feel huge, aggressive, and close to the player, some tasteful distortion or heavy control can actually support the experience.
Not always. And obviously you do not want to overdo it. But it was interesting to see how far some sounds were pushed when the in game result called for it.
I spent much less time in Reaper than expected
This one really stood out.
I love working in a DAW, especially building sounds from raw sources, experimenting, layering, and shaping things from scratch. That is one of the most enjoyable parts of sound design for me.
But on this project, I spent far more time in Wwise and Unreal than in Reaper.
Part of that was because I joined later in development. A lot of the sound material already existed. So instead of constantly designing brand new libraries from scratch, I was often:
- Using sounds that were already in the project
- Tweaking or editing them
- Making alternate versions
- Implementing them in game
- Testing and adjusting them in context
That is worth understanding if you want to work in game audio. Depending on the project, your job may be much more about implementation, integration, polish, timing, and systems work than about sitting in a DAW all day making fresh assets from scratch.
Basic coding knowledge helped more than I expected
I am not saying you need to become a hardcore programmer. I did not have to go write engine code or build features in C++.
But having a basic understanding of logic, systems, and how things connect was genuinely useful.
It helped with things like:
- Understanding blueprint graphs
- Following how an event was triggered
- Finding the right place to make a change
- Seeing how audio connected to visuals or other systems
- Knowing what to search for when something was unclear
Even a small amount of technical literacy makes implementation work less intimidating. You do not need to become an engineer, but being comfortable around systems will help a lot.
The biggest audio lesson: it has to sound good in game
At the end of the day, the main rule was simple.
Does it sound good in the game?
That mattered more than obsessing over how a sound looked in Wwise or whether its waveform looked pretty in isolation.
Of course there were still normal technical expectations:
- Typical sample rates and bit depths
- Clean enough imports
- Trimmed one shots when appropriate
- Consistent naming conventions
- Following project documentation
But the real test was always context.
Once a sound is in the game, it may be affected by:
- Volume settings in Wwise
- Volume settings in Unreal
- Effect chains
- Mix relationships
- Gameplay timing
- Animation and sequencing
So a sound that seems quiet or strange in isolation may work perfectly once it is in the full system. And the opposite is true too. Something that sounds great by itself can fail once it is in context.
That is one of the reasons implementation skill matters so much in game audio.
Documentation made everything easier
This project had strong documentation, and I cannot overstate how helpful that was.
Whenever I had a question, there was usually a clear order of operations:
- Check the documentation
- If the answer is not there, ask the lead or the right teammate
- If needed, ask in the team chat
That kind of support structure reduces friction a lot. It helps new people ramp up faster, helps everyone stay consistent, and makes the whole production smoother.
My overall takeaway
The experience was different from what I expected.
I went in thinking more of the work might revolve around designing sounds from scratch in Reaper. Instead, a lot of the role involved implementation, editing, tweaking, lining sounds up in sequences, placing them in Unreal, and making sure everything worked properly in game.
That was a good lesson.
AAA sound design is not just about making cool sounds. It is also about:
- Understanding pipelines
- Communicating clearly
- Working within team structures
- Handling technical constraints
- Reviewing in context
- Delivering under pressure
It was a really valuable experience, and one of the best parts was being around a team of very skilled, very experienced sound designers. That alone teaches you a lot.
If you are building your own library for practice or for game audio work, you can grab my free Sound Designer Starter Pack. It is a simple way to get more material to work with.
