Download presentation
Presentation is loading. Please wait.
Published byEzra Fowler Modified over 9 years ago
3
All brands, logos, and trademarks used in this presentation are under the copyright of their legitimate owner.
4
Distributed Sound Specification in CryEngine1 Sound properties spread across Sandbox, C++, lua tables
5
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
6
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
7
Data-driven Sound Specification in CryEngine2 Sound properties centralized in prototype Sandbox, C++, lua can only spawn instances ID = PlaySound(„physics:bulletwhiz:long“);
8
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
9
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
10
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
11
Distance Function
12
Audio Example
13
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
14
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
15
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
16
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
17
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
18
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
19
Visit us at booth 848 WH Questions?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.