Welcome to my next Blog post for my work on 310Games’ The Krilling! This week I will be working on implementing a lot of the past scenario systems into a HUD so that the player can have quick access to their current objective and track its progress.
The main goal of this week to get the HUD displaying in some form or another the required emotion for the player to collect, and then swap properly either when a scenario changes or when the requirement is changed within a scenario. As a reminder, we have 3 game events that handle our scenario functionality currently, UpdateScenario, CompleteScenario, and ChangeScenario. UpdateScenario is where we currently indicate a change of score (and is where I my first attempt at updating other things about the HUD will be), CompleteScenario is where we indicate that a scenario has been finished, and ChangeScenario is called after CompleteScenario to actually swap to the next Scenario. I first began this implementation by adding a call to UpdateScenario after we change the emotion requirement.
Combined with a call of the same event after the score is updated, this should give me all the information I need to get an implementation of the hud functioning. Next, I made a HUD.cs script and put it on our HUD prefab. This will be the script that controls the HUD and updates it with gameplay.
Now, the only problem with having multiple functionalities connected to the same game event in this case is that this method that handles that event will have to be a little more complicated. However, since this event also always passes the entire current scenario through it, we can just make a series of if statements that can check for and handle any changes that may occur. Here’s what that looks like:
You will notice that I am using not one but TWO of the game events I mentioned previously. I tested the code as you see it now without the OnScenarioChanged event and on initialization of the scene it would not set up the HUD correctly. However, as you can also see, I can set the UpdateHUD method to handle multiple game events, so I can do the exact same thing I had planned, but make sure it is handled in all cases where it should be. You may notice the comment saying “TODO REPLACE”. That is because this section of the code will be handling the art assets that display which emotion the player currently needs to be collecting. For now, since I do not have those assets, I will just be setting the color of the slider handle to the corresponding color of the emotions in the game. Later, this section will be replaced by displaying the proper art assets. This portion of the code was also just a test, however, so I will now be writing a switch statement to handle each of the 4 possible emotions the player could have as a requirement. That looks like this:
I would normally use color codes at the very least for something like this to have better control over it, but again it will ultimately be replaced anyways and this is more of a proof of concept and blueprint of what to do later, so it’s ok. Now, we test! I will be testing this functionality across 2 test scenarios. Each one has 2 requirements each, and they cycle through each of the four emotions. The second scenario also has a different required amount of emotion for each emotion. This will ensure that this system can handle initialization (start of game), score updating, swapping to the next requirement after the first one is filled (and resetting the bar), and swapping to another scenario. I will share some screenshots showing these features working, or failing if they fail. Here they are:
Initialization: Success!
Display score via slider: success!
Swap to next emotion after completing first: Success!
Next emotion tracks on slider correctly(slider reset): success!
HUD Transitions to next scenario correctly: not quite…
So, a failure did indeed occur, and right where I expected one would be if it were to happen. Upon slightly further testing (mostly on accident), if I collected another sadness ball after this last screenshot, the slider would indeed transition to the correct color. After this transition it would also track the second scenario perfectly and swap properly. So, the issue is specifically only on the changing of scenarios, and it’s only a partial issue as that (because as you can see in the last screenshot, the VALUE of the slider reset, just not the color). Based on how I have written the method to interact with the game events, my best guess is that the updating of the score at the end of a scenario and the changing of the scenario are getting called at basically the same time, so now I need to handle a race condition and make sure that the changed scenario is prioritized. For this problem I once again reached out to Zach as he is the main expert on the Scenario system. I had tried a couple small things but nothing worked so in order to avoid changing someone else’s system drastically, I figured I would enlist his help with it.
AND it turns out it was a problem with how I created the scenario.
You will notice that the first requirement is a neutral emotion with 0 required amount. This would cause the color problem I was seeing and would also make sense why after I had collected a single emotion of any type it would move on to the proper emotion. The problem is now fixed and this serves as a reminder to always check the simple things too!
As one last step on this (very basic and preliminary) implementation, I went through the slider child objects and found all of the image components and toggled off “raycast target” as we don’t need the player to be interacting with the slider with the mouse.
That is where the HUD work finishes for me this week. To wrap up the week, I just made sure we had 4 different scenarios that were all connected to a different wall in the game right now so that the game is “playable”. We will definitely be changing things about these scenarios later, but in the case where we needed to play through the entire game, it should now be possible in that sense.