Sound and soundpacks¶
CCB distinguishes gameplay sound events from audible sample playback. The sounds namespace
records simulation events for hearing, AI, and markers; the sfx and backend layers map IDs and
variants to files, playlists, channels, attenuation, and SDL playback.
Authoritative paths¶
src/sounds.*defines gameplay sound categories and event processing.src/sound_backend.hand SDL2/SDL3 backend implementations define device/sample behavior.src/sdlsound.*coordinates initialization, soundset loading, music, and shutdown.doc/SOUNDPACKS.mddescribes pack metadata and JSON;data/sound/Menu_Sound_Test/is a small checked example/fixture.
IDs, variants, and ownership¶
Code/data emit a stable sound ID plus variant and context. A soundpack maps it to licensed audio
files. Gameplay events must still work when SOUND is disabled or device initialization fails;
audio playback cannot become simulation authority.
Contributor workflow¶
Record original source, creator, license, edits, loop status, format, and attribution for every sample. Normalize only through a documented process. Update mappings and fallback variants; never hard-code an absolute local audio path.
Validation¶
Validate soundpack JSON and referenced files, exact and fallback variants, playlists, loop/fade, channel/group behavior, indoor/night/season choices, angle/volume, missing sample diagnostics, device init failure, SDL2/SDL3, and a no-sound build. Use the sound backend tests where applicable.
Performance and packaging¶
Preload policy, decoded sample size, simultaneous channels, and repeated variant resolution affect memory and frame time. Package only distributable assets and preserve case-sensitive paths. Large third-party soundpacks should remain independently distributed unless policy and license explicitly allow bundling.
CCB boundary¶
CCB may share historical IDs with upstream, but its emitted contexts and bundled mappings are the contract. Validate a port against CCB events rather than assuming an upstream soundpack is complete.