refactor AI system
This commit is contained in:
@@ -52,13 +52,13 @@ See REQ-GW-COORDS for the authoritative tile-coordinate convention. This section
|
||||
|
||||
Simulation types shared across subsystems:
|
||||
|
||||
- `EntityId` — strictly increasing integer handle, allocated centrally by the simulation. Assigned to every targetable entity: ships, scrap drops, **and** buildings (including HQ and defence stations). Buildings additionally retain their anchor tile for spatial lookups and placement; the `EntityId` is the canonical reference used by ship-component target fields (`Weapon.currentTarget`, `RepairTool.currentTarget`, `ThreatResponse.currentTarget`, etc.), so a combat ship can target either another ship or a defence station uniformly.
|
||||
- `EntityId` — strictly increasing integer handle, allocated centrally by the simulation. Assigned to every targetable entity: ships, scrap drops, **and** buildings (including HQ and defence stations). Buildings additionally retain their anchor tile for spatial lookups and placement; the `EntityId` is the canonical reference used by ship-component target fields (`Weapon.currentTarget`, `RepairTool.currentTarget`, `AttackBehavior.currentTarget`, etc.), so a combat ship can target either another ship or a defence station uniformly.
|
||||
- `Rotation` — enum `{ North, East, South, West }`. The rotation applied to a building's surface_mask when placed.
|
||||
- `BuildingType` — enum covering every building type in requirements.md (Miner, Smelter, Assembler, ReprocessingPlant, Shipyard, SalvageBay, Belt, Splitter, Hq, PlayerDefenceStation, EnemyDefenceStation). `Belt` and `Splitter` share the enum for cost, construction, placement, and `visuals.toml` lookup, but their runtime data lives inside the belt subsystem rather than in `Building` instances (see Belt Subsystem).
|
||||
- `ItemType` — tagged id of every transportable material (ores, ingots, intermediates, building_blocks, scrap).
|
||||
- `Item` — `struct Item { ItemType type; }`. Items on belts have no persistent identity across ticks.
|
||||
- `Port` — `struct Port { QPoint tile; Rotation direction; }`. Identifies a belt-adjacent cell and the direction of flow across that cell.
|
||||
- `MovementIntent` — `struct MovementIntent { int priority; QVector2D target; }`. Priority follows the order declared under Movement Arbitration. Cleared at the start of each tick; the highest-priority write wins; `tickMovement` reads the winner.
|
||||
- `MovementIntent` — `struct MovementIntent { bool active; QVector2D target; }`. Written by the winning behavior's executor (see Movement Arbitration). Cleared (`active = false`) at the start of each tick; `tickMovement` brakes when inactive, otherwise drives toward `target`.
|
||||
- `WeaponFiredEvent` — `struct WeaponFiredEvent : public Event { entt::entity shooter; entt::entity target; Tick emittedAt; }`. Transient record emitted each time a weapon fires (REQ-SHP-FIRING, REQ-SHP-FIRING-BEAM). Buffered in a sim-owned vector during the tick, then drained and re-emitted via EventManager by the UI frame handler; see Sim → UI Events.
|
||||
- `SchematicChoiceOption` — `struct SchematicChoiceOption { string schematicId; SchematicType type; string displayName; bool isNewUnlock; int targetLevel; }`. Describes one option in the schematic choice dialog (REQ-DEF-SCHEMATIC-DROP). Up to three are generated when an enemy station set is destroyed. `SchematicType` is `Ship`, `Module`, or `Recipe`.
|
||||
- `SchematicChoicesAvailableEvent` — EventManager event carrying a `vector<SchematicChoiceOption>`. Sent by the UI each frame when pending choices are detected; handled by `MainWindow` which opens the schematic choice dialog.
|
||||
@@ -107,8 +107,8 @@ Within a single simulation tick, subsystems run in this fixed order. The order i
|
||||
4. **Building production** — advance production timers; start new cycles when inputs and output-buffer space permit (REQ-MAT-CYCLE); on completion, deposit output.
|
||||
5. **Building → belt push** — buildings push items from output buffer onto the belt tile at their output port (REQ-MAT-OUTPUT-PORT).
|
||||
6. **Belt tick** — advance items along belt tiles; apply splitter routing (REQ-BLD-SPLITTER).
|
||||
7. **Ship behavior systems** — clear `MovementIntent` on each ship, then run `tickThreatResponse`, `tickScrapCollector`, `tickRepairBehavior`, `tickHomeReturn` in any order (arbitration is via intent priority).
|
||||
8. **Combat resolution** — ships and defence stations acquire targets, fire, apply damage; queue deaths. Each fire appends a `WeaponFiredEvent` to the sim's weapon-fired-event queue (REQ-SHP-FIRING-BEAM).
|
||||
7. **Ship behavior systems** — clear `MovementIntent` on each ship, then the `AiSystem` runs three batched phases: every behavior **evaluator** scores its behavior and sets its target data; a **selection** pass records the highest-scoring behavior per ship in `SelectedBehaviorComponent`; each behavior **executor** runs for the winner, writing `MovementIntent` and preferred module targets. The module systems then perform world mutation: `SalvagerSystem` (scrap collection/delivery) and `RepairSystem` (healing). See Movement Arbitration.
|
||||
8. **Combat resolution** — ships and defence stations validate/acquire targets, fire, apply damage; queue deaths. Each fire appends a `WeaponFiredEvent` to the sim's weapon-fired-event queue (REQ-SHP-FIRING-BEAM).
|
||||
9. **Deaths & loot** — process queued deaths: drop scrap (REQ-RES-SCRAP-DROP); if a full enemy-defence-station set was destroyed this tick, generate up to 3 schematic choice options (REQ-DEF-SCHEMATIC-DROP) stored as pending state for the UI to present; remove entities.
|
||||
10. **`tickMovement`** — advance ship positions based on final `MovementIntent`.
|
||||
11. **Scrap despawn** — decrement scrap timers; remove expired scrap (REQ-RES-SCRAP-DROP).
|
||||
@@ -217,16 +217,20 @@ struct RepairTool { float ratePerTick; std::optional<EntityId> currentTarget;
|
||||
|
||||
### Behavior Components
|
||||
|
||||
Behaviors are decomposed, not bundled into per-role monolithic AIs. This is the critical modeling choice: adding a capability (e.g., putting a `Weapon` on a repair ship) must not require rewriting AI code.
|
||||
Behaviors are decomposed, not bundled into per-role monolithic AIs. This is the critical modeling choice: adding a capability (e.g., putting a `Weapon` on a repair ship) must not require rewriting AI code. Each behavior is a small component carrying its own target data plus a `float score` written by its evaluator each tick.
|
||||
|
||||
```cpp
|
||||
struct ThreatResponse { float engagementRange; CombatStance stance;
|
||||
CombatTargetPriority priority;
|
||||
std::optional<EntityId> currentTarget; };
|
||||
struct ScrapCollector { std::optional<QVector2D> scrapTarget; EntityId deliveryBay; };
|
||||
struct RepairBehavior { RepairTargetPriority priority;
|
||||
std::optional<EntityId> currentTarget; };
|
||||
struct HomeReturn { float retreatHpFraction; QVector2D homePos; };
|
||||
struct AdvanceBehavior { float score; }; // baseline fallback, all ships
|
||||
struct RallyBehavior { QVector2D rallyPoint; float score; }; // player combat ships
|
||||
struct RetreatBehavior { float retreatHpFraction; QVector2D retreatPoint; // player ships
|
||||
float score; };
|
||||
struct AttackBehavior { std::optional<EntityId> currentTarget; float score; };
|
||||
struct RepairBehavior { std::optional<EntityId> currentTarget;
|
||||
float maxRepairRange_tiles; float score; };
|
||||
struct SalvageScrapBehavior { std::optional<QVector2D> scrapTarget;
|
||||
float maxCollectionRange_tiles; float score; };
|
||||
struct DeliverScrapBehavior { BuildingId deliveryBay; float score; };
|
||||
struct SelectedBehaviorComponent { BehaviorKind winner; float bestScore; }; // selection result
|
||||
```
|
||||
|
||||
### Ship
|
||||
@@ -246,38 +250,42 @@ struct Ship {
|
||||
std::optional<SalvageCargo> cargo;
|
||||
std::optional<RepairTool> repairTool;
|
||||
|
||||
// Behaviors
|
||||
std::optional<ThreatResponse> threatResponse;
|
||||
std::optional<ScrapCollector> scrapCollector;
|
||||
std::optional<RepairBehavior> repairBehavior;
|
||||
std::optional<HomeReturn> homeReturn;
|
||||
// Behaviors (attached per capability; AdvanceBehavior + SelectedBehaviorComponent
|
||||
// on every ship, RetreatBehavior on player ships, etc.)
|
||||
std::optional<AttackBehavior> attackBehavior;
|
||||
std::optional<SalvageScrapBehavior> salvageScrapBehavior;
|
||||
std::optional<DeliverScrapBehavior> deliverScrapBehavior;
|
||||
std::optional<RepairBehavior> repairBehavior;
|
||||
|
||||
// Written by behavior systems, read by movement.
|
||||
// Written by the winning behavior's executor, read by movement.
|
||||
MovementIntent intent;
|
||||
};
|
||||
```
|
||||
|
||||
### Systems
|
||||
|
||||
Each behavior has its own tick system. A system iterates a flat `std::vector<Ship>` and skips ships that do not have the relevant components.
|
||||
Each behavior is split into a stateless **evaluator** and **executor** class (one per behavior, e.g. `AttackEvaluator`/`AttackExecutor`), orchestrated by `AiSystem`. Evaluators and executors only read/write behavior components and module target fields — they never mutate the game world. World mutation lives in dedicated module systems that run every tick, independent of which behavior won:
|
||||
|
||||
- `tickThreatResponse` — requires `threatResponse` + `weapon`. Acquires target, fires, manages cooldown.
|
||||
- `tickScrapCollector` — requires `scrapCollector` + `cargo`. Flies to scrap, picks up, returns to delivery bay.
|
||||
- `tickRepairBehavior` — requires `repairBehavior` + `repairTool`. Finds damaged target, moves to range, repairs.
|
||||
- `tickHomeReturn` — requires `homeReturn`. Overrides movement if hp drops below threshold.
|
||||
- `tickMovement` — reads `intent`, advances `position`.
|
||||
- `CombatSystem` — validates each weapon's executor-set target, falls back to nearest-target acquisition, fires, applies damage.
|
||||
- `SalvagerSystem` — collects scrap into cargo and delivers full cargo at a `SalvageBay`.
|
||||
- `RepairSystem` — validates each repair tool's target, falls back to nearest damaged friendly, applies healing.
|
||||
- `MovementIntentSystem` (`tickMovement`) — reads `MovementIntent`, advances `position`; brakes when inactive.
|
||||
|
||||
### Movement Arbitration
|
||||
|
||||
When multiple behaviors want to drive movement, a fixed global priority resolves the conflict. Each behavior system writes a `MovementIntent` carrying its priority; a higher-priority write overwrites a lower-priority one. `tickMovement` reads the final winner.
|
||||
Arbitration is **score-based**, not fixed-priority. In a single tick `AiSystem` runs three phases:
|
||||
|
||||
Initial priority order (subject to tuning):
|
||||
1. **Evaluate** — every behavior's evaluator iterates the ships that have its component, sets its target data, and writes a `float score` (see `BehaviorScores.h`). An evaluator returns an inactive score when its behavior does not apply.
|
||||
2. **Select** — `selectWinningBehaviors` resets each `SelectedBehaviorComponent`, then compares every behavior's score per ship, recording the highest as `winner`. Behaviors are considered highest-band first so a strict `>` breaks ties toward the more urgent behavior.
|
||||
3. **Execute** — each behavior's executor runs only for ships where it is the `winner`, writing the single `MovementIntent` and any preferred module targets.
|
||||
|
||||
`AdvanceBehavior` is present on every ship with the lowest score, guaranteeing a winner. The resulting band order:
|
||||
|
||||
```
|
||||
HomeReturn > ThreatResponse > RepairBehavior > ScrapCollector
|
||||
Retreat > Attack / Repair / SalvageScrap / DeliverScrap > Rally > Advance
|
||||
```
|
||||
|
||||
`tickMovement` runs last. Intents are cleared at the start of each tick.
|
||||
`MovementIntent` is cleared (inactive) at the start of each tick; `tickMovement` runs last.
|
||||
|
||||
### Why Not ECS
|
||||
|
||||
|
||||
Reference in New Issue
Block a user