CAGD 495 - Stumble Sprint #3

  Starting Sprint #3 for Stumble, there were various things that I wanted to get done; personally, I wanted to implement the core game loop and get started on the arena for the game. During the sprint kickoff, there were various priorities that the designer and producer wanted me to get done at the beginning of the sprint, which were modifying the player controller further and changing some keys; these changes were based on the playtests conducted at the end of the previous sprint. It was mentioned to me that during this sprint, we were going to have an animator & rigger for the team, so I wanted to get animations in the game.

So, the first thing I started working on was the priorities and adjusting the player controller. I started working on a delay for the diving mechanic. The biggest problem during the playtest was that players were unable to cancel the dive and dive midair again; if you were quick enough, you would get boosted forward just by tapping space quickly. I added a check that prevents you from diving if you are in midair and already have dived. This means that once in the air, you can only dive once, and you cannot dive again until you touch the floor. The other change to the player controller was separating the dive button from the jump button; thankfully, in the previous sprint, I saw that this might be brought back, so my code was not heavily modified, and changing it back was very easy.

Next, I worked on replacing the capsule with the stumble bumps model; as easy as this may sound, this brought a couple of problems. The most notable problem was with the cosmetic changer, which allowed the player to switch between a set of colors. Luckily, thanks to the use of Scriptable objects, it was very easy to fix. I just needed to change the material to match the material for the stumblebumps, and thanks to our modeler, there were four stumblebump colors. This is how that turned out:

After making these changes, I wanted to work on two mechanics that were meant to bring more life to the game: the race countdown and the level showcase before starting. The first I tackled was the race countdown, using sprites and and Image it was fairly easy to accomplish and using Unity’s animation system, I was able to make a small animation and repeat it, changing the sprite of an image. For the level showcase, I wanted to be able to make some kind of cinematic controller. A lot of time was spent researching what would be the best approach to handling the cinematic controller, and I found out that Cinemachine has a tracking camera that is able to follow a set path and have a focus point. Combining this Cinemachine camera and the Unity timeline system I was able to achieve a smooth cinematic at the start of the level that will show 2 parts of the level and then show the finish line. Finally, a smooth camera transition was added so that once the cinematic ends, the camera will go back to each player separately.

After having both the countdown and the lobby cinematic, I wanted to work on the prototype for the arena game, in which the players will have to bump each other off a platform, and the last one standing wins. Doing the arena level was not as hard as I thought; the first thing was to make a spawn manager for the arena so the player would start in the set spawn positions. Next I had to make some kind of spectator system in which when the player dies they will be able to spectate another player but not control it.

With this prototype done, I wanted to put some effort into making the game navigation easier for the team so the level designers could have an easier time playtesting the level and the designer navigation and adjusting some core values. The first thing I worked on was transferring the movement setting variables to a scriptable object; that way, the designer can have multiple instances of the player movement and apply them when needed to the player controller, and that way, there is no need for editing the script. Next, I started working on the level designer tools. I added a dev scene in which the level designers are able to type whatever scene they want to be loaded or assign it to their shortcut options and add load any scene with a player as if they came from the menu. This is what those tools looked like:

After developing these tools, I noticed that the project needed more structure from the programming side. After talking to my designer and producer and getting this idea approved, I started reworking the game's backend systems. There were many major changes done, including how players were handled, optimization of scripts, the addition of more modular scene types, a game controller from which backend systems rely, and a global player-manager that can be added to any scene and will spawn in the players brought over from another scene as well as assigning values. During this whole rework process, I started talking to the designer about what should the UI of the game look and feel like; that way, the UI could be implemented as what the official look for it would be like, and that would also allow the UI artist to replace whatever is needed. This is how the game rework turned out:

During this time, I also had the chance to work with the animator and rigger and add working animations to our Stumblebump character, which turned out great. In the future, im looking forward to implementing blend trees to make the animation transitions more smooth. As I implemented these animations, I started working on the cosmetic choosing screen. At first, I didn’t know how to start this system, but I figured it out by making a small addon to the player controller that uses the selection input map. It was going to be great for changing cosmetics instead of giving each player UI control. Using some Icons and some interpolation, I managed to make a smooth player cosmetic selection mechanic that allows each player to choose their own cosmetic. This is how those two look like:

Overall, this sprint was very productive, and I got to work on a lot of stuff that I needed to be tackled as soon as possible. The whole re-work of the system was challenging but it definitely improved everything happening behind the curtain for the game. Some minor improvements could have been implemented; for example, the re-work wouldn’t have been needed if I had been thinking of making more modular code from the beginning. Working with other members of the team has widened my view from just programming, and it has been a great time putting everything together. I’m delighted with where this project stands right now, and I hope to develop more fun features in the future.