800-Unit Autonomous Swarm Engine in Godot 4 on a 10-Year-Old Laptop (Intel HD 520)

Showcase In Development
1

Hi everyone,

I wanted to share a technical showcase of my crowd engine running in Godot 4: Sovereign Horde Dungeon Crucible.

The goal of this project was to push large-scale autonomous crowd dynamics to the extreme, specifically targeting lower-spec legacy hardware and handhelds like the Steam Deck. Also, most AA/AAA games that feature swarm or crowd engines don’t exhibit the fluid group dynamics that I personally want to see in these types of games. A few top AAA titles handle swarms to great effect, but almost always from a First-Person Shooter perspective. While there’s nothing wrong with that, the top-down tactical perspective is what really excites me, and where organic collective behavior truly shines.

:bullseye: Solving the 3 Classical Hurdles of Swarm / Crowd Systems

Most crowd simulations look decent in open, empty fields, but fall apart in structured dungeon environments. This engine was specifically designed to tackle the three classic failure points:

  1. Doorway & Chokepoint Gridlock: Instead of getting wedged or stacking up into a rigid traffic jam at narrow doorways, the horde exhibits dynamic fluid compression—units funnel smoothly through bottlenecks and organically fan out into open rooms.
  2. Micro-Jitter & Vibration: Many crowd algorithms suffer from violent high-frequency jitter when units pack closely together. Our solver maintains smooth, continuous separation forces even when hundreds of units pack into tight clusters.
  3. Stragglers & Local Minima: Traditional pathfinding often traps units behind pillars, sharp corners, or adjacent rooms. Here, zero units get left behind—trailing units organically catch up and flank around obstacles without getting stuck.

In this demo, an active horde of 800 units navigates a multi-chamber dungeon environment with dynamic chokepoints, modular rooms, and interactive hazards.

:laptop: Target Hardware (The 10-Year-Old Laptop Baseline)

Rather than developing on a high-end desktop workstation, the entire project was built and profiled on a 2015 dual-core laptop to guarantee real-world efficiency:

  • CPU: Intel Core i5-6300U (2 Cores / 4 Threads @ 2.4 GHz)
  • iGPU: Intel HD Graphics 520 (Integrated 24 EUs)
  • Live Performance: ~34–38 FPS unrecorded during full 800-unit dungeon combat and navigation.
  • (Note on video capture: Recorded via Godot’s built-in Movie Maker mode at a fixed 30 FPS to avoid the memory-bus throttling of running external screen recording tools like OBS on an integrated GPU).

:hammer_and_wrench: Developer Integration Studio & Multi-Role Utility AI

Notice the [Studio (F10)] toggle in the top header: the project includes a built-in Developer Studio Workstation designed to bridge prototype simulation into real game production.

  • Micro-Decision Utility AI: Beyond macro swarm flow, the architecture supports lightweight Utility AI curves per unit/group. This allows individual entities or sub-squads to autonomously make micro-decisions in real time—evaluating local danger, dynamic role transitions, tactical bracing, retreating when wounded, or breaking away to scavenge and assist allies.
  • Live Visual Tuning: Instantly freeze the simulation to inspect spatial metrics, adjust caste masses, tune flocking stiffness, and test chokepoint elasticity on the fly.
  • Custom Asset Pipeline: Easily swap unit themes (e.g., Goblins, Skeletons, or custom meshes) and inspect unit turntables with zero-copy buffer syncing.
  • Hardware Budget Profiler: Provides real-time CPU/GPU millisecond breakdowns and target hardware scaling estimates (from 15W handhelds like the Steam Deck up to current-gen consoles and PC rigs).
  • Plug-and-Play Integration: The long-term goal is to allow developers to drop the C++ solver, steering framework, and tactical Utility AI directly into their own top-down ARPGs, RTS titles, or dungeon crawlers.

:shield: What’s Happening in the Demo:

  • Autonomous Swarm Traversal: 800 units moving cohesively through chokepoints, doorways, and corridors without individual pathing stalls.
  • Dynamic Chokepoint Elasticity: Notice how the swarm organically compresses when squeezing through narrow stone doorways and then expands to fill larger chambers.
  • Caste Roster Dynamics: The horde consists of multiple specialized classes (Scouts, Grunts, Brutes, Champions, Specialists), each with distinct masses, movement thrusts, and spacing behaviors.
  • Tactical Squad Partitioning: Units can dynamically split into vanguard assault wedges, defensive perimeters, and specialized task groups.

Built with Godot 4 using the lightweight GL Compatibility renderer and native C++ backend acceleration.

Happy to hear your thoughts and feedback!

3 Likes
2

Timing could not be better!
Doing a swarm thing myself, with three types of units that have different attributes. Care to share more technical/theoretical details? :grimacing:

My project is more about logistics than combat, but with some defensive, adverserial tactics.

3

Thanks! Great to hear someone else is tackling swarms with diverse unit attributes.

The biggest breakthrough for me was completely moving away from standard physics nodes (CharacterBody3D) and per-unit pathfinding, which quickly choke the CPU when scaling past a couple hundred units.

A few high-level design principles that helped me:

  1. Pressure-Based Movement: Rather than units following a rigid line where they all cram into the center of a doorway, I treat crowd movement like fluid flow. When an area gets too crowded, the pressure naturally pushes trailing units toward open side corridors.
  2. Inertial Mass Ratios: Instead of equal spring bouncing, I weigh collision separation by unit mass. That way, your heavier/larger units naturally part smaller units out of the way without needing heavy physics solvers.
  3. Batch Processing: Decoupling the swarm simulation from individual scene-tree node overhead so all unit updates happen together in memory.

I are currently working on packaging this technology into a native Godot 4 EditorPlugin so developers can author and drop large-scale living swarms directly into their scenes without having to build a custom backend from scratch.

Best of luck with your logistics project!

4

Thanks! Great to hear someone else is tackling swarms with diverse unit attributes.

The biggest breakthrough for me was completely moving away from standard physics nodes (CharacterBody3D) and per-unit pathfinding, which quickly choke the CPU when scaling past a couple hundred units.

A few high-level design principles that helped me:

  1. Pressure-Based Movement: Rather than units following a rigid line where they all cram into the center of a doorway, I treat crowd movement like fluid flow. When an area gets too crowded, the pressure naturally pushes trailing units toward open side corridors.
  2. Inertial Mass Ratios: Instead of equal spring bouncing, I weigh collision separation by unit mass. That way, your heavier/larger units naturally part smaller units out of the way without needing heavy physics solvers.
  3. Batch Processing: Decoupling the swarm simulation from individual scene-tree node overhead so all unit updates happen together in memory.

I are currently working on packaging this technology into a native Godot 4 EditorPlugin so developers can author and drop large-scale living swarms directly into their scenes without having to build a custom backend from scratch.

Best of luck with your logistics project!