Krilling Dev-Log #2

Published January 28, 2024
Advertisement

After taking close to 2 weeks off due to being sick I am back working and ready to post a small update. This week my team decided that the AI was in a solid state and that we had other outstanding work that needed a higher priority. Most importantly our UI Programmer and artist were working on creating the UI for the scenarios where “scenarios” will show up on the screen and players will have to collect the right amount and types of emotions to complete it. While our UI programmer was working it came to our attention that this system was never finished in the first place. So this week I went back to that system and rewrote it to the new specifications required by our UI team. The system at its core relies on these scriptable objects that hold the information for a given scenario.

These are then held by the scenario manager who handles adding values to the scenario, completing scenarios, and moving on to the next scenario. This is where a lot of functionality was missing as the scenario manager never actually moved on to another scenario as you can see here.

This would be trivial on its own but there were some other issues in the system including it being difficult to get data from the scenario, scenario data being saved between play tests, and new requirements from the UI team, most notably the need for the emotions to be ordered so players will need to collect the correct emotions in the correct order. So I went about rewriting most of this system to what we needed. My goal was to make it as easy for the UI team to interact with including creating scenarios easily and getting information from scenarios easily. My first step was to create a new class specifically for holding information about a given scenario requirement. This class handles one requirement meaning 1 emotion and 1 required value. Then in a scenario, a list of these requirements is created which acts as the order in which they need to be satisfied. This class is simple and just has methods for getting relevant data such as current values or if the requirement has been satisfied and a method for adding value to the requirement.

The important part is that by adding the [Serializable] tag to the class it allows our UI team to easily create these requirements in the inspector. When adding an element to the requirements list they can edit the values for the requirement right there.

I then set up the ScenarioManager to keep track of things properly including proceeding to the next scenario, and informing the game event system when scenarios are completed, updated, or a new one has started. Also to avoid the UI team from having to delve deep into the data of the scenario I added properties for getting relevant values they might need.

This is to avoid our team needing to write lines such as scenario.CurrentRequirement.CurrentValue, and overall require more knowledge of the system than is necessary.

That is everything from this past day or so since I have recovered. Now that I am healthy and ready to work I hope to have more completed to share next week on what will this time be actually weekly updates.

0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement