CAGD 495 - Stumble Sprint #4

During Sprint 4 of Stumblebumps, I wanted to accomplish various tasks, including fixing some of the bugs found in previous sprints and reworking some backend systems. During Sprint Kickoff, I was assigned to work on more systems and fix bugs. One of the main concerns or focus for this sprint was making better developer tools that the designer and the level designers needed to test the levels more efficiently.

Right after the Sprint kickoff, I first tackled Player Animations. Since both of our animators were being shared among all the teams, I knew the earlier we had that animation feedback, the better for them. This was my first big approach to handling character animations in Unity, and I wanted to make them look good so they fit our character controller and display the animations themselves. Because I wanted the animation handling to be outside of the main third-person movement, I had to implement a wrapper that would extract some values from the main third-person controller and send them to Unity’s animator so that the animations would be executed.

The next thing I worked on was the arena game mode prototype. The arena game mode is a last-man-standing mode in which the players bump each other and try to knock their opponents off the platform. From my previous prototype, I was told to set the number of lives a player will have during the level. Another thing that needed to be added was displaying the quantity of players alive. I also connected the arena mode to the podium scene so that the players would be displayed in the order of the last man standing.

After making this arena prototype more stable, I had an issue with some of the systems not being reliable, causing some inconsistencies when playtesting. So, I proposed to the producer and the designer to rework the game's backend so that we could have a more solid and stable foundation. After doing some research, I concluded that a more chain approach would be the best for the systems. This approach will ensure that one system will not start or initialize when the other, more importantly, has not yet begun. I concluded that using async functions will allow the systems to wait on each other and start the order needed for them to work. After testing, I found that this approach looked promising; however, I would need some kind of organizational chart to track which systems rely on, which led me to make a UML Diagram. After figuring that out, I started turning each system into a chained component of the whole system for that section of the game. After testing and debugging some minor errors, I achieved the background behavior key for the game to work correctly.

After having our systems running on a more solid foundation, I needed to reorganize the whole project and remove things that would not be used anymore. Luckily, I had the designer help me with this task since he had a better sense of what everyone was working on and what had been deprecated in the project. Because of this re-organization, we had to ask the whole team to push all their work to their parent branches until everything was together in our Dev branch. Because this process required everyone to stop working, we decided to do this late at night, and we managed to organize everyone’s work and provide their branches with the latest updates. We managed to complete this on time, and the designer was also able to update the documentation so that the whole team would be on the same page.

 

After this, I worked on the Development tools since the new system was in and everything was more stable. Previously, level designers had to go to another scene to load their level scenes. We needed to fake the player joining and introduce them to the new level scene. However, because we now had a chain approach, I could halt the system starting if a component was missing, so I could complete fake player joining while the scene was running and once the players were selected. They would be joined in the scene, and all the systems would be initialized. This idea was great. However, I wanted to make this tool the best it could be, so I started researching the Unity Editor and was amazed at what I found. Using this new knowledge, I developed the “Backup Kicker,” which allowed the developer to choose the player quantity they wanted to fake and join them into the scene and start the game. Something that was asked by the designer a while ago was the support for multiplayer players faked; that way, the level could be tested with more than one player. I also included the documentation on the backup kicker within the unity component.

Following up with the backup kicker, I was able to update the Level Debugger, which gave designers specific tools so that they could test their levels more easily. I also added the integrated documentation to the component, so both main development tools were consistent and easy to use.

Something that I also wanted to add because it was requested by the designed is that there was more documentation on how to use these tools, so I made separate google docs. I shared it in the team's google drive with everything that needs to be known before and after using these tools. Also, I took the chance to make documentation on the backend rework in which all the new systems are described in terms of their task and how essential they are for a scene to work.

Next, I worked on the spectating system, which meant that you were meant to finish the race and see where other players were. Thankfully I had already made a prototype for this system in the old arena mode,  so I just had to adapt it to fit with the racing mode and optimize the player view of spectating. A problem I encountered during this was players in spectator mode were colliding with the spectated player, and this was due to Unity’s character controller integrated collider not turning off, after searching for a workaround, the player spectating in race mode was now working.

 

During this sprint, we had a build due, and the designer asked specifically to have a feedback form at the end of the game so that any playtesters could access it when they finished. It would direct them to our playtest form and get valuable data. I was able to make this as modular as possible so that this feedback add-on could be added to the scene, made a few references in the inspector, and now it's working.

The next big thing I worked on was handling the options menu, which was a bit challenging since the options required changing the music volume across scenes and also limiting the game's maximum fps. So after doing some research on the audio mixer, I was ready to implement this system. I made a wrapper that would control the audio mixer’s output level so that the player could control different audio levels separately. That’s why I decided to divide the Audio into some sections:

• General

• Music

• SFX

This audio categories are very straightforward, General controls both SFX And music and the other two are children, meaning they can be turned off separately.

Finally I worked on solving some bugs and adding small additions to the game. I imported our 2D artist font and solved bugs ike the bumper momentum being kept when the player respawned on a checkpoint and adding the music that our Audio designer did to the game.

Overall this sprint was very productive and I was able to achieve my persona goal and the Sprint goal. There were a couple of problems that i faced during the development phase of this sprint however, it was overcomed and after some better communication we were all able to line up with the ideals and the future of Stumblebumps.