-
Notifications
You must be signed in to change notification settings - Fork 0
Data Driven Design
PGX v0.4.0 | 58 Data Asset Types | Zero-Knowledge Usable | Progressive Disclosure
Where do you configure the save system's auto-save interval in your project?
If the answer is "check the C++ constructor," you have a code problem. If the answer is "check the ini file," you have a deployment problem. If the answer is "check the Blueprint default," you have a discoverability problem. If the answer is "check the Developer Settings," you have a consistency problem. If the answer is "it depends on which system you are asking about," you have an architecture problem.
Most Unreal Engine projects scatter configuration across five or six different mechanisms. C++ constructors hold default values. INI files override some of them. Developer Settings override others. Blueprint class defaults override yet more. Some systems use a combination. The result: when a designer asks "where do I change X?", the honest answer is "it depends."
PGX eliminates that ambiguity with a single rule: the Data Asset is always the box.
Imagine a preschool toy -- a box with shaped holes on top and a collection of wooden shapes. A triangle goes in the triangle hole. A circle goes in the circle hole. The child does not need to understand geometry or manufacturing. They pick up the shape, find the hole it fits, and push it through.
PGX configuration works the same way.
The Data Asset is the box. It has slots -- typed properties that accept specific values. The developer does not need to understand how the save system processes auto-save intervals internally. They just open the Save Config Data Asset, find the "Auto-Save Interval" property, type a number, and save.
The class is the shape. When the developer wants custom behavior, they create their own class (a Blueprint class or a C++ class) and tell the Data Asset "use this one instead of the default." The custom class fits the same slot. The system treats it the same way. No rewiring, no configuration changes, no code surgery.
This is the design philosophy that drives every configuration decision in PGX:
The developer does not think about abstraction. They just put the piece in the hole.
PGX uses Data Assets for two distinct purposes:
Every PGX system has one Config Data Asset that controls its behavior. The Save system has a Save Config. The Audio system has an Audio Config. The PSO system has a PSO Config.
Config Data Assets answer the question: "How should this system behave?"
Examples:
- Auto-save interval, maximum slot count, compression settings (Save)
- Channel count, transition validation rules, debug visualization (GameFlow)
- Concurrency limit, batch size, warm-up priority (PSO)
- Default volume, ducking curves, HDR settings (Audio)
There is exactly one Config DA per system. The system discovers it automatically at initialization through the Asset Registry -- no manual registration, no code changes, no ini entries. Drop the asset in the project folder, and the system finds it.
Beyond configuration, PGX uses Data Assets to define game content. These are not system settings -- they are the building blocks of the game itself.
Examples:
- Audio definitions: sound profiles, music tracks, dialogue chains
- Construction definitions: what components and properties an actor should have
- Platform profiles: hardware capability tiers and budget constraints
Object Data Assets answer the question: "What things exist in my game?"
The same workflow applies: create the asset in the Content Browser, fill in properties, done. The Data Registry system discovers them at runtime for on-demand querying.
Every PGX system follows the same workflow. No exceptions.
+-----------------------------------+
| STEP 1: Create Data Asset |
| |
| Right-click in Content Browser |
| --> PGX section |
| --> Choose system |
| --> Choose asset type |
+-----------------------------------+
|
v
+-----------------------------------+
| STEP 2: Fill Properties |
| |
| Open the asset |
| Details panel shows properties |
| Essential ones visible by |
| default |
| Advanced ones under dropdown |
+-----------------------------------+
|
v
+-----------------------------------+
| STEP 3: Done |
| |
| System discovers the asset |
| automatically via |
| Asset Registry scan |
| No code changes needed |
| No registration calls |
| No ini file entries |
+-----------------------------------+
That is the complete workflow. A developer who has never read a line of PGX documentation can create a working save system by right-clicking in the Content Browser, choosing the Save Config asset, and filling in three properties.
How does the system find the Data Asset? Through the Unreal Engine Asset Registry.
When a PGX system initializes, it queries the Asset Registry for assets of its Config DA type. If it finds one, it uses it. If it finds none, it uses sensible defaults. If it finds more than one, it logs a warning and uses the first one found.
This means:
- No registration code. You do not call "RegisterConfig" anywhere.
- No ini references. You do not add a path to any configuration file.
- No startup logic. You do not override any initialization function.
- Just drop the asset. The system finds it because it exists.
This is the same pattern Epic uses for several engine systems. PGX applies it consistently across all 13 production systems.
A Save Config Data Asset has over 20 configurable properties: auto-save interval, maximum slots, compression algorithm, checksum validation, version migration chain, domain separation tags, and more.
Showing all 20 properties to a developer who just wants to set up basic save/load is hostile UX. It is the equivalent of opening Photoshop for the first time and being greeted by every toolbar, palette, and panel simultaneously.
PGX uses the same progressive disclosure pattern that Epic applies to Actors, Components, and every base class in Unreal Engine: the Advanced Display section.
When a developer opens a Save Config Data Asset, they see 3-5 essential properties:
- Save directory
- Maximum save slots
- Auto-save enabled (yes/no)
These are the properties required for a working save system. Nothing else.
Clicking the "Advanced" dropdown (the same UI pattern used throughout the Unreal Editor) reveals the remaining properties:
- Compression settings
- Checksum validation
- Version migration chain
- Domain separation tags
- Async I/O settings
- Slot metadata
Every property on every Config Data Asset is classified as one of three categories:
- Visible: The Data Asset will not work without this property being set. Always shown.
- Advanced: Has a sensible default that works for most projects. Hidden under the Advanced dropdown.
- Never Hide: Looks like it should be advanced, but hiding it causes silent bugs. Always shown despite appearing non-essential.
This classification is documented per-property with explicit reasoning. The intent is preserved even when the original author is not available to explain it.
The result: a junior developer fills in 3 fields and has a working save system. A senior developer expands "Advanced" and has full control over 20+ parameters. Same asset, two experiences, zero compromises.
PGX provides default implementations for every system. But real projects need custom behavior. The save system needs project-specific serialization. The audio system needs game-specific music transitions. The game flow system needs levels-specific validation rules.
The Class Override Pattern solves this without requiring developers to understand PGX internals.
PGX provides two ways to specify a custom class, because Blueprint developers and C++ developers have different workflows:
For Blueprint developers:
1. Open the Config Data Asset
2. Find the "Use Custom Blueprint" checkbox
3. Check it
4. Drag your Blueprint class into the slot
For C++ developers:
1. Open the Config Data Asset
2. Find the "Class Override" dropdown
3. Select your C++ class from the list
(PGX default is pre-selected)
Both mechanisms produce the same result: the system uses the developer's class instead of the PGX default.
A common failure mode in class override systems: the base class creates an instance, then the override creates another instance, and now two instances exist doing conflicting work.
PGX prevents this structurally. When a custom class is specified, the base class detects it during initialization and yields -- it does not create its own instance. There is always exactly one instance, whether it is the default or the override.
System Initialization
|
v
Is a custom class specified in Config DA?
|
+---+---+
| |
Yes No
| |
v v
Create Create
custom default
class class
| |
+---+---+
|
v
Exactly ONE instance exists
System proceeds normally
The developer never sees this flow. They just specify their class in the Data Asset and everything works. The system handles the rest.
PGX integrates deeply with the Unreal Content Browser so that Data Asset creation feels native.
Right-clicking in the Content Browser shows a dedicated PGX section with all 58 Data Asset types organized by system. Each system has its own color-coded subsection:
Content Browser > Right-Click > PGX
+-- Save (Green)
| +-- Save Config
| +-- Save Slot Definition
|
+-- Audio (Orange)
| +-- Audio Config
| +-- Sound Definition
| +-- Music Config
| +-- Dialogue Chain
|
+-- GameFlow (Orange)
| +-- GameFlow Config
| +-- Phase Definition
|
+-- PSO (Cyan)
| +-- PSO Config
| +-- Pipeline Set
|
... (13 systems, 58 types total)
Each asset type has a dedicated factory, a unique icon, and a system-specific color. When a new Save Config asset appears in the Content Browser, it is green. When a PSO Config appears, it is cyan. Developers can visually identify which system owns an asset at a glance.
For systems with extensible classes, the Content Browser also offers Blueprint creation entries. Right-clicking shows options to create a new Blueprint derived from PGX base classes:
Content Browser > Right-Click > PGX Blueprints
+-- Create Save Blueprint
+-- Create Audio Blueprint
+-- Create GameFlow Blueprint
...
These Blueprints are pre-configured with the correct parent class, ready for the developer to add their custom logic in the Event Graph.
PGX's design test is this: a developer who has never read PGX source code should be able to create a working system by interacting only with the Unreal Editor.
The developer:
- Right-clicks in the Content Browser and sees PGX asset types.
- Creates a Config Data Asset for the system they want.
- Opens it and sees labeled, categorized properties with tooltips.
- Fills in the essential properties (3-5 fields).
- Presses Play.
The system works. No documentation was read. No code was written. No configuration file was edited. The editor UI made the workflow obvious.
If a new developer needs to read documentation to understand WHERE to configure something, the UX has failed. The editor should make it obvious.
This does not mean documentation is unnecessary. Documentation explains why and how at deeper levels. But the basic workflow -- create, configure, use -- must be discoverable through the editor alone.
Understanding the connection between design-time configuration and runtime behavior helps explain why Data Assets are the right abstraction.
The developer creates Data Assets in the editor. These assets are serialized and stored as part of the project's content. They participate in cooking, packaging, and distribution like any other Unreal asset.
When the game starts (or when the editor enters Play-In-Editor), PGX systems initialize in a deterministic order. Each system queries the Asset Registry for its Config DA. If found, the system reads the configuration. If not found, defaults apply.
Engine Start
|
v
+---[Profile]---+ Reads platform config, sets budgets
|
v
+---[GameFlow]--+ Reads flow config, sets initial state
|
v
+---[Log]-------+ Reads log config, sets verbosity
|
v
+---[Save]------+ Reads save config, initializes slots
|
v
+---[PSO]-------+ Reads PSO config, begins warm-up
|
v
... (remaining systems)
Systems use the configuration read at initialization. Some properties can be changed at runtime through console commands or Blueprint calls, but the Data Asset is the authoritative source. If the game restarts, configuration reloads from the Data Asset.
Why Data Assets and not the other UE5 configuration mechanisms?
| Mechanism | PGX Position | Reason |
|---|---|---|
| Data Assets | Primary configuration method | Discoverable in Content Browser, typed properties, supports per-level overrides, serialized with project content, visible in editor Details panel |
| Developer Settings | Used for editor-only preferences | Pin states, inspector visibility toggles -- things that vary per developer, not per project |
| INI Files | Not used for PGX configuration | Not discoverable in editor, no typed validation, merge conflicts in version control, different syntax than the rest of UE5 workflows |
| C++ Constructors | Not used for configuration | Requires recompilation to change, not visible to non-programmers, scattered across codebase |
| Blueprint Defaults | Not used for system config | Appropriate for gameplay objects, not for system-level configuration that should be asset-driven |
The principle: configuration should be visible in the same tool the developer already uses (the Unreal Editor), in the same format they already understand (property editing), using the same workflow they already know (create asset, fill properties).
Across 13 production systems, PGX defines 58 Data Asset types. Some systems have one (just a Config DA). Others have several (Audio has sound definitions, music configurations, dialogue chains, and more).
Every Data Asset type follows the same rules:
- Created through the Content Browser with a dedicated factory
- Color-coded by system
- Properties organized with progressive disclosure
- Tooltips on every property
- Auto-discovered by the owning system (for Config DAs) or queryable through the Data Registry (for Object DAs)
The consistency means that learning one system's workflow teaches you all of them. The Save Config DA and the Audio Config DA look different in their properties, but they behave identically in how you create, configure, discover, and override them.
The Class Override Pattern means developers extend PGX without modifying it. This is important for maintenance:
- PGX updates do not overwrite your customizations. Your custom classes live in your project, not inside PGX plugin folders.
- PGX defaults always work. If you remove your custom class reference from the Config DA, the system falls back to the PGX default. No broken state.
- Multiple projects, different configurations. The same PGX installation supports different projects by pointing Config DAs at different custom classes.
PGX Framework (unchanged)
|
+-- Project A
| Config DA --> Custom Save Class A
| Config DA --> Custom Audio Class A
|
+-- Project B
| Config DA --> Custom Save Class B
| Config DA --> (uses PGX default audio)
|
+-- Project C
Config DA --> (uses all PGX defaults)
Three projects, one framework installation, zero source code modifications.
A concrete example. You want a save system in your project.
Without PGX: You create a save manager class. You decide where configuration lives (maybe a struct in the header, maybe an ini file, maybe a developer settings page). You implement serialization. You implement slot management. You implement auto-save. You create a UI for the save/load screen. You hope your approach is compatible with future systems you build later.
With PGX:
- Right-click in Content Browser. Select "Save Config" under the PGX section.
- Open the asset. Set "Max Slots" to 5. Enable auto-save. Set interval to 60 seconds.
- Press Play.
The save system works. Slots are managed. Auto-save triggers every 60 seconds. The Save Inspector panel shows live state. Console commands let you debug. Blueprint nodes let you trigger save/load from gameplay logic.
When you need custom serialization? Create a Blueprint (or C++ class) that extends the save base class. Set it in the Config DA. Your custom logic runs where PGX's default used to. Everything else -- slots, auto-save, async I/O, compression -- continues working.
The framework provides the engineering. You provide the game logic. The Data Asset connects them.
El diseno data-driven de PGX sigue una filosofia simple: el Data Asset es siempre la caja, y la clase custom del desarrollador es la forma que encaja en ella. Toda la configuracion de cada sistema vive en un Data Asset, no en constructores C++, archivos INI, ni Developer Settings. El workflow del desarrollador se reduce a tres pasos: crear el asset en el Content Browser, llenar propiedades en el panel Details, y el sistema lo descubre automaticamente via Asset Registry. PGX utiliza progressive disclosure -- cada Config DA muestra 3-5 propiedades esenciales por defecto, con el resto bajo el dropdown "Advanced", siguiendo el mismo patron que Epic aplica en toda la engine. El Class Override Pattern permite a los desarrolladores especificar su propia clase custom (Blueprint o C++) a traves del Data Asset, y el sistema base cede automaticamente sin crear instancias duplicadas. Con 58 tipos de Data Asset across 13 sistemas, todos siguen las mismas reglas: factory dedicada, color por sistema, tooltips, auto-discovery, y extension sin modificar el framework. El test de UX es claro: si un desarrollador nuevo necesita leer documentacion para saber DONDE configurar algo, el diseno ha fallado.
- Development Preview
- Getting Started
- Release branch catalog
- Public Plugin Matrix
- Early Preview Plugins
- Known Issues
- Architecture Overview
- Plugin Topology
- Module Reference
- Configuration and Registry
- Data-Driven Design
- Profiles and Budgets
- Gameplay Tag Architecture
- Initialization Pipeline
- Cross-Plugin Communication
- Message System
- Event Handlers
- Logging and Trace
- Runtime Flows
- Blueprint API Design
- Editor Integration
- Editor Visual System