Basic Movement

What's in the Current Build?

This week's work has been admittedly minimal. Other classes have demanded my attention (imagine enrolling in uni and needing to do uni work, total scam), but I've still managed to get a basic movement system developed. And I do mean very basic. 

Currently, the player is an object with a plain white square sprite renderer, a box collider 2D, and rigidbody 2D, and a movement script. They also have a child object, but I'll detail that later. 

The world is made by tilemap, and it was nice to get back in touch with tilemaps a little, as I intend to use them for building the rest of the game's levels (No, I will not be taking questions on the implications of getting back in touch with something only to use it, the tilemap system is not a person, it does not necessitate ethical consideration). The implementation here was very basic, and reused assets from the tutorials earlier in semester. Notably, the collision for the tilemap needed to be set to polygon to fix a few bugs around clipping into the floor. 

There's also a very basic script attached to the player to move the player back onto the screen opposite the place they left. This isn't an actual feature, mind, but it was a very quick way to prevent excessive reloading during playtesting. 

See all this in the gif below!

What's the Movement Like?

The movement is currently a simple system of A and D for moving left and right and W for jumping, though I've laid the groundwork in the script for the arrow keys to be supported as well (on a simple bool toggle), and I'm considering looking into complete key rebinding, though we'll see if there's time / motivation. 

I wanted the jumping to emulate the classic "mario style" of 2D platformer jump, namely with an instant acceleration upward, followed by a fast fall back down. This wasn't too hard to achieve, and I simply decrease the player's gravity scale when the jump begins, then set it back to the original, higher value at the peak of the jump. Harder to implement was a variable jump height, letting the player go higher the longer they hold jump, up to a point.

Feedback

I think it feels pretty good as is, there is a good bit of weight to it. Only issue is that their is a bit of a clipping issue when landing sometimes and the player is inside the platforms for a few frames.

It seems that the feel of the jump is at least in the right ball park, but there is an issue with the player clipping into the floor after a jump. I'll need to look into ways to prevent this, but I'm unsure of where to start. 

(It's hard to see, look at the bottom right corner of the player right as they land)

Also, for the falling screen looping mechanic, it ends up going so fast that your player becomes invisible, might it be worthwhile implementing some sort of lower terminal fall velocity? Other than those two issues (collision clipping with ground after a jump and infinite fall speed) I couldn't identify any further issues with the movement system. It feels pretty good, I like the feel of the jump

Again it seems that the feel of the jump is good, and it is worth noting that the screen wrapping behaviour is noticeably unpleasant. 

Bugs, Technical Details, Workarounds

As mentioned above, the player has a child object. This child object is nothing but a thin box collider 2D at the feet of the player that can detect if the player is touching the ground. This is used to make sure that the player can't just continue jumping in midair to effectively fly. However, the original implementation of this had a problem, namely that walking right up against a wall would have the box collider detect the wall as the ground, and allow the player to completely scale the wall. 

(Look at my box child, flying away. Be free, be free and find a better life)

To remedy this, I made the box collider slightly less wide than the player, but this resulted in it being possible for the player to just be on the edge of a platform, but unable to jump because the ground detecting collider was not touching the platform. To remedy this, I changed how the detection worked, such that when the ground detecting box collider touches the ground, a "grounded" variable is set to true, and when the player has significant vertical velocity (greater than a very small number, as floating point inaccuracies sometimes result in very small and unintentional vertical velocities on the order of 10^-5) the "grounded" variable is set to false. 

This effectively makes the jumping rules look like "You can only jump if you are grounded" and "You are considered grounded if you have not moved vertically since the last time you touched the ground". 

I am still considering how to fix the edge case of a player jumping, and thus becoming not grounded, and then landing on the very edge of a platform, such that their ground detecting collider does not trigger, and thus they are unable to jump, even though they have landed. I am unsure of how to fix this, but I imagine I may need to rewrite the system entirely. 

I do worry that my current implementation of the variable jump height, which continually adds a small portion of the jump force while the player is holding W,  might feel a little jittery. I might rework the system to gradually increase the gravity back to its original value, but do so more slowly if the player is holding W, but I'm unsure at the moment. 

It is also worth noting that the current system for defining the jump is a little hard to interpret. The way I have the variables set up in the script just doesn't lend itself to a precise understanding of what each change will do, and fine-tuning until this point has largely just been based on feel. I might tackle re-doing the script to be more human interpretable, but I suspect it will require a significant amount of work.

What's Next in the Pipeline?

The foremost issues I need to tackle, in no particular order, are: 

• -redoing the jump script to be more intuitive
• -tackling the "jumping and landing on the very edge of a platform" edge case (Trim the hedge of the edge landing edge case)
• -fine tuning the jump 

And the foremost new features I intend to add are:

• Custom sprites and animations
• a wider moveset 
• building a level

This week is looking much more open for game development, since I've just finished a chemistry lab report that was really weighing me down. I'm looking forward to see what I can do!