Devlog 1 - Week 8: Player Movement

Implementation

The implementation of player movement began with the creation of the Davey's sprites, arranged into a spritesheet. Though I am not quite satisfied with some artistic aspects (e.g., the dreadlocks in the north-facing sprites), it is sufficient for implementing movement.

Davey's spritesheet, drawn by me.

This spritesheet contains a simple walk motion, wherein the middle frame also acts as an idle frame. To bring Davey to life, his spritesheet was converted into multiple sprites by slicing the sheet in Unity, a very convenient feature. The sprites can then be patched together and turned into individual animations for north, south, east, and west walking or idling. Each frame goes for one second, with the middle frame repeating for fluid motion. The speed of the animation can also be conveniently adjusted with Unity; I slowed the motion down to match the movement speed of the character.

The animation layout of Davey's walking sprite.

Player movement was then implemented by adding a Rigidbody 2D component to Davey, with the gravity set to zero (so that he doesn't fall of the screen!). This Rigidbody2D component allows for physics-based movement by applying forces, and handling collisions. However, more is needed for the player to be moved with controls; that is where our trusty script comes in!

This script enables an entity to move in eight directions based on keyboard input, using the Rigidbody2D component for smooth physics-based movement. The script checks for key presses (W, A, S, D) to determine the direction of movement, updates the associated Animator for animation control, ensuring constant velocity, regardless of the movement angle. When there is no input, the player stops moving, and triggers an idle animation state. This script was adapted from the EightWayMovement script as implemented in the KIT109 practicals.

The implemented player movement (and a zombie!). All assets created by me.

User Feedback / Improvements

User Feedback was obtained via peer review threads on Discord. Here are the main takeaways:

• Smooth movement: players agreed that the movement was smooth and felt good, and had uniform speed.
• Camera and screen perception: when moving directly up or down, there was concern that the character might collide with objects at the screen's edge before reacting to them, potentially affecting gameplay. This could be corrected by adjusting the camera that is following the player, so that there is more visible space north and south of the moving player, to give greater clarity of the player's position.
• Character facing direction: there was an observation that the character's facing direction appears inconsistent when moving diagonally; specifically, when moving down and to the right, the character faces right, while in other diagonal directions, the character faces either up or down. This could be improved upon by adjusting the animation states currently implemented, or setting diagonal-moving animations (even if the character only faces in four directions).
• Potential diagonal-facing sprites: a player suggested possible diagonal sprites, as the player moves in eight directions. This may be implemented later, if time constraints allow for it. Currently, the four-directional sprites sufficiently communicate player movement.

Alternative Approaches

• Player movement: an alternative approach to implementing player movement within a script, would be to directly modify the transform.position based on the input. While this approach is simple and allows for direct control over the player's position, it doesn't simulate physics like the Rigidbody-based approach that I implemented.