Game Audio: Audio Testing

Audio can be a very abstract world to describe in words. A games tester once told me – that he could not always describe what was happening in the ‘aural environments’ of the games he was testing. When he found a bug he could hear that something was wrong, but found it difficult to describe in words.

I believe it is important to make focused testing on audio design and audio implementation. Games testers with a keen interest and ‘ear’ for audio and music should focus on how well the musical context and sound design work in game.

There are many questions to consider when testing audio design. Apart from testing on many different hardwares and systems – it is important to prepare a thorough testprocedure for the actual in-game audio.

In my experience the testprocedure can roughly be divided into 5 categories for each scene and level:

1. Music
2. Sound Design
   
3. Ambience
   
4. Dialogue
   
5. System performance

The above categories 1-4 are then extended with subcategories – examples of subcategories are:

• Characters
• Enemies
• UI sounds
• Feedback sounds
  
• HUD sounds
  
• Collision sounds for each character, enemy and etc
• Interactive objects
• Idle sounds for each character, enemy and etc
• Gadgets
• Weapons
  

For each sound effect, music theme, ambience and dialogue – the following parameters need to be tested:

• Volume
• Execution
• Position
• Timing
• Variations

As a games tester it is important to listen for problems like: delay, distortion, noise, phase, compression problems, clipping, echo, missing sounds, dynamics and latency.

System performance, which is mentioned above as category 5, requires a different setup of testprocedures, which will need a seperate discussion. BUT some of the questions that are important having in mind, in general regarding audio testing of hardware, are according to Alexander Brandon*:

• CPU performance:
  • Too many audio files playing simultaneously?
    
  • Sluggish performance?
    
  • Need to find a more reliable audio file format?
    
  • Optimisation of code?

• Limits testing – finding the limits of audio design and system:
  • How many audio files can be played at the same time?
  • What if the same audio file is played by multiple sources simultaneously?
  • What if audio is turned off and on again?

• Relevancy:
  • Which areas are important to focus on from a programming point of view?
  • Will the coding make an aesthetic difference for game play?
    
  • Will the coding make a qualitative difference for game play?

The above categories and subcategories can be extended, depending on the project and technology used in development.

The testprocedures above cover most areas of audio design, but they are tested with visuals. A different approach will be needed to test the actual music design – meaning the relationship between music, sound design and dialogue. A solution to testing the music design is the blindfold testing, which will be covered in my next post.

Audio testing is an area that definitely needs to be taken seriously when improving interactive audio design and audio quality in games. The development team should hear to the ‘noise’ in the QA Department!

My next post will be on the blindfold test – a procedure to test the relationship between music, sound design and dialogue.

*See posts ‘Game Audio: Interactive Audio Design’ & ‘Game Audio: Improving Interactive Audio In Games’