-
Notifications
You must be signed in to change notification settings - Fork 0
Tooling Overview
"If you can't inspect it from the editor, it doesn't exist."
Game frameworks love to ship systems. Save games, audio pipelines, loading screens, state machines — the list grows. But once those systems are running, you face a harder question: how do you know they're working?
Most UE5 projects solve this with UE_LOG, breakpoints, and a prayer. You scatter print statements across your codebase, rebuild, play, squint at the Output Log, and try to correlate timestamps with behavior. When something goes wrong in production, you add more logging, rebuild again, and hope you can reproduce the issue.
This is not engineering. This is archaeology.
PGX takes a different position: every runtime system must be inspectable, testable, and debuggable from the editor without writing a single line of code. Not as an afterthought. Not as a "nice to have." As a hard requirement baked into the Definition of Done for every system in the framework.
That philosophy produced six tool plugins, 23 editor panels, and a tooling surface area that treats developer experience with the same rigor as runtime performance.
PGX ships six dedicated tool plugins. Each one solves a specific category of developer pain.
What it solves: "I need to see what every PGX system is doing, right now, without leaving the editor."
Editor Tools is not a single panel — it's the infrastructure that makes all other tooling possible. It provides:
- The Hub Dashboard — A single landing page with 12 system cards. Each card shows the system's health status, version, and a one-click link to its inspector panel. Think of it as the framework's cockpit.
- 23 Inspector Panels — One per implemented system, plus cross-cutting tools. Each panel renders live data from its corresponding subsystem: current state, configuration, telemetry, history. No fake data. No placeholder text. If the subsystem is running, its inspector shows real numbers.
- The System Observer — A unified view of all active subsystems with health indicators, polling status, and live sparkline graphs. When something is degrading, you see it here first.
- The Test Dashboard — Run all system tests from one panel. Color-coded results, per-system breakdown, JSON export for CI integration.
- The Visual Showcase — An interactive catalog of every design token and atomic widget in the framework's visual construction system. If you're building editor tooling on top of PGX, this is your reference sheet.
The toolbar provides quick-access buttons for pinned inspectors, a tools submenu for everything else, and a safe editor restart command with PIE/compile guards.
What it solves: "I want to evaluate this framework before committing to a game project."
The Simulation Harness operates in two modes:
- Demo Mode populates 20 Data Asset entries across 7 categories with realistic sample data. Your Content Browser fills up with properly configured save domains, audio channels, loading contexts, and game flow states — all without you creating a single asset.
- Harness Mode performs deep injection across all 13 systems with approximately 160 API calls covering roughly 90% of each system's public surface. A live simulation ticker then exercises cross-system interactions: save slots cycle, game flow transitions fire, audio channels respond, loading screens appear and dismiss.
The result: every inspector panel in the framework shows meaningful, realistic data. You can evaluate PGX's capabilities, test your editor workflows, and demonstrate the framework to stakeholders — all without a game project.
What it solves: "I want my AI coding assistant to create assets and modify project structure inside the editor."
The Agent Bridge runs a REST API server inside the Unreal Editor with token-based authentication. It exposes 11 endpoints for asset lifecycle operations (create, duplicate, rename, delete), directory management, conversational chat, and multi-step plan tracking.
Every mutation operation runs inside a transaction — full undo/redo support through the editor's standard history. A Python connector script bridges the gap between CLI-based AI tools and the editor's HTTP interface.
What it solves: "I don't want to spend the first hour of a new project creating the same folder structure and Data Assets by hand."
Project Scaffold provides a three-phase UI:
- Select a template from four built-in options (or create your own).
- Configure variables, review the hierarchy tree with checkbox propagation, and validate everything before execution.
- Review the build plan and execute — all inside a single transaction that you can undo with Ctrl+Z.
One click to scaffold a full game project structure. One more click to undo it if you change your mind.
What it solves: "I have 90+ documentation files and I keep switching between the editor and a Markdown reader."
The Documentation Viewer renders Markdown natively using Slate widgets — no embedded web browser, no CEF dependency, no Chromium process eating your memory. Full-text search, bookmarks, live file watching (edit a doc file, see it update in the panel), and cross-reference navigation between documents.
What it solves: "I want to check my changelists, browse commit history, and manage branches without opening a terminal."
A dockable Slate panel that wraps Git operations: changelists, commit history, branch management, and clipboard integration for sharing commit links. Designed for the developer who lives inside the Unreal Editor and wants to minimize context switches.
This is not optional. The framework's Definition of Done includes a 13-item editor wiring checklist. Item 9: toolbar entry. Item 10: tools submenu. Item 11: hub card. Item 12: system observer snapshot. Item 13: inspector panel registration.
If a system ships without an inspector, it ships incomplete. Full stop.
Every button does something. Every KPI shows real data. Every table row comes from the actual subsystem state. If a feature is not implemented, its UI element does not appear. This rule — "Tooling Honesty" — is enforced as an engineering standard, not a suggestion.
All 23 panels share a common visual language: a design token system with 11 atomic widgets, governed by 10 non-negotiable UX Design Dogmas. The result is that switching between the Audio Inspector and the Save Inspector feels like switching tabs in the same application, not jumping between tools built by different teams.
A developer who has never written a line of PGX code can:
- Open the Hub Dashboard
- Click any system card
- See live data in the inspector
- Run tests from the Test Dashboard
- Populate sample data with the Simulation Harness
Zero code. Zero configuration. Zero knowledge of PGX internals required.
| Plugin | Panels | Purpose |
|---|---|---|
| Editor Tools | 23 (Hub + 13 Inspectors + Observer + Test Dashboard + Showcase + Others) | Runtime inspection, testing, visual reference |
| Simulation Harness | 1 | Demo population, deep injection, live simulation |
| Agent Bridge | 1 | AI-assisted asset operations, chat, plan tracking |
| Project Scaffold | 1 | Template-based project setup with validation |
| Documentation Viewer | 1 | Native Markdown rendering with search and bookmarks |
| Version Control | 1 | Git workflow integration |
Total: 6 plugins, 28 panels, 0 lines of game code required to use them.
The tooling layer is strictly editor-only. No tool plugin ships in a packaged build. No tool adds runtime overhead. The separation is enforced at the module level: tool plugins live in editor-only modules with no runtime dependencies.
But the connection to runtime is deliberate. Each inspector panel reads from its corresponding subsystem's public API. The System Observer polls all active subsystems on a configurable interval. The Test Dashboard invokes each system's standardized test utility. The Simulation Harness calls the same public API that your game code would call.
This means the tools test the same code paths your players will exercise. There is no "test mode" that behaves differently from production. What you see in the inspector is what your players get.
- Solo developers get a full observability stack without writing any tooling themselves.
- Teams get a shared visual language for system inspection — everyone reads the same dashboard.
- Technical leads get a Definition of Done that prevents systems from shipping without visibility.
- Evaluators get the Simulation Harness to see everything working before writing a single line of game code.
- AI-assisted workflows get the Agent Bridge to automate repetitive asset operations.
The tooling layer continues to evolve alongside the runtime systems. Planned additions include an Execution Waterfall view for event debugging, a Pragmatism Map for handler coverage visualization, and deeper integration between the Agent Bridge and the Project Scaffold for fully automated project setup.
The guiding principle remains unchanged: if a system exists in PGX, the developer must be able to inspect it, test it, and debug it — without touching code, without reading documentation, and without leaving the editor.
- 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