itch.io is community of indie game creators and players

Dev Log 2.3 - Production RAHHHHH

For the past few weeks, I have been mostly focused on completing our game's functionality, specifically the newspaper user interface. Working with Unity's built-in UI elements had posed great challenges for me in the past, as seen in previous dev logs. However, this time around has been quite easy-going. Because I have laid out the foundation and structure of the drag-drop functionality, it is rather simple to elaborate upon that. That being said, the hurdle now becomes "How do I store data efficiently and signal scene changes based on various certain conditions?"

After vigorous research and reiteration of the same system, this is what I ended up with. The news articles appear in the notebook on the right. Ideally, they would have notes/ photos that are indicative of the story contained in the article. These notes would remind the player on what stories they have collected and help them decide which article would go into the newspaper. 

While developing this, I really trying to think of ways to make it as modular as possible, meaning that I will not have to go through the code to change it once the stories are added. After trial and error, I found that the most understandable and efficient method, at least in my opinion, was to store data within the article objects themselves. That way, when I drag the articles onto newspaper slots, I will have a way to access and display the information on the screen. Additionally, this means that I can spawn more or less articles and the amount of information available to me would also change accordingly.

Now, the issue is, that I need a way in which I can access which news articles were chosen in a future scene (so that I can trigger branching story paths). To do this, I need a Game Manager, one that will be present consistently throughout the game. Sounds simple enough, but I cannot store and retain GameObjects across multiple different scenes. At first glance, Don't Destroy On Load may seem like an obvious answer. However, as I dug deeper into the system, it didn't seem to be very effective, because I would end up with duplicates of articles and a full game hierarchy by the end. 

This was when scriptable objects came into play. It's not a very creative use of scriptable objects, but it is novel since the feature was created to store data across different scenes in Unity. Each scriptable object represents a collected article (similar to an item). Articles have display text, popularity score, appearance, and story flags data all embedded within so that I can access that information whenever necessary, as long as I have access to the article scriptable object. What this also means is that implementing new articles would be a lot simpler. I would only need to add new scriptable objects and story flags!

Article Scriptable Objects store flags, the main distinguishing feature between different stories. We originally had a flag manager that flicked certain booleans on and off but by day 5 of the game, that wouldn't be feasible (unless I write a line that checks 50 different booleans). So I changed the flag manager to store a list of collected story flags instead. Those flags will then determine which articles will spawn in the newspaper scene. 

Besides all that, I also added an animated popularity meter showing the player's 'score' once they click complete. I used the LeanTween Library to animate the popularity meter. 

Overall, I felt like the past week was very productive. As I delve deeper into the game as a programmer, I find it quite refreshing to be able to problem-solve and see my code function in real-time. It is a very rewarding experience, to say the least. I've learned a lot and I am quite content with how it turned out. 

Read comments (2)