Visjonen: Kontroll på direktørnivå I motsetning til tradisjonelle RTS-spill hvor spillere detaljstyrer enheter, bruker min kolonisimulering en hybrid kontrollmodell. Spilleren fungerer som en Direktør som plasserer 'Smart Markers' for å sette intensjon på høyt nivå (f.eks. 'Høst område', 'Forsvar sone'), mens kubens AI-hierarki håndterer utførelsen autonomt.
Den kjernetekniske utfordringen var å frikoble spillerens intensjon fra agentens utførelse. Dette krevde bygging av en robust 'oppgaveøkonomi' hvor agenter dynamisk kan bytte mellom å være uavhengige autonome aktører (Kolonisimulerings-modus) og styrte 'arbeidere' i en gruppe (RTS-modus) basert på kubens taktiske behov.
Trelagsarkitektur for AI Jeg utviklet et hierarkisk AI-system for å bygge bro mellom overordnet strategi og individuell bevegelse:
**1. Strategisk lag (The Hive Mind)**: `HivePlannerComponent` bruker en høynivå GOAP-planlegger for å analysere den abstrakte `HiveWorldState` (ressursunderskudd, trusselnivåer). Den kjører periodisk for å formulere et `CurrentStrategicDirective` (f.eks. 'Oppnå ressursbalanse'), og fungerer effektivt som koloniens utøvende hjerne.
**2. Taktisk lag (Orkestratoren)**: `TacticalCoordinator` oversetter strategiske direktiver til konkrete handlinger uten å utføre spilllogikk selv. Den koordinerer undersystemer som `SpawnDecisionEngine` (hva som skal bygges) og `TaskDispatcher` (publisering av jobber til det globale styret) for å nå strategiske mål.
**3. Agent-lag (Arbeidsstyrken)**: Individuelle agenter kjører en `GOAPAgent`-løkke. Unikt for dette systemet opererer agenter i en av tre 'kognitive moduser' avhengig av deres rolle: FSM (for repetitivt arbeid med lav kostnad), TaskFollower (for sentralt tildelte jobber), eller AutonomousGOAP (for selvstyrt, fremvoksende atferd).
Tilstandsløs GOAP & 'Driver/Engine'-mønsteret For å optimalisere for hundrevis av agenter, gikk jeg bort fra standard tilstandsbaserte AI-objekter. Jeg implementerte et 'Stateless Prototype Pattern' hvor GOAP-handlinger og mål er singletons. All runtime-tilstand per agent lagres i poolede `RunData`-objekter, noe som minimerer presset på Garbage Collection.
Jeg skilte strengt beslutningstaking fra utførelse ved å bruke et Driver/Engine-mønster:
- **Driveren (AI)**: Enten en agent kjører en FSM State eller en GOAP Action, fungerer den kun som en beslutningstaker.
- **Motoren (`WorkOperationRunner`)**: En sentralisert, scene-scoped tjeneste som utfører den faktiske logikken (f.eks. 'Trekk ut ressurs').
Dette tillater forskjellige AI-hjerner (Dronning, Arbeider, Kryp) å dele identisk interaksjonslogikk samtidig som de opprettholder distinkte beslutningsarkitekturer.
Modulær entitetsmontering For å støtte evolusjonært gameplay, er enheter ikke definert av klasser, men monteres ved kjøretid via et 'Chassis + Modul'-system basert på `ScriptableObjects`.
- **Logisk montering**: `UnitConfigurator` kombinerer en `CasteDefinition` (Chassis) med `TraitDefinitions` (Moduler). Den validerer kompatibilitet, beregner endelige stats, og løser 'Cognitive Gating' - hvor maskinvare (Traits) låser opp programvarefunksjoner (GOAP Actions).
- **Visuell montering**: En `ModularInsectAssembler` konstruerer enhetens mesh i sanntid. Den mapper visuelle prefabs til spesifikke sockets på et master-skjelett, noe som tillater uendelige visuelle variasjoner som deler en enkelt animasjonsrigg.
Oppgaveøkonomi & 'Smart Markers' I stedet for en grid-basert feromonsimulering, utviklet jeg et 'Smart Marker'-system for å drive kolonilogistikken.
Spillerplasserte 'Pheromone Markers' fungerer som oppgavegenereringssoner. De bruker `SensorToolkit`-sensorer for å skanne sitt lokale miljø for interagerbare objekter (ressurser, fiender). Markørene legger deretter disse funnene ut som 'Sub-Tasks' til en global `TaskManager`.
Agenter fungerer som konsumenter i denne økonomien. En `TaskAcquisitionComponent` på agenten spør `TaskManager`, som matcher tilgjengelige agenter til oppgaver basert på prioritet, avstand og evner. Dette skaper en skalerbar 'Pull'-økonomi hvor agenter intelligent fordeler seg mellom spillerens mål uten manuell tildeling.
Tekniske utfordringer løst **Utfordring 1: JIT Interaksjonsprotokoll** - Å forhindre at agenter klumper seg sammen eller clipper inn i ressurser var vanskelig. Jeg implementerte et 'Just-in-Time' reservasjonssystem. Agenter handler etter en protokoll: 'Staging Radius' -> 'Reserve Slot' -> 'Micro-Align'. Interaktive objekter administrerer sin egen kø av `ReservationHandles`, noe som sikrer rettferdig tilgang til ressurser uten overlapping.
**Utfordring 2: UI/Logikk-frikobling** - For å håndtere kompleksiteten i simuleringsdataene, brukte jeg OneJS til å bygge UI-et. Dette tillot meg å skrive grensesnittet i TypeScript/Preact med Tailwind CSS, og binde reaktive UI-komponenter direkte til C#-hendelser (`OnInventoryChanged`, `OnPopulationChanged`) uten polling.
