Levels, Mechanics, and Iteration

This build introduces several new mechanics that, while not finished, begin to give an idea of what levels will feel like.

New

Level & Art

An initial, testing/tutorial level has been added. This level includes an upper area, that comprises simply a hallway, with a "throne room" where the player spawns. It's definitely a throne room, just ignore the wooden chair, it'll make sense later I promise. The King character here is a (very unfinished) custom sprite, who will give the player their quest at the start of the game. Currently, there is no initial direction for the player, and the player must figure out that they need to go right. There will be a prompt for this in future.

The player's spawn position, and a new King NPC

Beyond the hallway to the right, the player finds an entrance to the dungeon. The dungeon comprises of 4(?) rooms that require different techniques of flight, intended to show several types of challenge the player may encounter. These rooms are designed to be easily understood and straightforward to complete, but not overly easy. As there isn't meant to be an exceptional challenge in this level, there are frequent checkpoints.

The layout of the dungeon rooms, with the final room containing a door to move on (not implemented in this build)

Each stage is simple, but the difficulty steadily increases between rooms to teach the player how to play (first room and hallway), and introduces basic challenges in the rest of the rooms. When leaving the  throne room, the player must jump up several steps, teaching them how to jump. The first room of the dungeon has no way of dying (aside from flying into a wall at mach 7), but is impossible to solve without flight, forcing the player to learn the basics of this before moving forward. 

Camera Tracking & Dynamic Changing

The build now uses Cinemachine to track the player's movements. In the upper area, including the area with the King and the hallway, the camera is zoomed in on the player, but zooms out when the player enters the dungeon.

The player entering the dungeon, with the camera zooming out automatically.

Dying/Traps, Checkpoints, & Respawning

This build introduces basic respawning with a simple particle effect. Each respawn point is an edge collider that stores a defined Transform location in a singleton object when the player passes through it, and then deletes itself (to prevent deleting newer respawn points).

The player getting a checkpoint by walking through a trigger collider, with a message alerting to this at the top of the screen

When the player dies, they curl up inside their hat and then re-appear at their last checkpoint in a puff of magic. Traps (such as spikes) kill the player instantly on contact.

The player respawns after 1.5 seconds at their last respawn point.

Stun & Impact Deaths

When the player flies into a wall too fast, they will be either stunned or killed depending on their speed. Medium speeds will "stun" the player, preventing them from flying for half a second (risking hitting a trap), whereas high speeds will result in the player instantly dying. Currently this uses the same animation as a trap death, but a type of "splat" animation may be added in future to differentiate them. Currently stun has no effect or animation at all. This will likely be changed in a later build to include a particle effect to show the impact happening, to avoid the player thinking the game stopped accepting their inputs.

Iteration

Movement

The flight system has been somewhat changed, as well as values for jump heights and various speeds. Further, the player's hitbox (collider) rotating with them lead to confusion in the previous testing round, as falling sideways onto a corner of a platform made the player slide strangely. This was changed, and the collider is now held constant, and only the sprite is rotated.

This was finicky to implement, but was a fairly simple solution overall. Rotating the sprite would be easy, but when playing, it's obvious it's not a simple rotation: the rotation has angular velocity. This was fine when everything was controlled from a rigidbody (collider included), but in order to have angular velocity on a child object (the sprite), a different solution was needed. 

The first attempt at this was nesting rigidbodies, where the sprite would have an immovable rigidbody that can rotate, and the parent one would not be able to rotate, but would be able to move in the world controlled by physics and the player. However, this lead to undefined behaviour as nested rigidbodies in Unity is not supported. A joint option was considered, but due to the simplicity of the rotation physics, a custom approach was chosen. 

In this build, the sprite is a child object of an empty that contains all the player scripts, including movement, as well as the collider and rigidbody. The sprite object contains the sprite renderer as well as a custom script called simply "CustomRotationPhysics", that handles angular velocity and angular drag in FixedUpdate, completely independent of the rigidbody.

Testing & Feedback

Level Feedback

Layout is great, but may be a bit too hard for a tutorial level
Zig zag is very hard, especially with the tight turn at the bottom
Last part [where there are spikes on the floor and ceiling] is tricky but not as hard as the zig zag

Regarding the first point about difficulty, this was very helpful as feedback, as it's hard to attain the difficulty of a system when you're quite familiar with the controls from testing it yourself. The zig zag (2nd to last section) was not intended to be as challenging as it was, and was a frequent note from testers that it was quite difficult and often took far longer than any other puzzle. 

As an additional positive of this feedback, it will help to inform future level design greatly, as knowing which motion types are easy and which are hard will allow the levels to progress naturally, rather than a given level being extremely hard followed by an extremely easy one. 

Mechanics

Dying when you hit a wall at high speed feels like a bug
Not being able to fly sometimes makes the game feel unresponsive

This will largely be addressed in future iterations focused on visuals, but it's helpful to know that these features have a noticeable impact on gameplay. In future, dying on collision, as well as being stunned, will have their own animations or visual effects to demonstrate that something has happened.

Spikes sometimes felt too easy to hit; the colliders hit without visual connection sometimes

This was a concern when defining collider shapes, and in future traps will likely have colliders slightly smaller than their visuals to ensure the player never feels like the game cheated them.

Bugs Found

In addition to the already known bugs, it was found that the play can die or be stunned from sliding down a wall, as the direction of the relative velocity of a collision was not checked to ensure the player is going towards the wall, so sheering forces will harm the player if they're against a wall when sliding.