Architecture¶

GASPALS is built from three layers:

1. The pawn owns movement, input and the meshes, and exposes its state through an interface.
2. System components (camera, cover, equipment, first person, overlay, ragdoll, traversal) sit on the pawn. Each one is self-contained: it reads what it needs from the pawn and its own settings, and handles its own input actions.
3. Anim Blueprints pull the pawn's state every frame and turn it into a pose, with layers linked in by the systems.

flowchart TB
    subgraph Framework
        GM[GM_Sandbox<br>pawn and character lists] --- PC[PC_Sandbox<br>pawn switch, teleport]
    end
    subgraph PawnBox[Pawn: SandboxCharacter_Mover / _CMC]
        Move[Movement<br>CharacterMover or CMC]
        Meshes[UEFN mesh, first-person logic mesh,<br>VisualOverride child actor]
        Systems[System components<br>Camera, Cover, Equipment, FirstPerson,<br>Overlay, Traversal, Ragdoll, VisualOverride]
        Iface[BPI_SandboxCharacter_Pawn<br>Get_PropertiesForAnimation / Camera / Traversal]
    end
    ABP[Character Anim Blueprint] -->|pull every frame| Iface
    Director[Camera director] -->|pull every frame| Iface
    Systems -->|link anim layers,<br>attach items| ABP
    Systems -->|read state| Iface
    GM -->|spawns| PawnBox

The pawns¶

The pawns offer the same features; they differ in how movement, prediction and replication work. See Mover and CMC pawns.

Each pawn has:

• a UEFN mannequin mesh running the character Anim Blueprint (the animation source for every character);
• a hidden first-person logic mesh (SkeletalMesh_FP) running the first-person Anim Blueprint;
• a VisualOverride Child Actor component for retargeted characters;
• a Gameplay Camera component (and a legacy spring arm camera used only when Gameplay Cameras are turned off);
• a Motion Warping component for traversal;
• the system components below.

System components¶

Components that react to input bind their own input actions (AC_CameraSystem handles the perspective keys, AC_EquipmentSystem the equipment menu, and so on), so adding a component adds its controls. They only receive input when the pawn is player controlled.

Initialization¶

Systems are initialized by the pawn, through the interface BPI_ModularSystems and its event InitializeModularSystems. The pawn calls it at the end of BeginPlay, and AC_VisualOverrideManager calls it again whenever the visible character changes, because the meshes change.

sequenceDiagram
    participant P as Pawn
    participant FP as AC_FirstPersonRendering
    participant O as AC_OverlaySystem
    participant E as AC_EquipmentSystem
    participant C as AC_CameraSystem
    participant R as AC_RagdollSystem (CMC)
    participant Cv as AC_CoverSystem
    P->>FP: UpdateFirstPersonVisuals (connect logic mesh, build FP meshes)
    P->>O: InitializeSystem(mesh)
    P->>E: InitializeSystem(pawn, meshes, visual meshes)
    P->>C: InitializeSystem(pawn, visual meshes, camera)
    P->>R: InitializeSystem(pawn, mesh, capsule)
    P->>FP: InitializePrimitives
    P->>Cv: InitializeSystem(pawn)
    P->>Cv: bind OnCoverVaultReady → traversal

Because the event can run several times, every InitializeSystem is written to be safe to call again. Follow the same rule in your own systems.

When a player possesses the pawn, a client RPC runs SetupCamera (activates the Gameplay Camera for the player controller) and SetupInput (adds IMC_Sandbox).

Per-frame data flow¶

Data is pulled. The pawn implements BPI_SandboxCharacter_Pawn with getters that assemble its state into structs:

The Anim Blueprints copy the struct on the game thread (Update_PropertiesFromCharacter) and compute the pose on a worker thread.

Writes go the other way through layer linking: the overlay and equipment systems call LinkAnimClassLayers on the meshes to swap the Anim Blueprints that implement the overlay layers (ALI_OverlayPose, ALI_OverlayBody, ALI_OverlayFirstPerson).

Input to movement¶

Game framework¶

There is no global game mode in the project settings: each level sets it in its World Settings.

Where to extend¶