RPG revision: research, decisions and acceptance

Status: research complete; implementation in progress. The previous passing functional tests did not make the RPG presentation successful. This revision addresses the owner's rejected camera, HUD hierarchy and window treatment. The RTS stays separate.

References examined

Primary source	What it actually demonstrates	UIForge decision
WoW: updated HUD, including the published Modern Preset image	Player and target information grouped near the action bar, a clear central world view, small peripheral controls, and recognizable frame/ornament treatment. The article describes independent component configuration.	Compact combat cluster, restrained bronze/obsidian frame identity, no permanent boxed explanation under every icon. Independently authored geometry and artwork; no Blizzard asset copying.
FFXIV: Navigating the Game Screen, including the annotated PC HUD image	Party, objectives, target, status and casting have distinct roles. Many peripheral widgets use little opaque backing. Party targeting is interactive.	Small party rows, text-led objective tracker, transient cast/status information, secondary detail in tooltips/windows. No fake network chat to fill empty space.
FFXIV: HUD customization and HUD guide	Size/layout/display settings and separating target health, cast and status support different information priorities.	Continue using public layout profiles, entry classes and theme overrides; density should not require editing plugin C++. Do not claim an in-game drag editor unless implemented/tested.
GW2: action camera	Direct character/camera control, clear targeting states and automatic camera release for dialogs/panels.	RPG camera orbit/zoom and camera-relative movement, menu ownership wins over look input, gamepad look uses meaningful dead zones. Right mouse looks rather than issuing RTS movement orders.
Unreal: Spring Arms	Engine camera obstruction handling and configurable camera attachment.	An example-only Blueprint-editable spring-arm/camera rig; no camera system in the UI core.

These references support interaction/hierarchy choices, not a claim that one layout is universally best or that UIForge matches their art budgets. The historical published WoW/FFXIV images are references to specific layouts, not claims about every current patch. Reference pixels are viewed remotely and are not shipped.

Current implementation audit

• RPG uses a fixed camera approximately1,270cm from the character with650cm elevation. It cannot orbit. The diagonal view, ground selection rings and right-click world orders make it read as RTS.
• Player/target/party/objectives/cast all reuse boxed readouts. Their equal visual weight obscures what matters now. Minimap occupies192×204Slate units; actions have persistent captions below56px icons. Party rows retain large opaque backgrounds.
• Main/pause and journal share plain rectangular frames with little internal hierarchy. Journal is one vertical text stack, rather than a composed information window.
• Existing strengths: CommonUI stacks/focus/back/modal ownership, staged settings, remapped prompts, data/entry bindings, layout profiles, actual encounter actions and the independently reproduced Sakura center-origin cooldown. Preserve these.

Focused release matrix

Area	Retain	Change	Cost / proof
Third-person experience	Existing encounter and measured v022 actions	Orbit/zoom camera near character, camera-relative movement, look release on menu/popup; remove RPG right-click orders	Medium; real look/move/zoom, obstacle and panel ownership checks; verify RTS unchanged
Combat HUD	Models, input prompts, cooldown material, layout profiles	Compact action strip/vitals, quieter party/objectives, target/cast hierarchy, no player selection ring	Medium; 720p/1080p/ultrawide, enlarged text, tooltip and focus review
Styling	Theme/font/audio configuration	Original etched frame skins, inset surfaces, dividers and compact entries. Shared public surface-style keys instead of per-variation C++ subclasses	Low/medium; swap theme/style in Blueprint and inspect actual result
Windows	Functional settings, journal, confirmations and save/return	Consistent header/content/footer, section labels, close/back affordances, responsive reading width and spacing	Medium; complete playable menu/settings/journal/modal flow
Demonstration	Actual party/ability/quest data	Present the same working adapter more clearly	Low; repeated attack/cast/quest/party checks; no inventory, backend chat or new MMO simulation

Acceptance gates

1. The default RPG is immediately recognizable as third-person: visible character, usable forward view, orbit/zoom, camera-relative control. RTS retains its strategy camera/orders.
2. At1920×1080 normal scale, the central play region remains free of persistent opaque HUD; essential information fits a compact lower cluster and edge docks. Measure actual widget bounds; do not sacrifice text readability to hit an arbitrary percentage.
3. Every revised screen is a saved editable Widget Blueprint built from public UIForge controls. Theme surface styles, fonts, entry classes, positions and animation choices can be changed without plugin source edits.
4. Menus/settings/journal/dialogs have coherent detail and spacing, not oversized empty rectangles. Actions work and values change the actual example.
5. Preserve Sakura tint, v022 contact/grip/pose behavior, existing saves, core independence and the RTS. Build/cook/run on5.8.3, compile saved Blueprints, inspect real interactions/resolutions and record failures honestly. Physical controller/touch remain user-deferred; software events are labeled separately.

Implementation sequence: camera/input vertical slice → RPG-only theme/entries/HUD → full window pass → runtime/visual iteration → documentation and current packaged candidate. Use the existing bounded build hosts; preserve the before-rpg backup and prior signed receipts. Do not claim completion from this document.

Owner correction: combat hierarchy and binding regression

The owner rejected the lower target/player pairing. The new default places a dedicated target name, health and numbers at the top center. This is a product decision informed by the FFXIV target-bar documentation, not a claim that every MMO uses the same placement. The bottom center contains the player resource frame and six usable action slots. Avoid ornament repeating on every small readout.

The audit found two concrete regressions in the first RPG rework: its HUD CDO omitted the earlier mapping-aware Shortcuts array, and its health-bar authoring helper did not override Forge Progress's SquarePerimeter default to Linear. Right-mouse capture also needs an explicit look policy. Current verification must cover the actual InputKeySelector UI, applied gameplay behavior, prompt changes, cancel/conflict handling and reloading saved bindings. Historical RTS rebinding evidence cannot substitute for these RPG checks.