Moving stuff that isn't a player in Roblox
You can't just stick an AnimationController on a random Part and expect it to behave. Humanoid gets special treatment from the engine. Wheels, doors, vehicles, decorative props — they all need different approaches depending on what you're trying to move. Here's what actually works in practice. The most common mistake I see is people trying to use standard animation system methods on non-characters. That approach hits a wall pretty quickly. For simple mechanical movement — doors opening, pistons extending, platforms rotating — TweenService is usually the answer. It's straightforward and doesn't require rigging anything. You set up a TweenInfo with your desired easing style and time, then call TweenService:Create() on the part you want to move. It handles the interpolation automatically. I've been burning through prop animations for a theme park game and this method cuts the work down significantly compared to manual frame-by-frame CFrame manipulation.
The setup looks like this: create the TweenInfo object, specify start and goal properties on the part, and play the tween. If you need looping animations like a spinning fan blade, you set the LoopCount property on the tween info or use a repeated callback pattern.
AnimationController approach for complex rigs
Sometimes TweenService isn't enough. You need actual keyframed animation on a model with multiple moving parts. The AnimationController is technically designed for Humanoids, but it does work on regular models if you set it up correctly. You need to place an AnimationController instance inside your model, create an Animation asset with proper keyframes targeting the correct joint hierarchy, then load and play that animation on the controller. The catch is your model needs the right structure — WeldConstraints or Motor6Ds connecting the parts, and the animation needs to be authored against that same hierarchy. I ran into a specific problem with a minecart model last year. The cart had six wheels and two body segments welded together with Motor6Ds. When I tried playing the animation, the whole thing deformed wrong because the animation was authored for a different weld layout. The workaround was to check every single Motor6D Transform property in the animation editor against the actual weld definitions in the model. Mismatched names or axes would silently produce broken animation instead of throwing an error.
Get the Full Details
CFrame-based custom animation loops
When you need something that runs every frame and responds to game logic, you write your own loop using RunService. This is the most flexible approach but also the most code to maintain. You subscribe to RenderStepped or Heartbeat, calculate where each part should be based on time or state, and set their CFrame values directly. For a simple gate that opens when a player walks nearby, this might take 15 to 20 lines of code total. For something with multiple phases and conditions, it can grow faster. The advantage here is full control. You can blend between states, respond to remote events instantly, and compose movements from multiple independent calculations. The downside is that you handle all the math yourself. No baked animation curves, no visual preview in the editor, nothing. You're writing sine waves and lerp functions instead of clicking keyframes.
Constraints as animation tools
This one surprises people. Constraints like HingeConstraint, Motor6D, and BallSocketConstraint have properties you can animate directly. A HingeConstraint lets you drive the Angle property to swing a door, and it handles all the rotational math and physics interaction for you. I used this approach for a swinging chandelier prop in a haunted house game. The chandelier hung from a CeilingAttachment connected to a HingeConstraint on the main chain piece. Animating the constraint angle made it swing realistically while still colliding properly with players who walked through it. Tweening the Angle property with a sine wave created a continuous pendulum motion that looked decent without any complex physics simulation. The limitation is that constraint-based animation only works for single-axis or predefined degrees of freedom. You can't make a free-floating object do arbitrary rotation this way. Each constraint type has a fixed motion profile. But for things that naturally rotate or slide along a path, it's often the simplest solution available.
Important caveats
Not every object plays nice with every method. Network ownership matters if you're animating client-side on the server. CFrame animations on servers are authoritative but can cause visual jitter if clients don't interpolate. TweenService animations won't sync across clients unless you broadcast the state and run the same tweens locally on each machine. If your object needs to interact with physics while animated, you'll need to choose between making it a rigidbody that gets pushed around by constraints, or temporarily disabling physics during the animation window. Both approaches have tradeoffs. Disabling physics during animation is simpler but makes the object feel weightless. Driving physics through constraints is more realistic but harder to predict exactly. For most prop animation work, I'd recommend starting with TweenService for simple cases, HingeConstraint or similar constraints when the motion is constrained to a natural axis, and CFrame loops only when you need dynamic behavior that doesn't fit the other categories. AnimationControllers on non-Humanoid models work but require careful setup and aren't as well documented, so only go there if you need the preview tooling the AnimationEditor provides.
