Tutorial 1: Sound, Save Data, and Playtesting

Unit 7 · Audio, data, and testing

Objectives

Audio communicates proximity, success, danger, and rhythm. Route sounds through categories such as music, effects, and UI so volume controls remain understandable. Avoid using audio as decoration when it competes with essential information.

record SaveData {
    int level;
    int score;
    double playerX;
    double playerY;
}
// Serialize only stable, necessary state.

A playtest question should observe behavior rather than ask players to design the game. Ask “What did you expect this button to do?” or measure how long it takes to find the objective. Record the context, observation, and possible change.

Exercises

  1. Separate saveable state from derived state in your prototype.
  2. Write five playtest tasks with observable success criteria.
  3. Design sound priorities for music, effects, and UI.

Self-check

  1. Why avoid saving derived values?
  2. What makes a playtest question useful?
  3. Why separate audio categories?

Self-Check Quiz

1. What should a save file contain?

AnswerIt should contain the minimum stable state needed to reconstruct progress, not temporary or derivable presentation data.

2. What is stronger evidence: “Did you like it?” or time to find the objective?

AnswerTime to find the objective is observable behavior and is easier to compare and act on.

Homework

  1. Define a versioned save-data format for your game.
  2. Plan a 15-minute playtest with three tasks and success measures.
  3. Implement one audio setting and test it with headphones and speakers.
Sample answerA useful plan stores level, score, inventory, and player position with a version number. Testers should be asked to complete concrete tasks while the developer records hesitation, errors, and completion time. Audio settings should independently control music and effects and should not be required to understand a critical event.
👤