Getting cue names
Hi,
I would like to ask about methods for getting cue names.
XACT provide two ways to expose that names but both methods are not enought for me. Generating header with cue indexes oppose the main idea of XACT in my opinion because it involve programmer needlessly.
Generating cue list is not good too because one need to parse such file. XAudio share interface with other apis and to make whole process uniform I need to convert that list to script or generate similar list from scripts that define sound banks for other apis. That case would be easier if one could define a format of output list in XACT.
It would be nice to have functions that get cue names from sound banks because it would simplify and shorten the way of sounds from sound designer/composer to level designer. Level designer could immediately use produced sounbanks and choose cues in level editor without involving programmer or additional tools.
As an conclusion I would like to ask if addition of such funcionality is planned in future?
[1026 byte] By [
perun] at [2008-2-5]
Hi Perun. Two-part answer -
1. Are you asking for XACT to include UI to define an arbitrary format for its output lists? The cue list we generate is a simple tab-separated text file so it shouldn't be hard to convert to another format programmatically / using command-line tools. This could be done in a .CMD script immediately after running XactBld. Adding conversion support to XACT itself would be complex and unlikely to address everyone's needs perfectly.
2. Do you mean that XACT should provide runtime APIs that can extract the list of wave/sound/cues from a XWB/XSB file? I assume this would be useful to support some kind of UI in a game's debug build that would let the sound designer select an appropriate cue to use for each game event from some kind of drop-down list of cues. But the XACT philosophy is that the list of all game events that require sound should be agreed upon up front and then left more or less static (except when the game design changes). The sound designer's job is to create sounds to accompany each event in this fixed set appropriately. Game events are designed first, then sounds - not the other way around. So I don't see much value in allowing runtime discovery of the cue list. Perhaps I'm not understanding your suggestion?
Dugan Porter - Game Audio Team - Microsoft
This posting is provided "as is" with no warranties, and confers no rightsHi, thanks for so quick reply!
re 1:
It's idea I want to use if there will be not other way. It would be very helpful if there would be post-build step in XACT and one could define script to execute in that step. Usually sound designers don't have compilers and they are not programmers so automatic solutions are preferable (make them to run scripts manually is risky, they probably will forget to do it). It's similar with level designers.
Text output could contains file names of sound banks, it would be easier to determine which file should be loaded during game/level initialization.
re 2:
API to extract cue names would be enough, names of waves and sounds are worthless. It would be useful if a level designer could browse and choose cue from a list of cues in a level editor (in release builds too) and assign them to events exposed by programmers. During level edition it's common to check which sound fits better to a situation. It's sometimes uncomfortable to assume sound's name before it's creation if You suggest it. If one want to support other sound APIs and allow to switch between them, there must be coherent common interface for them that will allow to do the same things. One must do a lot of work to fit there XACT if design changes aren't acceptable (at least file conversions, additional scripts, level editor changes).
Is it so expensive to provide api that can extract cue names?
Of course there is many ways to hack it but it would be helpful to have such functionality.
Regards
I mentioned this at gamefest a few weeks ago, but this is one area where XACT needs to come up to speed quickly.
Sound designers are not programmers, but we use these middleware tools
to interact with them. Its exceptionally important for us
to be able to document exactly what we've done to the programmer, and
simply generating a cue list is not enough.
Its important to document all of the following things to the programmer once we complete an XACT build:
- cue name
- wave bank(s) associated with the cue
- sound bank associated with the cue
- RPCs associated with the cue
- groups associated with the cue
- variables that can affect the cue
- variable parameters
- notes
XACT knows all of this information, but parsing from the file it
is difficult, time-consuming, and prone to human error. This is
all extremely important information that needs to be
communicated clearly and hopefully in some kind of standardized format
to the programmers.
The programming and sound design worlds will unite in harmony
and sing songs of peace when an XACT generated spreadsheet like this
comes into our worlds. :)
An additional report that would be useful to the sound designers would include all of the list above, plus
- sounds assiciated with a cue
- sound wieghting assicaited with the cue
- samples associated with the cue
- sample paths
- pitch and variation parameters
This is important stuff.
F-mod is leading the way with regards to sound designer
documentation. I would love to see Microsoft pick up the ball and
set things in motion.
Thanks.
That's one of the features we have on our list of stuff to do.
-Brian
Which feature? :)
Have You meant extended text output or getting cue names through API?
But the XACT philosophyis that the list of all game events that require sound should be agreed
upon up front and then left more or less static (except when the game
design changes).
This is confusing. XACT seems to be built completely for the purpose of data-driven design, and it has almost everything it needs to support more modern development philosophies (i.e. rapid prototyping or iterative approaches). And then, inexplicably at the last minute, XACT hits you upside the head with this silly header-file generation and text file parsing.
Run-time discovery of cue and variable properties would completely remove the programmer from the loop (if the game is properly engineered). Designers could make levels and pass them to the audio guys who could place sounds in the levels... animators could create animation events to play sounds... all without having to involve a programmer.
Naturally there has to be some control or assets will just start flying all over the place and DVDs will run in fear. But the programmer shouldn't be that bottleneck IMO.
