Movement Overhaul
After the extensive development of the player’s movement and features to support the free-roam and spline-locked movement, I’d reach an epiphany that would simplify a lot of the logic that went into the spline-locked movement’s logic. This required me to build the whole spline-locked movement from scratch. Luckily, I’d already separated the different movement types into their own components in a previous update.
Rather than locking the player’s location to a point on the spline, I’d get the player to find the point on the spline closest to them and read the parameters of it, refering to its vectors and orientations. This allows the player to actually move in a predictable manner, and also opened up the movement enough to potentially support custom gravity. However, instead of going into that, I’d focus more on the aspects that would make the MVP(Minimum Viable Product) of this game this time around, since I’d gotten the movement back into a playable state to the way it was before. (albeit, it was much easier building the new spline-locked systems). I’d start working on more of the things that would aid the level designers to make their levels. I’d create a bouncepad, some collectible points, and a foundation for enemy units. It’s already known the player can zip to enemies, but the player can also zip to bouncepads and jump even higher.
Similar to most platformers, where the collectible points are represented by a unique object, I’ve decided to name our points “Sprites”! Originally, I wanted them to be referred to as “Wisps”, soas to represent the wandering spirits of the dead. However, my friends were adamant about not calling them wisps, because of their immediate affiliation of the name to the similarly named “wisps” of Sonic Colors and Sonic Forces. While I initially was reluctant, I thought “sprites” would work just as well, since sprites in a lot of videogame media are commonly seen as entities of an elemental property. In the case of Project Styx, it wouldn’t be out of place to refer these wandering spirits “sprites”. This would also allow me to conceptualize different kinds of sprites if I wanted to. Along with this, I’d lay the groundwork for the ingame UI, specifically setting up the Points display so I can track how many sprites I’ve collected.
The next week, I’d dig even deeper into the movement system to ensure this overhaul gives me the greatest yield for the level designers to reap as much out of it as possible. I’d set up the movement system to support custom gravity from its very foundation, so that it can no only allow the player to travel at crazy angles along splines, but so we can also create even more alternate paths utilizing the gravity shiting mechanic.
I’d add much more polish to the movement after I published the video. The player now orients properly the moment they’ve entered the G-shifter Disk. I’d make the G-shifter Disks look something similar to portals until I can create VFX to make it more clear the direction it shifts gravity. The camera now has better smoothed rotation to the new gravity direction when switching gravity. Targetting objects no longer targets untargettable objects. The player no longer attaches to spline zones if they do not meet the gravity requirements for the spline path. Bouncepads now have more control over the player’s bounce trajectory.
Toybox 2
The new look of the Toybox where various features are being tested.
Most of the kinks in the movement code have been ironed out and it works great performance-wise. I won’t deny that my team and I do come across hitches at times during testing, but I’ve found the reason for the hitches happening actually happens due to the current implementation of the targetting system checking every targetable object every tick. Though the tick rate of the targetting system component is lowered, it is still computing a lot of work every tick that it does trigger. The solution to this is a combination of multiple things:
Having targetable objects spawn in or be accounted for in code when the player is close enough by using a trigger volume.
Having objects spawn in when the player enters a room volume.
And more things related to actor management.
To be frank, these are things I will inevitably have to do soon anyways, as I’m starting to get into the combat mechanics of the game. Some of the things I’ll be focusing on will be:
Enemy Behavior Trees
Making Character Models
Animating Combat Actions
Modeling Weapons
Creating projectiles
Health Management Systems
Parry Mechanics
Object Magnets
Lock On Camera
Dream Eater Mode
Data Tables
Boss Fights
I’d also have to look into implementing some VFX so that the player understands the angle of which they are standing better, as well as adjusting the player’s design to allow some elements to hang off of the player towards the direction of the ground. I’d returned to Gravity Rush 2 to study the way it ticks once again just today. It really feels like I’d cracked open Pandora’s Box a second time, as this was the second time I’ve pursued gravity-shifting gameplay in a game engine. (The first time was when I tried to reinvent the physics framework of Dreams on the PS4 ;P )
This is a lot that I’ll have to work on, but I have a great love for creating combat and movement systems, so it will be a blast for me to undertake! We are so close to having a playable prototype, and when that’s ready and out, I’d be able to be way more open about expectations for this game!
