All brands, logos, and trademarks used in this presentation are under the copyright of their legitimate owner.

Distributed Sound Specification in CryEngine1  Sound properties spread across  Sandbox, C++, lua tables

Distributed Sound Specification in CryEngine1  Highly specialized  Each sound is set up individually  Very error prone  Reuse of a sound (maybe inconsistent)  Distributed definition of sound properties  Hard to mix  Complex interfaces  Everyone has control over everything

Responsibility in Distributed Sound Specification  Sound designer:  Produces wav-files  Communicates sound name and settings to game programmer  Game programmer:  Calls a sound with settings  Organizes sound settings  Audio programmer:  Sets up sound  Has to debug to catch wrong settings or calls  Supports new effects

Data-driven Sound Specification in CryEngine2  Sound properties centralized in prototype  Sandbox, C++, lua can only spawn instances ID = PlaySound(„physics:bulletwhiz:long“);

Data-driven Sound Specification in CryEngine2  General purpose  A sound is just an instance of a prototype  Less error prone  Consistent use of a sound throughout game world  Centralized definition of sound properties  Some administrative overhead  Easy to mix  Scales well with growing team, sounds and complexity  Simple interfaces  Limited and disjunct control

Audio Implementation Tools  XACT  Microsoft (XBox, 360, Win) Microsoft  ISACT  Creative Labs Creative Labs  FMOD Designer  Firelight Technologies (13 platforms) Firelight Technologies  MultiStream  Sony (PS3) Sony  In-house development

Sound Properties  Volume  Radius  Distance-based functionality  Falloff curve  Reverb send  Mix of sounds  Physics attributes (vehicles, collisions)  Parameter: rpm, mass, speed, contact type, road bumps  Game data  AI radius, AI threat, dialog subtitle

Distance Function

Audio Example

Responsibility in Data-driven Sound Specification  Sound designer:  Produces complete sounds with effects  Communicates prototype identifier to game programmer  Game programmer:  Starts a sound by identifier, that‘s it  Updates game-driven parameters  Audio programmer:  Querys settings from prototype and creates instance  Forwards „unknown“ parameters from game code  No need to implement each new parameter  Designs more abstract interfaces  All can work more independently and creatively

Mixing  Constant need  After a presentation is before a presentation  Group-based / Category-based  E.g. all footsteps on grass, all vehicles  Indirect  Changing values without a immediate audition, e.g. notepad  Direct  In audio implementation tool for larger design changes  In-game  In AIT connected to the game for efficient tweaking and verification

Conversion - Preperations  Redundancy  Create redundant sound assets  Support both code-wise  When do we break it?  Plan and communicate your down time  Convert game code modularly (weapons, vehicles, physics)  We did it in a few hours, only trashing a few builds  Get rid of the „old“ stuff  Safely remove code (or leave it)  Filter wav-files from your build

Conversion – New Role  Many people have to change their habits  Accept it and get used to it  New responsibility  Sound designer: more control, more responsibilty  Game programmer: just call a sound  Audio programmer: query, present, pipe information  Communication  Adapt process of sound requests  Communicate errors, get QA involved

Forgot something?  Localization demands special solution  Crysis has currently >7k lines  Unpractible to have a prototype for each line  Instead we use „whisper“, „shout“, „radio“ prototypes and play localized wave data  Support or restrict modding

Summary  Data-driven audio changes your audio pipeline  Centralized sound specification  More efficient mixing  New responsibilities  If you want to convert:  Prepare  Communicate  Accept  Dont forget to consider your localization

Visit us at booth 848 WH Questions?