-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Common questions from evaluators, potential users, and developers considering PGX for their projects.
PGX (Professional Game Extensions) is a modular C++ middleware framework for Unreal Engine 5. It provides the architectural layer between a raw UE5 project and your game code -- save systems, audio management, game state machines, loading pipelines, platform profiling, and more. It is not a game template, not a starter kit, and not a visual scripting tool. It is production infrastructure.
Lyra is a complete game sample -- a playable shooter demonstrating Epic's recommended patterns for gameplay framework, input, abilities, and experience management. PGX is middleware -- a reusable architectural layer that provides the foundational systems Lyra builds on top of. PGX's Message Bus is informed by Lyra's messaging pattern; PGX's Audio system is validated against Lyra's audio architecture. You could build a Lyra-style game on top of PGX, or use PGX systems alongside Lyra's gameplay framework. They serve different purposes at different layers of the stack.
Most UE5 plugins solve one problem: a save plugin, an audio plugin, an inventory plugin. PGX is a coherent framework where all systems share the same architecture, the same configuration patterns, the same editor tooling conventions, and the same communication model. The value is not in any single system -- it is in the consistency and interoperability across all of them.
PGX is designed for three audiences. Solo developers who want the architecture of a professional studio from day one. Teams who need a shared foundation so every engineer follows the same patterns and conventions. Studios who want a reusable investment that carries across multiple projects and engine versions.
Yes. The star topology guarantees that every feature plugin depends only on the core runtime, never on other feature plugins. You can remove any plugin without affecting the rest of the framework. The only exceptions are three documented dependencies between the Loading, PSO, and GameFlow plugins, which are load-order critical and validated.
Through a three-bus model. The Message Bus handles one-to-many notifications (e.g., "a level finished loading -- anyone who cares, here is the data"). The Event Handler resolves one-to-one behavior requests (e.g., "something triggered a damage event -- who handles it and what happens?"). The Data Registry provides persistent shared state. No system ever imports another system directly.
Every PGX system that can be extended provides a mechanism for developers to specify their own custom class to replace the PGX default. The framework's base class detects the override and steps aside automatically -- only one instance is ever created. From Blueprint, you activate a checkbox and drag in your class. From C++, you select from a dropdown. The result is the same: your class runs instead of the default, with zero risk of duplicate instances.
PGX subsystems initialize in a deterministic sequence: Profile (platform detection), GameFlow (state machine), Log (observability), Save (persistence), PSO (pipeline warm-up), Widget, Audio (sound management), Registry (data store), Message (pub/sub bus), EventHandler (behavior resolution). This order is documented, enforced, and designed so each system can rely on the systems that initialize before it.
Both, by design. Over 170 Blueprint nodes cover the full API surface, organized with progressive disclosure -- daily-use nodes are prominent, advanced and debug nodes are in subcategories. C++ developers access the same API without Blueprint overhead. 10 base classes are fully subclassable from Blueprint with 79 overridable events. The framework does not force a choice -- it supports both workflows equally.
Create a Data Asset in the Content Browser, fill in properties in the Details panel, done. Every PGX system discovers its configuration automatically through the Asset Registry at initialization. There is no registration step, no code to write, no configuration file to edit. Simple properties are visible by default; advanced properties appear under expandable sections. A developer who has never read PGX documentation should be able to configure a system by following the editor UI.
Every system is designed for extension at multiple levels. Config Data Assets accept custom classes via the Class Override Pattern. Blueprint events are overridable. Construction Data Assets are subclassable for project-specific fields. The Data Registry accepts any Data Asset type. The Log system's domain renderers are Blueprint-subclassable. Extension is a first-class concern, not an afterthought.
It means no hardcoded values. Save slot counts, audio mix layers, loading screen timing, PSO warm-up policies, platform budgets -- everything is configured through Data Assets. You change behavior by editing assets in the editor, not by modifying source code. This also means you can have different configurations for different platforms, different build targets, or different game modes, all without recompilation.
PGX includes 25 dockable panels (NomadTabs) covering system inspection, testing, documentation, and productivity. Key panels include the System Observer (live subsystem status), Test Dashboard (automated test runner), Log Viewer (polymorphic domain rendering), and per-system inspectors for Save, GameFlow, PSO, Audio, and more. Each panel follows the same visual design language with consistent layout, color coding, and interaction patterns.
PGX adds 58 Data Asset entries and 23 Blueprint entries to the Content Browser's "Add New" menu, organized by system with distinct color coding. Each asset type has a dedicated factory with correct defaults. A custom Content Browser extension adds system-specific icons and categorization.
Editor Settings provides per-panel pin toggles (show or hide quick access toolbar buttons), and the toolbar integrates a submenu for all PGX tools. The panels themselves are built on a shared visual token system, so any studio can modify the design language by adjusting the token values.
PGX wraps UE5 systems; it never replaces them. Audio calls go to the engine's audio system. Save operations use UE serialization. PSO warm-up uses the RHI pipeline cache. The framework adds organizational overhead (subsystem dispatch, tag lookups, message routing) that is negligible compared to the engine operations themselves. Profiling data is available through the MGOS observability system and per-system console commands.
Yes. The Profile system (v2.0) provides a platform configuration asset where you define per-platform budgets for every system. If a handheld platform has a 32-sound concurrent limit, the Audio system enforces it. If a mobile platform has a reduced save slot count, the Save system respects it. All 13 implemented systems read and enforce platform budgets from the same configuration source.
The foundation supports it. Base classes include network role filtering for component injection. The Save system can partition data per player. GameFlow channels can track per-player state. The Message Bus is designed for both local and networked broadcast. A dedicated multiplayer replication plugin is planned but not yet implemented.
PGX currently targets Unreal Engine 5.6.1. The multi-engine version strategy uses branches (a snapshot is frozen when adopting a new engine version) and release tags that encode both the PGX version and the engine version. Engine updates are included in all license tiers.
13 systems are implemented and compiled. 957 static analysis warnings have been fixed across two remediation rounds. 22 editor panels have been audited for UX quality. A comprehensive simulation harness tests approximately 160 API calls across all systems, covering roughly 90% of the framework's surface. The framework is in active development with regular feature additions, but the implemented systems are stable and production-grade.
Over 90 documentation files, including 21 architecture documents, 20+ usage guides, 9+ testing guides, and 13 extension guides. 18 interactive tutorials are available in both English and Spanish. Every system has a complete architecture document explaining design decisions, a usage guide with practical examples, a testing guide for verification, and an extension guide for customization. This wiki provides additional context on licensing, statistics, and common questions.
Through multiple layers. Engineering rules (covering UE5 discipline, delegate lifecycle safety, build system integrity, and more) are enforced during development. A clang-tidy configuration with 30 checks runs per-plugin. An audit doctrine covers 13 code quality rules that static analysis cannot detect. 22 panel audits verify editor UX quality. The simulation harness validates runtime behavior across all systems.
Each system provides a test utility with standardized test functions. The Test Dashboard panel runs all tests with color-coded results. The Simulation Harness injects realistic data across all 13 systems for integration testing and evaluation. Console commands provide runtime inspection. The System Observer panel provides live status for all subsystems during PIE sessions.
PGX is distributed through the Platano Games Academy at www.platanogames.es. Licensed users receive access to the private GitHub repository containing full source code, documentation, and tooling.
The Community tier is free for studios whose PGX-based products generate less than EUR 50,000 in annual gross revenue. This covers the vast majority of independent projects. Full details are available on the Licensing & Distribution wiki page.
This public repository provides comprehensive documentation, architecture descriptions, statistics, and this wiki. For source code evaluation, contact us through the academy website to arrange a time-limited review.
Your license includes perpetual access to the version available at the time of any interruption. The source code is yours to use and modify for your projects. PGX's architecture (star topology, data-driven, message-based) means you can maintain and extend the framework independently if needed.
GameplayTags provide hierarchical, data-driven, runtime-queryable identifiers that work across plugin boundaries without creating compile-time dependencies. PGX uses over 180 tags with a branch ownership model that prevents naming collisions. Tags can be extended by developers without modifying framework source code.
Data Assets integrate natively with the Unreal Editor -- they appear in the Content Browser, they have Details panel editing, they support asset references, they work with source control, and they can be versioned. Configuration files (INI, JSON, XML) require custom parsers, custom editors, and manual serialization. Data Assets are the UE5-native solution.
Direct references between systems create compile-time coupling that violates the star topology. If the Audio system needs to know when a level loads, it subscribes to a message -- it does not import the Loading system. This means either system can be removed without affecting the other. The message bus adds routing overhead measured in microseconds; the architectural benefit is measured in months of maintenance saved.
- 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