ALS Codes in Game Development: A Practical Animation Guide

ALS codes in game development: what they actually do

ALS codes are the configuration and behavior scripts that drive the Advanced Locomotion System, a community-maintained animation framework used in Unreal Engine to give third-person characters responsive, physically grounded movement. The codes themselves are not a single file. They are a coordinated set of animation blueprints, C++ component classes, state machine graphs, blend spaces, IK rigs, and data tables that together translate player input, velocity, ground slope, and capsule geometry into a pose that looks like a real body moving through a real space. For a programmer, designer, or technical animator evaluating whether to adopt the system, the codes represent the contract between raw input and rendered motion. They are also where most of the integration cost lives, because each project needs its own character skeleton, movement speeds, gait tables, and action set.

This article treats ALS codes as a working technical subject. It explains what the system is, how the state machine is structured, where the C++ components sit in the runtime, what data you must supply for a clean integration, and what trade-offs appear when you adapt the framework to a new project. The goal is to give an animation programmer, a technical artist, or a small studio lead enough context to decide whether to adopt, fork, or write their own alternative.

A few terms recur throughout the text. The “animation blueprint” is the asset that owns the state machine and the event graph. The “native component” is a C++ class attached to the character that exposes movement state, stance, and rotation mode as replicated variables. The “content layer” refers to the skeleton, retargeted sequences, IK rigs, and data tables the runtime evaluates. Once those three layers are clear, the codes read as a layered system rather than a pile of nodes.

Where ALS codes sit inside a real character pipeline

Most ALS integrations live in three runtime layers and one content layer. Understanding the boundaries between them is the first step in reading the code or planning a fork.

Input layer: Enhanced Input action bindings, axis mappings, and movement tags that describe what the player wants to do, such as start, sprint, crouch, aim, or roll.
Logic layer: an animation instance written as an animation blueprint with a state machine, sub-state machines, blend spaces, and event graphs that consume input and physics state.
Native layer: C++ component classes that expose movement states, replication hooks, and curve-driven properties the animation blueprint samples each frame.
Content layer: the skeleton, IK rigs, retargeted animation sequences, gait data tables, and pose search assets the runtime evaluates.

The codes that ship with the public repository are primarily native layer and logic layer. The content layer is project-specific and is the largest single source of integration work, even when the framework itself is used as-is. Teams that skip the content layer and rely on the demo mannequin end up shipping a character that feels borrowed, because the curves and the retargeted sequences carry the studio’s animation language.

The layered shape has a practical consequence: each layer can be replaced without rebuilding the others. A team that wants a different input model can keep the native component and the content layer untouched. A team that wants to retarget the framework to a quadruped can keep the logic layer’s state machine names and rewrite the underlying blend spaces. The discipline of keeping the layers separate is what makes the framework a useful starting point rather than a rigid demo.

The state machine at the heart of ALS codes

The animation blueprint’s main state machine is the most recognizable part of any ALS integration. The state names are stable across versions and projects, which makes them a useful entry point for new contributors.

Locomotion: the default grounded state, broken into sub-states for idle, walk, run, and sprint, with separate sub-state machines for movement in place and stop transitions.
Airborne: a self-contained state that handles jump, falling, and land, and exposes hooks for air control and double-jump modifiers.
Crouch: a layered sub-state that keeps locomotion logic but reduces capsule height and adjusts foot-IK targets.
Ragdoll: a state that blends from the animated pose into the physics asset and back, typically driven by a hit reaction or a death event.
Mantling and parkour: an extension state, often conditionally compiled, that drives vaulting, climbing, and ledge traversal.

Each top-level state owns a transition rule graph that reads variables from the native component. Velocity magnitude, direction, slope angle, and the player input vector are the usual primary inputs. The state machine itself rarely contains logic beyond a guard, an immediate-entry flag, and a time remaining value for blend-out. Reading the codes is therefore less about reading state machine graphs and more about reading the native component that writes the variables the graph consumes.

A common source of confusion is the difference between the top-level state and the locomotion sub-state machine. The top-level state decides whether the character is on the ground, in the air, in a ragdoll, or in a special action. The locomotion sub-state decides whether the character is walking, running, sprinting, or stopping, and it lives inside the grounded state. The two layers are deliberately separate so that a project can swap the lower layer for a swimming, climbing, or driving locomotion without rewriting the upper transitions.

Transition rules are written as small boolean expressions rather than full scripts, which keeps the graph readable but pushes the complexity upstream into the data the rules consume. A rule that compares the velocity magnitude against a threshold is cheap to read, but the threshold itself comes from a curve that a designer tuned. Debugging a transition that fires too early usually means reading the curve, not the graph.

What the C++ component actually exposes

The native component is where ALS codes feel like a real engine system rather than a graph-only experiment. Several properties and methods appear in nearly every fork of the framework, although the exact names depend on the project and the engine version.

Movement state: an enum value that describes how the character wants to move, including walk, run, sprint, and the directional modifiers that feed the gait blend space.
Stance: a separate flag that switches between standing and crouching and feeds the crouch sub-state machine and capsule sizing logic.
Rotation mode: a setting that controls how the character mesh aligns with the camera, with options for velocity direction, looking direction, and aiming.
Overlay state: a separate small state machine for upper-body actions such as aiming, reloading, climbing, or weapon inspection, so the lower body can keep blending.
Grounded and movement-mode events: booleans and event dispatchers that the gameplay code subscribes to in order to play sounds, spawn dust, or trigger gameplay consequences on landing or direction change.

For a programmer, the practical implication is that the C++ surface is intentionally small. The component is a data container that the animation blueprint reads every frame. Moving behavior into the component rather than the graph keeps the animation blueprint readable, but it also means that custom movement systems must learn to write to the same variables rather than reimplementing them in a separate graph. The convention is simple: if a value affects a transition rule, it belongs in the component.

The component also owns the small set of methods that gameplay code calls when it needs to request a state change. RequestSprint, RequestCrouch, RequestMantle, and RequestRagdoll are the kinds of names that show up across forks. They are thin wrappers that set the underlying enum, fire an event, and let the animation graph react on the next tick. Treating the component as the only writer of the movement state keeps the system predictable.

Replication flags are usually attached at this layer as well. The component is set to replicate, the movement state enum carries a rep notify, and the stance flag is marked as replicated with an owning-client condition so that cosmetic changes stay local. The framework does not mandate a particular net model, but the convention is that the server is the only writer of authoritative state and the owning client is allowed to predict cosmetic flags such as the lean magnitude.

Reading the locomotion graph like a programmer

The locomotion sub-state machine is dense, but its structure repeats. Once you understand one transition, the rest of the file becomes familiar.

Locomotion sub-state machine selects between idle, walk, run, and sprint based on the maximum walk speed curve and a sprint boolean.
Within each gait, a blend space interpolates forward, backward, and strafe poses based on a normalized direction value written by the C++ component.
Stop transitions are handled by a separate sub-state that reads the deceleration curve and a remaining time-to-stop value to blend the last stride into a planted idle.
Foot-IK targets are computed in the animation graph, not in the native component, and are fed by a forward-solve pass that samples the slope and the capsule trace.
Lean and stride-warp nodes adjust the root motion and pelvis offset to keep the feet planted on uneven ground without slipping the visual feet.

A useful reading technique is to disable parts of the graph and watch the result. Hiding the lean node reveals how much of the perceived quality comes from the additive lean rather than the underlying animation. Disabling foot-IK exposes how much of the grounded feel depends on the solver. This is faster than reading the C++ first, because the graph gives immediate visual feedback.

Another technique is to scrub the timeline while watching a single variable. Pick the normalized direction, the lean vector, or the foot-IK offset, and step through the frames during a sharp turn or a stop. The shape of the curve tells you whether the curve asset is the bottleneck or whether the underlying animation is. Designers often blame the animation when the curve is the real problem.

For teams new to Unreal animation graphs, the locomotion file is a reasonable place to learn the engine’s idioms. The state names, the blend space layout, and the IK target names are reused across many community projects. Once a programmer can read an ALS locomotion file, reading a custom animation blueprint for a different genre becomes a matter of mapping concepts rather than learning a new system.

The data tables and curves that tune the system

ALS codes include a set of data tables and curve assets that the runtime samples to convert speed and stance into blend parameters. The exact list varies by project, but the categories are consistent.

Data asset	Format	Purpose	Common pitfall
Movement model table	Data table keyed by gait	Holds walk, run, sprint speeds and acceleration values	Speed values that exceed the curve clamps cause blend snapping at the upper edge of the blend space
Gait curve	Float curve on the blend space	Maps a normalized speed value into the blend axis	A linear curve makes transitions feel mechanical; a non-linear curve requires a designer to retune each pose
Slope angle curve	Float curve in the native component	Adjusts stride length and foot height based on slope	Curve sampled in degrees must match the trace that produces the input, otherwise the system over- or under-corrects
Lean curve	Vector curve sampled by direction	Adds lateral and forward pelvis lean during sharp turns	Lean amplitude that ignores animation length causes the feet to slip at the end of a sharp turn
Foot-IK targets	Per-foot bones and offsets	Adjusts planted foot placement on uneven ground	Forgetting to disable foot-IK on root motion animations that already include planting causes double correction
Rotation rate curve	Float curve in the native component	Sets mesh rotation speed by stance and gait	A flat curve produces a robotic pivot; a curve tuned only for sprint breaks when the character slows down
Stop deceleration curve	Float curve on the stop transition	Maps remaining time to a blend weight for the stop pose	A curve that decays too quickly cuts the last stride short and produces a visible slide

A common mistake during integration is to ship the default data values unchanged. The defaults are calibrated for the demo mannequin, not for a production character. Re-tuning the curves is where most of the perceived quality gain comes from, and it is also where studio art direction is encoded. A studio that wants a heavier, more planted character can reduce the lean amplitude and lengthen the slope curve. A studio that wants a lighter, more responsive character can increase the lean and shorten the slope curve. The numbers are small, but the visual difference is large.

Curve assets are also where a single bad value cascades. A slope angle curve that samples in degrees while the trace returns radians will silently half-correct, and the character will clip the ground on every stair. The fastest way to find that class of bug is to log the sampled value at the same time the trace is performed, then compare the two logs frame by frame.

How replication interacts with the animation graph

For multiplayer projects, ALS codes include replication-aware properties that the server and clients must agree on. The native component is usually set to replicate, with the variables that drive the state machine marked as replicated using the appropriate condition. Three failure modes appear often in forks of the framework.

Stale velocity: a client receives an updated movement state but its locally simulated velocity still reflects the previous tick, so the blend space shows the wrong direction for one frame. The fix is to derive the blend axis from the replicated state rather than the local velocity.
Crouch desync: the server sets stance to crouch, but the client capsule has not yet resized, which causes a one-frame clip into geometry. The fix is to apply the capsule change on the same tick as the stance change, or to use a predicted capsule on the owning client.
Overlay flicker: a server-driven overlay such as aim or reload is set on a non-owning client one frame later than the locomotion state, which produces a visible mismatch between upper and lower body. The fix is to replicate overlay state through the same channel as the locomotion state, or to derive overlay flags from the same input that drives locomotion.

The name “ALS” is also the acronym for amyotrophic lateral sclerosis, a neurodegenerative disease. Some readers land on this article after searching for medical information about that condition. The framework’s name is an unfortunate collision, and the two topics share nothing in practice. If you came here looking for clinical context, the relevant disambiguation page is the broader ALS disambiguation entry on Wikipedia, which links to the medical article. The rest of this guide is strictly about the game animation framework.

The framework does not solve these problems for the project. It provides a clean place to add the project-specific fix because the state writes are centralized in the component. A team that decides to add a custom movement ability, such as wall run or slide, must follow the same pattern: write the new state into the component, expose it to the graph, and replicate the relevant subset.

Server authority is the default assumption. The state is set on the server, replicated to the clients, and consumed by the animation graph on every connection. Projects that use a rollback or a heavily predicted movement model need to add a predicted stance and a predicted capsule, and they need to reconcile the prediction against the authoritative state when it arrives. The framework does not ship that prediction layer, so it has to be added on top.

Bandwidth is rarely the bottleneck for a single character, but it matters for crowds. A project that wants many ALS-driven characters in a single scene should consider replicating only the high-level state and deriving the rest locally, or moving the cosmetic layer to a non-replicated component that the owning client animates independently. The same data table that drives the server can drive the local cosmetic layer without a network round trip.

Common customizations that real projects ship

Studios that adopt ALS rarely ship the default feature set. The framework is treated as a starting point, and the work is in the modifications. The following customizations appear in production code more often than the basic locomotion itself.

Mantling and parkour: a sub-state that reads a forward trace and an upward trace, and selects a vault, mantle, or climb animation based on the geometry.
Combat stances: an overlay state that holds the upper body in an aiming pose while the lower body keeps blending, with separate blend weights per weapon.
Swimming and traversal: a separate top-level state that replaces the foot-IK and lean logic with a buoyancy pass and water-line sampling.
Downed state: a low-health or revive state that blends the character into a crawl pose, with its own reduced-speed movement model.
First-person arms: a separate animation blueprint that consumes the same movement state but drives visible arms and weapon, while the third-person mesh uses the default graph.
Mounted riding: a state that disables root motion and uses a different lean and foot-IK model because the character is no longer the source of its own locomotion.
Stamina and exhaustion: a data-driven modifier that scales lean amplitude, sprint speed, and stop blend time when the character is tired, which the gameplay layer can write into the component.

Each of these requires the project to add new native variables, new transition rules, and new data assets. A useful rule of thumb is that any new state should be designed in the component first and then exposed to the graph. Building a complex new state entirely in the animation blueprint makes it hard to reuse and harder to debug across a team. It also tends to fragment the replication model, because a state written only in the graph cannot be cleanly replicated from the server.

Trade-offs you should know before adopting the framework

ALS is popular, but it is not free. The codes carry a learning curve and a maintenance cost that depend on the size of the team and the scope of the project.

Dimension	What the framework gives you	What it costs the project	When to consider an alternative
Animation quality	Strong default foot-IK, lean, and stride-warp behavior out of the box	Defaults are tuned to the demo skeleton, so retuning is required for production characters	If the project uses only two or three gaits and a fixed camera, the overhead may not pay back
Engine integration	Plays well with Enhanced Input, the new movement component, and modern animation tools	Some hooks assume specific engine version APIs, so upgrades require porting	If the project pins a very old engine version, the codes may not compile without significant porting
Multiplayer	Clear replication points because state lives in the C++ component	Custom movement abilities must be added with replication in mind from the start	If the project uses authoritative server movement with heavy rollback, a custom animation layer may be simpler
Code maintenance	Stable state names and a well-understood native surface	Forked versions diverge over time, so upgrades require merging	If the team does not have a programmer dedicated to animation, the fork may rot
Content cost	Reusable state machine and IK logic	Each character needs its own retargeted animations and gait data	If the project ships a single character, the retarget cost may dominate the gain
Debugging surface	On-screen debug values for state, stance, lean, and foot-IK targets	Debug widgets are convenient in development but must be stripped or guarded for shipping builds	If the project ships to certification, the debug layer needs its own cleanup pass

The framework is most useful when the project has at least one human-like character, a third-person camera, and a programmer or technical artist who can own the integration. It is least useful when the project is a 2D game, a fixed-camera adventure, or a first-person shooter where the visible body is rarely seen. The middle ground is large: many real projects have a mix of characters and cameras, and the framework works well in that mix as long as the team treats the C++ surface as a contract rather than a suggestion.

How to validate that the integration is working

Animation bugs are subtle, and a working integration is not the same as a polished one. A useful validation pass covers input, state, ground, and network as separate checks.

Input: print the movement state and the stance on the screen, and confirm that the values match the player’s input on every frame, including the frame after a state change.
State: scrub the timeline and confirm that the transitions fire at the expected time, that the blend-out is not cut off, and that no state remains active when the character has stopped moving.
Ground: walk across a slope, a stair, and a small obstacle, and confirm that the feet do not float or slip, that the pelvis does not clip, and that the lean does not accumulate across turns.
Network: in a listen server with one client, repeat the previous checks and confirm that the client matches the server within one frame, and that no transient pop is visible during a state change.
Stress: spawn a handful of characters with the same ALS setup and confirm that the visible differences come from gameplay intent, not from the animation layer desyncing between instances.

A useful habit is to commit the validation scenes to the project repository. They are easy to lose, and they pay for themselves the first time a refactor breaks the locomotion behavior in a way that is not visible in normal play. A validation scene is also a good place to keep the screen-printed debug values, because the next person who needs to debug the system will not have to reconstruct the print statements.

Quantitative checks help when subjective ones disagree. Recording a short clip of the same walk and stop across two characters, and comparing foot-IK error, lean magnitude, and stop blend time, gives the team a number to argue about. Subjective checks remain important, but a number anchors the conversation and makes regressions easier to catch in code review.

Integrating ALS codes with a custom character

Adding a new character to an existing ALS integration follows a predictable order. Skipping a step usually produces a bug that looks like an animation problem but is actually a data or setup problem.

Re-skin or retarget the skeleton to the new mesh, keeping the bone names and the virtual bones that the system expects.
Set the animation class to the ALS animation instance and the movement component to the ALS-aware character movement class, or to a subclass if the project has overrides.
Populate the movement model data table with the new gait speeds, and adjust the gait curve to match the new character’s stride length.
Re-author the foot-IK targets and re-tune the slope angle curve, because the new skeleton will have different bone lengths.
Re-record or re-bake any audio cues that are tied to the foot-IK events, because the timing of the planted foot will change with the new skeleton.
Run the validation pass on a test map with slopes, stairs, and a network listen server, and confirm that no step regressed.

The same order applies to adding a new movement ability, except that step three and step four become the new state’s own data and IK targets, and a fifth step is added: write the new state into the C++ component and replicate it. The order matters because the upstream steps feed the downstream steps, and reversing them usually produces a bug that is hard to localize.

Pitfalls that show up in production forks

Even when the integration is structurally correct, a small set of issues appears repeatedly in production forks. They are worth calling out because they are easy to miss in code review and easy to fix once identified.

Animation budget blowup: the foot-IK forward solve runs every frame on every character, including characters that are not on screen. Wrapping the solve in a visibility check keeps the cost in line with the visible count.
Curve drift after engine upgrades: curve assets are migrated silently, and a project that upgrades from one engine version to the next can find that a previously tuned curve has been resampled. Re-running the validation pass after every major engine upgrade catches this early.
Overlay state mismatches: a new overlay added in a fork is not added to the owning-client prediction path, so the owning client sees a one-frame delay on the upper body. The fix is to write the overlay into the same prediction block that writes the locomotion state.
Retargeted sequences that ignore the virtual bones: the framework expects certain virtual bones for foot-IK and pelvis offset, and a retarget that drops them silently disables the IK pass without raising an error. A small check at the start of integration catches this before the first bug report.

None of these issues are unique to ALS, but they are the ones that come up most often when a fork diverges from the upstream repository. Documenting the fixes inside the fork’s own README pays off the next time a new contributor joins the project.

When to fork the framework and when to write your own

The decision to fork, vendor, or replace the framework is a project-level call that depends on the team, the engine version, and the long-term roadmap. A few signals help with the decision.

Fork the framework when the project needs a working baseline on day one, has a programmer who can own the integration, and is willing to merge upstream changes at a regular cadence. The fork then becomes a living artifact that tracks the upstream while carrying the project’s customizations on a stable branch. Vendoring the framework is the same as forking for the purposes of this article: the only difference is whether the team plans to send changes back upstream.

Write a custom system when the project’s animation needs are narrow and well known, such as a 2D platformer with a single character, or when the project’s engine version is so old that the framework no longer compiles without major surgery. A custom system is also the right answer when the project needs an animation model that the framework cannot express, such as a procedurally generated creature whose gait is computed at runtime rather than authored in a blend space.

The middle path is to keep ALS as a reference and write a smaller, project-specific system that borrows the state machine shape without copying the asset graph. This is useful for studios that want the mental model without the maintenance dependency, and it is the path that several commercial studios have taken once they outgrow the public repository.

Reading list and next steps

For programmers who want to dig deeper, the most useful exercises are reading the native component from top to bottom, retargeting the demo mannequin to a stock Mixamo skeleton, and then disabling each graph node one at a time to watch the system degrade. The hands-on pass is faster than any documentation, and it surfaces the questions that documentation cannot answer.

For technical artists, the highest-leverage exercise is to retune the gait, lean, and slope curves against a target reference clip. The numbers are small, but they encode the studio’s animation language, and the result is immediately visible in motion.

For leads, the most useful exercise is to write a one-page decision record that states whether the project will adopt, fork, or replace the framework, and what signals would trigger a re-evaluation. The decision record is more useful than a code review, because it forces the team to be explicit about the cost of the dependency before the dependency becomes load-bearing.

Frequently asked questions

What are ALS codes in a game development context?

ALS codes are the configuration and behavior scripts that drive the Advanced Locomotion System, a community-maintained animation framework for Unreal Engine. They include C++ component classes, an animation blueprint with a state machine, blend spaces, IK rigs, and data tables that together convert player input and physics state into a grounded, physically plausible character pose. The codes are not a single file but a coordinated set of assets that the runtime evaluates each tick.

Do ALS codes run on the CPU or the GPU?

The animation evaluation itself runs on the CPU in Unreal Engine’s animation graph, with parts of the IK and pose search optionally running on worker threads. The C++ component runs on the game thread, but the variables it writes are sampled by the animation thread through the worker system. The framework does not use the GPU for animation, so a project that needs GPU-skinned crowds must add that as a separate optimization layer.

Can ALS codes be used without C++ knowledge?

Yes, for the default feature set. A technical artist who is comfortable with animation blueprints and data tables can integrate the default locomotion, crouch, and airborne behavior without writing C++. The native component is provided as a drop-in class, and the animation blueprint is exposed for editing. C++ becomes necessary when the project needs a new movement state, a new overlay, or a new replication hook, because those changes belong in the component.

Are ALS codes suitable for first-person games?

Partially. The third-person mesh and the locomotion state machine can be used as-is, but the first-person arms usually need a separate animation blueprint that consumes the same movement state. The framework does not provide a first-person rig, so the project must author the arms, the weapon sockets, and the camera attach points. A project whose visible body is rarely seen may not benefit from the full framework.

How do ALS codes handle multiplayer replication?

The native component is set to replicate, and the variables that drive the state machine are flagged as replicated with a condition that matches the project’s net model. The animation blueprint reads the replicated state on both server and client, so the same state machine produces the same pose on every connection. Projects that use predicted movement or rollback need to add a predicted capsule and a predicted stance, because the framework expects the server to be the source of truth for the state.

What is the most common mistake when integrating ALS codes?

Shipping the default data values unchanged. The defaults are tuned to the demo mannequin, so production characters look mechanical until the gait curve, the lean curve, and the slope curve are retuned. The second most common mistake is to add new states inside the animation blueprint instead of in the C++ component, which makes the new state hard to reuse and harder to replicate.

How do ALS codes compare to a custom locomotion system?

ALS provides a known-good state machine, a clean replication surface, and a community knowledge base, at the cost of integration overhead and a long-term maintenance dependency. A custom system gives full control and zero dependency, at the cost of the team’s time and the risk of reinventing well-understood problems. The right choice depends on the team size, the number of characters, and the engine version the project pins.

Can ALS codes be used in a non-Unreal project?

Not directly. The framework is built on Unreal Engine’s animation blueprint, C++ component model, and replication system, and porting it to another engine would mean rewriting the runtime. A team that wants similar behavior in a different engine should treat ALS as a reference design and reimplement the state machine, the data tables, and the native component in the target engine’s native systems.

How long does a clean ALS integration take?

For a small project with one human-like character and no multiplayer, a clean integration usually takes between one and three weeks for a single technical animator, including the retune pass. The first character is the slowest because the data curves must be re-authored. Additional characters usually take a few days each, mostly for retargeting and audio re-bake.

Are ALS codes a good fit for a vertical slice?

Yes, if the slice needs a polished third-person character. The framework is well suited to a short playable section because the default quality is high and the integration cost is concentrated in the first character. A vertical slice that uses only a fixed camera or a stylized rig may not benefit, and a smaller, hand-written system may be faster to ship.