CAGD 495 - Stumble Sprint #1

For CAGD 495 (Advanced Production), I was assigned to work on a group working on the game Stumble. Stumble is a competitive Obstacle Course game in which you race up to 4 players to reach the finish line. This concept stood out to me, and once I was assigned to my group, we quickly started the project. Fortunately, I was assigned to do the programming for this project, which was my first pick role.

My first task was to set up a GitHub for the project and invite every team member to it. I started by creating the repository and adding a Unity Project to it. Next, I added everyone to the repository. This was easy since the designer and producer had a spreadsheet where everyone put their contact information. They also managed to ask everyone for their GitHub-connected email, which facilitated my work.

After the first programming meeting with the designer and producer for Stumble, it was clear that Sprint #1's target was getting the player movement working and implementing some of the base game mechanics. The catch to developing the player controller is that the designer wanted to use the Character Controller, which I've never used before. Usually, I make player controllers using RigidBodies; however, I was interested in taking the challenge.

Using Unity's new input system, I had to set up the Input Actions and assign the controls the designer assigned in the Player Controls document. After that, I had to make the Player Controller, which will take the values inputted from the player and transfer them to movement. Using the Character Control integrated move function was easy to accomplish. What became a challenge was incorporating a camera that allowed the player to rotate with their inputs and make the movement relative to the camera angle.

Now that the player movement was working, it was time to work on some designer-requested variables. For the player controller, something that needed to be implemented to have a better feel for the game is to have an acceleration and acceleration overtime on the player's movement and have the friction force and the acceleration magnitude be customizable to the designer's liking. After implementing these mechanics, the player control became smoother.

After finishing the basics of the player movement and controller, I got requested to change the character's camera sensitivity and have that as a value that can also be adjusted by the designer to fit the player's liking. Cinemachine has integrated values into this, and since I already had a camera reference for the player movement, I just had to get the cinemachine component from that and adjust the speed for the x and y values of the control. 

With that also came another feature requested for the player's movement: jumping. Jumping itself sounds easy but hard to implement because it deals with checking if the player is grounded. The Character controller does have an integrated grounded function; however, for the current player, it was not accurate to where the player was on the scene. In this case, I started developing my grounded function to shoot a ray cast below the player and check how far they're from the ground. Until I got a decent final product.

One of the hardest things to implement is the dive mechanic. This mechanic allows players to dive or throw themselves to the floor and enter a prone state. What was challenging about the dive mechanic was the collision detection once it went horizontal. Character Controller does not allow rotation, so I had to come up with a replacement, meaning once the player dives, a new Collider appears, which fits the size of the capsule. Another error with the testing was that the "isGrounded" check no longer worked once the player was in a dive slate. Once this was fixed, I also had to implement the Bump mechanic, which was about a Player Diving into another player, triggering a bump, and pushing the target player in the direction the bumper is looking. This bumper was made as modular as possible, making a bumper interface that can be implemented in any collision detection, and it will check if the collision object implements the bumper interface. I had a bit of trouble with the math of the angles, but I got it figured out and got a working bumping mechanic.

 

During this time, the design and producer requested that I install the Unity Universal Render Pipeline. After some quick research and help from the designer, I figured out how to upgrade the project to URP and fix all the materials. After that, I had to standardize URP in all project branches on Github.

Finally, the last thing I worked on during this sprint was the local multiplayer, and it was by far one of the most challenging to implement. I've used the new input system to check for multiple inputs, but I have never done so so that they each have their own camera control. My first struggle came with assigning different player inputs to different players. After that was figured out, I was able to test the multiplayer for up to 4 players at once, and if there are 3 players, a UI will appear on the 4th Screen, which can be modified in the future. I also had to figure out how to set up a split screen with the camera setup and screen organization.

Overall, this Sprint was great. I got a lot of the basics done, which was what I was aiming for. I also learned a lot about the new input system and local multiplayer controls. I would have liked to finish other core mechanics for this sprint, but I ran out of time. I had great communication with my group's designer and producer and could understand the project's vision early in the development.