The Vision: Director-Level Control Unlike traditional RTS games where players micro-manage units, my Colony Simulation utilizes a Hybrid-Control Model. The player acts as a Director, placing 'Pheromone Markers' that set high-level intent (e.g., 'Harvest Area', 'Defend Zone'), while the hive's AI hierarchy autonomously handles execution.
The core technical challenge was decoupling the player's intent from the agent's execution. This required building a robust 'Task Economy' where agents can dynamically switch between being independent autonomous actors (Colony Sim mode) and directed 'thralls' within a Brood (RTS mode) based on the hive's tactical needs.
Three-Tier AI Architecture I engineered a hierarchical AI system to bridge the gap between grand strategy and individual movement:
1. Strategic Layer (The Hive Mind): The `HivePlannerComponent` uses a high-level GOAP planner to analyze the abstract `HiveWorldState` (resource deficits, threat levels). It runs periodically to formulate a `CurrentStrategicDirective` (e.g., 'Achieve Resource Balance'), effectively acting as the colony's executive brain.
2. Tactical Layer (The Orchestrator): The `TacticalCoordinator` translates strategic directives into concrete actions without executing game logic itself. It coordinates subsystems like the `SpawnDecisionEngine` (what to build) and `TaskDispatcher` (posting jobs to the global board) to meet strategic goals.
3. Agent Layer (The Workforce): Individual agents run a `GOAPAgent` loop. Uniquely, agents operate in one of three 'Cognitive Modes' depending on their role: FSM (for low-cost repetitive labor), TaskFollower (for centrally dispatched jobs), or AutonomousGOAP (for self-directed, emergent behavior).
Stateless GOAP & The 'Driver/Engine' Pattern To optimize for hundreds of agents, I moved away from standard stateful AI objects. I implemented a Stateless Prototype Pattern where GOAP Actions and Goals are singletons. All per-agent runtime state is stored in pooled `RunData` objects, minimizing Garbage Collection pressure.
I strictly separated decision-making from execution using a Driver/Engine pattern:
- The Driver (AI): Whether an agent is running an FSM State or a GOAP Action, it acts only as a decision-maker.
- The Engine (`WorkOperationRunner`): A centralized, scene-scoped service that executes the actual logic (e.g., 'Extract Resource').
This allows different AI brains (Queen, Worker, Critter) to share identical interaction logic while maintaining distinct decision-making architectures.
Modular Entity Assembly To support evolutionary gameplay, units are not defined by classes but assembled at runtime via a 'Chassis + Module' system backed by `ScriptableObjects`.
- Logical Assembly: The `UnitConfigurator` combines a `CasteDefinition` (Chassis) with `TraitDefinitions` (Modules). It validates compatibility, calculates final stats, and resolves 'Cognitive Gating' - where hardware (Traits) unlocks software capabilities (GOAP Actions).
- Visual Assembly: A `ModularInsectAssembler` constructs the unit's mesh in real-time. It maps visual prefabs to specific sockets on a master armature, allowing for infinite visual variations that share a single animation rig.
The Task Economy & Smart Markers Instead of a grid-based pheromone simulation, I developed a 'Smart Marker' system to drive colony logistics.
Player-placed Pheromone Markers act as Task Generation Zones. They utilize `SensorToolkit` sensors to scan their local environment for interactable objects (Resources, Enemies). The markers then post these findings as 'Sub-Tasks' to a global `TaskManager`.
Agents act as consumers in this economy. A `TaskAcquisitionComponent` on the agent queries the `TaskManager`, which matches available agents to tasks based on priority, distance, and capability. This creates a scalable 'Pull' economy where agents intelligently distribute themselves among the player's objectives without manual assignment.
Technical Challenges Solved Challenge 1: JIT Interaction Protocol - Preventing agents from crowding or clipping into resources was difficult. I implemented a 'Just-in-Time' reservation system. Agents act on a 'Staging Radius' -> 'Reserve Slot' -> 'Micro-Align' protocol. Interactive objects manage their own queue of `ReservationHandles`, ensuring fair, non-overlapping access to resources.
Challenge 2: UI/Logic Decoupling - To manage the complexity of the simulation data, I used OneJS to build the UI. This allowed me to write the interface in TypeScript/Preact with Tailwind CSS, binding reactive UI components directly to C# events (`OnInventoryChanged`, `OnPopulationChanged`) without polling.
