Welcome to my next work update for my work on 310Games’ The Krilling! This week I spent my time bug finding and fixing for a build we needed for an event we attended to show off our game! We are also preparing to launch, so it’s definitely time for some bugs to be squashed! This summary will go through each bug I found and how I fixed it. I was working with some team members while doing this process, but I will focus on the bugs that I fixed.
The first bug I found and addressed was one where the HUD slider that tracked the player’s progress in the scenarios was moving up and down when the player pressed A and D. This bug seemed to only happen if the player had clicked on any element of the UI beforehand. While this did not affect the actual value of the slider being tracked, it obviously destroyed any clarity for that hud element. The way I fixed it was quite simple, I just clicked on the slider in the scene, went into the inspector for the slider component and changed the “navigation” section to None.
The next bug I found relates to the possessable objects that get stolen from the player and returned to their starting positions by the staff members in the game. Specifically, the trash can possessable. Normally, the trash can fires a projectile to invoke emotion on the victims and moves with the momentum created by firing that projectile. However, when returned to its starting position by the staff, it would stop being able to fire that projectile. I found that a coroutine was responsible for the cooldown of the trashcan ability, which is fine except for when the staff collects the object and toggles it to inactive. It gets turned back on once the trashcan is replaced, but by then the damage is done. The fix for this was changing the cooldown from a coroutine to an asynchronous function, as seen here:
My next set of bugs don’t really have associated screenshots so I will just describe them. The ai (both the staff and victims) were constantly getting stuck on various parts of the map or they were walking through objects they should not have been able to walk through. We are using a Navmesh, so most of these issues were resolved by setting specific objects to static that were not properly set previously, or adjusting some positions of POI’s that the AI would path to to ensure they stay within the baked navmesh. The navmesh needed to be rebaked around 5 times across my entire process of bug finding as usually once one problem was solved another came up.
The AI also got caught on some specific objects in the scene when there wasn’t really room for them to move around them. For this, we just turned off a couple of colliders that shouldn’t really affect the player (and, after all, they are a ghost. Walking through objects is normal).
Another bug was that we were using an editor only method, but a quick google search told me that at least in the way we were using it, we could simply replace .Path with .ToString and everything worked as intended.
One bug I found but could not fix happens when we take our luggage cart and drive it to certain areas of the map. Due to many colliders existing in places where they shouldn’t/don’t need to (for example, rugs on the floor of the hotel), the cart will believe it is running into something where it is not. I reported the bug, but the environmental art is being overseen by someone else so I did not want to step on any toes. The problem did not arise enough to be problematic for a playtest, but we will address it soon.
Finally, not so much a bug but a missing feature, I realized that the work I had done on our scenario menu was incomplete. As it stands, we always intended for there to be a final chunk of the UI that appeared at the end of the game after all scenarios were complete that would guide the player to the final possessable, the boat. I had no way of labeling a scenario in such a way to indicate it was the final one and to perform different functionality with the scenario chunks mentioned in my previous work summaries. Or so I thought. I looked through the functionality of the Scenario objects as they were without changes and realized that we had a fifth option as an emotion needed to be collected:
Neutral! So, I decided since my scenario chunks didn’t need that emotion to function, I would use this combined with a specific required value (300) to be the trigger for the end of the game. I also realized in this process that my code did not address what happens when the ingredient list is empty on the chunks (and since this is the end of the game, no ingredient is needed!). So, in the process of adding this situation to the switch, I also made my code a little more robust by checking for the presence of ingredients. Here is the new code:
Over the course of bug testing I played through the game many times for multiple hours. The rest of my time this week was spent working on my next role analysis which will come out in about a month after this summary!