Roblox Running Animation

Setting Up Custom Running Animations in Roblox Studio

You open your project, put in a custom run animation, and immediately notice the character's feet are sliding across the floor like they're on ice. This happens because the animation rig's root translation doesn't match what the animation expects. The fix is usually in the Animation Editor's graph view, not in the properties panel. You need to scrub through the keys on the hip bone and ensure the root moves forward at roughly 16 studs per second, which is the default walk speed multiplied by the run multiplier. A Roblox Running Animation is just an Animation object that gets assigned to a Humanoid's WalkSpeed-triggered state. By default, every character plays a built-in run cycle at priority 5. When you drop a custom animation into the rig, it replaces that default. The system doesn't care what the animation looks like; it only cares about the priority level and whether the animation is actually playing on the right slots. Most people miss this: if your custom animation is set to priority 4 instead of 5, the default run will never stop playing over the top of yours, and you end up with two overlapping motion cycles that look terrible. I ran into this exact issue on a combat-heavy project last year. I had a sleek custom run imported from Mixamo, set the priority correctly, and everything looked fine in the rig viewport. The moment I played in-game, the character's legs were doing a fast walk while the upper body was sprinting. The problem was that Mixamo's default output includes a separate idle and walk cycle baked into the same animation file, and the Humanoid was sampling the wrong sub-animation depending on the state machine state. I fixed it by separating the run into its own clean file, removing all keyframes outside the run cycle, and re-exporting. Takes about twenty minutes and saves you hours of debugging.

Where to Get Custom Running Animations

Most creators pull from places like Roblox's own library under the Animation tab, grab free rigs from the Creator Marketplace, or build their own in Blender and export as .fbx with the Roblox rig pre-rigged. The Animation Editor in Studio handles .mot3 files natively, but if you're importing from Blender, you need to make sure the rig matches the R15 or R6 skeleton exactly. Any mismatch in bone names and the animation disappears on import without warning. Studio doesn't throw errors for bone mismatches, which is probably the most frustrating thing about this whole workflow. If you need a quick, free option, there are several well-known packs on the Roblox Developer Forum and the Animation Marketplace. Look for ones tagged with "R15 compatible" and check the preview animation before downloading. Some packs ship with broken IK chains or root drift that becomes obvious only after you've spent an hour integrating it.

The Workaround for Foot Sliding

Foot sliding is the most common complaint and it's rarely a problem with the animation itself. It's almost always a Root Motion setting issue. In the Animation Editor, select the root bone, go to the Properties, and toggle Root Motion. If you enable it, the animation drives the character's position directly. If you disable it, the Humanoid moves the character and the animation just does the leg work. For most platformers and arcade-style games, you want Root Motion disabled so the Humanoid's WalkSpeed controls the pace and the animation cycles to match. If you leave it enabled and the Humanoid is also moving the character, you get double translation and that slide effect. There's another subtler cause: the animation length doesn't align with the movement speed. If your character walks at 16 studs per second and your run animation cycle is exactly one second long, each footfall lands at the same world position. That's fine for slow movement. But as WalkSpeed increases, the feet start landing mid-stride relative to the ground. The fix is to either scale the animation speed to match WalkSpeed using a script, or build longer cycle animations that account for high-speed play. I usually bake in a 2-second cycle for run animations meant for fast-paced games. It feels more natural and gives the foot plants a clearer contact point with the ground.

Scripting the Assignment

Putting the animation into the game is straightforward. You reference the Animation object, create an AnimationInstance, and play it on the player's Humanoid. Here's the basic pattern I use in local scripts: local animation = Instance.new("Animation") animation.AnimationId = "rbxassetid://YOUR_ID_HERE"

local animTrack = humanoid:LoadAnimation(animation) animTrack.Priority = Enum.AnimationPriority.Movement animTrack:Play()

The Priority enum matters more than people give it credit for. Movement priority (value 5) sits below Action priority (value 6) and above Core (value 1). If you're layering effects like sprint bursts or power-up runs on top, those should use Action priority so they override the base run without canceling it entirely. I had a project where a dash ability kept canceling the run animation because both were at the same priority. Lowering the dash to Action and setting the run to Movement fixed the interaction cleanly.

When This Approach Falls Apart

Custom running animations don't solve everything. They add overhead to your character controller and can cause issues with network interpolation if you're not careful. Every frame the client sends movement data, and if the server isn't syncing animation state properly, other players will see jittery or desynchronized movement. The bigger problem is that Roblox's default run animation is already highly optimized. A custom one will always perform worse because the built-in animation is pre-baked into the engine's render pipeline. For casual games this barely registers, but in high-player-count experiences with lots of visible characters, swapping the default run can add measurable draw call overhead. If you're building something performance-sensitive, the best approach is often to modify the default animation rather than replace it entirely. You can edit the built-in run in Studio by loading it through the Animation Editor, adjusting the curves, and saving your tweaks. This keeps the engine-level optimizations intact and lets you change stride length, speed, or posture without the networking and rendering penalties of a full replacement. It's also significantly faster to iterate on. A typical tweak cycle takes about five minutes instead of the twenty to thirty you'd spend rebuilding and re-importing a custom animation from Blender.

Bottom Line

Getting a good Roblox Running Animation comes down to understanding how the Humanoid's state machine interacts with animation priority and root motion. Start simple, verify your bone names match the rig, set the priority to Movement, disable root motion unless you have a specific reason not to, and test at different WalkSpeed values before committing. The foot sliding issue is almost always fixable without re-importing. And if you find yourself spending more than an hour on animation tweaks, you're probably overcomplicating it and should switch to editing the default run instead.