Spikes and Mobile Interface

I'm planning on redesigning the demo level soon. During the planning, I realized I needed to add hazards to the game before introducing more obstacles and movement mechanics. Without adding hazards I'm limited in being able to test the player on their mastery of obstacles and mechanics. To help unblock the level redesign I implemented the first of the game's hazards: spikes.

Spikes are considered a ground hazard. They damage the player if the player lands on top of the spikes. To get this working I had to implement a few other systems first. Namely, damage sources and damage receivers. Damage sources encapsulate information about damage being dealt to a damage receiver. At the moment, this includes how much health the damage receiver should be dealt and how intense the knockback on receiving damage should be. Damage receivers are passed a damage source and apply the damage to the health system. Damage receivers also emit events for knockback and keep track of invulnerability frames.

This also means that the player movement controller needed to be updated to handle knockback. I also created a hurt flicker effect that indicates the duration of the invulnerability frames.

As an aside, the other day I tried opening the WebGL build on my phone. I noticed it ran at a solid framerate. However, there are no mobile controls for this game so it was not playable without connecting a controller. I looked into how difficult it might be to add virtual gamepad controls and it turns out the Unity input system has some easy-to-use components for this. So, I decided to add a mobile interface. It was pretty quick to get the virtual gamepad working, but it was a little more challenging to accurately determine if the WebGL build was being run on mobile. I created a plugin that does a few checks to determine the platform. If any of these checks returns true we display the mobile interface. I don't find playing the game with the virtual gamepad to be fun, but there are plenty of other games using this control scheme so I'll at least try to support it.

I also spent some time tuning values. One common feedback I've gotten is that jumping feels too floaty. Today, I tried doubling the value for gravity and it was a pretty obvious improvement. I might do smaller adjustments later, but it's easy to see that gravity was set far too low in previous builds. I also adjusted the max jump height slightly. The level is designed using 2-meter major increments. This is exactly the maximum player jump height. Because of this, too many jumps look like the player barely made it which is jarring. I still like 2 meters as a major increment, but now the player will just slightly overshoot it so movement looks more natural.

The final recent change was incremental camera rotations. I was doing some research into how platformers handle camera movement and I found a good breakdown of incremental (fixed-angle) camera rotations vs continuous camera rotation.  Incremental camera rotation on the D-Pad is helpful for players to quickly reorientate the camera mid-jump. Continuous camera rotation on the right stick is helpful because the player does not have to let go of the left stick to reorientate the camera. I decided I'd like to include both control schemes in the game. Additionally, incremental camera rotation is what the mobile interface will use.