Platform Aware Budgets

Platform-Aware Budgets

"A system that ignores its platform is a system waiting to fail in certification."

---

The Problem

Your game runs on PC. It has 32 concurrent audio channels, unlimited save slots, 2GB of shader cache, and enough RAM that nobody thinks about streaming budgets. Everything works beautifully.

Now you port to console. The memory budget is fixed. The disk budget is constrained. The shader compiler has a different pipeline. The concurrent audio channel count drops. The save system has platform-specific requirements.

Your framework's configuration — the Data Assets that drive every system — was authored for PC. None of it accounts for console constraints. You now face a choice: create per-platform configuration overrides (tedious, error-prone, diverges over time), or find every system's configuration and manually audit it against console TRCs (time-consuming, requires platform-specific expertise, must be repeated for every platform).

This is not a shipping problem. It is a development problem. Platform awareness must be built into the framework's configuration layer from the start, not bolted on at the end of production.

---

The Solution

PGX Profile v2.0 provides a Platform Configuration Data Asset that defines per-system budgets for each target platform. Eleven subsystems read these budgets during initialization and enforce them throughout their lifecycle.

The Platform Configuration Data Asset

A single Data Asset per platform (or platform profile) that defines budgets for every system:

Audio Budgets

• Maximum concurrent sounds
• Memory budget for audio assets
• Channel count limits
• Streaming buffer sizes

PSO (Pipeline State Objects) Budgets

• Shader cache size limit
• Maximum warm-up time budget
• Pipeline count cap

Save Budgets

• Disk space budget per domain
• Maximum slot count
• Encryption requirements (some platforms mandate it)

GameFlow Budgets

• Feature awareness flags (which features are available on this platform)
• State transition timing constraints

Loading Budgets

• RAM budget for loading
• VRAM budget for texture streaming
• Maximum concurrent load operations

LevelFlow Budgets

• Streaming pool size
• Maximum concurrent streaming levels
• Distance-based streaming thresholds

Log Budgets

• Disk budget for log files
• Log rotation policy
• Verbosity limits per domain

MGOS (Memory/GC Observability) Budgets

• Mode constraints (which GC modes are permitted)
• Memory threshold triggers

Message Budgets

• History buffer size
• Maximum concurrent listeners
• Message throughput limits

EventHandler Budgets

• Cache size budget
• Maximum concurrent cached handlers
• Telemetry recording limits

Data Registry Budgets

• Maximum entry count
• Memory budget for cached entries
• Async loading concurrency

---

The Resolution Model

When multiple platform profiles apply (for example, a "Mobile" profile and a "Low-End Mobile" profile), PGX resolves conflicts using a three-rule model:

Capabilities: AND

If a capability is a boolean (like "supports feature X"), all applicable platforms must support it. If any platform says "no," the capability is disabled.

This is the conservative approach: a cross-platform title only enables features that work everywhere.

Budgets: MIN

If a budget is a number (like "maximum concurrent sounds"), the most restrictive platform wins. If PC allows 64 and console allows 32, the resolved budget is 32.

This ensures that the game never exceeds any platform's limits, even during cross-platform development on PC.

Features: MostRestrictive

If a feature has three states (Allowed, Fallback, Disallowed), the most restrictive state wins:

• Disallowed > Fallback > Allowed

If PC says "Allowed" and console says "Fallback," the resolved state is "Fallback."

This three-state model handles the common case where a feature works on one platform, has a degraded alternative on another, and is impossible on a third.

---

Enforcement Across 11 Subsystems

Each participating subsystem enforces platform budgets in its own domain:

Audio

Reads the concurrent sound limit and memory budget during initialization. When the limit is reached, new sound requests are rejected or prioritized (depending on the audio channel's priority rules). The Audio inspector shows current usage against the budget.

PSO

Reads the shader cache budget during initialization. Warm-up operations respect the time budget. The PSO inspector shows precache progress relative to the shader budget.

Save

Reads the disk budget per domain. Save operations check available budget before writing. Encryption is enforced or skipped based on platform requirements. The Save inspector shows disk usage per domain.

GameFlow

Reads feature awareness flags. State transitions that require unavailable features are blocked or redirected to fallback states. The GameFlow inspector shows which features are active on the current platform profile.

Loading

Reads RAM and VRAM budgets. Loading operations respect memory limits by throttling concurrent loads. The Loading inspector shows memory usage during load operations.

LevelFlow

Reads the streaming pool budget. Level streaming operations respect the pool size by managing concurrent streaming levels. The LevelFlow inspector shows streaming pool utilization.

Log

Reads the disk budget for log files. Log rotation triggers when the budget is approached. Verbosity levels adjust based on platform constraints (a shipping console build may suppress verbose logging that a development PC build retains).

MGOS

Reads mode constraints. GC observation modes that exceed platform capabilities are disabled. Memory threshold triggers adjust based on available memory.

Message

Reads history buffer limits. Message history is capped per the budget. Older messages are discarded when the buffer fills.

EventHandler

Reads cache size limits. The handler cache evicts entries using LRU when the budget is reached. Telemetry recording respects the recording limit.

Data Registry

Reads entry count and memory limits. Registration operations check available budget. Async loading respects concurrency limits.

---

The Platform Health Dashboard

A dedicated editor panel that visualizes platform budget status across all systems for all configured platform profiles.

The dashboard shows:

• Per-system budget bars: Current usage vs. budget limit, color-coded (green = healthy, yellow = approaching limit, red = over budget)
• Per-platform columns: Side-by-side comparison of budget utilization across platforms
• Resolution visualization: How the AND/MIN/MostRestrictive rules resolve when multiple profiles are active
• Violation alerts: Immediate highlighting when any system exceeds its platform budget

The dashboard reads from the same platform profile Data Assets that the runtime uses. What you see in the dashboard is what the subsystems will enforce.

Editor Simulation

The dashboard supports platform profile simulation: select a platform profile from a dropdown and see how every system's budgets would resolve under that profile. This allows PC-based development with visibility into console constraints.

You do not need to switch target platforms, create console builds, or modify any assets. The simulation reads the platform profile's budget values and applies the resolution model, showing the effective budgets that each subsystem would enforce.

This is critical for cross-platform development: the team works on PC but can verify at any moment that their configuration respects console budgets.

---

The 5-Layer Profile Model

Platform budgets are one layer of a five-layer profile model:

1. Hardware capabilities: What the physical hardware supports
2. Platform policies: What the platform holder requires (TRC/TCR compliance)
3. Quality targets: What the project's quality bar demands
4. User preferences: What the player has selected in settings
5. Runtime conditions: What the current session's conditions permit

The platform configuration Data Asset captures layers 1-3. Layers 4-5 are resolved at runtime. The resolution model (AND for capabilities, MIN for budgets, MostRestrictive for features) applies across all five layers.

---

Integration with Base Classes

The 10 PGX base classes participate in platform awareness through the ApplyPlatformProfile event. When a platform profile is active, each base class instance receives a callback to adjust its behavior according to the resolved budgets.

For example: a character class that plays footstep sounds can check the audio budget and reduce footstep frequency on platforms with tighter concurrent sound limits. A save-participating actor can check the disk budget and skip optional save data on constrained platforms.

This integration is optional (the event has a default no-op implementation) and configurable per-instance.

---

Why Data Assets and Not Project Settings

Platform budgets could live in Project Settings — a single configuration page with per-platform sections. PGX chose Data Assets instead for three reasons:

1. Per-configuration profiles: A project might have "PC High," "PC Low," "Console Standard," and "Console Performance" profiles. Data Assets naturally support multiple instances. Project Settings support one.

2. Team workflow: Data Assets live in the content directory, are version-controlled as individual files, and can be branched and merged. Project Settings changes produce a single monolithic diff.

3. Framework philosophy: The Data Asset is always the box. Configuration lives in the Data Asset. This is consistent with every other PGX system.