Clockwork TD Devlog #6: Enemy Info
This is the sixthpost in an ongoing series about the development of my thesis project, Clockwork TD.
An important part of Tower Defense games is clearly communicating to the player the sort of threat they’re facing.
This would look better grouped, right?
It’d be great if the player could see even more info on the enemy, like Health, Speed, and any special abilities:
This was a short update, but I fell out of the habit over the last two months, so I needed to get these gifs out into the world! I may try to make this devblog more contemporaneous each week as part of my workflow, so let’s see how it goes 🫠
Clockwork TD Devlog #5: Terrain Bonuses
This is the fifth post in an ongoing series about the development of my thesis project, Clockwork TD.
Terrain bonuses, ala Rogue Tower, were something I decided I wanted early on in order to add to the randomness of each playthrough. Tiles are simply assigned a random TileBonus from 0-3 at creation, then moved up and color lerped in order to match, while the CursorState uses this Bonus value to generate the floating text on hover:
Bonus = Random.Range(0, 4);
transform.localScale = Vector3.one + Vector3.up * (Bonus * .5f + 1f);
var color = Color.Lerp(renderer.material.color, Color.white, Bonus / 5f);
renderer.material.color = color;
Stats in the game use the SeawispHunter.Roleplay.Attributes package, which provides an amazing framework for working with all sorts of RPG stats. The Tower Bonus is assigned at time of tower placement; this pattern is used for all Upgradeable stats throughout the game, allowing trickle-down from the Tower Setup to the individual tower level.
// add 1% to each stat for each level of tile bonus
TileBonus = new ModifiableValue<int>(0);
var rangeMod = TileBonus.Select(x => 1f + x / 100f);
AttackRange.modifiers.Add(Modifier.Times(rangeMod));
AttackSpeed.modifiers.Add(Modifier.Times(rangeMod));
AttackPower.modifiers.Add(Modifier.Times(rangeMod));
I had used Kryzarel’s CharacterStat framework in previous RPG stat projects, but found the SeawispHunter package at the start of this project. It’s really powerful and flexible, and highly recommended! Next time around, we’ll take a look at generating / showing the next enemy wave.
Clockwork TD Devlog #4: Unlocks & Dynamic Build Menus
This is the fourth post in an ongoing series about the development of my thesis project, Clockwork TD.
One thing that I knew would be of huge importance before I even started designing my game was the UI. Many games in the Tower Defense genre focus on depth and breadth of systems in lieu of a coherent UI, which makes no sense — tower defense games are meant to suck the player in and keep them hitting the Next Turn button, so why would you not concentrate on creating as frictionless an experience for your player as possible? As such, I knew that designing the UI had to be a major part of the game, and not a bolted on afterthought. This sort of thinking is what led me use FSMs for GameState and CursorState, to ensure that I have the utmost control over the player’s game experience at any given time. My UI and my GDD were created in a back-and-forth iterative process, as I worked out gameplay ideas on paper and then tried to imagine how they’d translate to a UI in Figma.
By taking the time to create a full style & color guide from the beginning, it allowed me to very easily combine building blocks in Figma to create a coherent UI language.
Like the Command Manager, the Unlock Manager is another ScriptableObject, as it has no per-frame logic to execute. Unlockables are another abstract ScriptableObject class; by providing virtual methods for OnUnlock and OnReset, we can override UnlockableBase to Unlock all sorts of objects in the game, whether a Damage Bonus or New Buildable Tower:
public abstract class UnlockableBase : ScriptableObject
{
public UnlockableBase LockedBy;
public bool Unlocked;
[SerializeField] private bool unlockedToStart;
public bool Unlockable => !Unlocked && (!LockedBy || (LockedBy && LockedBy.Unlocked));
protected abstract void OnUnlock();
protected abstract void OnReset();
public void UnlockItem(bool force = false)
{
if (!force && !Unlockable) return;
Unlocked = true;
OnUnlock();
}
public void ResetItem()
{
Unlocked = unlockedToStart;
OnReset();
}
private void OnEnable()
{
ResetItem();
}
}
public class UnlockableBuildable : UnlockableBase
{
[SerializeField] private BuildableSetup buildableSetup;
protected override void OnUnlock()
{
buildableSetup.Unlock(true);
}
protected override void OnReset()
{
buildableSetup.Unlock(Unlocked);
buildableSetup.Reset();
}
}
public class UnlockableTowerBonus : UnlockableBase
{
[SerializeField] private BuildableSetup buildableSetup;
[SerializeField] private BonusTypes bonusType;
protected override void OnUnlock()
{
switch (bonusType)
{
case BonusTypes.Power:
buildableSetup.PowerBonus.initial.value++;
break;
case BonusTypes.Range:
buildableSetup.RangeBonus.initial.value++;
break;
case BonusTypes.Speed:
buildableSetup.SpeedBonus.initial.value++;
break;
case BonusTypes.Health:
buildableSetup.HealthBonus.initial.value++;
break;
case BonusTypes.Armor:
buildableSetup.ArmorBonus.initial.value++;
break;
case BonusTypes.Shield:
buildableSetup.ShieldBonus.initial.value++;
break;
default:
throw new ArgumentOutOfRangeException();
}
}
protected override void OnReset()
{
buildableSetup?.Reset();
}
}
This lets us query our list of Unlockables to find out what’s Unlocked, what’s Unlockable, and what’s still Locked; which can then be used to create the build menu using UXML classes that inherit from Button to pass data:
void ToggleBuildMenu(ClickEvent evt, BuildableType buildableType)
{
currentBuildableType = buildableType;
secondContainer.Clear();
buildableButtons = new List<BottomButton>();
foreach (var buildableSetup in buildableType.GetBuildables(gameData.BuildableSetups))
{
var newButton = new BottomButton();
newButton.Init(buildableSetup);
newButton.AddClickEvent(BuildableButtonClicked, buildableSetup);
if(!buildableSetup.Unlocked) newButton.SetEnabled(false);
buildableButtons.Add(newButton);
secondContainer.Add(newButton);
}
buildableTypeButtons.ForEach(b => b.EnableInClassList("active", false));
buildableTypeButtons.FirstOrDefault(b => b.ButtonType == buildableType)?.EnableInClassList("active", true);
}
This same data can also be used to unlock new cards at the end of every round (more on this in a later post, covering card pack minimum rarity levels):
The damage numbers here showing off the game’s first splash damage projectile are created with a TMPro Billboard shader I found on github, combined with the rising number effect from Accumulus. The UnlockManager calls Reset on all Unlockables at the start of each new game, ensuring that all Unlockable items start each new game fresh.
By focusing on the end result I wanted the gameplay & UI experiences to have early on in the process, I was able to use my GDD and Figma to create a coherent, functional UI in my game even this early in the development process. Come back next time for info on terrain bonuses and the enemy wave info screen!
Clockwork TD Devlog #3: CursorState FSM
This is the third post in an ongoing series about the development of my thesis project, Clockwork TD.
Rather than define separate game states Building, Moving, Selling, etc., I chose to create a separate FSM for the cursor state. Like the game states, each of the cursor states is strongly defined as a ScriptableObject:
[Header("Game States")]
public MainMenuState StateMainMenu;
public GameStartState StateGameStart;
public PlayerPreparationState StatePlayerPreparation;
public EnemyAttackState StateEnemyAttack;
public GameOverState StateGameOver;
[Header("Cursor States")]
public CursorDefault CursorStateDefault;
public CursorBuilding CursorStateBuilding;
public CursorSelling CursorStateSelling;
public CursorMoving CursorStateMoving;
public CursorUpgrading CursorStateUpgrading;
This makes it easy to add new game & cursor states and also to access them from anywhere in the project.
The base CursorState includes abstract & virtual methods to override, depending on the desired behavior of the current state:
public abstract void TileClicked(Tile tile);
public abstract void TileEntered(Tile tile);
public abstract void TileExited(Tile tile);
public abstract void BuildableClicked(Buildable buildable);
public abstract void BuildableEntered(Buildable buildable);
public abstract void BuildableExited(Buildable buildable);
protected void Enter()
{
if(gameData.CurrentCursor) gameData.CurrentCursor.Exit();
gameData.CurrentCursor = this;
if (debug) Debug.Log(this + "::Enter() (" + gameData.CurrentCursor + ")");
OnEnter();
Entered?.Invoke();
}
protected virtual void OnEnter(){ }
private void Exit()
{
if (debug) Debug.Log(this + "::Exit() (" + gameData.CurrentCursor + ")");
OnExit();
Exited?.Invoke();
}
protected virtual void OnExit(){ }
protected virtual void Cancel()
{
gameData.CursorStateDefault.Enter();
}
As in the GameStates, CursorStates have Entered and Exited events that can be subscribed to, as well as OnEnter() and OnExit() methods for inheriting CursorStates to override. Buildable and Tile both implement the “IPointerClickHandler, IPointerEnterHandler, IPointerExitHandler” interfaces, calling back to the current CursorState during those mouse events. This allows the code for say, Building to be fairly straightforward (incomplete code but you can get the gist — oh I just got why github named it that):
public void SetNewBuildable(BuildableSetup newTower)
{
currentBuildable = newTower;
ShowInfoPanel(newTower);
if (gameData.CurrentCursor != this) Enter();
}
protected override void OnEnter()
{
base.OnEnter();
InputManager.EscapePressed += Cancel;
InputManager.RightClickPressed += Cancel;
}
protected override void OnExit()
{
base.OnExit();
HideGhostTower();
HideBonusText();
HideRangefinder();
HideInfoPanel();
currentBuildable = null;
InputManager.EscapePressed -= Cancel;
InputManager.RightClickPressed -= Cancel;
}
public override void TileClicked(Tile tile)
{
if (currentBuildable.Cost > currentBuildable.Currency.Value) return;
var buildCommand = new BuildCommand(currentBuildable, tile);
gameData.CommandManage.AddCommand(buildCommand);
HideGhostTower();
HideBonusText();
HideRangefinder();
if(!InputManager.ShiftHeld) Cancel();
}
public override void TileEntered(Tile tile)
{
ShowGhostTower(currentBuildable, tile);
ShowBonusText(tile);
ShowRangefinder(tile, currentBuildable.AttackRange.value * (1 + (tile.Bonus / 100f)));
}
public override void TileExited(Tile tile)
{
HideGhostTower();
HideBonusText();
HideRangefinder();
}
public override void BuildableClicked(Buildable buildable) { }
public override void BuildableEntered(Buildable buildable) { }
public override void BuildableExited(Buildable buildable) { }
Here’s the initial results for the various states:
The Undo queue is a fairly simple Command Stack, with everything routing through a ScriptableObject CommandManager (for Managers that don’t require pertick functionality, I tend to take the extra step to make them ScriptableObjects). Here’s that class, along with the MoveCommand:
public class CommandManager : ScriptableObject
{
public event Action QueueChanged;
public int Count => commandsBuffer.Count;
private Stack<ICommand> commandsBuffer = new();
public void AddCommand(ICommand command)
{
command.Execute();
commandsBuffer.Push(command);
QueueChanged?.Invoke();
}
// undoes the last command
public void UndoCommand()
{
if(commandsBuffer.Count == 0) return;
commandsBuffer.Pop().Undo();
QueueChanged?.Invoke();
}
// undoes all the commands in reverse order
public void UndoAllCommands()
{
if(commandsBuffer.Count == 0) return;
while (commandsBuffer.Count > 0)
{
commandsBuffer.Pop().Undo();
}
QueueChanged?.Invoke();
}
// executes each tower's cleanup command and clears the stack to finalize the commands
// (only used to cleanup after sell commands right now)
public void FinalizeCommands()
{
while (commandsBuffer.Count > 0)
{
commandsBuffer.Pop().Commit();
}
ClearCommands();
}
public void ClearCommands()
{
commandsBuffer.Clear();
QueueChanged?.Invoke();
}
}
public interface ICommand
{
void Execute();
void Undo();
void Commit();
}
public class MoveCommand : ICommand
{
private readonly Buildable commandObject;
private readonly Tile originalTile;
private readonly Tile newTile;
public MoveCommand(Buildable buildable, Tile original, Tile target)
{
commandObject = buildable;
originalTile = original;
newTile = target;
}
// move the Buildable, cleanup the Tile statuses
public void Execute()
{
originalTile.MarkBuilt(false);
commandObject.transform.position = newTile.GetTopOfTile();
commandObject.HomeTile = newTile;
commandObject.TileBonus.initial.value = newTile.Bonus;
newTile.MarkBuilt(true);
}
// move the Buildable back, revert the Tile statuses
public void Undo()
{
originalTile.MarkBuilt(true);
commandObject.transform.position = originalTile.GetTopOfTile();
commandObject.HomeTile = originalTile;
commandObject.TileBonus.initial.value = originalTile.Bonus;
newTile.MarkBuilt(false);
}
// no cleanup necessary
public void Commit() {}
}
Stay tuned for the next installment, which will probably cover some UI elements.
Clockwork TD Devlog #2: Gameplay Progression & FSMs
This is the second post in an ongoing series about the development of my thesis project, Clockwork TD.
In the last entry, we covered A* Pathfinding for the enemies to find their way to the grid center (check out my Hex Grid Framework here). A major part of my thesis was a Tower Defense game where the enemy spawn point changed throughout the course of the game, requiring the player to counter that somehow. Using the Hex grid math I learned at redblobgames.com, I came up with a system where the spawner will move around each ring of the game map–similar to a clock–working its way from inside to out, giving the player the longer stretch of enemy path they’ll need as the game goes on and the number of enemies multiplies.
In this early version, the spawner simply lasts for one turn at each location, then the tile it’s standing on changes from a path tile to a buildable tile, giving the player an extra location to place a tower. When the spawn tile moves to a new ring, it spawns at the location closest to the last ring’s opening for the first round, to get the player acquainted to the change in the game.
I also built upon the camera system I created for Accumulus, which builds on Unity’s Cinemachine follow camera to move an invisible GameObject around the map with the player’s keyboard input. Here I added a mouse scrollwheel function for Zoom, which simultaneously moves the camera down and forward. Camera control is a huge sticking point for me in top-down games like this, so making sure I nailed my camera was very important to me. The camera control hooks into the GameState and CursorState systems to ensure it’s only active during the correct game phases.
The GameState and CursorState systems are both ScriptableObject-based FSMs; each State has Entered() and Exited() events that game managers and other objects can subscribe to, such as deleting all objects OnNewGameStart, or changing the bottom buttons (not shown yet in these gifs) when the player clicks the OnPlayerPrepared button to start the enemy attack phase.
public abstract class GameState : ScriptableObject
{
public event Action Entered, Exited;
[SerializeField] private bool debug;
public void Enter(GameData gameData)
{
if(gameData.CurrentState) gameData.CurrentState.Exit(gameData);
gameData.CurrentState = this;
if (debug) Debug.Log(this + "::Enter() (" + gameData.CurrentState + ")");
OnEnter(gameData);
Entered?.Invoke();
}
public virtual void Execute(GameData gameData)
{ }
protected virtual void OnEnter(GameData gameData)
{ }
private void Exit(GameData gameData)
{
if (debug) Debug.Log(this + "::Exit() (" + gameData.CurrentState + ")");
OnExit(gameData);
Exited?.Invoke();
}
protected virtual void OnExit(GameData gameData)
{ }
public void Return(GameData gameData)
{
gameData.PreviousState.Enter(gameData);
}
}
By inheriting from the base state, strongly typed states can be defined that allow each state to have unique behavior and hold any necessary data. For example, the MainMenu state can automatically pause and resume the game when exited and entered:
[CreateAssetMenu (fileName = "State_MainMenu", menuName = "Game States/Main Menu", order = 51)]
public class MainMenuState : GameState
{
private float oldTimeScale;
protected override void OnEnter(GameData gameData)
{
base.OnEnter(gameData);
oldTimeScale = Time.timeScale;
Time.timeScale = 0;
}
protected override void OnExit(GameData gameData)
{
base.OnExit(gameData);
Time.timeScale = oldTimeScale;
}
}
In the next entry, I’ll cover how this same technique is used to define each of the states the game cursor can be in, which allows for straightforward, durable code flexible enough to handle Building, Moving, Selling, Upgrading, Hovering Over, and Clicking On the game’s Buildables.
