GMS Feature List

What You Can Build

Generic Movement System helps you turn character locomotion into reusable architecture, but the product should be understood as framework code plus companion content. A component-driven movement control layer and a data-driven animation/locomotion layer work around one Gameplay Tag vocabulary, while the companion project shows how those ideas are assembled into a playable movement system with real characters, animations, Movement Sets, and demo maps.

Gameplay Patterns You Can Build

• Multiple characters sharing one locomotion architecture while using different speed, stance, overlay, and animation data
• Walk, jog, sprint, aim, weapon, carried-object, injured, or project-specific stance changes
• Animation-pack and skeleton variants that reuse the same locomotion structure with their own data
• Humanoid, quadruped, animal, horse, and dragon examples used as reference implementations for your own content
• Third-person action, shooter, RPG, adventure, or melee locomotion foundations
• Multiplayer presentation where remote animation receives meaningful movement state
• Character Movement based traversal, such as zipline or custom project movement modes

Integration, Profiles, and State Semantics

• Integrate through the character architecture you already own. GMS is built around a movement system component and an animation-layer workflow, so the framework can sit beside your project character instead of forcing a new parent class.
• Create a complete profile for each character style. Movement Definitions select Movement Sets through Gameplay Tags, so different characters, stances, or loadouts can own their control, backend, overlay, and project-specific data.
• Switch setup at runtime. Gameplay logic can change Movement Definition, Movement Set, movement state, rotation mode, locomotion mode, and overlay mode through the shared GMS protocol.
• Separate intent from reached result. Desired movement state and current movement state are distinct, giving animation a stable result to read during acceleration, deceleration, starts, and stops.
• Choose facing as a gameplay policy. Rotation modes support movement-direction and view-direction behavior for exploration, aiming, lock-on, or project-specific states.
• Apply temporary speed changes cleanly. Buffs, slows, surfaces, or AI catch-up can override, multiply, or add to active speed without damaging the base profile.
• Drive presentation from Gameplay Tags. Gameplay state can drive animation and pose changes through tags, reducing conditional logic scattered across character and animation graphs.

Animation Layers and Presentation Composition

• Split locomotion responsibility into focused layers. The main animation instance coordinates grounded locomotion, overlays, view, additive motion, and skeletal controls instead of forcing one graph to own the entire character.
• Layer presentation over base movement. Pose overlays, sequence overlays, and parallel overlay stacks support weapon poses, carried items, injuries, or project-specific presentation.
• Keep skeleton-specific setup in data. Animation graph settings store the layer settings and bone references needed by supplied animation nodes, so different skeletons and animation libraries can be configured without rewriting the framework.
• Let graph nodes read gameplay meaning. Gameplay Tag blend, curve blend, layered-bone blend, orientation warping, stride warping, and Chooser / Pose Search context help animation select from semantic state and authored data.

Companion Project Content

• Study a working GMS content layout. The companion project includes core animation blueprint templates, animation layer interfaces, overlay layers, animation modifiers, animation notifies, debug/editor helpers, and MovementSystem settings content.
• Start from concrete character examples. Demo content includes humanoid examples, animal Movement Sets, horse and dragon examples, GMS demo levels, cameras, UI widgets, and custom overlay examples.
• Inspect gameplay-driven state changes. The GMS demo content includes GAS-oriented basic character actions, state management, triggers, and gameplay effects for states such as carrying, hand-tied, injured, and overlay switching.
• Use optional integrations as examples, not hidden requirements. Essential Animation Movement Sets and some pack-specific integrations are tracked separately from the default companion content.

Multiplayer and Gameplay Tag Semantics

• Replicate the context animation needs. Movement Definition, Movement Set, locomotion mode, overlay mode, Gameplay Tags, and view rotation are synchronized for remote presentation.
• Carry Character Movement decisions across the network. On the Character Movement path, requested gait, requested rotation mode, and movement intent are replicated.
• Work naturally with Gameplay Tag driven projects. GMS prefers Gameplay Tags over closed enum-style project state, making it friendly to projects that already use GAS or other tag-producing gameplay systems.

Dual Backend Architecture and Reuse

• Give custom movement modes semantic meaning. Map custom mode ids to Locomotion Mode tags so animation can understand climb, zipline, or project-specific traversal without depending on raw backend values.
• Start from a readable traversal reference. The plugin includes Character Movement zipline implementation pieces that demonstrate the extension path.
• Share one animation-facing protocol across backends. GMS abstracts over CMC and Mover so animation can consume the GMS protocol without caring which backend the Pawn uses.
• Use CMC as the current stable path. The Character Movement Component path is stable; Mover support remains experimental and can be explored in the companion project's _Mover content.
• Reuse animation blueprint templates. Most core animation blueprints in the companion project are Animation Blueprint Templates and are not tied to one skeleton; skeleton-control and Montage-slot graphs use the standard UE5 skeleton where that setup is required.

Boundaries to Design Around

• Do not evaluate GMS as a standalone code-only movement generator; practical adoption depends on studying and adapting the companion project content.
• The Fab plugin upload contains code modules, while characters, animations, skeleton-specific setup, input assets, Blueprint examples, and demo maps are provided through the companion project after purchase verification.
• The current recommended production path is Character Movement Component; Mover-related types remain experimental under the current source baseline.
• GMS is not aimed at absolute beginners; you should be comfortable reading documentation and working with Blueprint, animation assets, and Gameplay Tags.
• GMS organizes locomotion architecture, but your project still decides animation quality, control feel, input setup, and final Gameplay Tag vocabulary.