Skiwi V3

Welcome to the Skiwi V3 devlog.
Hello! This update is not a major one, but it isn't exactly minor either. The work on it has mostly been focused on refactoring the primary mechanics of the game so bugs are less frequent. I also introduced some mechanics that I think will be core to the game when I scale it.

Leaderboard:
I added a leaderboard that registers and displays accrued stats at the end of each race.

Fruits:
I made an orange (thank you Umami for the idea) that boost your stats in certain ways when eat it (which you do by skiing through it). Currently the orange comes in two flavors. The first one is a normal orange and I imagine it tastes just like one. If you eat it you get an initial burst of speed, and then your max speed is increased for 5 seconds.

The second one looks like a big blueberry. Who or what turned it blue is up for speculation. If you eat it your flip speed will be increased for 5 seconds.

Checkpoints:
Checkpoints are evenly placed along the map and you will be able to re-spawn close to one if you ski through it.

Plans for the next release:

Multiplayer:
There are a few more hurdles for me to get over in regards to implementing this but I am sure I can do it.

Gamepad support:
This was originally the update that was going to ship this feature, but when I started implementing controller support I realized I had to uproot scripts that intertwined skiing controls, animations and the tricking system. This was going to consume more hours than I had scheduled for this release, so I pushed it up for a later one.

Nerd stuff (feel free to skip this part):

Skiwi's collision solving:
There are two things you may notice when playing Skiwi in its current state.

1. The game is capped at 60 FPS.
2. The speed limit is capped at 50 cm/s (except for when you eat an orange, then it's capped at 60cm/s).

This has two reasons:

1. The rate at which the physics are solved is tied to the tick rate, which in turn is tied to the frame rate. If the frame rate exceeds or falls below 60 fps, the speed of the game will increase and decrease respectively. The way to make the physics solver frame-rate independent is typically done by multiplying the forces of the solver with the time it took for the engine to generate the last frame (delta-time). I've managed to implement this in about 50% of the variables I use for the physics solver, but then I begin to run into issues that I don't know how to solve yet. I'm sure I can fix this, I just need a bit more time.

2. If the bird reaches speeds over 50 cm/s, the odds of clipping through the map increases. This is because at high speeds the collision checking script doesn't notice that there's a floor or wall to be collided with. I know how to solve this; the basis for the solution is a method called CCD (continuous collision detection). I will try to implement this for the next update so I can increase the speed limit.

Unrelated to the previous two points, but still on the topic of my ineptly scripted physics solver, the collision force of the ground in Skiwi is calculated in two steps. The first step is projecting the bird's velocity at a right angle to the ground normal. The second step is pushing the bird away from the ground if intersecting with it too deeply. The way the first step is scripted causes the bird's velocity to be redirected in the matter of a frame when riding from one polygon to another. This is because flat normals are the only kind of normals the line trace in Unreal Engine gives me access to. There's nothing wrong with this, but it doesn't look as smooth as I want it to. Linear interpolation of the bird's velocity and rotation work to an extent, but also makes the simulation less accurate. The game SSX seems to solve this issue fairly well. I'm not sure how they've done it, but my goal is to do something similar. If you (the reader) have any ideas on how to make traveling across polygons smoother while retaining accuracy, please message me!

Next release date:
I'm aiming for the first of September.