# Enemy spawn director and squad coordination research

15 October 2026. Research and user decisions for ProjectI before revising M6.

## Direction

Use a Risk of Rain 2-inspired credit director to choose enemies, assemble groups and place pressure around a moving party. Use Destiny 2-inspired squad assignments and autonomous individual behavior to make those enemies cooperate after arrival. Side and rear arrivals are normal. Both visible and hidden births are allowed, with a readable reaction window for every birth.

The intended experience is changing, understandable pressure on an open handcrafted stage. Players can clear threats, reposition, flank, recover and explore. Enemies remain relevant as the party moves, without precise hidden tracking, instantaneous replacement or permanent formations.

This document records decisions made with the user in this discussion, supporting research and recommended details that still need specification or tuning. It does not implement the director, revise the existing implementation plan, or authorize M6 execution. The earlier request's restrictions on tests, builds, Unity operations, installations and commits remain in force; this requested research file is the only repository edit.

## Confirmed user decisions

| Topic | Selected direction |
| --- | --- |
| Credit economy | Each enemy has an editable cost and selection weight. Credit income and available choices can scale with run time, stage progression, chosen difficulty and player count. No hidden adaptation to player performance. |
| Three selection modes | Support a single enemy type, including individuals or homogeneous groups; premade group templates; and procedurally assembled groups. Each stage or encounter has editable weights for choosing between these modes. |
| Procedural compatibility | Apply compatibility rules only within the group currently being assembled. Support hard incompatibilities separately from soft weight increases/decreases. Hard incompatibilities hold regardless of selection order. |
| Mixed groups | Melee and ranged enemies may share a group and objective. Each member still needs its own valid placement and route. This replaces the existing same-navigation-family composition restriction in the intended design. |
| Spawn visibility | Allow visible and hidden births. Every birth has a reaction-window animation; rudimentary presentation is acceptable initially. This replaces hidden-spawn-only admission. |
| Arrival vulnerability | Arriving enemies are damageable but cannot attack until their reaction window ends. |
| Group arrival | Use a short, configurable stagger, with credit and population capacity accounted for. This changes the existing one-enemy-per-normal-interval approach. |
| Spawn direction and movement | Threats may arrive from any direction. Spawning follows the moving party rather than fixed encounter rooms. Safe distances, supported terrain, clearance and legal navigation remain required. |
| Split parties | Weight reachable player areas by party size and existing committed pressure, allowing temporary imbalance. Do not promise equal damage or exact round-robin allocation. |
| Earned space | Killing a group removes its pressure. Replacement follows normal admission timing; kills do not cause an immediate replacement refund or refill. |
| Blocked spending | Credits may accumulate up to a configurable ceiling. Opening space must not release a catch-up burst. |
| Boss reinforcement | While the boss lives, replace exploration spawning with a separate boss profile with its own credit income, cadence, enemy pool and add limit. Existing adds remain; all enemies obey a shared hard population limit. |
| Roaming elites | Elites can temporarily cooperate with packs they did not spawn with, retaining their own identity. Cooperation behavior is configurable by role. Without a useful nearby pack, an elite continues its own role-appropriate pressure toward the moving party. |
| Shared information | A cooperating elite receives observed player locations and fresh reports while an ally sees that player. Direct-fire attacks still require the elite's own clear sight and firing path. |
| Additional research scope | Explore roaming elite/pack relationships. Stage rewards, interactables, optional challenges and run modifiers are not selected additions to this document's design scope. |

The copied phrase “preserving hidden births” was explicitly resolved: hidden births remain possible, but hiding is no longer mandatory. The user chose readable arrivals rather than preserving the old visibility rejection.

## What the reference games establish

### Risk of Rain 2

The community's reverse-engineered director description separates initial stage setup, Void Seed setup and ongoing combat. Continuous directors earn credits; instantaneous directors receive an allocation. Enemy choices have costs, weights and eligibility conditions. Exploration and teleporter spawning use different director contexts. This supports separate profiles and budget ownership rather than one universal spawn loop. Exact numerical tables remain version-dependent. [Community director analysis](https://riskofrain2.wiki.gg/wiki/Directors)

Public modding documentation describes ground/air node graphs, monster-size restrictions and placement flags. Inspectable R2API source exposes spawn distance, overhead prevention, selection weight and stage eligibility. These are evidence for constrained placement and configurable choices, not proof that every point has a useful combat route. [Stage authoring](https://risk-of-thunder.github.io/R2Wiki/Mod-Creation/Assets/Stage/), [R2API card source](https://raw.githubusercontent.com/risk-of-thunder/R2API/master/R2API.Director/AddressableDirectorCard.cs)

Beetles visibly emerge from the ground and can be damaged during arrival, according to community documentation. This supports the chosen presentation reference, but does not establish a universal identical attack delay for every RoR2 monster. [Beetle](https://riskofrain2.wiki.gg/wiki/Beetle)

Community documentation describes Mending elites helping nearby eligible allies. That demonstrates a support effect based on nearby allies; it does not establish dynamic squad membership, shared target memory or a general roaming-elite coordinator. ProjectI's temporary cooperation and information-sharing rules below are its own design. [Elite effects](https://riskofrain2.wiki.gg/wiki/Celestine_Elites)

Version matters: the official 8 October 2026 update changes spawn-credit costs to adjust frequency and fixes invalid spawn nodes. Its release announcement names PC, PS5 and Xbox Series X|S. Do not copy old constants or assume older platforms are identical. [Official patch notes](https://support.2k.com/hc/en-us/articles/56193476123795-Risk-of-Rain-2-Patch-Notes-October-8-2026)

### Destiny and Destiny 2

Former Destiny/Destiny 2 designer Max Nichols describes squads receiving prioritized tasks associated with firing areas, with capacity and exhaustion conditions. Individual combatants retain autonomous behavior. Durable, conspicuous threats can anchor space while other roles pressure it differently. The useful adaptation is common purpose with distinct member actions; the project does not adopt fixed front/middle/back room progression. [Firsthand encounter-design account](https://namelessquality.com/the-basics-of-destiny-encounter-design/)

For Destiny 2's Infinite Forest, Nichols describes combining tactical sets into squads, using mutually exclusive combinations and unequal selection weights. He also describes excessive unrestricted randomness making runs feel indistinct. This directly supports compatibility-aware composition and stage-specific pools. His system selected tactical sets; ProjectI's proposed enemy-by-enemy conditional weights are an adaptation, not a claim about Bungie's algorithm. [Infinite Forest system-design account](https://www.maxnicholsdesign.com/system-design)

Destiny 2 AI engineer Levi Lindsey describes work on behavior trees, temperaments, firing points, path-following and abilities. This supports keeping squad guidance separate from individual decision and execution responsibilities. It does not disclose the complete targeting or squad-report algorithm. [Developer portfolio, Bungie section](https://levi.dev/)

Bungie's 2018 Scene Editor presentation demonstrates high-level control over spawning, movement and targeting in scripted story sequences. It is evidence of encounter authorship, not a universal runtime squad design. [GDC presentation](https://media.gdcvault.com/gdc2018/presentations/Moran_Evan_Walking_Talking_And_Projectiles.pdf)

An additional Bungie source, the October 2024 Solo Ops announcement, proposed dynamic squad spawning influenced by performance, time outside combat and objective proximity. This is an announced activity-specific design, not verified shipped behavior or a description of all Destiny 2 content. The user explicitly does not select its hidden performance-adaptation idea for ProjectI. [Solo Ops announcement](https://origin-static01.bungie.net/7/en/News/Article/solo_ops)

The existing [Destiny research](2026-10-13-destiny-enemy-ai-research.md) and [compatible AI research](2026-10-13-destiny-compatible-ai-gap-research.md) remain useful background. Their proposed ownership diagram is a ProjectI synthesis, not a recovered Bungie call graph. No inspected source establishes that unrelated Destiny elites automatically join packs or share personal sight exactly as proposed here.

## How the selected design should fit together

### Credit and selection layers

Keep cost, selection weight and eligibility distinct:

- **Cost:** how much of the available credit budget admitting this enemy consumes.
- **Weight:** how likely an eligible choice is relative to other eligible choices.
- **Eligibility:** whether it is allowed now, considering stage, profile, compatibility, population and physical feasibility.

There are also two different levels of weight: choosing a spawning mode, then choosing content within that mode. Making procedural groups more common should not accidentally change a particular enemy's price.

The recommended starting rule is to derive group cost from its members. A template discount or surcharge would be an additional balance feature, not an assumed requirement. Elite tier and enemy role remain separate: a sniper or Keeper is a role; an elite variant is a stronger tier. Representing elite variants as explicit purchases is preferable to silently combining a new credit system with the existing kill-based elite roll, but the exact authoring representation remains to specify.

For a procedural group, start from the selected profile's eligible enemy pool. Each selection changes the remaining options. Hard incompatibilities reject a combination regardless of draw order; soft modifiers change the relative likelihood of otherwise legal choices. Stop at configured group-size and budget limits. An exhausted or unaffordable pool must have a bounded result rather than endless rerolling.

The user's examples illustrate two different rule types: sniper/melee exclusion, and ordinary ranged enemies making a tether-support choice more likely. These are composition examples, not a finalized roster-wide compatibility table or chosen numerical multiplier. Exact stacking of multiple soft modifiers also remains a specification detail.

These rules apply to procedural assembly. They do not retroactively remove living enemies, forbid independent groups from meeting, or stop a roaming elite from cooperating nearby. Whether a future common authoring validator should also apply selected compatibility rules to premade templates is not yet decided.

### Purchase, admission and arrival

Treat a group purchase as a bounded arrival commitment. It must account for both credits and population capacity before admitting members. Revalidate each actual birth against the current stage, players, occupancy and that member's navigation requirements.

Recommended safeguards for the future specification:

- Pending members consume reserved capacity, so overlapping purchases cannot oversubscribe the hard limit.
- Births proceed at the configured short stagger. Failed placement cannot move already born members to another distant spawn footprint.
- Unused reservations expire or are cancelled explicitly. Any refund concerns an enemy that was never born, not one players killed.
- A member killed during arrival is a legitimate loss, not a missing member to replace in the same purchase.
- Stage changes, all-player loss, reset and boss-profile transitions cancel or explicitly resolve pending work.

The reaction window is an authoritative gameplay rule with matching presentation. It must not depend only on a local animation finishing. A basic materialization effect or emergence animation is sufficient for an initial prototype. The start/end, damageable body and point at which attacks become possible should be understandable on remote clients as well as the host. Exact timings, movement during arrival and restrictions on non-damaging support effects remain tuning/specification questions.

### Moving pressure and earned space

Placement follows eligible player regions and supported approaches. It may produce side or rear arrivals without requiring one dominant front. Party size and existing commitments influence which reachable area receives the next purchase; they do not multiply the global population ceiling for every separated player.

Count relevant commitments, including groups already approaching an area, rather than only enemies currently dealing damage. Otherwise the director can repeatedly purchase pressure for the same destination before earlier groups arrive. This is spatial allocation, not hidden adaptation to player skill or current health.

Credit income and spawn scheduling are separate. A capped bank permits saving for costly threats, while normal admission timing and bounded group arrival prevent the bank from becoming an immediate refill after a clear. Existing survivors keep useful actions; recovery must not be implemented as a global AI pause. The chosen design does not yet guarantee a fixed quiet period after each group dies.

Retain safe distance from every living player, supported geometry, per-member clearance and appropriate legal routes. The current 20–60 m distance ring and 6 m footprint are baseline tuning, not newly accepted final values. Useful ranged/support approaches may differ from reaching a player's exact coordinate; resolve that with M3/M6's role-specific positioning contracts.

### Boss reinforcement profile

Boss entry switches admission ownership from the exploration profile to the boss reinforcement profile. This is a replacement, not two independent streams stacking their full pressure. The boss profile exposes its own income, banking ceiling, cadence, selection-mode weights, content pool and add limit.

Surviving ordinary enemies remain and count against the relevant limits. Reducing the boss add limit should prevent further purchases rather than delete survivors. Boss health, required defeat and progression remain separately owned; killing reinforcements cannot stand in for defeating the boss.

Recommended transition behavior is to start the boss profile with an explicit authored balance and cancel unadmitted exploration commitments, avoiding an accidental exploration-bank dump at boss entry. Credit carryover is not a confirmed user decision. The shared hard limit's numerical value, boss reservation and how descendants count need explicit preservation/tuning in the implementation plan. The current 16 ordinary / 17 including boss contract is the baseline, not permission to increase population.

### Squads and individual behavior

The director determines what is bought and where pressure is needed. Squads receive a common temporary objective and broad approach region. Individual enemies choose role-appropriate positions, targets and actions using their capabilities and actual evidence.

A mixed group does not require identical destinations, synchronized volleys or a formation that waits for the slowest member. Melee can advance while a shooter maintains a useful lane and support serves eligible allies. Preserve stable decisions, bounded pursuit, paid attack recovery and useful routes while replacements are pending.

Changing an assignment or entering cooperation must not restore health, reset cooldowns, renew the same pursuit indefinitely, or grant knowledge of an unseen player's live location. Hidden retirement remains a separate M7 failure policy. Permitting visible births does not authorize visible disappearance or teleport recovery.

## Roaming elites and temporary cooperation

Separate three relationships: an enemy's birth group, its current pressure assignment, and temporary cooperation with nearby allies. A roaming elite can keep its identity and assignment while helping another group. Spatial proximity alone should not merge all nearby enemies into one permanent squad.

The selected default is independent, role-appropriate pressure with opportunistic cooperation. A support elite may seek a position that benefits nearby allies; a ranged elite may contribute another lane; a melee elite may share the general engagement while using its own approach. These are recommended examples to evaluate with existing roles, not authorization for new abilities.

When an eligible cooperating member personally sees a player, the elite receives that observed position and fresh reports while observation continues. Those reports guide awareness, approach and repositioning. Direct-fire permission still comes from the elite's own sight and physical firing path. When every observer loses sight, the last report ages rather than following the hidden player.

Preserve the original observer, target lifetime and observation time. Forwarding a report must not refresh its age or turn it into personal sight. Existing [report intake](../../Assets/_Project/Features/Enemies/Perception/EnemyPerception.cs) already distinguishes these concepts; M6 still needs to own which squads and temporary partners may exchange reports.

Recommended cooperation controls are local range/reachability, compatible purpose, a bounded number of partners and stable reassessment. Release cooperation when the group is gone, the opportunity is no longer useful or separation makes cooperation unreasonable. Preserve valid personal memory and ongoing paid actions rather than restarting the elite's brain. Exact join/leave thresholds, report frequency and whether sharing is reciprocal remain specification details; reciprocal sharing is a reasonable candidate, not a recorded user selection.

Killing a roaming elite should remove its contribution without promoting a surviving grunt into a substitute or purchasing an immediate replacement. Killing a pack should similarly matter even if its cooperating elite survives. Support must retain its own target eligibility, range, visibility, stacking and lifecycle rules; temporary cooperation does not bypass them.

## Current implementation and required plan changes

Repository baseline inspected: `21bd4aadf2aa17b2b59fd96e24827273cfc17059`. The [current brief](../PROJECT_PLAN.md#current-state-and-next-step) records accepted M5/M5B work within its evidence limits, with normal-stage enemies still passive. Historical pack AI is retired. This document describes desired future behavior, not active normal-stage combat.

| Current behavior or requirement | User-selected change or preservation | Repository reference |
| --- | --- | --- |
| Elapsed-time pressure beats and one ordinary opportunity per interval; no enemy credit economy | Credit-funded selection, capped saving and short staggered groups; preserve bounded admissions and earned space | [PrototypeEncounterDirector](../../Assets/_Project/Features/Enemies/Encounters/PrototypeEncounterDirector.cs), `TickOrdinaryAdmission`, lines 108–125; [EncounterPacing](../../Assets/_Project/Features/Enemies/Encounters/EncounterPacing.cs), lines 36–67 |
| Ordinary points can be rejected for player visibility | Allow visible arrivals with authoritative reaction windows; retain physical safety | [Visibility check](../../Assets/_Project/Features/Enemies/Encounters/PrototypeEncounterDirector.cs), lines 398–415; [point checks](../../Assets/_Project/Features/Enemies/Encounters/EnemySpawnCircleSelector.cs), lines 407–419 |
| Composition profiles reject mixed navigation families | Allow mixed-role groups with independent member validation | [EnemyCompositionDefinition](../../Assets/_Project/Features/Enemies/Coordination/EnemyCompositionDefinition.cs), lines 13–24 |
| Boss phase retains adds but stops ordinary admission | Retain existing adds and enable a separate boss reinforcement profile | [EncounterRules](../../Assets/_Project/Features/Enemies/Encounters/EncounterRules.cs), lines 19–30; [accepted old boss policy](../superpowers/plans/2026-10-06-encounter-pressure-holds.md) |
| Random player anchors and complete paths to projected player coordinates | Allocate around reachable player areas using party size and committed pressure; clarify useful role-specific approaches | [EnemySpawnCircleSelector](../../Assets/_Project/Features/Enemies/Encounters/EnemySpawnCircleSelector.cs), lines 156–166 and 421–428 |
| Personal sight and received reports are distinct | Preserve that distinction while adding scoped squad/elite report transport | [EnemyPerception](../../Assets/_Project/Features/Enemies/Perception/EnemyPerception.cs), lines 175–185; [EnemyObservationRules](../../Assets/_Project/Features/Enemies/Perception/EnemyObservationRules.cs), lines 34–49 |

The [existing M6](../superpowers/plans/2026-10-13-enemy-ai-implementation.md#m6--add-moving-encounter-pressure-and-squads) explicitly preserves hidden-spawn safety, same-family composition admission, cadence and the old boss reinforcement policy. Those instructions conflict with the selected future direction. A later authorized planning task must revise the affected contracts before implementation; this research file does not silently rewrite them.

The unchanged foundation includes server/host authority, actor/target/session/stage identity, physical safety, bounded work, legitimate death and reward ownership, required boss defeat, preserved damage through reassignment, and separate individual knowledge/attack validation. M7 retirement, M10 Keeper behavior, M13 descendants, M14 bosses and M15 production promotion must be reconciled with the new admission/cooperation design where affected.

## Recommended next step and evidence

First revise the spawning/coordination plan around this agreed direction. Keep director purchasing and physical admission distinct from squad decisions and individual AI. A useful sequence is to prove credit purchases and readable safe arrivals, then mixed-group assignments and split-party pressure, then temporary elite cooperation and its information boundaries. Boss reinforcement requires explicit lifecycle integration. This is a suggested sequence, not an implementation plan or permission to begin it.

The research leaves numerical and technical choices open: costs, weights, group-size ranges, income curves, banking ceiling, stagger and inter-group cadence, reaction-window length, distance/route preferences, boss starting balance, cooperation thresholds, soft-modifier stacking, and final elite-purchase representation. Initial values should be editable proposals rather than presented as decisions the user already made.

Future keep/tune/revert evidence should address:

- Visible/front/side/rear arrivals: can host and clients recognize the arrival and react before hostile action, without clipping or appearances on top of players?
- Strong clears and blocked admissions: does a clear produce meaningful space, with no accumulated purchase burst, killed-member replacement or unlimited credit backlog?
- Procedural groups: do hard exclusions hold in either selection order, do soft preferences affect variety, and do impossible pools finish safely?
- Mixed roles and movement: can each member contribute through supported approaches without the entire group waiting, reversing together or chasing indefinitely?
- Split parties: do solo/two/four-player arrangements receive relevant pressure without multiplying the cap or permanently neglecting one branch?
- Elite cooperation: does a newly associated elite use genuine ally observations, lose fresh information when observation ends, and retain its own sight requirement for direct fire?
- Boss transition: do existing adds, pending purchases, profile switching, caps and required defeat behave coherently without unintended reinforcement surges?
- Role removal: does killing support or an elite change the encounter immediately, preserving single-target as well as area-build value?

Use the project's [testing procedure](../TESTING.md) and relevant [catalogue](../TEST_CATALOGUE.md) when selecting future checks. Automated proof, actual co-op gameplay, readability and representative hardware acceptance remain separate. No gameplay verification was performed for this research document.