Adopt modules deliberately
GGS is split into modules. Choose the capability you need, then add the corresponding module dependency and project assets. Do not put every system into the character class or assume the plugin supplies a complete character, game mode, or finished UI.
Keep data and policy ownership clear
- Your project owns GES tags, surface mappings, and effect libraries. Supply context from callers instead of duplicating presentation rules across actors.
- Your project defines camera modes. Use the mode stack and blend extension points; do not treat a fixed camera behavior as a plugin template.
- Your project owns the root UI layout, style, input routing, and feature content. Settings UI is a separate adapter.
- Decide storage scope for each setting: use a Local Accessor for machine-level settings and a Shared Accessor for player preferences. Define preview and rollback behavior for Dynamic values.
- The project provides interaction queries; the component coordinates candidates and state. Design server authority separately from client prompts.
- Validate ragdoll recovery together with character movement replication, physics settings, and the animation state machine.
Preserve stable interfaces
Use Public APIs and stable SettingIds / Gameplay Tags. Declare the correct module dependency in Build.cs for cross-module references and avoid including another module's Private headers. Give provider removal, UI extension removal, and runtime component lifetimes explicit cleanup paths.
Validation sequence
First build the host project with UE 5.8+, then run minimal editor and multiplayer checks by module. Verify registry state, Apply/Cancel, platform restrictions, UI back navigation, Smart Object state, and remote ragdoll presentation; enabling the plugin alone does not complete integration.