The placeholder that ships is never the one that sounds bad. A bad placeholder gets noticed. It gets replaced. The placeholder that ships is the one that sounds fine — good enough that nobody flags it in a playtest, good enough that it survives the milestone, good enough that by the time the real sound is supposed to arrive, the real sound has been deprioritised because “the game already sounds OK there.”
The risk is not that the sound is low quality. It is that the sound is indistinguishable from a finished one at the moment someone would have to notice it. Placeholder assets survive by being forgettable, and forgettable is exactly the property a placeholder should not have. The sections below are about the three mechanisms that make a placeholder detectable before it becomes permanent: the name, the metadata, and the sound itself.
Why a Good Placeholder Is More Dangerous Than a Bad One
A placeholder sound has one job in production: to let the game run before the real asset exists. That job is about function, not quality. A placeholder footstep needs to fire at the right moment and tell the player that a step happened. It does not need to sound like the character, the surface, or the scene.
When a placeholder does more than that — when it has the right timing, the right rough frequency balance, and a plausible duration — it stops reading as a placeholder and starts reading as a sound that is “fine for now.” The people who would have flagged it are no longer paying attention to it, because it is not causing a problem. The prototype vs polish guide covers the phase distinction that makes this possible: a prototype sound is answering “does the mechanic read,” and a placeholder that answers that question well has done its job. The danger is that it also happens to look like a sound that is finished.
The practical consequence is counterintuitive. A placeholder should be functionally adequate and perceptually marked. It should fire at the right time, at the right duration, with the right rough character, and it should also carry an unmistakable signal that it is temporary. The signal can be in the name, in the metadata, in the sound, or in all three. What it cannot be is absent.
Make the Filename Say “Placeholder” Before Anyone Opens It
The cheapest detection mechanism is the one that works
without opening the file. A filename that begins with
PLACEHOLDER_ or ends with _TEMP
sorts to the top of a folder listing and appears in every
search that uses the word. That is not a cosmetic preference;
it is the same principle that makes a naming convention
useful at all — the filename is what automated systems and
human searchers read first.
The naming convention has to be chosen before the first placeholder is created, because a convention applied retroactively is a batch-renaming job that someone will postpone. A workable pattern is a prefix that no final asset will ever use:
PLACEHOLDER_sfx_footstep_grass_01.wav
PLACEHOLDER_ui_confirm_01.wav
PLACEHOLDER_amb_forest_wind_loop.wav
The prefix is deliberately loud. It will not survive a final
pass, because a final asset named
PLACEHOLDER_ anything is a contradiction that
someone will fix. That is the point. The name is doing the
detection work that a folder structure cannot do, because
folders get reorganised and files get moved. A prefix travels
with the file.
The naming guide
covers the parseable-string principle in more detail; the
placeholder case adds one rule to it: the marker has to be a
token that no finished asset will contain, so that a search
for the token returns only the temporary assets. A suffix like
_v2 fails this test, because finished assets also
have versions. PLACEHOLDER_ passes it, because a
finished asset that carries the prefix is a mistake that is
easy to define and easy to catch.
Make the Middleware Say “Placeholder” When the File Is Imported
The filename survives until the file is imported. After that, the middleware object is what the team interacts with, and the filename may not be visible in the object list. The placeholder marker has to exist at that layer too, or the detection stops working the moment the asset enters the project.
Wwise provides a Notes field on every object, and the field is
searchable in the Project Explorer. A placeholder object with
PLACEHOLDER in its Notes is findable through the
same search that finds a finished object by name. The field is
also visible when the object is selected, which means the
marker is in front of the person editing the object, not
buried in a file that they would have to open separately.
FMOD’s equivalent is the User Data field or a dedicated parameter that carries a placeholder flag. A user data field can be read by automation scripts, which means the same detection can happen in a build check rather than in a manual search. The exact field is less important than the principle: the marker has to live in the layer where the decision to replace the asset is made, not only in the layer where the asset was created.
There is a second middleware-level mechanism that is often
overlooked: the bus or bank assignment. A placeholder that is
routed to a dedicated PLACEHOLDER bus is
detectable by its routing, and the bus can be muted or
soloed in a single action. The
mix hierarchy guide
covers how bus structure carries meaning across a project; the
placeholder case is a specific application of that principle,
where the bus assignment is itself a marker.
Make the Sound Itself Sound Wrong in a Useful Way
The name and the metadata are detection mechanisms for people who are looking. The sound itself is the detection mechanism for people who are not. A placeholder that sounds obviously temporary will be flagged by anyone who hears it, including the people who are not running a placeholder audit.
The trick is to make the sound wrong in a way that preserves its function. The placeholder still has to fire at the right moment, last roughly the right duration, and sit at roughly the right level. What it does not have to do is sound like it belongs. Three techniques work well together.
Use a source that is clearly the wrong category. A footstep placeholder that is a synthesized click, a weapon placeholder that is a single sine sweep, a UI confirm that is a tone rather than a designed click — these are all functionally correct and instantly recognisable as placeholders. The AI sound effects for prototyping guide covers how to generate these quickly, which is the point: a placeholder that takes ten minutes to make is a placeholder that will be replaced, because the cost of replacing it is lower than the cost of keeping it.
Leave one processing step visibly unfinished. A placeholder that has not been EQ'd, or that has an obviously unnatural fade, or that is a single layer where the final sound will have three, is marked by the missing step. The marker is not “this sounds bad.” It is “this sounds like it stopped at step two of four.” Anyone who has heard a finished sound in the same category will recognise the gap.
Keep the timing and duration plausible, and the character wrong. The SFX duration guide gives the ranges that make a sound read as its category; a placeholder that sits inside those ranges will not cause timing bugs, which is exactly what you want. The character is where the placeholder marker lives. A footstep that has the right duration and the wrong material is a placeholder; a footstep that has the wrong duration and the right material is a bug.
Build Checks and Deletion: The Two Mechanisms That Do Not Rely on Attention
The name, the metadata, and the sound all rely on someone noticing. That is acceptable for a small team and a short project. It is not acceptable for a project that ships, because attention is the resource that runs out first.
The mechanism that does not rely on attention is a build check. A CI step that scans the middleware project for objects whose name or metadata contains the placeholder token, and fails the build if the count is above zero, makes the placeholder impossible to ship by accident. The check can be scoped: a build for an internal playtest allows placeholders, a build for a release candidate does not. The scoping is what makes the check usable, because a check that fails every build is a check that gets disabled.
The second mechanism is deletion. A placeholder that is deleted rather than muted will cause the game to fail in a way that is immediately visible — the sound is missing, the event logs a warning, the playtest notes it. A placeholder that is muted will cause the game to run silently, which is a much smaller problem and therefore a much smaller signal. The pipeline decisions guide covers the structural layer this belongs to; the placeholder case adds one rule: the temporary asset should fail loudly when it is removed, not quietly.
Deletion is also the test of whether the placeholder was doing any work. If the game runs correctly without the placeholder, the sound was not carrying information, and the final sound may not need to either. If the game breaks, the placeholder was load-bearing, and the final sound has to preserve whatever the placeholder was providing. Either answer is useful, and neither is available if the placeholder is merely muted.
A Placeholder Checklist That Fits on One Line per Asset
The checks below are ordered from the cheapest to the most expensive. Each one is a field or a property, not a judgement call, so it can be verified by someone who did not make the sound.
-
Filename prefix. Does the file begin with
PLACEHOLDER_or an equivalent token that no final asset will use? - Middleware Notes or User Data. Does the imported object carry the placeholder marker in a field that is searchable and visible in the editor?
- Bus or bank assignment. Is the object routed to a dedicated placeholder bus or bank, so it can be muted, soloed, or counted in one action?
- Sound character. Is the sound functionally correct (right timing, right duration, plausible level) and perceptually marked (wrong source, unfinished processing, or clearly synthetic)?
- Build check. Is there a CI step that counts placeholder objects and fails a release build if the count is above zero?
- Deletion test. Has the placeholder been removed in a test build to confirm that its absence is noticed?
A placeholder asset is not a lesser asset. It is a game sound effect with a shorter intended lifespan and a different set of design requirements. The requirements are not about quality. They are about detectability, because the only placeholder that is safe to ship is the one that cannot be forgotten.