One Turret Should Be Fine

Project Info

Thanks for reading. If you have any feedback or an idea how I should name this game — please reach out. Honestly, help me. Naming is hard… contact@roqumgames.com

The Long Time Goal

My long-term goal is to build an RTS game in the style of They Are Billions — large-scale city building survival with massive enemy swarms. But I didn’t want to commit three or four years to a single project and come out the other end with nothing shipped.

So instead I’m building toward it in steps, releasing games that each push the underlying systems further:

1. Incremental / Idle Tower Defense — (current game) tens of thousands of enemies animated in realtime
2. City Builder / Tower Defense — multiple turrets, base building system, navigation system
3. RTS / Swarm Survival (They Are Billions-like game) — combining both and adding RTS units control system

Each game is a standalone release, but they share the same core tech. By the time I get to the RTS, the enemy rendering pipeline, building system and navigation system will already be implemented and tested in at least one of my two shipped games.

The primary goal for this game is to build and ship a performant enemy rendering pipeline capable of 30,000+ enemies at 60fps — the foundation every subsequent game in this plan depends on.

About the Game

One Turret Should Be Fine is the first step in that plan. It’s an incremental Nodebuster-like with a weapon build system. (Nodebuster-like: a short active loop — typically timer or wave based — where you earn currency in the run and spend it outside on persistent upgrades, then go again. Passive income runs in the background between sessions, like a classical idle game.)

You control a single turret that auto-fires. Enemies come in endless waves, the swarms grow larger, and eventually the turret goes down. Between rounds you spend your earned currency on a research tree and swap your weapon loadout build. It’s incremental at heart: numbers grow, the screen fills up, and each run you push a little further than the last.

Technical Architecture

The main challenge with this kind of game is scale. Having tens of thousands of enemies that actually move, animate, and interact with gameplay systems without destroying performance isn’t something Unreal handles out of the box. The architecture is built around three core systems:

• Mass (Epic’s Entity Component System)
• Spatial Partitioning
• Niagara Particles + Vertex Animation Textures (VAT) to represent entities.

Mass Entity Component System

Enemies run entirely on Unreal’s Mass ECS — Epic’s data-oriented entity framework built for high-count processing. There are no Actors involved. Each enemy is a lightweight entity with only the data it needs: position, velocity, health, state, etc. Mass processes them in batches across multiple threads, which is what makes the scale possible in the first place.

Spatial Partitioning

With tens of thousands of entities on screen, weapons need to query nearby targets constantly — for targeting, proximity checks, and area-of-effect calculations. Without spatial partitioning, every query would have to iterate the full entity list — at 40,000 enemies that’s not viable. I implemented a uniform spatial grid that divides the world into fixed-size cells, and each entity registers itself per tick. Queries only touch the cells within range — drastically reducing the number of entities checked per weapon system per tick.

Niagara + Vertex Animation Textures (VAT)

Rendering thousands of skeletal meshes is out of the question at this scale. Instead, enemies are rendered as Niagara GPU particles, with animations baked into Vertex Animation Textures. The entire animation playback happens on the GPU — no skeletal mesh evaluation, no CPU overhead. The mesh data is sampled per particle from the VAT each frame. Combined with a custom LOD system, this is what makes rendering 30,000+ animated enemies viable.

Gameplay Ability System (GAS)

I use Unreal’s Gameplay Ability System for the player progression and weapon abilities. As my projectiles, fired by several weapons, are also simulated by Mass, I had to implement some custom communication between Mass and GAS.

Current State

What’s done so far:

• Mass-based enemy simulation with multiple enemy types (3 enemy types currently)
• Niagara + VAT rendering pipeline with custom LOD system
• Uniform spatial grid
• Weapon loadout system with multiple barrel slots (left, right, top)
• 3 Weapons (Gatling gun, homing missiles, and grenade launcher)
• Custom research tree editor tool to ease up tech tree creation
• Flexible and scalable spawning system

What’s Missing

I almost have all the systems I need in place. So now it’s actually about designing, creating and adding the actual game content and making it visually appealing. As I am not an artist, visual appeal is the most difficult task I am currently struggling with.

Showcase

Enemy Horde — Gameplay

75,000 Entities at 38 FPS

40,000 Enemies

Gatling Gun

Homing Missiles

Grenade Launcher

Hangar — Weapon Equipment & Mesh Update

Research Tree

Tech Tree Editor — Custom Graph Tool

To make building the tech tree manageable, I wrote a custom node-based graph editor inside Unreal. Each node represents an unlockable and connections define unlock dependencies. The properties panel on the right lets me fully configure each node: requirements to unlock it, Gameplay Effects that are applied once researched, and UI data — icon, title, and description text. The description supports {codenames} that are resolved at runtime to pull the actual values directly from the node, so numbers stay in sync without manual editing.