Multiple Paths & Bouncing

( Music used: Sonic and the Secret Rings - No Way Through )

My first task in this update was to fix the player’s collision detection. The last update showed the horizontal blue and red lines going across the screen, and would remain aligned to the center of the spline. This meant that the player would be yanked towards the center, if an object were to get between the player and the spline’s center. I had the collision tracing moved to the character’s position, and then changed the calculations not to pull the player in if the player’s distance exceeded the distance of the surface of the object as well as the allowance threshold, but to calculate the distance of the object from the player’s position, and to add to or subtract from the player’s horizontal offset to the spline’s center based on the angle and direction of the object’s surface collided. Once that was done, it was time to get working on the next feature.

I’d requested my friend, Ben, to do some amount of level designing to help test the limits of the movement system I’ve been working on, since not only was this to get him introduced to Unreal Engine’s workflows, but because he’s a veteran Sonic fan who also shares some of the same gemaply ideals as I. One of the things he told me he wanted in his level was multiple paths. It took a lot of brain-racking to get the spline movement system to support split paths, but there were specific things I had to get through in order to get the split path to work. I had to work on the drawing board trying to find the best way to handle it, then I realized that, if I could just have it where the player can simply move from the end of one spline to the start of another would be the place to start.

By chaining a spline at the exact location is easy, but that isn’t intuitive to the level designer. If there is so much as a single positional offset, either location or rotation, or even orientation, it would throw everything off, snapping the player to the same horizontal offset relative to the new spline. So I did some testing while intentionally offsetitng the next spline. I worked on vector calculations to calculate the player’s horizontal offset to the spline’s center. Now, when the player goes from one spline to the next, the player would never notice that the center of the spline had shifted as they eased to the next path.

Since I wanted there to be some wall-running and some spectacle pathing, I’d attempted to get some gravity shifting going. However, due to the movement system snapping the player’s X and Y location to the position along the spline, only the Z movement would remain freed from the spline’s influence. When the spline’s orientation shifts, the player’s downard direction remains along the world’s Z direction. One could say to just rotate the world itself, but that goes against my philosophy regarding how gravity should work in the game world. Since there is intention to have multiplayer in the game, I cannot rotate the world. My desired solution would be to rotate the player’s axis, so that they can still follow the spline relative to it’s own local X and Y axis, while still moving freely in it’s local Z axis. I’ve programmed custom gravity and got the player to run on arbitrary surfaces in the past when I’d studied Gravity Rush’s mechanics in the past. However, the spline movement itself complicates the process of gravity shifting. I’d decided to put this task on hold for now, and make the best of what I’ve got working so far.

Since I can’t change gravity, I can at least make a setting for the spline component to lock the player to the spline’s center instead, restricting free Z movement. When restricting free Z movement, the player can no longer be affected by gravity, and cannot jump either. This allows the level designer to twist and orient the spline however they please without the player jumping at an odd direction relative to the camera’s orientation. I’d also made a setting that can force the player’s horizontal offset to the spline to center, so that the player cannot move horizontally while on the wall. This setting was made as a debug option while trying to get the player’s horizontal movement to align to arbitrary surfaces, as the horizontal offset when angled is still inconsistent. For now, it serves well to meet the same effect that 3D Sonic games do when they have Sonic running on arbitrary platforms.

After working those settings to allow the player to move from one spline to the next, it was high time that I’d get multiple paths working. The reason why I’d come to the conclusion of using spline transitions was because of how I perceived the way the player could choose the direction to go. The way I wanted the player to choose where to go was based on the interstate roads in the US. I’d decided to work on the “lanes approach”. If the player is in this lane by the time they reach the split, they should be bound to this spline following it. Where I want the intersection to happen, I would place two splines following the same angle and direction as the last segment of the spline before it. I would use the terrain to get the player to commit to a lane before reaching the end point of the current spline. In the area leading up to the split in the terrain, there are trigger volumes that will assign the player’s next spline to transition to before they meet the end of the current spline’s path. This way, the player blueprint already knows what spline it will transition to before meeting that end, allowing the player to continue running without a hiccup. Once the player has chosen a path, they will never know they moved into a different spline until they find out the direction they didn’t take was on a completely different path.

I felt super achieved after I’d successfully gotten the split path feature to work. It doesn’t even need the paths to be level to the last spline to transition either! From there, I would make some animations on Blender to further complete the game feel of the prototype. I’d return to the animation blueprint and rework animation blend spaces and add a new state machine to the animations. I added jumping animations and plunge animations to let the player enjoy the feeling of bouncing. Speaking of which, the plunge before was implemented wierdly. I thought for some reason I could have a bounce higher than a normal jump by releasing the plunge button before reaching the ground. It was super unintuitive for the player, requiring frame-perfect input release in the very few frames between plunging and landing on the ground. I ended up opting for a better solution. When the player slams into the groun after a plunge, the player is in the “slammed” state for a short duration. If the player jumps while in the “slammed” state, they will perform the high bounce. This gives the player a feeling of satisfaction when timing jumps to the ground impact when traversing. This was a much better solution to the plunge bounce predicament.

With all of this made, I’ve come to understand that my “Level Layers” concept is a completely viable option. You may notice in the video above that when the player runs into those hoops that they teleport to a new location. This is one of the results that came from working on the spline-transitioning system. When the player reaches the end of a spline, they move to the start of the next spline. This does not require that the following spline be near the previous. This gives my team the option of having teleportation in our levels.

To explain my “Level Layers” concept, it is one of my level dungeon ideas, that a player could go deeper in elevation to meet with tougher monsters and more dangerous areas. The way the player would descend would be to enter spirit currents that take them either downard or upward to the next floor. This is actually a very metroidvaina-esque level design. The reason this is one of my level design values is that I wanted to use building blocks for the dungeon levels, so that I could also create a randomized rougelite gameplay mode where the player can delve deeper to find more treasure or hunt more dangerous monsters. The player will want to hunt monsters for their materials, as well as treasure. I want the player to manage inventory of materials and treasure to either upgrade or exchange for a currency. There may also be other various rewards the player could find in the dungeons. While it may seem like scope-creep, this was one of the features I’d planned to have when I was in the process of building my design document. If it may still seem like much, my only excuse is that I’m ambitious.

The next piece of the movement puzzle I need to work on are movement-heavy attacks. Once usch example is the homing attack. I’ve already got the necessary pieces of the puzzle to get that working while maintaining control with the spline movement. Thanks to the vector calculations that allow for spline transitions, it won’t be hard to let the player escape control from the spline and then to return to the spline after the motion.