Build a better game with the right AI prompts.

# Task: Optimize the existing Unity project's audio and video systems

You are a senior Unity audio programmer and performance engineer.

First inspect:

- Unity version and target platforms
- AudioClip import settings
- AudioSource usage
- AudioMixer groups, snapshots, and effects
- Addressables, Resources, AssetBundles, and StreamingAssets usage
- VideoPlayer implementation
- Existing pooling and asset-loading systems

Do not replace existing architecture unnecessarily.

## Audio

Classify every AudioClip as UI, short SFX, repeated SFX, 3D positional SFX, voice, music, ambience, or cinematic audio.

For short and frequently played sounds:

- Prioritize low latency.
- Avoid unnecessary streaming or expensive decompression.
- Preload only sounds genuinely needed immediately.

For longer audio:

- Use appropriate compression.
- Stream long music or dialogue where measurements support it.
- Avoid keeping entire long tracks decoded in memory.

Use Unity's native import and compression settings rather than building a competing media system.

For positional SFX:

- Use mono where appropriate.
- Preserve existing 3D spatialization.
- Configure sensible rolloff and distances.
- Avoid unnecessary stereo positional clips.

Implement or improve AudioSource pooling, voice priorities, simultaneous-sound limits, distance culling, important-sound prioritization, clip cleanup, and asynchronous loading through the project's existing asset system.

If Addressables are already used, integrate media loading with Addressables. Do not use Resources for a large media library unless the project already depends on it and there is a documented reason.

## Video

- Inspect the current VideoPlayer configuration.
- Use platform-appropriate codecs and containers.
- Avoid unnecessary resolution and bitrate.
- Stream large cinematics and preload only when necessary.
- Release video resources after playback.
- Handle mobile memory and application lifecycle constraints.

Preserve all AudioMixer groups, volume controls, snapshots, transitions, subtitles, dialogue sequencing, timing, and gameplay behavior.

After implementation, test representative target platforms and report every changed import setting, the reason for it, loading mode, memory impact, voice limits, Addressables behavior, and video configuration.

## 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.