It struck me while putting together my website that I hadnt actually explained the building blocks of Dashstar in my devlog. Since the following couple of posts regarded the development of movement mechanics, I think a little exposition dump about the lore is in order.
Dashstar is made to indulge a fantasy. When watching games like Quake and playing games like Titanfall, I was always extra enthused by maintaining a flow state. Especially in regards to movement mechanics, I always found the idea of drifting perfectly and succinctly to a cool, rhythmic beat cathartic. So. The intention of the game is to be a smooth experience and enable movement to a beat. The next natural step is to identify the project as a rhythm game, and then to decide the main vector of... enjoyment? Like Geometry Dash has jumping, Beat Saber has cutting cubes. This main component has to be a satisfying mechanic, because it underpins the fantasy. If this doesnt fundamentally satisfy in some way, nothing can be built on top of it. Bugs become extra frustrating, and most importantly for me, anything that stops control becomes ten times more flow-breaking. In other words, I have to build my character to facilitate a high level of control in regards to movement. Great. I've got a clear vision for what my character needs to be able to achieve mechanically. The problem is in Unreal's default character movement component. This component is built by a set of very clever people, and uses physics calculations ot mimic real world momentum, power and work based outcomes. A specific issue arises whencontrolling the character in air. The camera (the viewport/whats on your screen) could be pointing one way, but if your character model is NOT moving that way, it will not instantly correct, instead it will continue travelling in the direction that had the most work done previously. In other words, it would carry its momentum forward instead of instantly correcting to the new camera angle. I did a little graph to try communicate what happened. As the blue line instantly adapts its direction, the red takes time to adapt itself to it. (I have absolutely no doubt there is a logical lapse somewhere here, am simply not able to maths that quick) That felt BAD, and broke flow. Unfortuantely, because of the structure of the inbuilt movement component, changing this was incredibly difficult, and so the solution became to make a new character component that acted differently to the prebuilt one. Hence, my issues when creating the wallrunning in relation to this component. The tutorial I was following to help me out wanted to use functions on the movement component that didnt exist.