Geek Culture
Published in

Geek Culture

How can I move a Sprite? — Player Movement Scripting

Objective: create a player and script its movement using a rigid body approach

The first thing to do is to create our Player object. As did for other player objects in other tutorials, I’m going to follow this approach: keep the model as a child of the main object.

So let’s create an empty object and drag the player sprite into it. This will create a child object bearing a Sprite Renderer component. Let’s make sure that this child is at zero position.

The main object will be the one carrying scripts and other components, so let’s add a rigid body 2D and a box collider 2D. If need, the collider can be adjusted to fit the sprite.

Now that the player has a rigid body component, it is subject to the laws of physics: gravity is automatically applied. The player fall and other movements are stopped by other colliders, such as the ground.

Movement Scripting

The movement will not be implemented through the transform but by applying a velocity to the rigid body. Velocity is a rigid body property and we can set it with a vector2.

To set the velocity, we need a vector2 variable. Its components are going to be set at each frame: for the horizontal, we take input from the axis and multiply it by a custom speed.

The custom speed will be chosen among two possibilities, detecting another input: while pressing left shift the player will run instead of walk. In the future, we may even implement a stamina-depleting feature.

Once the velocity is prepared, we can set it into the rigid body.

Oops!

Since we have a realistic physics box moving, friction will push it along the bottom in a direction opposite to the motion. This results in some torque applied to the body and then a rotation. To prevent this behaviour, we cheat and ask Unity to forget about the rotations!

In the rigid body inspector, let’s make sure that the Freeze Rotation box is checked.

Jump Scripting

As for the movement, jump consists in setting the rigid body velocity, in particular its vertical component.

We also need to make some checks before jumping, namely if the correct input has been given and if the player is grounded.

The change in the Move method is little: we add an evaluation of y velocity to be set at the end. This evaluation returns the jumping velocity, here given by a simple formula starting from the jump height, if the jumping criteria are met (input and grounded player) otherwise the rigid body vertical velocity is returned. This is necessary: if the player jumps, the change in velocity occurs in a frame and then gravity takes place. If not jumping (grounded or in mid-air) we are still setting the velocity into the rigid body but we don’t want to interfere with gravity, so we set its value.

To check if the player is grounded, we have many possibilities. Just to name some of them: using colliders or using raycast. I’m going with the latter.

Raycast is a physics tool that allows casting a ray or a line from a point (origin) in a given direction, for a given distance. This ray can detect colliders on its way a return a lot of info about them.

To cast a ray, we then need an origin, a direction and possibly a distance. I used the player box collider as a reference. Starting from the position, I evaluated the origin using the collider offset, to have the origin slightly out of the collider itself. The direction is of course down. The distance has been chosen as the minimum useful distance.

If a ray cast down is going to tell me if the player is grounded or not, it can not reach too far: the player would then be considered grounded even if in mid-air but at a distance from the ground less than the ray casting distance.

The Raycast method returns an object containing info about the hit collider(s) if there is any: so we check if there is it and we return true, the player is grounded because it is on top of something. Else, false.

We also draw the ray so it is visible in the scene view.

The choice of putting the origin outside the box allows avoiding the ray colliding with the player itself. This can be carried out more elegantly also. The Raycast method has another overload that accepts also a layer as a parameter.

If we assign the player and the ground to different layers, and then we pass the ground layer to the method, we automatically avoid detecting collision between the ray and the player collider, no matter the origin.

If you liked it, clap to it! Check out my games or buy me a coffee: every kind of support is appreciated!!

--

--

--

A new tech publication by Start it up (https://medium.com/swlh).

Recommended from Medium

Moat Part 2 — Multiplayer Dungeon Crawler

The task was to Display an Alphabet using a 7 segment display (common cathode and common…

ADN (API DELIVERY NETWORK) GIVES SUPERPOWERS TO OUR APIs

NaGaDeMon #16 — Green Commons

| Engineering News-Record

Does OO still Function?

5 Pairs of Magic Methods in Python You Should Know

The 6 Steps I Took to Get My First Software Testing Job

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Daniele Quero, PhD

Daniele Quero, PhD

A professional developer with passion for game developing and skill-growing. A former Nuclear Physics Researcher who changed his life to pursue his dreams

More from Medium

Diverging from Base Enemy Class

Making a RTS game #50: Implementing a technology tree 1/3 (Unity/C#)

Journal 144 — Unity Project Development, 2.5D Shooter

Cross-platform Input Controller in Unity