As the director of INARI, I guided the game’s production by identifying project needs, assigning and keeping up with team members’ weekly tasks, and leading weekly meetings. Since we were a small team, I also took on other different roles, such as programming and creating concept art, to best support the team and reach monthly milestones.
Checkpoint and Save System
Drawing from the knowledge I gained by working on Brain Agent’s cloud save system, I created a simple save system that could be used to respawn players at the checkpoint they passed last. This would allow for progress to be saved without creating any dependencies on Unity’s systems, and opened up the possibility of recovering a player’s save data in the case of a game crash (which I noticed that other capstone games in the past were likely to do). This would allow for the game to be less frustrating while giving designers control over what is carried over between player lives. Here are links to the classes that handle player data saving and respawning the player at the correct checkpoint on the INARI Github repo.
To breathe more life into our enemies, I created an enemy behavior controller that would allow for designers to customize their behavior and let them do more than just stand there while they wait for the player to approach. Since I knew that the enemies should only be able to do one thing at a time, and there was a glitch in the first playable demo that allowed some enemies to attack after death, I created a state machine to handle enemy behavior. The state machine communicated with the enemy animator and Unity animation events to ensure that certain actions were only triggered once the previous state’s animation was finished playing. I also implemented error messages that would show in Unity’s console windows if designers inputted values that would cause the controller to behave in a manner that was not intended when I programmed it.