Super Easy - 3 Lane Player Movement using Unity with Playmaker - Beginner Game Dev Tutorial #Shorts

Super Easy FREE tutorial on 3 Lane Player Movement using Unity 3D and Playmaker for beginning game devs. Also check out How to Make a Bounce Game Series https://bit.ly/39HIYBU. ► Download Playmaker at https://bit.ly/3dV8JzC ► Download Unity at https://unity.com 🚀 Download Trixel Rocket for free

A three lane movement system built in Unity with PlayMaker, the kind used in endless runners where the player snaps between a left, center, and right track. It handles both keyboard and swipe input, and the whole thing is one FSM built as a loop.

Listen for both input types at once

The FSM starts in a listening state that watches for two different kinds of input simultaneously. Get Key Down handles the left and right arrow keys for testing in the editor, and swipe gesture events handle left and right swipes for touch devices.

Wiring both into the same state from the start is the right call. You get to iterate quickly in the editor with a keyboard while the touch path stays live, so you're never maintaining two separate versions of your movement logic.

Move to the left lane

If the player swipes left or presses the left arrow, the FSM transitions into the left state. There, the character is moved over a short distance to the left, animating into the left lane.

Note that this is a fixed offset rather than continuous movement. Lane-based games work because positions are discrete, so the character always lands exactly on a lane and never ends up between two of them.

Return to the center

While in the left state, the FSM is now listening for the opposite input: Get Key Down on the right arrow, or a swipe right. When it fires, the character animates back over to the center.

Once that move completes, the FSM returns to the main input listening state, ready for whatever the player does next. This is the piece that makes the whole thing work as a loop rather than a set of separate cases.

Mirror it for the right lane

From the center listening state, a right input sends the character over to the right lane using the same pattern, and a left input from there brings it back to the center.

The result in play: press left or swipe left and the character moves to the left lane. Press right and it returns to center. Press right again and it moves to the right lane. Each input moves you exactly one lane in the direction you asked for, and you can never overshoot the outer lanes because there's no transition defined past them.

Why the loop structure matters

Building this as a loop of states rather than tracking a lane number in a variable has a real advantage: the FSM cannot enter an invalid position. The graph itself encodes the rule that there are three lanes, so no amount of frantic swiping can put the character off the track.

It also means adding lanes later is a matter of extending the chain rather than rewriting bounds-checking logic, and every state is visible on the graph when you're trying to work out why a transition isn't firing.