Tower defense in an indie 3D game (Unity DOTS/ECS)

I worked as a Unity developer on an indie 3D game, in a globally distributed team of three, up to 30 hours a week. I owned the tower defense part of the game, with the project lead as support.

The ECS refactoring was one of my favourite things to work on. It meant understanding code I hadn't written well enough to change its whole structure, and thinking about how data is laid out and processed each frame instead of just what the code does. That's the kind of puzzle I enjoy.

In a typical object-oriented Unity setup, each thing in the game is an object that holds its own data and its own behaviour. A tower knows its position, its range and how to find a target, and every tower runs that logic by itself.

In data-oriented design with ECS, that gets split up. An entity is basically just an ID. The data lives in components (small plain structs like position or range), and components of the same kind are stored packed together in memory. The behaviour lives in systems, which run once per frame and go through all entities that have a certain set of components, working on the data in bulk.

So the question changes from "what does this object do?" to "what data is there, how is it laid out, and what gets processed each frame?" Data stored tightly and read in order is friendlier to the CPU cache, and processing it in bulk makes it easier to spread work across cores, which is why Unity built DOTS around it.