CAGD 495 - Stumble Sprint #2

Starting Sprint 2 for Stumble, I wanted to do many things this sprint, including getting the bumpers that will push the player and getting the transferring of the Connected Players from the Lobby to the Game scene working. During the sprint kickoff, I negotiated this with my designer and producer, and they agreed that it should be the focus of this sprint. They also added some fixes that they wanted in the player controller to give a smoother gameplay experience. More in detail, some changes on inputs for the player and also timers that will prevent the Player from performing actions quickly.

The first thing I started working on was the bumpers, and using the GDD, I had a general idea of how they needed to interact with the player. After researching how to achieve this, I needed the bounce direction to be perpendicular to the bounce surface. Finally, I came to a function inherited from Raycasts, in which you can get the direction normal from the surface the Raycast hit. Knowing this, I managed to develop my first prototype.

Shortly after developing the prototype, I implemented the bumping interface that player bumping uses to create working bumpers. I also added an upward force that the designer could choose to add if they wanted the bumping to push the player upwards.

After the Bumpers were done, I started focusing on the multiplayer connection. The first thing that I worked on was selecting the amount of players desired. It is limited to a minimum of 1, and a maximum of 4. After that, I had to make a visual way for the player to know when a new player would connect. After talking with the designer and thinking of future player customization, we concluded that the players needed to be present on the menu. I also knew that we would need some way to save the player connection data, like is the player, Host, what is the character name of the player, what’s the input scheme that the player is using, and what device is hooked up to the player. This is made so later, I can pass this information to a game mode scene and that will manage and spawn the players. Another thing I found crucial for this was introducing events that trigger when playerJoins, playerLeaves, playerDisconnect, and playerReconnect. Last thing I wanted is a way for the player to know which input device is connected to which character in the game, so I added Jumping in the lobby. The last feature requested by the designer was to add a button to allow the players to re-select the player quantity, making all the current players disconnect from the game. This is how the Lobby turned out:

After the players were able to connect to the Lobby, I needed to spawn in them in the game scene, and as easy as it sounds, it was not easy. The first thing I worked on for it was getting the player data into the game scene, which I was able to achieve using Don’t Destroy on load. Next up, I needed some kind of playerManager that would be in charge of spawning the players into the scene and updating the player data for the player input and the player assigned to the scene. The first problem I encountered was that the cameras did not display anything once the player spawned. This was due to a bad setup of the camera and the virtual camera; changing the setup fixed the problem, and now the cameras are displaying. The next problem that came up was all cameras focusing on the same player; after some quick research, I managed to solve it by creating different Layers for each player and assigning those Layers to each player as they joined.

Next, I worked on the respawn system, which was meant to respawn the player whenever they enter an area; they will be teleported back to the spawn and also the checkpoint system which should keep track of which player is at which checkpoint. Something that I wanted for the respawn system was to allow the designer to add as many spawn positions as they wanted inside the checkpoint. So, I started working on the checkpoint system and keeping track of all the checkpoints. To make it easier for the designer, I made it so the first checkpoint is where the players will spawn, and the last checkpoint is the finish line. The last checkpoint doesn’t need spawns since it's the finish line, and each checkpoint must have at least four spawns. A problem I faced during the development of the respawn system was that once the player hit a kill zone, the player would not be teleported to the spawn; this was a very hard thing to fix since I didn’t have a lead of what the possible cause for the problem might be, all the systems were working in place and working as intended except changing the player position. After diving into some forums, I came to realize that my problem was related to the Character Controller and to change the position accurately, the Character Controller had to be turned off, the position changed, and the Character controller back on. After fixing that and adding the first spawn compatibility with scene switching, this is how re-spawning turned out:

Something that I personally wanted to implement in early sprints was the support for cosmetics. I wanted to implement this early because the earlier we can lay down a foundation for cosmetics, the easier it will be to implement them. So, after getting the designer's approval, I started working on the color-changing mechanics for the characters. After creating a module that keeps the data of the player’s chosen cosmetics and attaching that to the already made Player Data, the base of the color-changing implementation was done. Now, I needed the color to be applied once the player joined the game scene, which was fairly simple by subscribing to the player joins event and getting the player data from that event call. Finally, the designer asked me to implement a way for each player to have a different color and not be able to have the same color as another player. This was fairly easy to implement by checking each player’s color and seeing if the next color in the list was in use. This is the final result of the player's choosing:

Another feature that needed to be implemented was pausing the game whenever one of the player’s input devices disconnected, so that was fairly simple to implement. I had a Game Manager subscribe to the player input disconnection event and use that to pause the game. I also needed to keep track of the loss of more than one player and display that in a UI. Finally, after the player reconnects, the game will resume, and the race will continue. This is how player disconnection turned out:

The last thing I worked on during this sprint was displaying a scoreboard at the end of a level. This had a challenge which was keeping track of the exact milliseconds that the player crossed the finish line. Fortunately, I was quick to find a way to keep track of time and once the player crossed the finish line, it will keep that time and save it. After all players crossed the finish line, it will display which player crossed first and display their time.

Overall, this sprint was very productive; I achieved my personal and the sprint’s objectives. Completing the local multiplayer is still challenging but achievable. I’m really proud of making my code modular and future-proofed as much as possible. Which hopefully will make the experience easier in the future. This turned out to be a great sprint.