Introduction

Before working with CRI Atom Craft, we recommend that you read the Introduction to the CRI ADX Tools chapter if you have never used the tool before (or not in a long time).
This section describes what kind of data you should prepare
in order to efficiently cooperate with programmers by explaining the data flow for sound playback.

The Sound Creator Makes a Design and the Programmer Plays the Sound Based on it

The sound creator prepares the waveforms to be used as sound sources.
The programmer plays the specified sound at certain times as directed.

Differentiation by File Name

The simplest method for the programmer to play sounds is to specify their "Waveform file name".
Identify something with the waveform file name and associate it with something in the game.

Differentiation by Scenes or by the Role of the Sounds

It is important to estimate as accurately as possible which sounds are required in which scenes or situations.

There are many ways to group sounds depending on the game.

Example: User interface sounds (OK, Cancel sounds etc.),
Crashing sounds, footsteps,
Background music, dialog explaining the situation etc...

Repartition of Tasks Between Creators and Programmers

There are differences between what programmers and sound designers can achieve in terms of how the sound is played back.

At the sound designer level, a specific action can be designed,
such as not to play back too many sounds or to implement automatic ducking.

At the programmer's level, he/she must design how to control the playback in the context / time line of the actual game.
Which sound should be played back at which time?
At which time should the program load new sound data and discard the sound data which is no longer required?
It may sometimes be too granular to load/discard each sound, so a CueSheet, which is a group of sounds, should be used.
Both programmer and designer must consider what is the best way to easily manage sounds (= CueSheet).

Creating a Simple Sound Effect and Passing It to Programmer

The simplest method to create sounds in CRI Atom Craft is as follows.
(To make the explanation simple, some elements are omitted)

Create a project file
Create a work unit
Create a CueSheet
Create a Cue
Register a Waveform
Specify the encoding settings and the playback method (memory or stream)
Create a CueSheet binary file
Pass the CueSheet binary file to a programmer

Until here, a CueSheet binary file is created. It contains the design of sounds.
From here, the programmer can play the sound in the game program based on the design done in the authoring tool.

The Programmer Integrates the Sound to the Game

Initialize the ADX runtime
Load the CueSheet binaries in memory
Create a Player
Assign the Cue to the Player
"Start" the Player

This starts the sound specified by the Cue.

Basically, the programmer creates a Player and assigns the Cue to play in the game, than starts the Player.

Debugging a Problem

Sometimes, the sound may not be played back as intended.
The designer checks the design in CRI Atom Craft using the preview or the profiler to make sure that the data is correct.
The programmer checks that the function used for playback are actually called in the game using the profiler.

Sharing Sound Data Between Several Sound Designers

If there are many sound designers, they should create the data by separating it into multiple files.
In CRI Atom Craft, the data is divided and managed in files called Work Units.
This is another type and level of grouping sounds than the CueSheets.
It is important to estimate who handles which task during the production of the game.

Beyond Simple Playback

You can configure the following features of a Cue.

Management of the number of voices that can be played
Behavior based on the playback priority (voice to be played or not)
Random sound element (various sounds are played back)
Sound group element
Fade-out

The idea is to put most of the control in the hands of the sound designer while reducing the need to involve a programmer as much as possible.
Therefore, most of the time, all the programmer needs to do is to start a Cue.

For a simple playback, the sound is played with the information described above and the Voice is managed according to the sound designer's input.

Getting More Advanced

Using the previous method as a basis, ADX allows you to set interactive music by taking full advantage of various real-time effects, blocks, beat synchronization and selectors. Complex control is also possible from the program.
In addition, in order to simplify the programming, the sound control can be hidden in the Cue using the action feature, and the intensity of the effect can be easily changed using a snapshot.

Considering the Method to Use Depending on the Game Size

In a larger game, loading all the individual sound effects becomes a burden.

To play just a few sound effects, a CueSheet can be used.

However, in larger projects, all sounds cannot be included in a single CueSheet.
Using streaming playback for music or long dialog will help a little.

When all the sounds still cannot be included in a single CueSheet, simply divide the CueSheet.
It is important to clearly define how to separate the CueSheet.

How and which data should be divided and what the minimum unit should be depends on the scale of the game.
It also depends on how many persons work on it, so there is are no fixed recommendations

When you use ADX, the data can be separated into units such as projects, Work Units and CueSheets.
The following describes these.

Number of Voices, Sound Groups

The reason being voice management is to reduce the CPU load of the game.
In addition, allocating many resources for playback will increase the memory usage at run-time.

Here we introduce a mechanism to better control the sound.