Build a better game with the right AI prompts.

# Task: Optimize the existing Godot game's audio and video pipeline

You are a senior Godot audio programmer and performance engineer.

First inspect:

- Godot version and target platforms
- AudioStream assets
- AudioStreamPlayer, AudioStreamPlayer2D, and AudioStreamPlayer3D usage
- Audio buses and effects
- Existing resource loading and ResourceLoader usage
- Threaded or asynchronous loading
- Video playback implementation
- Asset export configuration

Do not replace existing architecture unnecessarily.

## Audio

Classify audio into UI, short SFX, repeated SFX, 2D positional sounds, 3D positional sounds, voice, music, ambience, and cinematics.

Do not use one format or loading mode for every asset.

For short critical sounds, prioritize immediate playback, preload only frequently required sounds, and avoid unnecessary streaming.

For long sounds, use suitable compressed formats, stream long music or dialogue where appropriate, and avoid loading entire long tracks into memory.

For 3D sounds, prefer mono when stereo information is unnecessary, preserve spatial audio, configure distance attenuation, and prevent excessive simultaneous instances.

Implement sound prioritization where necessary. When many sounds occur simultaneously, prioritize player actions, nearby combat, important gameplay feedback, important NPC sounds, environmental sounds, then distant background effects.

Implement resource cleanup and threaded or asynchronous loading where appropriate.

## Video

- Inspect the current format and playback implementation.
- Use formats efficiently supported by the target platforms.
- Avoid unnecessarily large videos.
- Stream large videos where appropriate.
- Load cinematics only when needed.
- Release resources after playback.

Preserve existing audio buses, effects, volume controls, spatialization, gameplay behavior, and video sequencing. Do not rewrite unrelated systems.

After implementation, test the supported platforms and provide a media optimization report containing:

Asset | Type | Format | Compression | Channels | Loading | Memory strategy | Fallback

## Player-readable output requirement

Everything shown to a player must be written and presented for a human player, not for a developer or debugger. This includes menus, HUD labels, buttons, prompts, tutorials, objectives, dialogue, tooltips, loading and save states, empty states, confirmations, warnings, errors, rewards, notifications, accessibility messages, and connection or recovery states.

Use concise plain language, the game's established terminology and tone, recognizable icons with text where meaning could be ambiguous, and a clear next action. A player-facing error should explain what happened in useful terms, whether progress is safe, and what the player can do next.

Never expose raw exceptions, stack traces, JSON, database IDs, internal event names, enum or variable names, file paths, debug coordinates, HTTP status codes without explanation, server implementation details, developer TODOs, placeholder text, or raw telemetry on a player-facing surface. Send technical details to development-only logs, diagnostics, telemetry, or an authenticated support view. A short support reference code may be shown to the player only when it helps support locate the private diagnostic record.

Verify representative success, failure, offline, loading, empty, permission, validation, timeout, save, reconnect, and recovery states from the player's perspective. Developer documentation and final engineering reports may remain technical; this requirement applies to anything the game presents to players.

## Required game documentation

Documentation is part of the definition of done for this task.

Before finishing:

1. Read the existing README, docs directory, architecture notes, decision records, and AI instructions that apply to this system.
2. Update the existing relevant documentation instead of creating a competing document or a second source of truth.
3. If no relevant document exists, create a clearly named Markdown document in the game's established documentation directory. Use docs/ when the project has no existing convention.
4. Document the current system, the decisions made, ownership and lifecycle rules, configuration, files or assets changed, commands and tests run, known limitations, and how another developer should extend or troubleshoot the work.
5. Update AI_INSTRUCTIONS.md or the project's equivalent when this task changes architectural boundaries, required workflows, naming rules, or validation commands.
6. Keep documentation accurate to the implementation. Do not claim support, measurements, or test coverage that was not verified.
7. In the final report, list every documentation file created or updated.