FreeRoam & Multiplayer
One of the many things that make up the gameplay concept of Project Styx is the variety of movement styles the player shifts between. Along with the spline-based movement, I also wanted areas of the game to give the player total control of their character similar to third-person action games like Kingdom Hearts and Devil May Cry. Modern Sonic games such as Sonic Generations also have a movement style switching feature in their games, where they go from an on-rails racetrack to a side-scrolling platformer. To achieve a similar effect of movement style switching in Project Styx, there are a few obstacles I had to overcome.
To handle the transition between spline-locked movement and free-roam movement, I’d have to take the same approach as I did with chaining multiple splines together. I created a new blueprint that would feature a box volume that the player will overlap. There will also be arrows pointing in opposite directions to determine which way the player is entering the volume. When entering the volume facing a certain direction, you could either lock your movement to the spline or free yourself to move in any direction and have camera control. Regarding the camera, that takes us to this next point.
To support the FreeRoam movement, I’d have to overhaul the camera. I would separate the camera from the player into its own blueprint, so that the player can move in any direction and the camera wouldn’t be forced to rotate. I will later add the setting to allow camera follow so that the players who prefer it can use it. Separating the camera allows me to reach my desired effect for free-roam movement and camera, but also gives me more control as a developer to craft just how the camera will work throughout the various gameplay scenarios. One issue when implementing this however was ensuring the effects of the player’s movement style would be reflected in the way the camera functions. I would include a setting in the camera the same way the player has a setting for movement styles. The camera would function like before for the spline-locked movement, but will unlock when the player enters free-roam areas, making it a seamless experience.
Duplicating the functionality of the spline-based movement actions over to the free-roam movement was the last thing I’d have to do to fully implement the free-roam movement to the current state of the game. The features I’d copy over include: Jumping, Plunging, Slam-Jumping, Dashing, Backflipping, Object Targetting, and Zipping.
One of the remaining issues really is this one bug that stems from zipping or dashing within spline-locked areas. When the player zips to an enemy, they will sometimes get yoinked back a few feet. This is likely due to some issues within the spline-reassignment logic. This also affects the player when it comes to entering movement style transition volumes. If the player were to exit a spline-locked area with either a dash or a zip, the next time they would reenter the spline-locked area, the player would be yanked forward. This is a matter I will explore into more in the near future.
On the side, I’d also work out a bit of the login authentication interface to utilize some of Hamilton’s network implementation for a cleaner login screen. Hamilton added some functionality to allow the game to connect to a specific server for when we have a dedicated server to host the game’s online server.
Learning to do Multiplayer Replication has been a hell of a time, especially due to the custom systems I’ve made for the project. A lot of hours flew by before I knew it. It took over the span of a few days just to get multiple players moving about in the same scene one everyone’s screens. However, the problem that lingers is that the camera is broken when playing online, due to some replication bugs regarding a separate actor for the camera. The reason I had a separate camera was for a modular camera system that would give level designers some more control. However, it created too many problems in a multiplayer environment since the client instances of the game could not seize the camera view from the modular camera. I would later rebuild the camera back inside the player’s blueprint. Players can move around in each others screens perfectly, though the multiplayer movement remains a little buggy from the camera rebuild. But these bugs are more manageable to handle. The floating objects also currently do not sync between games, but that’s something I can handle at a later point.
