-
Notifications
You must be signed in to change notification settings - Fork 0
Editor Tools
"The difference between a framework and a professional framework is what happens when you open the editor."
You have 13 runtime systems. Save games, audio pipelines, game flow state machines, loading screens, data registries, shader precaching, platform profiles. Each one has its own configuration, its own state, its own failure modes.
Now ask yourself: when something goes wrong at runtime, how do you diagnose it?
In most UE5 projects, the answer is some combination of breakpoints, UE_LOG, and tribal knowledge. The Audio system is dropping sounds? Set a breakpoint in the audio subsystem. The save system is writing corrupted data? Add logging to every write path. The game flow state machine is stuck? Hope the person who wrote it documented the transitions.
This approach scales linearly with system count and exponentially with system interactions. By the time you have 13 systems talking to each other through a message bus, the number of possible failure modes exceeds what any developer can hold in their head.
PGX Editor Tools solves this by making every system visually inspectable from the editor in real time. Not as an optional addon. As a mandatory deliverable for every system that ships.
Before we talk about individual panels, we need to talk about why all 25 of them look and feel the same. That consistency is not accidental — it's the result of a design token system that serves as the single source of truth for every visual decision in the framework's editor UI.
A single header file defines every color, font, spacing value, border radius, and motion timing used across all PGX editor panels. There are no hardcoded hex values scattered across 25 different files. There are no "magic numbers" for padding. Every visual property traces back to a named token.
The token categories:
- Surface colors: Base, Raised, Elevated, Overlay — the background hierarchy
- Text colors: Primary, Secondary, Muted, OnColor — for contrast ratios
- Semantic colors: Good, Warning, Error, Info, Neutral — for status communication
- System colors: One per subsystem (Save is green, Audio is orange, PSO is cyan, etc.)
- Spacing scale: XS (2px), SM (4px), MD (8px), LG (12px), XL (16px), XXL (24px) — base-4 rhythm
- Typography: 10 font tokens from PanelTitle (Bold 13pt) down to KPILabel (Regular 8pt)
- Border and radius: Consistent edge treatment across all containers
When a new panel is built, the developer picks from this vocabulary. When the design system evolves, tokens change in one place and every panel updates.
On top of the token system, PGX provides 11 purpose-built Slate widgets that encapsulate recurring UI patterns. These are not generic components — they are PGX-specific building blocks designed for subsystem inspection panels.
| Widget | Purpose | Instances |
|---|---|---|
| Accent Bar | 2px colored stripe at the top of every panel — visual identity | 22+ |
| Panel Header | Title + optional subtitle + density toggle + action buttons | 21 |
| Section Divider | Background band with accent stripe, title, and right-content slot | 75 |
| KPI Chip | Single metric card: accent bar + icon + label + large value | 29 |
| Status Badge | Colored pill with text — for states, categories, filters | 6 |
| Footer Bar | Sticky bottom bar with status text and optional action buttons | 19 |
| Empty State | Centered message + icon for "nothing to show" states | 1+ |
| Data Table Header | Column headers with fixed widths for tabular data | * |
| Health Dot | Tiny colored circle for inline health indicators | * |
| Budget Bar | Progress bar with thresholds for platform budget visualization | * |
| Table Row | Standardized row widget with system-color accent | * |
167 total widget instances are deployed across 22 panels. The framework migrated every panel through a five-phase process — infrastructure, token adoption, panel migration (450+ replacements across 27 panels), widget adoption (151 instances in the first pass), and gap closure.
These are non-negotiable rules that govern every editor panel in the framework. They emerged from a formal audit process (four independent reviewers evaluated all 22 panels and scored them on a 20-point UX scale) and were codified as permanent design law.
D1 — Vertical Oxygen: Section dividers carry 24px top padding. Content blocks never touch without explicit spacing. If it looks cramped, it is cramped.
D2 — Horizontal Proximity: Related data must be visually grouped. If the user's eye must travel more than 400 horizontal pixels to connect related information, the layout is broken. Action buttons live next to their content, not pushed to the opposite edge.
D3 — Section Headers: All section headers use the framework's section divider widget with a background band, optional accent stripe in the system's color, bold title, and a right-content slot for inline filter controls.
D4 — KPI Cards: Top accent bar (2px, full width). Optional icon with standard gap. Card padding follows the spacing scale. Label in 8pt regular, value in 18pt bold. No bottom decorations, no gradients.
D5 — Accent Identity: Every panel opens with a 2px accent bar in its system color. Section dividers carry the same color. KPI chips use semantic colors. The accent bar is always the first element — top of the panel, not bottom.
D6 — Typography Hierarchy: 10 font tokens, strictly assigned. Panel titles at 13pt bold. Section headers at 11pt bold. Body text at 10pt regular. Monospace for IDs and timestamps. KPI values at 18pt bold. No exceptions, no ad-hoc font sizes.
D7 — Spacing Scale: Base-4px rhythm. XS (2px) for micro-gaps. SM (4px) for tight gaps. MD (8px) for standard. LG (12px) for content. XL (16px) for section internals. XXL (24px) for section separation. All spacing multiplied by a density factor.
D8 — Density Awareness: Every panel supports a density toggle (Default 1.0x, Compact 0.75x). Row heights adjust. Font sizes adjust. The toggle lives in the panel header, not buried in a settings menu.
D9 — Theme Mechanism: Theme-sensitive values use lambda attributes, not static colors. Two minimum themes: Obsidian (dark, default) and ValidationLight (bright). Themes only affect surface and text base colors — semantic colors, spacing, and fonts are theme-invariant.
D10 — Filter Integration: Filter and range buttons live inside the section header's right-content slot. Never create a separate row just for filters. Active filters use the Info semantic color. All filters trigger immediate content rebuild.
The Hub is the framework's landing page. Twelve system cards arranged in a grid, each showing:
- System name and version
- Health status indicator (using Health Dot widgets)
- One-click navigation to the system's inspector panel
- Tutorial badges for interactive walkthroughs
The Hub is not a status page — it is a navigation surface. It answers one question: "Which system do I need to look at?" and gets you there in one click.
Twelve cards currently: Save, GameFlow, PSO, LevelFlow, Loading, Audio, Log, Profile, Data Registry, Construction, Message, EventHandler — each with its system color accent, matching the color conventions used across the entire framework.
Where the Hub shows you system identity, the Observer shows you system health.
The System Observer is a unified monitoring panel that polls all active subsystems on a configurable interval and renders:
- Subsystem list with health status indicators
- Live sparkline graphs showing per-system metrics over time (transition rates, message throughput, cache utilization)
- Global aggregation graph combining all system health into a single trend line
- Health dots for quick visual scanning: green (healthy), yellow (degraded), red (critical)
The Observer uses polling (not push) to avoid adding delegate overhead to runtime subsystems. The polling interval is configurable and defaults to a rate that provides useful visibility without measurable editor overhead.
When a subsystem is unavailable (e.g., no active PIE session), the Observer shows a clear empty state explaining why data is missing — not a blank panel, not a loading spinner, not stale data from the last session.
Each of the 13 implemented systems has a dedicated inspector panel. While the specifics vary by system, all inspectors follow the same structure:
- Accent bar in the system's color (top of panel)
- Panel header with title, version, density toggle
- KPI section with 2-4 key metrics
- Content sections with section dividers, data tables, and inline controls
- Footer bar with status text and optional quick actions
- Save Inspector: Active slots, key-value counts, checksum status, domain breakdown
- GameFlow Inspector: Current state, transition history with sparkline, channel status with health dots
- PSO Inspector: Precache progress, warm-up status, context list, shader budget
- Loading Inspector: Active loading screens, PSO coordination status, progress graph
- LevelFlow Inspector: Current level, streaming state, sublevel status, transition history
- Audio Inspector: Active sounds, channel mix levels, backend status, dialogue queue
- Log Inspector: Polymorphic domain-filtered log viewer with 13 domain renderers, live/manual refresh
- Profile Inspector: Platform capabilities, active budgets, platform health dashboard
- Data Registry Inspector: Entry count, category breakdown, cache stats, lookup telemetry
- Construction Inspector: Slot configuration, class source mode, validation status
- Message Inspector: Broadcast history, active listeners, channel activity, message throughput
- EventHandler Inspector: Handler browser, execution telemetry, blackbox recorder, cache status
- MGOS Inspector: GC metrics, mode status, profile engine state, memory graphs
Every inspector reads from the subsystem's live state. There are no hardcoded test values. If the subsystem has no data, the inspector shows an empty state widget with a clear message about what needs to happen for data to appear.
A single panel to run all system tests and view results.
- Run All: Executes standardized test utilities across all 13 systems
- Per-system results: Color-coded by system color, expandable for detail
- Pass/Fail KPIs: Total counts with accent-colored chips
- JSON Export: One-click export for CI pipeline integration
- Harness Mode toggle: Switch between testing with real project data and injected test data
The Test Dashboard does not implement its own test logic. Each system provides a standardized test utility with 7+ test functions. The dashboard invokes them, collects results, and presents them uniformly. This means test coverage grows automatically as new systems are added.
An interactive reference panel for the framework's design system. Every token, every widget, every color, every font — rendered live in a scrollable catalog.
The Showcase serves two audiences:
- Framework users building custom editor panels on top of PGX can see exactly what tokens and widgets are available.
- Framework developers extending PGX can verify that new panels match the existing visual language.
The Showcase is not documentation — it is a live rendering of the actual tokens and widgets from the same header that all other panels use.
The PGX toolbar integrates into UE5's main toolbar with:
- Quick Access buttons: Up to 25 pinnable shortcuts for frequently used inspector panels. Pin preferences persist in editor settings.
- Tools submenu: Complete list of all available inspector panels and tool windows.
- Safe Restart: A guarded editor restart command (Ctrl+Shift+R) that checks for active PIE sessions and unsaved packages before proceeding.
The toolbar is the framework's primary navigation surface for developers who prefer keyboard-driven workflows over the Hub dashboard.
PGX extends the Content Browser's right-click "Add New" menu with organized categories for all framework Data Assets and Blueprint classes.
- 58+ Data Asset entries organized by system
- 20+ Blueprint class entries for extendable components
- System-specific icons for visual identification in the asset browser
- Color-coded type actions matching each system's accent color
When you right-click in the Content Browser, PGX's assets appear in their own section with proper categorization. Creating a new Save Domain Configuration or Audio Channel Profile is the same gesture as creating any other UE5 asset.
A dedicated settings page under Project Settings for PGX editor preferences:
- Inspector panel pinning (which panels appear as Quick Access buttons)
- Default density mode
- Auto-refresh intervals
- Panel-specific configuration
Settings are read at editor startup and persisted between sessions. No recompilation required.
Every system in PGX must complete a 13-item editor wiring checklist before it can be marked as done:
- SVG icon in the resources directory
- Build dependencies registered
- Icon registered in the style system (two sizes)
- Pin setting added for inspector panels
- Asset factories declared and implemented
- Registry entries added (both Data Asset and Blueprint categories)
- Type actions registered with system color
- Content Browser icon mapping added
- Quick Access pin entry added
- Tools submenu entry added
- Hub dashboard card added
- System Observer snapshot added
- Inspector tab spawner registered
This checklist exists because editor wiring was consistently the most-forgotten part of system implementation. It is now enforced as a blocking requirement — you cannot mark a system as complete without all 13 items verified.
The editor tooling was not built once and shipped. It went through a formal multi-perspective audit:
- Four independent reviewers (different perspectives) audited all 22 panels
- Consolidated findings: 12 systemic issues, 8 critical, 42 major, 28 minor, 15 suggestions
- Average UX score before remediation: 11.9 out of 20
- 9 implementation plans executed across all panels
- Average UX score after remediation: estimated 16.5+ out of 20
The audit process itself became a reusable pattern — documented, reproducible, and applicable to future panels.
- 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