Player Movement
This week I made a spritesheet for the player, imported it into Unity and then turned it into animations for the player's movement. I wrote a PlayerMovement script that moves the player in the four cardinal directions, using WASD as input. The movement system is tile-based, so the player will automatically move to the centre of each tile, rather than stopping on the border of two tiles. Each purple tile you stand on becomes deadly and changes appearance after a short delay, so you are forced to stay on the move.
Here's what I have working (to some extent) at the moment:
Very simple level made as a demo for player testing
Process
The spritesheet was made by me in Aseprite using a base spritesheet by AntumDeluge (2017) as a reference, and consists of twelve separate sprites for the player to create the four directional walking animations (as well as respective idle animations). A PlayerMovement script moves the player smoothly to the middle of each tile and changes parameters so that the correct animation plays depending on the direction player is walking in. Once the player was set up I made a basic scene for them to walk around in using a tileset by Szadi art (2020). I then added the various scripts that I'd already made to make the tiles that you've stepped on turn deadly after a short delay. Some of this code came from a video tutorial by Shackman (2020). For the purpose of collecting feedback on player preferences, I also added some buttons to allow people to customise the player speed, tile changing speed, and the camera zoom.
For testing purposes players are able to customise certain parts of the game
Initially everything seemed fine with the setup, but after increasing the default player speed from 2 up to 3 I noticed that something strange was happening with the animation. See the Gif below:
A broken walking animation. You can see that the moving animation's progress bar is not reaching the end, and the idle animation's bar is flickering.
The problem is that the moving animation is being interrupted and reset every time the player steps on a tile, as it very briefly transitions to the idle animation. The reason I didn't notice this sooner is that it turned out the player's animation coincidentally fit perfectly with the player speed at 2, but increasing it to 3 made it finish whilst only two-thirds complete. With the animation relying on just three different sprites, having incorrect frames thrown into the mix completely ruined the illusion of the player walking. To fix it, I altered the program so that it doesn't change the animation back to idle when the player reaches the middle of a tile until it has confirmed that the player is truly meant to be idle by checking whether key input has also stopped. If a key is still being held down, the animation will continue playing. For comparison, below is the corrected end product:
The fixed animation cycle
Feedback and Future Improvements
The first round of feedback provided many insights into how the game could be improved. Here are some notable points with my explanations of how I will address them:
I might suggest trying to implement an input queue of some kind? Say a player knows they want to move up and then left and then up, and they press up left up, the lower speeds might make it so the left isn't registered because they're still moving to the first "up" tile, and having "inputs eaten" like that can be frustrating
Movement is such an important part of this game so getting the controls to feel precise and responsive is a high priority. At the moment the code will ignore any input made while the player is in the process of moving to a tile, but a "PlayerMovementImproved" script is in the works that will control the movement by creating a coroutine with each key press, hopefully allowing all inputs to be registered without breaking the tile-locked movement.
...There is a slight issue with collision in certain walls. It seems to mess with the character's precise tile-based movement
The current collision system is a very temporary one that didn't have much time put into it. I've realised that after implementing the fix for the animation it has become even worse, freezing the player if they bump into anything. At the moment the player has a collider where their feet are to stop them walking off the map, but I will change this so the player has a trigger that detects ahead of where they are going instead.
...Might be good to have a crumbling animation on the destroyed blocks, so rather than destroy after a certain time, use the animation to indicate when its about to become a block you can't stand on
I would personally like for the tiles to have an animation showing their transition to deadliness as well. Working with the tile system is harder than I initially expected but I think I can upgrade the current system to allow the tiles to have a triggerable animation.
The "green tiles" are almost indistinguishable on my monitor -- particularly with glare or lots of white elsewhere on screen
The tiles were put into Unity as is, and I thought they were pretty effective in creating a kind of gloomy Gothic aesthetic. This comment alerted me to the problem with this style - I will try to modify the tiles to use a colour scheme that is more visually distinct but still appropriate for my desired aesthetic.
References
AntumDeluge (2017), Cabbit Bases Collection. OpenGameArt.org, https://opengameart.org/node/79237
Shackman creates art and games (2020), How to store data in tiles (Unity Tilemap + Scriptable Objects). YouTube,
Szadi Art (2020), Rogue Fantasy Catacombs. itch.io, https://szadiart.itch.io/rogue-fantasy-catacombs
Death Boots
Fast-paced tile puzzle game made for main assignment of Games Fundamentals at UTAS.
Status | In development |
Author | estainer |
Genre | Puzzle |
More posts
- Documentation + User GuideOct 17, 2021
- Polish and UIOct 10, 2021
- Game TestingOct 07, 2021
- Presentation & GraphicsOct 03, 2021
- Enemies, Interaction, PuzzlesSep 27, 2021
- Level BlockingSep 19, 2021
- Game ConceptAug 29, 2021
Leave a comment
Log in with itch.io to leave a comment.