By Published On: July 8th, 2023Categories: Devlog, General0 CommentsTags: , , , , ,

This is the first post in an ongoing series about the development of my thesis project, Clockwork TD.

For this new series, I’ve decided to start a dev blog for my MFA thesis project, Clockwork TD (working title!). I’ll be developing it over the next year as I work on finishing my MFA, and hope to polish it enough to release it (in Early Access, at least) next summer on Steam!

This project started off as a thought experiment — what makes a Tower Defense game? For awhile, I tried to go down the road of Citadelic and do away with enemy paths altogether, using Citadelic’s Move mechanic to let the player readjust their defenses each round, but 1. that felt tedious and 2. it opened up questions around enemy pathfinding. I tried to persist with the idea that enemies would “bash down” towers in their way, making adjusting the enemy path via placing towers part of the game’s strategy (ala Defense Grid: The Awakening), but a tower defense game where the enemies can damage your towers feels like it’s getting too close to an RTS. Similarly, all of the solutions I could think of to help a player cope semi-comfortably with a lack of defined enemy paths also started slanting the game towards an RTS. While Diplomacy is Not an Option was a big influence in my thinking (especially before discovering Citadelic), that game is ultimately a base-building RTS, not a Tower Defense game.

So how then, to achieve a Tower Defense game with a dynamic map like Rogue Tower or Isle of Arrows? I tried to answer this question last year when making Voxel Defense, but eventually found that asking the player to build their own enemy path quickly got tedious, as fun as it could be to create the ultimate winding killbox. When thinking about this game, I had just finished working on Accumulus, which gave me experience with hex grid math and made me realize that hexagons as tiles are far more interesting than cubes. Originally, I thought of using Perlin or other noise to generate the map like I did in Ron Swansong, but I didn’t feel like spending ages trying to massage procedural generation algorithms enough to give me safe, reliable randomness; and even so, it felt like I was falling backwards into “this feels like an RTS” territory again.

Eventually, after spending an inordinate amount of time on redblobgames’ hex math page, I realized the answer was somewhere in the hex math itself — that I should be using diagonals, rings, etc. to “carve” my enemy path out of the playing space (the final effect in the current build is even cooler than this):

A big part of my thesis proposal was using Unity’s AI Navigation system (as seen in use by the red cylinder above) for simple enemy pathfinding, but its tendency to get jumpy, combined with the finicky nature of AI NavMesh (even in the 2022 LTS) meant that it was back to redblobgames and learning A* Pathfinding for the first time (finally!). Once I got that down, the march of the monsters could begin!

Finally, the last element of my dynamic path: moving the enemy spawners around the map! Once this mechanic was in, I dropped the first working title (the very dry Hex Vector Defense) and went with Clockwork TD to reflect the way the spawners move around the (hex) circle (shout out to 75th Hunger Games for a little inspiration, heh)

More to come in the next entry — I’m about 30 gifs behind still, even after the handful here!

You can check out the latest Clockwork TD build at

Computer coding on a screenUpdated Lightweight ScriptableObject Events in Unity
Unity ScriptableObject-based Pooling Framework

Leave a Reply