Robber Barons
Project Overview
Robber Barons is a tower defense game prototype built in Unity, where I implemented the core game features using C# scripts. The game revolves around waves of enemies attacking your castle, and you must build towers to defeat the enemy before they can steal your gold.
Defeating an enemy rewards gold to the player, while letting enemies reach your castle results in your gold being stolen. It also costs gold and time to build a tower.
Personal Game Project
Skills: C# Scripting, Debugging, Unity
Feature Overview
Tower Targeting System
One of the main functions I scripted was a Targeting System for the Towers, which controlled how the Tower chose a target, aimed, then fired at an enemy.
Iteration 1: Targeting the closest enemy
My first iteration for the targeting system had the towers calculate which enemy was closest to it, then fire at that. However, this system proved to be deeply flawed, as the tower would constantly change targets based on which enemy was closest at the given moment, leading to it being unable to finish off enemies properly. For the second iteration, I aimed to make my towers stay locked on to a target until it was defeated, before switching to another target.
As you can see, the tower keeps switching between targeting different enemies, making it inefficient at dealing with enemies.
Iteration 2: Staying on Target
In my second iteration for the targeting system, I added a condition so that the towers would not switch to a target until it had made sure its first target was either defeated, or was out of range. This succeeded in making the towers focus on defeating enemies one at a time. However, a bug still existed where the tower switched targets to the nearest enemy after defeating the first enemy, rather than targeting the enemy furthest along the path, which is more ideal for preventing the enemies from stealing the player's gold.
The tower now stays locked on to the first enemy until it is defeated, but the retargeting logic had some flaws.
Iteration 3: Targeting the Most Threatening Enemy
For the third iteration, I revamped the targeting system's logic for picking an enemy, by having it consider multiple factors such as: is the enemy in range? How far along the path is each enemy? Is the current targeted enemy defeated or no longer in range?
By having the towers consider more factors when choosing a target, I was able to help them make smarter choices, and improved their efficiency at defeating enemies.
The tower makes sure to defeat its current target, then adjust its aim to fire at the enemies closest to making it to the player's castle.
Object Pool Spawning System
When creating a spawning system for the enemies, I initially started with a script that would instantiate an enemy, then destroy it whenever it's health dropped to 0, or if it reached the players castle. However, after some testing I found that this could be taxing on the computer, so I iterated the spawning system to utilize Object Pools.
In an Object Pool, instead of creating and destroying game objects, you can keep game objects in a storage area of sorts, and activate and deactivate them based on what is happening in the game.
In this case, I set up waves of enemies to be held in the Object Pool, and activated them when a level began. When the enemies were defeated or reached the player's castle, I would deactivate them and bring them back to the starting location, so I could 'recycle' them as needed.
Using Object Pools significantly lowered the burden on my computer, and improved the performance of the game.
Some of the code for my Object Pool script
Serialized Fields
Throughout the project, I made sure make full use of Serialized Fields. In Unity, a serialized field is a variable in a script marked with the [SerializeField] attribute. This designation allows the variable's value to be viewed and edited in the Unity Editor's Inspector, making it a convenient way to expose specific variables for configuration without modifying the script's code directly. Serialized fields allows for an easier and more convenient way to tweak various parts of the game.
If I were to collaborate with other developers on this game, they would be able to easily fine tune various variables in the game, even if they were not comfortable going into the actual scripts.
In this example, I've serialized the variables that control the range, cost, and building time of this tower so anyone can easily tweak and adjust those values.
Thanks for checking out Robber Barons!