Posted On: 2026-04-06
While polishing a game I working on, I abruptly realized that there was no sound at all. Although that is something I should have anticipated*, I'd grown so accustomed to not thinking about it that I completely forgot it when planning out the scope for my remaining work. Rectifying that is an ongoing effort, but in the process I've learned some things that I think will be useful for avoiding such problems in the future. Today's post will touch on that - first by telling the story of how I got into this mess, and then extrapolating from how I was able to solve a similar problem in the past.
Early in my project, I was trying to manage scope and prioritize in a way that could lead to getting a project done (and fully polished) quickly. As I picked out how to scope things, I deliberately broke things down according to the specific gameplay element they belonged to. In addition to genre staples (mostly complete at the time), I planned to add a bunch of new interactions, none of which I had yet designed. To properly vet those interactions, I not only needed to code the systems, but also see how the visuals and animations conveyed their behavior, so I treated each interaction as a small vertical slice, requiring that I complete (or abandon) every aspect related to each new interaction before moving to the next one. At the time, I briefly considered whether that should include sound, but decided that it was not essential for vetting, and I could simply add it later.
While working through my plans for this year, I decided to push forward development on this project by cutting a large amount that I'd planned for it, in the hopes I could wrap it up and release it (relatively) soon. This led me to polishing what I have, and, as mentioned in the opening, realizing that I had not yet touched anything sound-related. Fortunately, the technical work for implementing sounds proved to be fairly quick*. Unfortunately, creating each individual sound was not.
The first sound (the sound played when clicking on a button) took the better part of a day, and it ended up requiring that I recreate it from scratch (the first simply sounded "wrong".) The second sound took longer, as it took several iterations in order to get something that matched the "feel" of the first, and there was additional rework when the duration of the sound didn't correctly match the duration of the (already polished) visuals. So far, productivity hasn't improved: each sound continues to take too long, and requires too many "iterations" that amount to completely starting over.
Looking back on it, I can clearly see where I made the mistake that created this particular problem. When I defined the scope of work for each new interaction, I included animation but excluded sound. The choice to include animation was, itself, a reaction to a particularly bad workflow problem in a prior project: after focusing on (entirely still) visuals during early development, I struggled to animate them later (often spending a day or more on each one). The parallels here are quite striking, and, going forwards, I intend to treat sound and animation similarly in my future projects: include them early because deferring them only makes things more difficult.