Welcome to blog post 4 of my programming work on 310Games' The Krilling! This is also the first blog post I am making that will be posted on the website (however when I can I plan to go back and post my previous blog posts). This week, the plan WAS to work with another programmer to redesign our scenario system to make it work within our new goals for the game, but when I mentioned this problem last week, the person I was going to work with decided to just go ahead and fix it themselves. This is partially because they had originally made the system with the idea of changing it later when we had a clearer view of the system, so they saw it more as finishing it rather than rewriting it. Either way, that allows me to to get my work done much faster this week! Due to other large turn ins this week and my fellow programmer working a bit ahead, I have less to do this week than I had planned for. My main goal is to be making sure the scenario system will acknowledge when emotions are collected and then properly destroy barriers when certain scenarios are complete!
First, I needed a way of flagging when a scenario would destroy a barrier. Knowing that our system works on a lot of signals and listeners, I figured when we signal that a scenario is complete I could just have the barriers listen and then check if the value they have been given matches the one on the completed scenario, and if so, they will destroy themself. So, within the Scenario.cs scriptable object we have, I wrote this variable:
This allows us to keep this value protected while still accessable. Now, whenever a scenario is completed we send out a signal with the entire scenario attached (in a manner of speaking). That way in cases like this we can access the finished scenario one last time to make sure other systems also know what happened and to which scenario.
Right now and for testing purposes, the barriers already destroy themselves when a player hits Q. This was a proof of concept so we knew we had the placement correct and so our artists had an object in the scene to start working with without impeding everyone else testing implementations into the scene. Now I can just add a listener method and it should work! This is what I added:
So now, when I set the barrier's value to 1 and the scenario's value to 1:
I can go into the game and test if this all works! Here is the before:
As you can see, I have not collected any emotion yet. Then, I go and collect 20 anger as per the listed requirements you can see above in the scenario and…
The barrier went away! This is exactly what we wanted. Now, it is as simple as making all the scenarios we want and labeling them appropriately. This system also allows us to make more scenarios later, place them in the queue of scenarios being handled by a world state manager, and the barriers will still unlock after the previously specified scenarios.
That is all for me this week. Once again big thank you to Zach, my fellow programmer who was able to help me out with the scenario system last week who allowed me to very efficiently get this work done now.