Was hier passiert, Zeile für Zeile

public enum AttackType : byte { Melee = 0, Ranged = 1 }
public enum TargetType : byte { Ground = 0 }

Zwei Aufzählungstypen. : byte heißt, sie werden intern als 1-Byte-Zahl gespeichert statt der C#-Standardgröße (4 Byte, int) — spart Speicher, wenn später tausende Units diese Werte tragen. TargetType hat aktuell nur "Ground", ist aber schon vorbereitet für z.B. "Air" später.

[CreateAssetMenu(fileName = "UnitDefinition", menuName = "Skirmish/Unit Definition")]

Dieses Attribut erzeugt den Rechtsklick-Menüpunkt "Create → Skirmish → Unit Definition" im Project-Fenster — so legst du neue Unit-Typen als Assets an, ohne Code zu schreiben.

public class UnitDefinition : ScriptableObject

ScriptableObject statt MonoBehaviour: lebt nicht auf einem GameObject in der Szene, sondern als eigenständige Asset-Datei im Project-Fenster — genau richtig für "Daten, die mehrfach wiederverwendet werden" (viele Units können dieselbe Definition referenzieren).

public string unitId = "Unit";
public int cost = 10;

Ein Name zur Wiedererkennung und die Gold-Kosten — cost wird erst ab Phase 3 (Base/Shop) tatsächlich benutzt, ist aber jetzt schon Teil der Definition.

public float maxHealth = 100f;
public float moveSpeed = 3f;
public float attackDamage = 10f;
public float attackRange = 1.5f;
public float attackCooldown = 1f;
public AttackType attackType = AttackType.Melee;
public TargetType targetType = TargetType.Ground;

Die eigentlichen Kampfwerte, die du im Inspector pro Unit-Typ einstellst: maximales Leben, Lauftempo, Schaden pro Treffer, wie nah ein Ziel sein muss, und wie viele Sekunden zwischen zwei Angriffen liegen.

public Mesh mesh;
public Material material;

Wie sieht die Unit aus — genau wie pilleMesh/pilleMaterial beim Pille-Bootstrap, nur diesmal pro Unit-Typ statt global.

public struct Team : IComponentData
{
    public byte Value;
}

0 = Team A, 1 = Team B. Ein byte reicht locker für zwei Teams (in Zukunft theoretisch bis zu 256).

public struct CombatStats : IComponentData
{
    public float MoveSpeed;
    public float AttackDamage;
    public float AttackRange;
    public float AttackCooldown;
    public byte AttackType;
}

Das ist der zentrale Trick aus dem Plan: Systeme lesen nur diese Komponente, nie UnitDefinition direkt. Der Wert wird einmal beim Spawnen aus der Definition (später: × Upgrade-Multiplikator) hineinkopiert. So kann man später Upgrades einbauen, ohne dass irgendein Kampf-System umgeschrieben werden muss.

public struct Health : IComponentData
{
    public float Current;
    public float Max;
}

Aktuelles und maximales Leben getrennt gespeichert — Max wird für Phase 3+ gebraucht (z.B. eine Lebensbalken-Anzeige "Current / Max").

public struct AttackCooldownTimer : IComponentData
{
    public float Value;
}

Zählt in Sekunden runter, bis die Unit wieder angreifen darf — analog zu einer Abklingzeit bei Fähigkeiten.

public struct Target : IComponentData
{
    public Entity Value;
}

Speichert, WELCHE andere Entity gerade als Kampf-Ziel gilt. Entity.Null heißt "kein Ziel gerade" — dann läuft die Unit stattdessen weiter Richtung Gegner-Base.

public struct UnitTypeId : IComponentData
{
    public int Value;
}

Merkt sich, aus welchem Eintrag im unitTypes-Array diese Unit stammt — noch ungenutzt, wird in Phase 4 gebraucht, um beim Tod die richtigen Gore-Teile (Kopf/Arm/Waffe) zuzuordnen.

public struct DeadTag : IComponentData
{
}

Ein "Tag" ohne jegliche Daten (leerer Struct-Body) — dient nur als Markierung "diese Entity ist tot, wird gleich entfernt". Systeme können mit WithNone<DeadTag> tote Units einfach aus ihren Abfragen ausschließen.

public struct LaneMoveTarget : IComponentData
{
    public float3 Value;
}

Ein fester Zielpunkt — die gegnerische Base. Team A bekommt beim Spawn die Position von Team B eingetragen und umgekehrt. Der Kommentar in der Datei merkt schon an: für eine später geknickte Lane (mehrere Wegpunkte) würde man hier ein BlobArray<float3> + einen Index ergänzen, ohne LaneMovementSystem umbauen zu müssen.

public void OnCreate(ref SystemState state)
{
    state.RequireForUpdate<CombatStats>();
}

Wie beim Pille-Movement-System: läuft erst, sobald mindestens eine Unit mit Kampfwerten existiert.

var job = new MoveTowardTargetJob { DeltaTime = SystemAPI.Time.DeltaTime };
state.Dependency = job.ScheduleParallel(state.Dependency);

Baut den Job mit der aktuellen Frame-Zeit und schickt ihn parallel über alle Units — exakt dasselbe Muster wie PilleMovementSystem.

[BurstCompile]
[WithNone(typeof(DeadTag))]
public partial struct MoveTowardTargetJob : IJobEntity

Dieses Attribut auf dem Job selbst filtert automatisch tote Units aus der Abfrage heraus — Leichen sollen sich schließlich nicht mehr bewegen.

void Execute(ref LocalTransform transform, in CombatStats stats, in LaneMoveTarget laneTarget, in Target target)

ref bei transform (wir ändern die Position), in bei den anderen drei (wir lesen sie nur, ändern sie hier nicht — schneller als ref, weil Burst dann weiß, dass es sich keine Rückschreibe-Gedanken machen muss).

if (target.Value != Entity.Null)
    return;

Hat die Unit gerade ein Kampfziel, wird hier sofort abgebrochen — CombatSystem kümmert sich dann ums Stehenbleiben-und-Angreifen, LaneMovementSystem lässt die Finger davon.

float3 toTarget = laneTarget.Value - transform.Position;
float dist = math.length(toTarget);
if (dist < 0.05f)
    return;

Vektor und Distanz zum Ziel. Ist die Unit praktisch schon da (unter 5 cm entfernt), wird nichts mehr bewegt — verhindert ein sichtbares "Zittern" durch minimale Überschreitungen.

float3 dir = toTarget / dist;
transform.Position += dir * math.min(stats.MoveSpeed * DeltaTime, dist);

Normiert die Richtung (Division durch die eigene Länge = Länge 1), bewegt sich dann Richtung Ziel — math.min(...) sorgt dafür, dass die Unit niemals über das Ziel hinausschießt, auch nicht bei großen Zeitsprüngen (z.B. kurzem Frame-Ruckler).

public struct LaneGridSingleton : IComponentData
{
    public NativeParallelMultiHashMap<int, Entity> Buckets;
    public float BucketSize;
}

Eine "HashMap", die zu einer Zahl (dem Bucket-Index) mehrere Entities speichern kann (deshalb "Multi"). Man kann eine NativeContainer wie diese direkt in einer Komponente speichern, solange sie unmanaged bleibt — hier als Singleton, damit jedes System per SystemAPI.GetSingleton Zugriff bekommt.

[UpdateBefore(typeof(TargetingSystem))]
public partial struct BuildLaneGridSystem : ISystem

Erzwingt die Reihenfolge: dieses System muss VOR TargetingSystem laufen, sonst würde Targeting mit einem leeren oder veralteten Grid arbeiten.

if (!SystemAPI.HasSingleton<LaneGridSingleton>())
{
    var entity = state.EntityManager.CreateEntity(typeof(LaneGridSingleton));
    state.EntityManager.SetComponentData(entity, new LaneGridSingleton
    {
        Buckets = new NativeParallelMultiHashMap<int, Entity>(65536, Allocator.Persistent),
        BucketSize = 5f
    });
}

Erzeugt die Singleton-Entity nur, falls sie noch nicht existiert. Kapazität fest auf 65.536 gesetzt (statt dynamisch wachsend) — das vermeidet, dass ein Reallokieren während ein paralleler Job gerade hineinschreibt, Probleme macht. Allocator.Persistent heißt: bleibt bestehen, bis wir es explizit wieder freigeben (nicht wie Temp/TempJob, die nur kurzlebig sind).

if (SystemAPI.HasSingleton<LaneGridSingleton>())
{
    var grid = SystemAPI.GetSingleton<LaneGridSingleton>();
    if (grid.Buckets.IsCreated)
        grid.Buckets.Dispose();
}

Gibt den mit Persistent reservierten Speicher beim Beenden frei — das ist Pflicht, sonst merkt sich Unity im Editor ein "Speicherleck" und beschwert sich beim nächsten Play.

var gridRW = SystemAPI.GetSingletonRW<LaneGridSingleton>();
gridRW.ValueRW.Buckets.Clear();
var job = new FillGridJob { BucketSize = ..., Writer = gridRW.ValueRW.Buckets.AsParallelWriter() };
state.Dependency = job.ScheduleParallel(state.Dependency);

GetSingletonRW gibt eine beschreibbare Referenz (statt einer Kopie). Clear() leert das Grid jeden Frame komplett (die alte Speicherreservierung bleibt aber erhalten — nur der Inhalt wird gelöscht). AsParallelWriter() erlaubt mehreren Threads gleichzeitig sicher hineinzuschreiben.

[BurstCompile]
[WithAll(typeof(Team))]
[WithNone(typeof(DeadTag))]
public partial struct FillGridJob : IJobEntity

[WithAll(typeof(Team))] ist wichtig: ohne dieses Attribut würde die automatische Query nur nach LocalTransform filtern (dem einzigen Parameter, den Execute direkt nutzt) — das würde auch die Pillen ins Grid mitziehen, falls beide Systeme gleichzeitig in derselben Szene laufen! Team ist eine Komponente, die nur Skirmish-Units haben.

void Execute(Entity entity, in LocalTransform transform)
{
    int bucket = (int)math.floor(transform.Position.z / BucketSize);
    Writer.Add(bucket, entity);
}

Berechnet, in welchen "Slot" entlang der Z-Achse (der Lane-Richtung) diese Unit fällt — z.B. bei BucketSize = 5 landen alle Units zwischen Z=10 und Z=15 im Bucket 2. Dann wird die Entity in genau diesen Slot eingetragen. Das ist der ganze Trick: statt 5.000 gegen 5.000 zu prüfen, muss man später nur noch den eigenen Bucket + die zwei Nachbar-Buckets durchsuchen.

var grid = SystemAPI.GetSingleton<LaneGridSingleton>();
var job = new AcquireTargetJob { Buckets = grid.Buckets, ..., TeamLookup = SystemAPI.GetComponentLookup<Team>(true), ... };
state.Dependency = job.ScheduleParallel(state.Dependency);

Holt das fertige Grid (von BuildLaneGridSystem) und drei ComponentLookups — das sind "wahlfreie Zugriffe": während der Job über EINE Unit iteriert, kann er trotzdem gezielt Daten von JEDER ANDEREN Entity nachschlagen (Team, Position, Tot-Status). Das true markiert die Lookups als nur-lesend.

void Execute(Entity entity, ref Target target, in Team team, in CombatStats stats, in LocalTransform transform)

Läuft für jede lebende Unit (Tote sind per [WithNone(typeof(DeadTag))] ausgeschlossen). entity ist die eigene Entity — gebraucht, um sich selbst später nicht versehentlich als eigenes Ziel zu wählen.

float rangeSq = stats.AttackRange * stats.AttackRange;
if (target.Value != Entity.Null)
{
    bool stillValid = !DeadLookup.HasComponent(target.Value)
        && TransformLookup.HasComponent(target.Value)
        && math.distancesq(transform.Position, TransformLookup[target.Value].Position) <= rangeSq;
    if (stillValid) return;
    target.Value = Entity.Null;
}

Bevor überhaupt neu gesucht wird: ist das aktuelle Ziel noch am Leben, existiert es noch, und ist es noch in Reichweite? Wenn ja, sofort zurück — das spart die teure Grid-Suche in den meisten Frames, weil eine Unit meist mehrere Angriffe hintereinander auf dasselbe Ziel macht.

int myBucket = (int)math.floor(transform.Position.z / BucketSize);
float bestDistSq = float.MaxValue;
Entity best = Entity.Null;

Der eigene Bucket (genau wie in FillGridJob berechnet), plus zwei Variablen, um während der Suche den bisher besten (nächsten) Kandidaten zu merken.

for (int offset = -1; offset <= 1; offset++)
{
    int bucket = myBucket + offset;
    if (!Buckets.TryGetFirstValue(bucket, out Entity candidate, out var it))
        continue;
    do { ... } while (Buckets.TryGetNextValue(out candidate, ref it));
}

Durchsucht den eigenen Bucket UND je einen links/rechts davon (offset -1, 0, 1) — deckt so auch Fälle ab, wo ein Gegner knapp jenseits der Bucket-Grenze steht. TryGetFirstValue/TryGetNextValue ist das Standard-Muster, um alle Einträge zu einem Schlüssel aus einer NativeParallelMultiHashMap herauszuholen.

if (candidate == entity) continue;
if (!TeamLookup.HasComponent(candidate) || TeamLookup[candidate].Value == team.Value) continue;
if (!TransformLookup.HasComponent(candidate)) continue;

Drei Ausschlussgründe: der Kandidat ist man selbst, der Kandidat gehört zum eigenen Team (keine Freundlich-Feuer!), oder er hat gar keine Position (theoretisch nie der Fall, aber sicherheitshalber geprüft).

float distSq = math.distancesq(transform.Position, TransformLookup[candidate].Position);
if (distSq <= rangeSq && distSq < bestDistSq)
{
    bestDistSq = distSq;
    best = candidate;
}

Von allen gültigen Kandidaten in Reichweite wird der nächste gewählt — nicht irgendeiner. Nach der Schleife (Zeile ganz unten: target.Value = best;) wird das Ergebnis gespeichert, egal ob ein Ziel gefunden wurde oder Entity.Null übrig blieb.

// Bewusst NICHT parallelisiert (kein ScheduleParallel): zwei Units koennten
// sonst im selben Frame gleichzeitig dasselbe Ziel treffen (Race Condition ...)
[UpdateAfter(typeof(TargetingSystem))]

Läuft garantiert erst, NACHDEM alle Ziele für diesen Frame feststehen. Der Grund für Single-Thread: zwei Units könnten sonst gleichzeitig (auf verschiedenen CPU-Kernen) versuchen, dieselbe fremde Health zu verändern — das wäre ein klassischer Daten-Wettlauf mit unvorhersehbarem Ergebnis.

var ecb = SystemAPI.GetSingleton<EndSimulationEntityCommandBufferSystem.Singleton>()
    .CreateCommandBuffer(state.WorldUnmanaged);
var healthLookup = SystemAPI.GetComponentLookup<Health>();

Ein EntityCommandBuffer (ECB) sammelt "Änderungswünsche" (hier: Komponente hinzufügen), die erst später sicher ausgeführt werden — man darf nämlich nicht mitten in einer laufenden Abfrage direkt Komponenten hinzufügen/entfernen. healthLookup hier ohne true — also lesend UND schreibend, weil wir gleich fremdes Leben verändern.

foreach (var (target, stats, cooldown) in
    SystemAPI.Query<RefRO<Target>, RefRO<CombatStats>, RefRW<AttackCooldownTimer>>()
        .WithNone<DeadTag>())

Ein SystemAPI.Query-foreach ist die "von Hand geschriebene", aber trotzdem Burst-schnelle Alternative zu einem separaten IJobEntity — hier bewusst gewählt, weil wir single-threaded bleiben wollen. RefRO = nur lesen, RefRW = lesen und schreiben.

cooldown.ValueRW.Value -= deltaTime;
if (target.ValueRO.Value == Entity.Null) continue;
if (cooldown.ValueRO.Value > 0f) continue;

Jede Unit zählt ihren Cooldown IMMER runter (auch ohne Ziel). Dann zwei Abbruchgründe: kein Ziel gesetzt, oder Cooldown noch nicht abgelaufen — continue springt zur nächsten Unit in der Schleife.

if (!healthLookup.HasComponent(target.ValueRO.Value)) continue;
var targetHealth = healthLookup[target.ValueRO.Value];
targetHealth.Current -= stats.ValueRO.AttackDamage;
healthLookup[target.ValueRO.Value] = targetHealth;
cooldown.ValueRW.Value = stats.ValueRO.AttackCooldown;

Liest das Leben des Ziels über den Lookup (nicht über die eigene Query — das Ziel ist ja eine ANDERE Entity), zieht den Schaden ab, schreibt zurück, und setzt den eigenen Cooldown auf den vollen Wert zurück (nächster Angriff erst wieder nach AttackCooldown Sekunden).

if (targetHealth.Current <= 0f)
{
    ecb.AddComponent<DeadTag>(target.ValueRO.Value);
}

Fällt das Leben auf 0 oder darunter, wird dem Ziel (nicht dem Angreifer!) über den ECB der DeadTag angehängt. Die Entity wird dadurch NICHT sofort gelöscht — das übernimmt erst DeathSystem im nächsten Durchlauf.

public partial struct DeathSystem : ISystem

Kein [BurstCompile] hier — bewusst, weil Debug.Log (in der Schleife) keine Burst-kompatible Operation ist. Da hier ohnehin nur wenige Units pro Frame sterben, kostet das kaum Performance.

state.RequireForUpdate<DeadTag>();

Läuft nur, solange mindestens eine Entity gerade den DeadTag trägt — in den meisten Frames (niemand stirbt gerade) macht dieses System dadurch komplett gar nichts.

var ecb = SystemAPI.GetSingleton<EndSimulationEntityCommandBufferSystem.Singleton>()
    .CreateCommandBuffer(state.WorldUnmanaged);
foreach (var (deadTag, entity) in SystemAPI.Query<RefRO<DeadTag>>().WithEntityAccess())
{
    ecb.DestroyEntity(entity);
}

Findet alle als tot markierten Entities und reiht sie zum Löschen ein (wieder über einen ECB statt direkt, aus demselben Grund wie in CombatSystem). WithEntityAccess() gibt zusätzlich zur Komponente auch die Entity-ID selbst mit in die Schleife.

[SerializeField] private UnitDefinition[] unitTypes;
[SerializeField] private string wallTag = "Wall";
[SerializeField] private float spawnHeight = 1f;
[SerializeField] private float spawnSpreadX = 8f;
[SerializeField] private int debugWaveCountPerTeam = 20;

Das Array, das du im Inspector mit deinen UnitDefinition-Assets befüllst. spawnSpreadX ist eine seitliche Streuung beim Spawnen, damit nicht alle Units exakt übereinander starten.

private Entity[] templatesTeam0;
private Entity[] templatesTeam1;
private float3 team0BasePos;
private float3 team1BasePos;
private EntityQuery aliveQuery;

Zwei Template-Arrays (ein Template pro Unit-Typ, getrennt nach Team, weil jedes Team ein anderes LaneMoveTarget braucht), die zwei Basis-Positionen an den Lane-Enden, und eine Query, die fürs Overlay zählt, wie viele Units gerade leben.

if (unitTypes == null || unitTypes.Length == 0)
{
    Debug.LogError("❌ ...");
    enabled = false;
    return;
}

Bricht sauber ab, falls im Inspector kein einziger Unit-Typ eingetragen wurde.

var laneBounds = ComputeLaneBounds();
team0BasePos = new float3(0, spawnHeight, laneBounds.min.z + 2f);
team1BasePos = new float3(0, spawnHeight, laneBounds.max.z - 2f);

Nutzt dieselbe Wand-basierte Grenzenberechnung wie beim Pille-System (nur diesmal als eigene Methode), aber interpretiert die Z-Achse als "Lane-Länge": Team A startet nahe dem Z-Minimum, Team B nahe dem Z-Maximum, jeweils 2 Einheiten von der Wand entfernt.

templatesTeam0 = new Entity[unitTypes.Length];
templatesTeam1 = new Entity[unitTypes.Length];
for (int i = 0; i < unitTypes.Length; i++)
{
    ...
    templatesTeam0[i] = CreateUnitTemplate(unitTypes[i], i, 0, team1BasePos);
    templatesTeam1[i] = CreateUnitTemplate(unitTypes[i], i, 1, team0BasePos);
}

Für jeden Unit-Typ werden ZWEI Templates gebaut — eines für Team 0 (das Richtung Team-1-Base läuft) und eines für Team 1 (Richtung Team-0-Base). Vorher wird geprüft, ob Definition/Mesh/Material gesetzt sind (Zeilen davor im Original), sonst Abbruch mit klarer Fehlermeldung.

var walls = GameObject.FindGameObjectsWithTag(wallTag);
...
foreach (var wall in walls) { ... combined.Encapsulate(rend.bounds); }
return combined;

1:1 dasselbe Muster wie PilleDotsBootstrap.ComputeWallBounds() — bewusst dupliziert statt geteilt, weil beide Systeme unabhängig voneinander bleiben sollen (kein gemeinsamer Code, der beide gleichzeitig beeinflussen könnte).

var entity = entityManager.CreateEntity(typeof(Team), typeof(CombatStats), typeof(Health), ...);
var desc = new RenderMeshDescription(...);
var renderMeshArray = new RenderMeshArray(new[] { def.material }, new[] { def.mesh });
RenderMeshUtility.AddComponents(entity, entityManager, desc, renderMeshArray, ...);

Erstellt eine Entity mit ALLEN Komponenten, die eine Kampf-Unit braucht (Team, Kampfwerte, Leben, Cooldown, Ziel, Typ-ID, Laufziel, Transform), dann exakt dasselbe Rendering-Setup wie beim Pille-Template — nur diesmal mit dem Mesh/Material aus der jeweiligen UnitDefinition.

entityManager.SetComponentData(entity, new Team { Value = team });
entityManager.SetComponentData(entity, new CombatStats { MoveSpeed = def.moveSpeed, ... });
entityManager.SetComponentData(entity, new Health { Current = def.maxHealth, Max = def.maxHealth });
...
entityManager.SetComponentData(entity, new LaneMoveTarget { Value = enemyBasePos });
entityManager.AddComponent<Prefab>(entity);

Kopiert die Werte aus der UnitDefinition in die ECS-Komponenten (das ist der "Bake"-Moment aus dem Plan). LaneMoveTarget wird schon HIER korrekt gesetzt (Team 0 bekommt team1BasePos als Ziel) — jede spätere Kopie erbt das automatisch, ohne dass man es beim Spawnen erneut setzen muss. Der Prefab-Tag schließt das Template wieder von allen Queries aus.

if (Input.GetKeyDown(KeyCode.Alpha1)) SpawnUnit(0, 0);
if (Input.GetKeyDown(KeyCode.Alpha2)) SpawnUnit(0, 1);
if (Input.GetKeyDown(KeyCode.Alpha3)) SpawnWave(debugWaveCountPerTeam);

GetKeyDown (nicht GetKey) — reagiert nur auf den Moment des Drückens, kein Dauerfeuer beim Halten. Taste 1/2 spawnen immer Unit-Typ 0 (den ersten im Array); für gezielte Typ-Auswahl kommt erst mit der Shop-UI in Phase 3 eine echte Steuerung.

var template = team == 0 ? templatesTeam0[unitTypeIndex] : templatesTeam1[unitTypeIndex];
var basePos = team == 0 ? team0BasePos : team1BasePos;
Entity newUnit = entityManager.Instantiate(template);
float offsetX = UnityEngine.Random.Range(-spawnSpreadX, spawnSpreadX);
entityManager.SetComponentData(newUnit, LocalTransform.FromPosition(basePos + new float3(offsetX, 0, 0)));

Wählt Template und Basis-Position je nach Team, erzeugt die Kopie, gibt ihr eine zufällige seitliche Streuung (X-Achse) und setzt die Start-Position. LaneMoveTarget muss NICHT erneut gesetzt werden — kommt schon korrekt aus dem Template mit.

for (int i = 0; i < countPerTeam; i++)
{
    int unitTypeIndex = UnityEngine.Random.Range(0, unitTypes.Length);
    SpawnUnit(unitTypeIndex, 0);
    SpawnUnit(unitTypeIndex, 1);
}

Spawnt countPerTeam Paare — pro Durchlauf einen zufälligen Unit-Typ für beide Teams gleichzeitig, damit die Test-Welle gemischt und für beide Seiten gleich stark ist.

int alive = aliveQuery.CalculateEntityCount();
GUI.DrawTexture(new Rect(5, 100, 430, 65), backgroundTexture);
GUI.Label(..., $"Skirmish - lebende Units: {alive} | FPS: ...");

Zählt aktuell lebende Units (Query auf Team + Health) und zeichnet das Overlay bei Y=100 — bewusst UNTER dem Pille-Overlay (das bei Y=5–90 liegt), damit beide gleichzeitig lesbar sind, falls beide Systeme parallel in derselben Szene laufen.

void SpawnUnit(int unitTypeIndex, byte team)
{
    float offsetX = UnityEngine.Random.Range(-spawnSpreadX, spawnSpreadX);
    SpawnUnitInternal(unitTypeIndex, team, offsetX);
}

public void SpawnUnitAt(int unitTypeIndex, byte team, Vector3 gridWorldPos)
{
    SpawnUnitInternal(unitTypeIndex, team, gridWorldPos.x);
}

void SpawnUnitInternal(int unitTypeIndex, byte team, float x)
{
    ...
    float3 spawnPos = new float3(x, basePos.y, basePos.z);
    entityManager.SetComponentData(newUnit, LocalTransform.FromPosition(spawnPos));
}

Für Phase 3 wurde die alte SpawnUnit-Methode in drei Teile aufgeteilt: die ursprüngliche Debug-Variante (zufällige X-Streuung, für Tasten 1/2/3) bleibt intern, dazu kommt eine neue öffentliche Methode SpawnUnitAt, die WaveManager aufruft — sie übernimmt die X-Position aus der Base-Grid-Platzierung, aber Y/Z immer vom festen Lane-Eingang des Teams. Ergebnis: welche Spalte im Base-Grid du befüllst, bestimmt, in welcher "Spur" der Lane die Unit lostäuft.