Unreal Engine FPS Movement & Animation

The brief

A game studio needed FPS movement that could be played, not a character that only looked right in a still. Walk, stop, turn, aim - driven in Unreal Engine, in Blueprints the rest of the team could open.

The studio is under NDA. The work is the locomotion, not a title we can put on the page.

The challenge

A shooter dies when the body and the camera disagree. Animation that was authored for a cinematic will slide, pop, or ignore the stick.

• Locomotion that matches stick input instead of playing a loop and hoping
• Aim and move that can overlap without the skeleton fighting itself
• Blueprints another animator or designer can read, not a black-box C++ dump
• A preview in the editor that shows the same move the build will play

How we approached it

The skeleton and the movement component were treated as one system. Idle, walk, and the transitions were wired in Animation Blueprints, with the FPS movement logic sitting next to them so a change in stride is a change in how the pawn moves.

The editor shot is the check: the character in the viewport, the graph open, the pose that will actually leave the machine.

What we built

FPS movement and animation Blueprints in Unreal Engine: locomotion, the aim path, and the graphs the studio can keep editing. The photograph is the character in the Unreal viewport while those systems are live.

We do not publish the studio, the title, or a player count.

Results

The engagement is under NDA. We do not publish who commissioned it, or how the build performed against a milestone.

In use

A later weapon or a later walk cycle plugs into the same graphs. The movement does not have to be rebuilt because someone changed a mesh.