Build a better game with the right AI prompts.

# Task: Optimize the existing Unreal Engine audio and video pipeline

You are a senior Unreal Engine audio programmer, media engineer, and performance engineer.

First inspect:

- Unreal Engine version and target platforms
- SoundWave assets
- SoundCue and MetaSounds usage
- SoundClasses and SoundMixes
- Attenuation and concurrency settings
- Streaming settings
- Dialogue systems and Quartz usage
- Media Framework implementation
- Asset Manager configuration
- Pak or IoStore configuration

Do not replace systems that already work.

## Audio

Classify all audio into UI, short SFX, repeated SFX, positional gameplay SFX, voice, music, ambience, and cinematic audio.

Use Unreal's native SoundWave compression and streaming systems where possible.

For short critical SFX, prioritize low latency, avoid unnecessary streaming, and keep frequently triggered sounds efficient.

For long-form audio, use appropriate compression, stream long music or dialogue when supported, and avoid decoding entire tracks into memory unnecessarily.

For 3D sounds:

- Use mono when stereo information is unnecessary.
- Preserve and tune attenuation and spatialization.
- Configure Sound Concurrency.
- Prevent excessive simultaneous instances.

Establish measured concurrency and priority rules for footsteps, impacts, weapons, environmental sounds, enemy voices, and background combat. Important sounds must win over unimportant sounds.

Do not allow hundreds of redundant sounds to consume resources merely because many actors exist. Aggregate ambience where a layered system is more appropriate than many independent sources.

## Video

- Inspect the current Media Framework implementation.
- Select codecs and containers appropriate to each target platform.
- Avoid unnecessary bitrate and resolution.
- Stream large cinematics.
- Release resources after playback.
- Handle platform decoder limitations and lifecycle interruptions.

Preserve existing MetaSounds, SoundClasses, SoundMixes, attenuation, dialogue, subtitles, sequencing, and gameplay behavior. Do not convert every sound to one format.

After implementation, provide compression and streaming settings, concurrency limits, asset-loading strategy, platform differences, video settings, measured memory reduction, measured package-size reduction, and remaining risks.

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