Blog Post 6

 

CAGD 470 - Video Game Production

Rune Chronicles

Blog Post 6

    This is the sixth installment in the Rune Chronicles sprint review. Our team has been hard at work getting our changes finalized and moving into bug-crushing mode. In order to prepare for the final stretch, our team's goal was to finalize all game systems, behaviors, and levels. We began our sprint by assigning a conservative 25 points at kickoff. This was to allow for plenty of time per person to identify bugs or work needed in order to further polish the game systems. As the team worked on their assigned tasks, I assigned Preston to dive into the game and start tearing it apart looking for bugs. He provided us with two different documents outlining the features that were not performing as expected and issues that he encountered during gameplay. Using this information, we were able to quickly get tasks assigned to tackle this list, ending with a total of 50 points being assigned by the end of the sprint, and 48 of these points being completed before sprints end.

(Data presented is of tasks being verified after completion)

    The first task that I began working on was further improving the feel and behavior of our player character. Feedback from our second electronic prototype build echoed what we were already feeling. The character just didn't feel smooth, nor did it work very comfortably over rougher areas in the terrain. My first step was trying to identify why our player was working so unreliably. Working with Colin and learning more about how our nav-mesh was set-up, I was able to find that by moving the player with velocity, our player was fighting against the connected nav-mesh, which acts as a layout on our terrain indication where the player (and enemies) can move. To improve this, I removed the code that was moving the player using its rigidbody, and instead connected a Unity Character Controller that we can influence using the input direction. This, combined with a navmesh "Offset" let us place our character slightly above the terrain, which vastly improved player movement and stability.

    The next few issues I decided to tackle involved our particle effects, and the amount of strain that they were putting on even top spec PC's. These particles were just light (little) visual effects that were being CPU driven. They were designed to spawn as destructible props were hit by the player, but they dropped/froze our framerate for a couple of seconds after being destroyed. After looking into a few of our destructible prefabs and their attached particle systems, I was able to find that they were set to spawn 1,000's of particles at once. On top of that, it appeared that they were duplicated multiple times withing the prefab, leaving us with upwards of 10,000 little particle images being spawned instantaneously (or not depending on in it froze). By spending a few minutes with each of our particle systems, I was able to clean this redundancy up and set it down to an appropriate number of particles that wouldn't affect many most machines performance.

    Before hopping over to more extensive tasks, I was asked our other programmer, Colin, to modify our Singleton parent class to allow for multiple load behaviors. This was a very quick fix and was solved by adding a boolean and conditional statement that checks to see if we would like an item destroyed on load, or not. This let us separate our managers much more effectively when connecting our menu systems. 

    Next, I moved onto creating save functionality within our game that would allow for players to see how many crystals they had collected within each level. We are using PlayerPrefs to store this integer, and then check for the saved data when displaying the level selection menu to the player. This allows us to easily check for this data from any scene. While testing this feature after implementation, I also noticed that there was an issue within our level select screen that was causing buttons to overlap and blocking sections of content. I fixed this by going through our menu prefab and cleaning out old canvas UI objects, and then anchoring objects to their appropriate corners. This left us with a cleaner level select screen.

    As the sprint started to draw to a close, I was able to also fix our spawner behavior. Up until now, we were having issues with spawning the enemies onto a navmesh without them being stuck in place or unable to reach the player. By reworking the spawn transform, and getting some help from Colin understanding the navmesh, I was able to get enemies spawning based off of their prefabs.

    Finally, I closed out the sprint by reworking multiple prefabs colliders and collision detection logic to be more uniform across the project. We had some systems working off of collision, and others off of triggers. This caused a few instances where collisions were calculated differently than expected. By reworking the enemies, spawners, the player, and the projectile, we were able to improve our collision detection by a lot. This helped my implement a knock-back feature when enemies are struck by the main player.