Aus der Bestandsaufnahme zur Beta-Bereitschaft. Kein Fehler im engeren Sinn — eine Erwartung, die das Spiel selbst weckt und dann nicht einlöst.
Befund
Der Gründungs-Harvester bekommt beim Fertigstellen der Raffinerie automatisch einen Feldauftrag (ConstructionSystem.GrantFoundingHarvester). Er fährt los und erntet, ohne dass der Spieler etwas tut.
Jeder weitere Harvester nicht. Simulation/Production/ setzt HarvestFieldId an keiner Stelle — nachgeprüft, es gibt dort keinen einzigen Treffer. Ein aus der Warteschlange produzierter Harvester läuft zum Sammelpunkt und steht.
Warum das mehr ist als eine fehlende Bequemlichkeit
Das Spiel bringt dem Spieler in der Eröffnung bei, dass Harvester von selbst arbeiten. Der erste tut es. Der zweite tut es nicht — ohne Hinweis, ohne Unterschied im Erscheinungsbild, ohne dass irgendetwas sagt, dass jetzt ein H fällig wäre.
Der Testbericht T-01 formuliert die Erwartung wörtlich: ein Harvester habe „keinen anderen Zweck". Für den zweiten und jeden weiteren stimmt das im Bestand nicht.
Nebenwirkung: die Eskorten-Logik greift erst bei HarvestFieldId != 0 (RtsDeviceInput.cs:751-757). Ein untätiger Harvester bekommt also auch keine Begleitung — er steht unbewacht am Sammelpunkt.
Was zu klären ist
- Soll ein produzierter Harvester automatisch das nächste eigene Feld nehmen? Das wäre die naheliegende Antwort und spiegelt den Gründungsfall.
- Welches Feld? Das nächstgelegene mit Restbestand ist die offensichtliche Wahl — seit Sprint 21 gibt es fünfzehn statt fünf, die Auswahl ist also nicht mehr trivial. Deterministisch muss sie sein: feste Reihenfolge, ganzzahlige Distanz, keine Zufallskomponente.
- Oder ist das gewollt? Ein Argument dafür gibt es: wer den Harvester selbst zuweist, entscheidet bewusst über die Expansion. Dann fehlt aber ein Hinweis, dass eine Entscheidung ansteht.
Hoheit
Simulation/Production/ ist nicht als Einheitenstrang geführt, liegt ihm aber nahe. Vor der Umsetzung mit dem Einheitenstrang abstimmen, welches Merge-Fenster das trägt — die Änderung bewegt Simulationsverhalten.
Aus der Bestandsaufnahme zur Beta-Bereitschaft. Kein Fehler im engeren Sinn — eine Erwartung, die das Spiel selbst weckt und dann nicht einlöst.
Befund
Der Gründungs-Harvester bekommt beim Fertigstellen der Raffinerie automatisch einen Feldauftrag (
ConstructionSystem.GrantFoundingHarvester). Er fährt los und erntet, ohne dass der Spieler etwas tut.Jeder weitere Harvester nicht.
Simulation/Production/setztHarvestFieldIdan keiner Stelle — nachgeprüft, es gibt dort keinen einzigen Treffer. Ein aus der Warteschlange produzierter Harvester läuft zum Sammelpunkt und steht.Warum das mehr ist als eine fehlende Bequemlichkeit
Das Spiel bringt dem Spieler in der Eröffnung bei, dass Harvester von selbst arbeiten. Der erste tut es. Der zweite tut es nicht — ohne Hinweis, ohne Unterschied im Erscheinungsbild, ohne dass irgendetwas sagt, dass jetzt ein
Hfällig wäre.Der Testbericht T-01 formuliert die Erwartung wörtlich: ein Harvester habe „keinen anderen Zweck". Für den zweiten und jeden weiteren stimmt das im Bestand nicht.
Nebenwirkung: die Eskorten-Logik greift erst bei
HarvestFieldId != 0(RtsDeviceInput.cs:751-757). Ein untätiger Harvester bekommt also auch keine Begleitung — er steht unbewacht am Sammelpunkt.Was zu klären ist
Hoheit
Simulation/Production/ist nicht als Einheitenstrang geführt, liegt ihm aber nahe. Vor der Umsetzung mit dem Einheitenstrang abstimmen, welches Merge-Fenster das trägt — die Änderung bewegt Simulationsverhalten.