Joseph Roberts

Final Game

Overview:

This new version of Those Left Behind is predominantly built around the resource management mechanic, so there are a lot more features such as camp upgrading, resource generation, and progression is based around this mechanic. However, these systems are modular with a different script specifically designed to manage them. The reason for this was to make the project scaleable and more reliable as it eliminates the chances for script conflicts like I had in my previous game. The core game loop now revolves around collecting resources overtime and then building and upgrading the camps to improve production rates all while managing various tasks and talking to each character to unfold the storyline. 

Here is the final prototype of Those Left Behind and additionally here is a detailed look into all 8 scripts that power this game with snippets of the most important methods and functions:

Technical Breakdown:

Before I get into the breakdown, I wanted to go over one of the major challenges I faced and how I ended up solving it. One of the most prevalent issues I faced until the end was ensuring the data persisted across the different scenes. As I would find out, This is a very, very common issue that occurs in Unity development. To make the game perfect, I needed to find a way to guarantee that when a player would talk to any characters and change scene all their progress would be saved in the camp scene, such as the camp states, resource counts, and task completions, and once they return to the camp scene all of this data would reload to ensure a smooth gameplay experience. My solution to this was to create a SceneTansitionData singleton for each play session that persisted across the scenes which made use of the PlayerPrefs i created which were in the SaveManager that allowed for long term player input data storage. Having to manage these layers of saved data required me to utilise the dictionaries and key management to avoid conflicts and data loss. Now, this seemed to be the logical way to solve this issue, albeit complicatedly, however, I ran into an issue of the camp states not being saved. After Ross had a look and my scripts he found a singular line of code I had written that was causing this issue. This line of code was this: SceneTransitionData.Instance.ClearCampData();. Now, it may seem that this was silly to implement, however, I did think this was still necessary as this was my original fix to an issue I was having with the camp state data not resetting when I restarted the game. All it took was calling this after I had saved each camp’s data for everything to work. Here is what they final fix looked like:

I obviously had numerous other issues / bugs that i had to face such as these that i documented after each night of testing however, they all had simple fixes such as hierarchy clashes, script clashes, and mainly the inspectors not being set up correctly for each Gameobject Managers. But here were the main issues i was left with on the final nights of finishing the games development:

SaveManager:

The purpose:

  • The save manager job was to create one area where the persistent and temporary game data storages by using PlayerPrefs and in-memory dictionaries whilst also controlling the session and permanent saves. 
  • This snippet demonstrates the use of this script as it uses PlayerPerfs to have a simple persistent storage of key data like the resource counts. This dual system or persistent and temporary session only dictionaries is crucial as there is certain player data that should stay consistent between scenes like the total resources, camp states etc. Using singleton patterns ensures the data is accessible and is in a consistent state. 

CampManager:

The purpose:

  • This script, as you may be able to guess, manages everything to do with the camps such as the building / upgrading logic, UI interactions, and the real time resource generation.
  • This shows the build camp logic. This modular camp system with UI and resource attributes allows for a flexible, scalable camp design. So, when you upgrade the camp it increases the production speeds which gives the player a clear path of progression. 

GameManager:

The purpose:

  • This was the core game state handler that tracks the day/week cycles, resource amounts, scene transitions, and the fail / restart conditions.
  • This snippet shows how i track the day/week cycles. The Day/Week gets tracked to coordinate with the narrative progression and resource checks so that the UI stays consistent. It saves the states across the scenes due to Unitys system unloading all game data when a scene is changed.

NarrativeManager:

The purpose:

  • This controls the different characters’ dialogue scripts and expressions whilst managing player choices and then once each script is complete it will update the games system so that it recognises the task as complete.
  • This bit of code demonstrates the integration with task manager to determine when a task should be marked as complete by showing when the text is getting displayed. This is important as there needs to be a tight link between the story and gameplay.

RestartGame:

The purpose:

  • Simply manages the UI to show a restart button that triggers a full game reset.
  • A fail panel with a button is required to allow the player to reset progress in a clean manner. This ties in closely with the GameManagers ResetGame method that ensures all game state data that has been saved to properly be cleared.

SceneTansitionData:

The purpose:

  • This was another way I have created a session-persistent storage for resource amounts, camp states, and progression across the different scene loads.
  • As i’ve already mentioned, Unity destroys all objects when changing scenes. As such, this singleton stores all crucial game state memory and then reloads it when its called on. 

TaskManager:

The purpose:

  • This manager coordinates the task system, manages the prerequisites, dialogue states, resource requirements, UI updates, and completion.
  • This snippet is a small section of code that is essential for the game to function as it ensures that there is a task progression and allows the player to actually complete tasks when they’ve finished the requirements. This script helps to provide a dynamic UI feedback, and ensures it saves task states to the PlayerPrefs to ensures the player can progress through the game.

TimeController:

The purpose: 

  • Controls the games clock, day progression, UI time displays and the speed up function
  • This is another one core feature and this snippet shows the function of the time being calculated and then being updated each tick so that the time clock functions as a clock. It also allows the player to fast-forward to decrease wait times and improve overall player engagement. 

Summary:

There are another 5 small scripts that Anna had to implement when designing the UI but these 8 core scripts are the backbone of a complex but well structured resource management game. Each script has it own necessary important role:

  • SaveManager and SceneTransitionData are in charge of handling the persistent data in an efficient manner that is crucial when loading scene in Unity
  • CampManager, TaskManager, and GameManager coordinates the core mechanics; resource generation, player progression, and the game state
  • NarrativeManager created the storyline and brings life to the game through the different character dialogues, expressions and player choices
  • TimeController creates the sense of urgency and progression by creating day cycles

Although it would probably take me a full semester just to go back over and in detail explain each function, this breakdown demonstrates how interconnected and complex these scripts are and reflect the challenge I went through to create this interesting idle game in 3 weeks. Please look through my entire scripts to understand the sheer quantity of coding that went into developing a seemingly small UI idle game. If you don’t have any access to them I will include in my final page a github link to the projects folder.