Naming Game Sound Effects So You Can Actually Find Them Later

A middleware system does not know what a sound is. It knows what the file is called. When an FMOD automation script processes an incoming audio file, it reads the filename and nothing else — the script determines which folder, which buses, and which bank the Event routes to based entirely on the naming pattern it finds in the string. If the file is called combat_final_v3_ACTUAL.wav, the script has no reliable way to know that it belongs to a weapon category, that it is a one-shot, or that it is the third variation of a set. If it is called sfx_zetterburn_fstrong_01.wav, the script knows the category, the character, the move, and the variation number without opening the file.

That is the difference naming makes. It is not a matter of tidiness. A naming convention is the contract between the asset and every automated system that will touch it — import scripts, batch renamers, search filters, middleware routing, and the sound designer who is trying to find a specific footstep at 2 a.m. two months into production. The sections below work through the naming structures that hold up under those constraints, the character limits the middleware imposes, and the fields that carry information a filename alone cannot.

The Filename Is Not a Label — It Is a Parseable String

The most useful way to think about a sound effect filename is as a small data record, not as a human-readable title. Every block in the string should be something a script can extract and act on: a category, a subcategory, a source, a variation number, a loop flag, a creator ID. If a block exists only to make the name look descriptive to a human, it is taking up space that could carry a parseable value.

This is the principle behind the Universal Category System (UCS), a public-domain taxonomy for sound effects that defines both a category hierarchy and a filename syntax. UCS currently defines 82 top-level categories (such as ambience, impact, and gun) and 753 subcategories (such as urban, metal, and antique). The filename structure is built from blocks that a database or middleware can parse independently: CatID-UserCategory_VendorCategory-FXName_CreatorID_SourceID_UserData. Some blocks are required and some are optional; the Strata collections shipped by Audiokinetic use five blocks by default.

The block structure is worth reading carefully because it separates three things that are often conflated in a hand-written name: what the sound is (CatID), what it is called (FXName), and where it came from (CreatorID and SourceID). A name like GUNAntq_Pistol Muzzleloader-Shot 01 Composite_AKB00M_Historical Firearms.wav encodes the category (antique gun), the descriptive name (muzzleloader shot), the creator or vendor, and the source collection. A database can sort by any of those fields without a human reading the string.

The separator rules matter as much as the blocks. UCS reserves the underscore and hyphen for specific roles: underscore suffixes UserCategory to CatID, underscore prefixes CreatorID and SourceID, hyphen suffixes VendorCategory to FXName. Those characters are not allowed to appear anywhere else in the filename. A name that uses an underscore as a casual word separator breaks the parse; the script cannot tell whether the underscore is a block delimiter or part of a descriptive word. The pipeline decisions guide covers the structural questions that sit upstream of naming; the naming rule is the first point where those structural decisions become visible in a string.

Wwise Imposes Character Limits That Change What a Name Can Be

Wwise’s naming rules are stricter than a general-purpose file system’s, and the restriction is not cosmetic. For Events, SoundBanks, Game Parameters, Switches, States, RTPCs, and Triggers, only numbers, unaccented Roman letters, and underscores are accepted, and the name cannot begin with a number. Most object names are limited to 260 characters; SoundBank names are limited to 252 characters by default, with the actual limit evaluated when the bank is generated and written to disk inside the project’s file path.

The 260-character limit sounds generous until a naming convention tries to encode everything into one string. A name that includes the module, the UI screen, the interaction type, the playback mode, and a version number can approach that limit before the project is half built, and a name that exceeds it will fail at bank generation with a file-writing error rather than at import, which makes the problem harder to diagnose. The practical response is to decide which fields belong in the object name and which belong in the folder structure or in metadata. Wwise’s own guidance on large libraries recommends a folder hierarchy that mirrors the game’s structure — SFX → Weapons → Pistols → Reload_01 — so that the object name does not have to carry the entire path.

A working pattern from Wwise integration practice encodes the module, the UI context, the interaction, and the playback mode into the object name itself: ABC_UI_TitleClick_OS, where OS stands for one-shot. The pattern is explicit about what it is encoding, and it stays short enough to survive the character limit. The same logic applies to AMB_Forest_Wind_Loop_01 or SFX_Player_Footstep_Grass_Heavy_03: the prefix names the category, the body names the specific event, and the trailing number names the variation. The loop versus one-shot guide covers why the playback mode is worth encoding at all; the naming point is that it is one of the few fields that changes how the engine reads the asset, so it belongs in the string.

Field	What it encodes	Where it can live
Category	SFX, AMB, UI, VO, MUS	Filename prefix; folder top level
Context	Module, character, scene, surface	Filename body; folder hierarchy
Playback mode	One-shot, loop, sustained	Filename suffix or body token
Variation	Two-digit number	Filename suffix
Creator / source	Vendor, recordist, collection	Filename blocks (UCS); metadata
Notes / design intent	Trigger logic, layering, state changes	Wwise Notes field; sidecar document

The table is a placement decision, not a mandate. The point is that not every piece of information about a sound belongs in the filename, and a name that tries to carry everything will hit the character limit or become unparseable. The fields that belong in the string are the ones an automated system needs to route or group the asset; the fields that belong in metadata are the ones a human needs to understand the design intent.

FMOD’s Automation Scripts Read the Filename Literally

FMOD’s automation workflow makes the parsing contract explicit in a way that general advice does not. In a production project that uses a script to route and process incoming audio, the filename format is not a suggestion — the script relies entirely on the name to determine routing. The documented format is:

[prefix]_[character_or_item_name]_[move_name]_[variation_number].wav

The script requires snake_case; spaces will cause the script to skip the file. The character or item name defines which folder, buses, and banks the Event routes to. The variation number must always be a two-digit suffix preceded by an underscore, and even a sound with no variation still needs _01 at the end for the script to run. The prefixes are a closed set: sfx_ or snd_ for character sound effects, sfx_item_ for item sound effects, vo_ for voice lines, and announcer_ for announcer lines. A file that uses a different prefix is not routed by the script at all.

The example filenames from the project show what the contract looks like in practice: sfx_zetterburn_fstrong_01.wav, sfx_armando_intro_01, snd_danfornace_fspecial_active_loop_02. The loop token in the move name automatically flags the generated Event as a looping sound. That is a naming convention doing engine configuration work: the filename tells the script to set a loop flag that a human would otherwise have to remember to set in the Event editor.

The general lesson is not “use this exact FMOD format.” It is that if a project has any automation — and most projects of any size do, whether it is a batch import script, a renaming tool, or a build pipeline — the filename is an input to that automation, and the automation will treat the name as a literal string. A name that is readable to a human but not parseable by the script is a name that will be skipped, misfiled, or routed to the wrong bus.

The Naming Fields That Survive a Project Long Enough to Be Searched

A naming convention that works in month one can fail in month eight, when the project has three hundred sounds and the person searching is not the person who created them. The fields below are the ones that tend to survive that transition, because each one answers a question that a searcher will actually ask.

Category first. A sound that begins with SFX_, AMB_, UI_, VO_, or MUS_ can be filtered before any other decision is made. This is the coarsest possible sort, and it is the one that saves the most time when the library is large. The category prefix also maps directly to the top-level folders and bus groups, so the name and the structure stay consistent.

Context before description. A name that says Player_Footstep_Grass_Heavy is searchable by the surface, the character, and the weight. A name that says footstep_nice_03 is searchable by nothing except the word “footstep.” The context tokens — who, where, what — are the ones that a searcher will already have in mind when they open the search field, because they are the same tokens the game uses to trigger the sound. The footstep surface guide covers why the surface is a useful token: it is a gameplay variable, not a descriptive flourish.

Variation numbers that sort correctly. A single-digit variation number sorts incorrectly after the ninth file (_1, _10, _2). A two-digit number (_01, _02, _10) sorts in the order a human expects. This is a small detail that becomes a daily irritation when a set has more than nine variations, and it is one of the cheapest things to get right at the start.

Consistent case and separator. The choice between snake_case, camelCase, and PascalCase matters less than the consistency of the choice. A library that mixes Footstep_Grass_01.wav with footstep_grass_02.wav will produce search results that miss half the files, because the search is case-sensitive or because the separator differs. The convention should be locked before the first file is named, and it should be written into the project’s README or wiki so that a new contributor can follow it without asking.

Playback mode where it changes engine behavior. A loop token is worth including when the middleware or the automation script uses it to set a property, as in the FMOD example above. It is less useful when the playback mode is set in the Event editor and the filename is never read for that purpose. The rule is not “always include the mode” but “include the fields that a system will actually parse.”

When the Filename Cannot Carry the Information, the Metadata Has To

Not everything about a sound fits in a filename, and the things that do not fit are often the things that matter most to the person who has to implement or maintain it. Wwise’s Notes field exists for this reason: a complex Event’s playback logic, the purpose of a Game Sync, and the intended layering of a ShareSet all belong in Notes, not in the object name. A filename can tell a searcher that the sound is a weapon impact; it cannot tell them that the impact is meant to duck the music by 3 dB when the player’s health is below 20%.

The same principle applies outside the middleware. A short sidecar document that describes the intended trigger logic, the natural loop points, and the state changes each variation was written for is part of the deliverable, not an optional extra. The information only the sound designer has — the reason a particular variation exists — is the information that cannot be recovered from listening, and it is the information that a filename has no room to carry.

The practical split is: the filename carries what a system needs to route, group, and search the asset; the metadata carries what a human needs to understand and maintain it. A naming convention that tries to do both in the string will either exceed the character limit or become unreadable. A convention that does neither will leave the library unnavigable by month eight. The middleware-ready design guide covers the parameter side of the same asset contract; naming is the string that the pipeline reads before any parameter value is set.

A Naming Test That Uses the Search Field, Not the Folder Tree

The test of a naming convention is not whether the folder structure looks tidy. It is whether a person who did not create the sounds can find the right one using only the search field.

1. Ask someone who has not seen the library to find every footstep on grass. They type “grass” and “footstep” into the search field. If the results include the grass footsteps and exclude the concrete ones, the naming is doing its job. If they have to open folders to narrow the result, the category or context tokens are missing from the names.
2. Ask them to find the third variation of the player’s heavy attack. They type “player” and “heavy” and “03.” If the file sorts to the top, the variation number is formatted correctly. If they have to scan past _1, _10, and _2, the numbering is single-digit and the sort is broken.
3. Ask them to find a sound whose filename you deliberately did not follow the convention for. If they cannot find it, the convention is doing real work. If they find it anyway, the convention may be redundant — or the library may be small enough that it has not been tested yet.

A library passes this test when the search field is the primary navigation tool and the folder tree is a secondary confirmation. A library that fails it will still work, in the sense that the sounds play. It will just cost more time every time someone needs to find one, and that cost compounds for the life of the project.