QA-Plan: Siege erleben, echte Reisen, vertraute Computerstimme
Stand: 13. September 2026. Die Umsetzung wurde mit „OK, umsetzen!“ freigegeben; anschließend auch Pakete B/C und die benannten umfangreichen QA-Blöcke. Die erste Umsetzung und die vertiefte QA mit Korrekturen dokumentieren die jeweiligen Ergebnisse. Die Vorgabe bleibt: Stimmen vorerst beibehalten, Hörvergleich später beurteilen. Der folgende ursprüngliche Plan bleibt als Gestaltungs- und Abnahmegrundlage erhalten; seine damaligen Freigabevorbehalte sind für die ausdrücklich beauftragten Blöcke erfüllt.
Die größte Verbesserung liegt in drei zusammenhängenden Änderungen: Ein Bossabschluss zeigt erst die Wirkung des Siegs, Transport- und Helfermissionen führen durch erkennbare Orte, und der Bordcomputer erhält eine anhand der weiblichen Originalstimme abgestimmte Identität. Vorhandene Mechaniken, Geschichte und Grafik liefern dafür bereits viele Bausteine.
1. Nachgewiesene Basis und Grenzen dieser Untersuchung
- Gemeinsames Projekt:
C:/Unity Projects/Space Hero - Galactic Reclaimers, ProduktionsszeneAssets/SpaceHero/Scenes/SpaceHero.unity. - Untersuchte Basis:
main,595d4a923d9ecd1180067d8d9111b3cbda3314da.Tools/Check-ProjectBasis.ps1meldetecurrent-basis-confirmed. Hauptprojekt und vorhandener Worktree12d9standen bei Beginn auf demselben Commit und waren sauber. - Letzte verifizierte Lieferung: v28.1,
SpaceHero-Playtest-20260910-014511.zip, Quellcommit40f3bf063951e04cc67d7aa0130cb4841919a1f3. Maßgeblich sind PROJECT-STATE, die aktuellen Abschnitte von PROGRESS und DELIVERY. - Gelesen wurden Kampagnenkataloge, Produktionsdirector und Ansichten, Kamera/HUD, Audiozuordnung samt Manifesten, Speicher-/Belohnungswege und bestehende relevante Tests. Die alten Skripte und Szenen dienen ausschließlich der Herkunftsrecherche.
- Grafikinventar: 90 Rasterdateien unter
Assets/SpaceHero/ArtundAssets/SpaceHero/Resources, 101 unterAssets/Sprites. Acht relevante Originaldateien wurden tatsächlich visuell angesehen; Einzelheiten in Abschnitt 5. Inventarzahl bedeutet keine vollständige visuelle Abnahme. - Audio wurde über Dateien, GUID-Zuordnungen, Produktionsmanifeste und Dokumentation untersucht. Keine Aufnahme wurde in dieser Runde angehört oder klanglich vermessen. Eine wahrgenommene Stimmfarbe ist damit nicht neu beurteilt.
- Keine Unity-, Spiel-, Audio- oder Leistungstests, keine Generierung, kein Build, keine Änderungen an Spielcode, Produktionsassets, Profilen oder Releases. Bestehende QA-Berichte sind historische Belege. Dieser Plan ist kein neuer bestandener Spieltest.
2. Befunde und Priorität
| Priorität | Belegter Befund | Konsequenz für den Plan |
|---|---|---|
| P1 | Jeder Kampagnensieg erhält 1,8 Sekunden Erfolgsanzeige und 4,5 Sekunden automatischen Rückflug. Boss-Erfolgstexte werden durch den allgemeinen Hinweis ersetzt. | Eigener Bossnachklang mit sichtbarer Wirkung, ruhigem Moment und bewusster Fortsetzung. |
| P1 | Bei 2-2, 3-1 und 3-2 liegen Wegpunkte/Arbeitsorte im selben Kamerafeld. Vorhandene Weglängenprüfungen können dort durch Schleifen bestehen. | Bestehende Eskorte, Versorgung und Formation über räumlich getrennte Etappen führen. |
| P1 | Weibliche Originalaufnahmen existieren. Die aktive Qwen-Produktion nutzt eine andere, ebenfalls als weiblich dokumentierte Referenz. Keine vertauschte Computer-/Crewbank gefunden. | Originale und aktuelle Stimme gezielt vergleichen; gewünschte Computeridentität festlegen, bevor viele Takes neu entstehen. |
| P1, technische Voraussetzung | Der Sieg wird erst nach dem Rückflug gespeichert; die aktuelle Speicherung zerstört zugleich die Flugszene. | Gesichertes Ergebnis und Darstellung trennen, damit ein längerer Nachklang keinen Fortschritt gefährdet. |
| P2 | Spätere Missionen haben bereits längere Anflüge, wiederholen jedoch teils identische lokale Liefer-/Befreiungsaufgaben. | Helfer und Fracht über die Verbindung hinweg relevant halten; Etappen funktional unterscheiden. |
| P2 | Sprachuntertitel beziehungsweise Funk können den situativen Auftragshinweis verdrängen. Dieselbe Siegsequenz spielt den Siegton zweimal. | Pflichtziel und Sprecher klar zeigen; Abschlussklänge und Sprache aufeinander abstimmen. |
| P3 | Für spätere Routen, Kapitelbilder, Crew und Maschinen gibt es umfangreiche bestehende Inhalte. | Nach dem ersten Vergleich gezielt verfeinern und bewährte kurze Einführungen erhalten. |
Quellanker beziehen sich auf den oben genannten Commit: Runtime/FlightDirector.cs:400–410, Runtime/MissionCompletionView.cs:12–30, Runtime/SpaceHeroApp.cs:556–562,633–650; alle unter Assets/SpaceHero.
3. Bossabschlüsse: konkrete Inszenierung
Ursachen im aktuellen Ablauf
FlightDirector setzt bei erfülltem Ziel finishing, beendet die Kampfsteuerung und überschreibt den individuellen Hinweis mit „EINSATZ ERFÜLLT“. Die große mittige Abschlusskonsole kündigt sofort Rückflug und Einsatzbericht an. Der Ablauf gibt dem Spieler somit zwar einige Sekunden, verwendet sie jedoch kaum für eine sichtbare Folge des Bosskampfs.
Krabbe, Wal und Netzherz bekommen danach keine eigene weiterlaufende Sieganimation. Bei den späteren Ansichten laufen im Wesentlichen Trefferblitz-Ticks weiter. Riegel und Echo-Quelle verschwinden bei ihrem Complete-Zustand sofort; das Blockadeschiff wird weitgehend stillgelegt/grau. Belege: FlightDirector.cs:308–364,467, ChapterTwoBossDirector.cs:122,160,195,220, LightBossDirector.cs:275,323, FinalBossDirector.cs:107.
Die Geschichte verlangt häufig Befreiung, Reparatur oder Entmachtung. Krabbe und Wal helfen später wieder mit (Core/FinalCampaignCatalog.cs:74–76). Die Abschlussbilder müssen das erzählen.
Vorgeschlagene Abfolge
Die folgenden Zeiten sind Startwerte für die Gestaltung und keine gemessenen Qualitätswerte.
| Phase | Vorgeschlagenes Verhalten |
|---|---|
| Sieg bestätigt | Letzte gültige Handlung wird einmal gewertet. Schaden, Geschosse, feindliche Aktionen und neue Funkereignisse enden. Statistik und Belohnungsgrundlage werden eingefroren. Ergebnis transaktional sichern. |
| Auflösung, etwa 2–3 s | Letzter Scan oder Treffer wird sichtbar beantwortet: Arme senken sich, Fesseln öffnen sich, Feld fällt zusammen oder Verbindungen lösen sich. Boss beziehungsweise seine Wirkung bleiben im Bild. |
| Nachklang, weitere etwa 4–5 s | Ruhiges, gut lesbares Siegbild. Kleine individuelle Erfolgsmeldung; höchstens eine kurze passende Computerzeile. Musik geht aus der Kampfspannung in einen ruhigen Abschluss über. |
| Bewusster Rückflug | Nach dem Kernmoment erscheint „Zurück zur Intrepid“. Neue Bestätigung erforderlich; zuvor gehaltenes Feuer/Scannen bestätigt nichts. Das Bild darf bis zur Entscheidung stehen bleiben. Wiederholungen können nach der kurzen Auflösung früher fortgesetzt werden. |
| Bericht und Kapitel | Bestehender Rückflug und Ergebnisbericht folgen. Nach 3-3, 6-3, 9-3 und 12-3 bleibt das vorhandene Kapitelende die bevorzugte erste Fortsetzung; Archiv und Replay bleiben erreichbar. |
Der Kernmoment soll zusammen ungefähr 6–8 Sekunden Raum erhalten. Ein Kapitelboss kann anschließend eine etwas längere sichtbare Folge zeigen; die bereits vorhandenen langen Finaletexte bleiben auf ihrem eigenen Bildschirm. Vorrang haben vorhandene Posen, Bauteile und dezente Lichtwechsel; neue Kamera-/Blitzeffekte sind für diesen Ablauf nicht erforderlich.
Eigene Wirkung für alle zwölf Bosse
| Mission | Sichtbarer Abschlussentwurf |
|---|---|
| 1-3 · K.R.A.B.B.E. im Fehlbetrieb | Greifarme fahren ruhig zurück, Kern wird freundlich, Krabbe gibt den Weg frei. Die reparierte Maschine bleibt erkennbar erhalten. |
| 2-3 · Der Magnetwal | Magnetbindung löst sich sichtbar; befreite Frachter ziehen vorbei. Wal und Spieler bleiben für den Moment gemeinsam im Bild. |
| 3-3 · Das Herz des Sternennetzes | Ringe stabilisieren sich; klare Verbindungen breiten sich aus. Kurze Botschaft: Die Heimwege sind offen. |
| 4-3 · Der Riegel | Letzte Archivverriegelung öffnet sich nachvollziehbar. Der Rammer kommt sichtbar zur Ruhe, der Zugang ist frei. |
| 5-3 · Durch die Blockade | Getrennte Decks driften auseinander; der entstandene Durchflug ist als Ergebnis des Kampfes zu sehen. |
| 6-3 · Das falsche Gesicht | Täuschbilder erlöschen nacheinander, der echte Sender verstummt. Klare Signale ersetzen die falschen Rufe. Der folgende Konflikt gehört ins Kapitelende. |
| 7-3 · Der Fänger | Letzte Fessel öffnet sich; alle drei Helfer sammeln sich sichtbar beim Spieler. |
| 8-3 · Prismenwächter | Letzter Strahl klingt aus, Spiegel gehen in neutrale Stellung, Kühlung beruhigt sich und die Route wird frei. |
| 9-3 · Der Ringschließer | Ringe öffnen sich in Folge und geben den Blick ins Archiv frei. Enthüllung anschließend im bestehenden Kapitelabschluss. |
| 10-3 · Schwarmregent | Kettenreaktion läuft aus; aggressive Schwarmformation löst sich und die Flotte kann vorrücken. |
| 11-3 · Das Belagerungswerk | Geschütze werden still, die gerettete Intrepid beziehungsweise ihre Abwehr bleibt sichtbar. Entwarnung statt nächster Kampfanweisung. |
| 12-3 · Die Zentralinstanz | Zwangsleitungen erlöschen, hilfreiche Netzverbindungen bleiben aktiv. Befreite Schiffe sammeln sich; die vorhandene Heimkehr schließt daran an. |
Diese Bilder sind Entwürfe innerhalb der vorhandenen Geschichte, noch keine neuen Assets oder fertigen Sequenzen. Erforderliche zusätzliche Frachter, Lichtmasken oder Verbindungseffekte erst am Referenzabschluss bestimmen.
Technische Absicherung
Ein gemeinsamer Ablauf mit Daten je Boss und kleinen Funktionen in den vorhandenen Ansichten reicht als Ausgangspunkt. Kampfregeln und Kapitelgeschichte bleiben erhalten. SpaceHeroApp.CommitResult muss Ergebnisverbuchung und späteren Bildschirmwechsel getrennt ausführen können (SpaceHeroApp.cs:633–650). Erstabschlussstatus, Belohnungsbasis und Outcome vor dem Speichern festhalten und über Sequenz sowie Schreibwiederholungen erhalten; sonst könnte der erste Kapitelabschluss nach der Speicherung irrtümlich als Replay gelten. Die bestehende Attempt-ID-Absicherung in Core/CampaignRules.cs:88–134 weiterverwenden.
Akzeptanz: genau eine Vergütung und Bosszählung; nach bestätigtem Sieg keine zusätzlichen Treffer/Abschüsse/Beute; ein bereits erfolgreich gespeicherter Sieg bleibt beim Beenden erhalten. Schreibfehler bekommen den vorhandenen Wiederholungsweg, ohne doppelte Auszahlung oder falsche Speicherbestätigung. Pause und Fokusverlust halten Darstellung und Ton korrekt an. Fortsetzung funktioniert bei stummer Sprache, mit Tastatur, Controller und Zeiger. Eingaben müssen nach dem Kampf neu ausgelöst werden.
4. Missionen: Länge durch Reise und Aufgabenentwicklung
Die Kamera hat eine feste orthografische Halbhöhe von 9 (SpaceHeroApp.cs:78–79). Der Spieler bewegt sich innerhalb dieses Ausschnitts (FlightDirector.cs:503–505). Ein neues Kamerasystem ist dafür nicht nötig: Kapitel 2–4 verschieben bereits Missionsräume durch das Bild. Dieses bewährte Prinzip soll auf die frühen Reisen übertragen werden.
Erste drei Umbauten
| Mission | Aktueller Befund | Vorgeschlagener Verlauf |
|---|---|---|
| 2-2 · Transporter im Nebel | Fünf Wegpunkte vollständig innerhalb x −7 bis 8, y −2 bis 5,5; Tor von Anfang an vorhanden. Frachtertempo 0,6. Rechnerisch etwa 62 s reine Wegfahrt, kein aktueller Playtestwert. | Treffpunkt → erster Nebelkorridor → angekündigter Flankenangriff mit sicherem Kurs → zweite räumlich erkennbare Passage → Tor nähert sich erst am Ende → Frachter fliegt sichtbar hindurch, kurze Rückmeldung. |
| 3-1 · Energie für die Sternenwerft | Drei Docks im selben Bild. Die vier Phasen Anflug, Begleitung, Entladung und Verbindung bestehen schon. | Lieferung im ersten Werftbereich erklärt den Ablauf → Reise zum zweiten Dock mit Querverkehr → dritter Bereich nutzt die bereits versorgte Werft sichtbar als Führung/Beleuchtung → letzte Anlage fährt hoch. |
| 3-2 · Konvoi zum Sternentor | Bereits echte Formation, Sammelpunkte, Reparatur und drei Passagen. Weg und Tor liegen jedoch im ursprünglichen Ausschnitt. | Helfer verbinden → gemeinsam die Werft verlassen → Passage mit angekündigtem Querverkehr → zweite Passage mit sicherem Umweg oder engerem Kurs → gemeinsamer Toranflug → drei erkennbare Ankünfte. |
Quellen: Runtime/RouteMissionDirector.cs:63–88,149–166,216–271; Runtime/ConvoyMissionDirector.cs:28–38,124–140.
Zunächst 2-2 als Referenz ausarbeiten. Danach 3-1 und 3-2 mit ihren eigenen Regeln umstellen. Vorläufige Zielkorridore für einen typischen menschlichen Pilotdurchlauf: 2-2 etwa 2–3 Minuten, 3-1/3-2 etwa 2,5–4 Minuten aktive Mission. Siegesnachklang und Menüs separat messen. Es gibt keine künstliche Mindestzeit; geübte Spieler dürfen schneller fertig werden. Tatsächliche Korridore nach dem freigegebenen Playtest festlegen.
Zweite Priorität: Hilfe über die Arbeitsstelle hinaus
- 7-2 · Gegen den Stilllegungsbefehl: Drei Anflüge existieren bereits. Nach zerstörten Sonden beträgt die rechnerische freie Fahrt des Frachters von y −0,4 bis über 6,1 bei 2,3 Einheiten/s nur rund 2,8 Sekunden; anschließend wird er entfernt. Das ist kein gemessener Playtestwert, Schäden/Reparatur können die tatsächliche Fahrt verlängern. Mindestens eine befreite Gruppe soll über die folgende Verbindungsstrecke tatsächlich begleitet werden und erst am sicheren Hafen zählen. Schutz, Reparatur und Zielanzeige müssen denselben Frachter betreffen.
- 8-1 · Maschinen, die helfen: Aufnahmeort und Maschine räumlich auseinanderlegen. Die erste Maschine öffnet den Weg, die nächste hilft beim Transport, die letzte bewirkt den sichtbaren gemeinsamen Durchbruch. Bestehende drei Anflüge dafür verwenden.
- 11-1 · Energie für den Durchbruch: Transportierte Energie soll während eines klaren Wegs zum Versorgungsschiff relevant bleiben. Die geladene Kanone öffnet den nächsten räumlichen Abschnitt sichtbar; wiederholte Ladungen erhalten unterschiedliche Anflugaufgaben.
Belege für 7-2/8-1: Runtime/FinalMissionDirector.Encounters.cs:20–28,121–151. Die übrigen Endkapitelmissionen besitzen bereits drei Anflüge mit insgesamt 380–580 Welteinheiten; 10-2 hat eine begründete Ausnahme mit 440 (FinalMissionDirector.cs:99,131–154,188–215, Geometrie und Pacing). Diese Strecken nicht pauschal verlängern.
Umgang mit den übrigen Nichtbossmissionen
Damit sind alle 24 Nichtbossmissionen im Plan erfasst. Die zwölf Bossmissionen stehen in Abschnitt 3.
| Gruppe | Missionen | Vorgehen |
|---|---|---|
| Kurze Einführung bewahren | 1-1, 1-2 | Einstieg und erste Scannererklärung bleiben kompakt; Orientierung und erkennbare Wirkung prüfen. |
| Frühe Reisen umbauen | 2-2, 3-1, 3-2 | Priorität wie oben; räumlich zusammenhängende Etappen. |
| Bestehende Raum-/Flugmechanik als Referenz | 2-1, 4-1, 4-2, 5-1, 5-2, 6-1 | Kristallpassagen, Wrackräume, Signalspur, Sturm, Abfangen und Sensorinfiltration zunächst erhalten. Nach dem Referenzumbau auf Lesbarkeit und Wiederholung prüfen. |
| Bewusst ortsgebundene Aufgabe | 6-2 | Plattformverteidigung darf ein Schauplatz bleiben. Abwechslung durch Übertragung, Störung, Reparatur und Helferbeitrag beurteilen. |
| Spätere Versorgung/Eskorte verbinden | 7-2, 8-1, 11-1 | Die vorhandenen Anflüge mit tatsächlich fortbestehenden Frachtern beziehungsweise Ladung verzahnen. |
| Spätere spezifische Mechaniken erhalten | 7-1, 8-2, 9-1, 9-2, 10-1, 10-2, 11-2, 12-1, 12-2 | Rettung, Räumer, Impulsbahnen, Schleppkern, Flottenkampf, Querung, Befreiung, Kühlung und gemeinsame Maschinenhilfe auf verständliche Folgen prüfen. Änderungen nur bei konkretem Befund. |
Abnahme des Reisegefühls
- Bei den umgebauten Reisen sind Start, mindestens zwei Reiseabschnitte und Ziel unterscheidbar. Neue Zielgeometrie kommt sichtbar aus der Ferne/in den Ausschnitt, der alte Ort verschwindet hinter dem Spieler. Landmarken und Arbeitsobjekte bewegen sich zusammenhängend.
- Die Gesamtmission lässt sich nicht von einer festen Bildschirmposition lösen. Fracht, Schutz oder vollständige Formation müssen tatsächlich zum nächsten Abschnitt gelangen.
- Jede Reise enthält mindestens zwei unterscheidbare Handlungen oder Entscheidungen und darf ruhige Abschnitte enthalten. Prüfen: aktive Spielzeit, sichtbarer Ortswechsel, längster Abschnitt ohne Aufgabe/Orientierungswechsel und Spielerurteil.
- Helfer verschwinden nicht unbemerkt; Nachholen, Scannerreparatur und Sammeln bleiben möglich. Boost darf keine unrettbare Trennung erzeugen. Entdecker und Pilot bleiben ohne Pflichtkauf neuer Waffen spielbar.
- Die letzte Lieferung/Rettung zeigt eine sichtbare Wirkung, bevor der allgemeine Missionsabschluss beginnt.
Vorhandene Bausteine: CrystalPassageDirector.cs:21–38,75–88, ChapterTwoMissionDirector.FlightRoutes.cs:32–108 und FinalMissionDirector. Beim Verschieben müssen auch Helfer, Tor, Warngeometrie, Scannerziele und Kollisionskörper mitgeführt werden: FlightDirector.cs:1098–1110 verschiebt reservierte Missionsobjekte bislang nicht automatisch.
Balance und Spielstände: MissionSpec.TargetDuration wird derzeit nur definiert/zugewiesen (Core/CampaignCatalog.cs:26,33); höhere Werte verlängern keine Mission. Zusätzliche Flugzeit erhöht die Gefahrenexposition und verringert bei festen Prämien das Erwerbstempo. Sterneziele und Schrott pro Spielminute deshalb gezielt bewerten; Zusatzloot ist auf 15 begrenzt (CampaignRules.cs:34,96–98). Keine automatische globale Änderung von Preisen, Waffenstärke oder Gegnergesundheit. IDs, vorhandene Freischaltungen und Erstprämien erhalten. Falls deutlich andere Leistungen eigene Revisionen brauchen, diese missionsbezogen planen; ContentRevision ist derzeit kapitelweise festgelegt.
5. Grafik, Lesbarkeit und Klangmittel
Tatsächlich angesehen: Art/Bosses/MagnetWhale-v1.png, Resources/ChapterTwoBosses/BlockadeMiddle.png, Resources/FinalBosses/CommandNexus.png, Art/Stations/Derelict-Atlas-v1.png, Art/Backgrounds/Region7-v1.png, Art/Backgrounds/Region12-v1.png, Art/Bridge/Homecoming-v1.png, Resources/FinalMissions/SupplyShip.png – jeweils unter Assets/SpaceHero.
Die Bilder bieten erkennbare Maschinen, räumliche Landmarken, ruhige zentrale Flugflächen und eine bereits ausgearbeitete Heimkehr. Der Wal hat eine deutlich andere, stärker stilisierte Formsprache als die späteren dunklen Industriebosse. Die neue Inszenierung soll die jeweilige bestehende Gestaltung weiterführen. Titel, Fonts, Menüs und der vorhandene Bildbestand bleiben erhalten.
| Vorhandener Bestand | Gezielter Einsatz nach Freigabe |
|---|---|
| Krabbenarme/-gelenke, Wal, Netzherz und separate spätere Bossbauteile | Ruhestellungen, kontrollierte Bewegung, Öffnung und Trennung im Siegbild. Fehlende Lichtmasken erst bei Bedarf ergänzen. |
| Wrackatlas, Werkstatt, Sternentor, WreckHull/Bulkhead | Unterscheidbare Ein-/Ausfahrten und räumliche Wegmarken. Sichtbare feste Hindernisse müssen mit ihrer Kollisionsgeometrie übereinstimmen. |
| SupplyShip, Helper, WorkerMachine, RescuePod, EnergyCargo | Gerettete Schiffe und gelieferte Fracht über mehrere Abschnitte weiterführen; Wirkung als Bewegung/Anlagenzustand zeigen. |
| Regionale Bilder, Sterne, Nebel und Vordergrundtrümmer | Ortswechsel über näherkommende Landmarken und verschobene Geometrie verdeutlichen. Planetengrafiken bleiben entfernte Landschaft. |
| Brückenstufen und Homecoming | Vorhandene Kapitelreaktionen und Heimkehr als Anschluss verwenden. |
| Scanner-, Magnet-, Funk- und Maschinenklänge, regionale Bossmusik | Passende Befreiungs-/Entriegelungsfolge, Spannung abbauen, eine klare Erfolgsgeste. Große Maschinenbrüche nur bei tatsächlich zerstörten Teilen. |
FlightBackground.cs:88–108,129–151 zeigt bereits bewegte Sterne/Nebel/Trümmer; das große Regionsbild schwenkt nur sanft. Schnellere Sternbewegung allein löst das räumliche Missionsproblem nicht. Importzuordnungen sind in Editor/AtmosphereAssetsBuilder.cs:20–30 und Editor/FinalCampaignAssetsBuilder.cs:21–29 vorhanden.
Zusätzliche kleine UX-Korrektur: Pflichtziel und aktuelle Etappe müssen während optionalem Funk auffindbar bleiben. SpaceHeroApp.cs:556–562 ersetzt den situativen Hinweis derzeit durch Sprach-/Funkuntertitel; eine klare Sprecherzeile und eine dauerhafte knappe Etappenanzeige sollen beide Informationen lesbar halten. Historische Überlagerungen im QA-v27-Bericht sind ein Prüfhinweis, kein neuer Renderbefund. Das Boss-Siegbild erhält eine kleine Meldung anstelle der großen mittigen Konsole.
6. Weibliche Computerstimme: Referenz und Vorgehen
Bestand und tatsächliche Zuordnung
Unter Assets/Resources/AudioFiles/ShipAI liegen 36 originale MP3s: 18 deutsch, 18 englisch. Drei deutsche Referenzen sind ausdrücklich als ursprüngliche weibliche Computeransagen dokumentiert:
Greetings/ship.de.HelloCommander.mp3Missions/ship.de.MissionAssigned.mp3Missions/ship.de.MissionComplete.mp3
Zusätzlich existieren Ziel-, Zusammenfassungs-, Autopilot- und alte Missionsansagen. Dateiname und tatsächlicher Inhalt müssen vor Wiederverwendung zusammen geprüft werden; etwa ship.MissionCompletePressBtnForAutopilot.asset enthält einen abweichend benannten Key. Keine automatische Übernahme allein nach Dateinamen.
Aktive Produktion: 80 Computer-Takes (48 Story, 29 Boss, 3 Status) und 44 Crew-Takes (37 Brücke, 7 Funk). Ein lesender GUID-/Manifestabgleich der fünf VoiceBanks ergab keine unerwartete Zuordnung. Physisch vorhandene ältere Dateien sind davon zu unterscheiden: drei Qwen- und drei Crew-WAVs liegen außerhalb der aktiven Manifeste; außerdem sind 90 früher abgelehnte Piper-WAVs archiviert.
Die aktuelle Computerstimme basiert auf einer eigenen synthetischen weiblichen Qwen-Referenz, nicht auf den alten Originalaufnahmen. Die frühere Auswahl ist in QA-Qwen-Integration und AUDIO-v28 belegt. Vier männliche Crewrollen und Lisa sprechen über denselben Sprachkanal mit anderen Bankdaten. Ein nachträglicher Pitchwechsel der Computerstimme wurde im aktiven GameAudio-Pfad nicht gefunden. Diese Befunde erklären mögliche Unterschiede, ersetzen aber das aktuelle Nutzerurteil nicht.
Dokumentationskorrektur im freizugebenden Paket: Audio-Production nennt die historische Drei-Originalclip-Phase noch „derzeit“. Den Stand klar als historisch markieren und auf v28.1 beziehungsweise den später freigegebenen Stimmstand verweisen.
Begrenzter Vergleich vor größerer Produktion
- Nach Freigabe die drei Originalmeldungen und die drei entsprechenden heutigen Qwen-Statusmeldungen beschriftet gegenüberstellen; zusätzlich ein längeres Computerbriefing, eine Bossansage und ein getrennt gekennzeichnetes Crewbeispiel. Unterschiedliche Texte offen ausweisen. Geschätzter Hör-/Entscheidungsumfang: 10–15 Minuten, keine komplette Sprachbank.
- Daraus eine verbindliche Stimmvorgabe ableiten: erwachsene weibliche Computerrolle, klares Deutsch, ruhig und präzise, bei Erfolg hörbar erleichtert. Stärke des Technikeindrucks, Tempo und Stimmhöhe am Originalvergleich entscheiden.
- Passende Originale können direkt zurückkehren, sofern Wortlaut und Ablauf stimmen. Bei neuen Texten erst wenige Vergleichstakes erstellen. Keine automatische Verwendung alter Aufnahmen als Klonvorlage und keine Vollproduktion, bevor die gewünschte Richtung klar ist.
- Auffällige Computer-Takes gezielt ersetzen und Rollen sichtbar benennen; Crew behält ihre eigenen Stimmen. Prolog, Briefing, Boss- und Systemmeldung sollen als ein Computer verstanden werden. „Commander“, „Maik“ und die zuletzt gewählte Intrepid-Aussprache C mitprüfen.
Klang des Siegs
Heute erklingt derselbe Siegton bei Zielerfüllung und nochmals im Ergebnis (FlightDirector.cs:404, SpaceHeroApp.cs:650), gefolgt von „Mission erfolgreich!“. Die 29 Bossclips erklären Aufgaben/Phasen; eine Aufforderung zum Neustart ist keine fertige Siegesansage. Vier vorhandene Kapitel-Finaletakes sind laut Manifest etwa 16–18 Sekunden lang und bleiben für den anschließenden Kapitelbildschirm reserviert. bridge-victory.wav gehört zum Admiral und Kapitel 2.
Plan: letzter Treffer/Scan → kurze hörbare Entspannung → zum Objekt passende Befreiung/Abschaltung → eine kurze Computerbestätigung → ruhiger musikalischer Ausklang. Erfolgston nur einmal pro Abschlussfolge; kein gleichzeitiger langer Crew-/Finalemonolog. Sprache aus darf die Sequenz nicht aufhalten. Vorhandene neun Maschinenbruchvarianten und regionale Musik bleiben die Materialbasis; ein fehlender kurzer Siegübergang wird erst nach dem Vergleich ergänzt.
Abnahme erfordert ein menschliches Urteil zur weiblichen Computeridentität und Verständlichkeit im Spielmix. Hashes, Transkripte und korrekte GUIDs beweisen diese Wahrnehmung nicht.
7. Umsetzungsreihenfolge und separat freizugebende QA
Arbeitspakete nach Umsetzungsfreigabe
| Paket | Konkretes Ergebnis | Abhängigkeit |
|---|---|---|
| A · Vergleich und Referenz | Stimmvergleich; ein vollständiger Bossabschluss für 2-3; eine Reise für 2-2. Speicherung/Darstellung trennen, vorhandene Grafik und Audio zunächst nutzen. | Umsetzungsfreigabe; die Stimmrichtung vor abhängiger großer Sprachproduktion beurteilen. |
| B · Frühe Missionen und Bossfamilien | 3-1/3-2 räumlich ausbauen; gemeinsamen Abschluss auf alle zwölf Bosse mit eigener Wirkung anwenden; Kapitelanschlüsse und Hinweispriorität erhalten/verbessern. | Erkenntnisse aus A. |
| C · Spätere Aufgaben und Medien | 7-2/8-1/11-1 verknüpfen; gezielte Sprach-/Effektlücken schließen; Sterne und Erwerbstempo der verlängerten Einsätze beurteilen. | Gestaltungs- und Stimmrichtung geklärt. |
| D · Lieferung | Geprüften Quellstand und Anleitungen festhalten, Windows-Playtest erstellen und verifizieren, gemeinsame Dokumentation aktualisieren. | Beauftragter Umfang abgeschlossen, konkret vereinbarte QA erledigt. |
Ein allgemeines „Umsetzen“ startet keine umfangreiche Testreihe. Die Regel aus AGENTS.md, Abschnitt 3, lautet: „Vor umfangreichen Tests die ausdrückliche Freigabe des Nutzers einholen.“ Die folgenden Blöcke machen Zweck, Umfang und Zeit dafür vorab konkret. Sie sind Vorschläge, noch keine gestarteten oder bestandenen Prüfungen.
Prüfpakete
| Prüfblock | Umfang und Zweck | Grober Zeitbedarf | Freigabe |
|---|---|---|---|
| Dokumentation, jetzt | Quell-/Assetreferenzen, Planvollständigkeit, Diff und sauberer gemeinsamer Stand. | In dieser Planungsrunde enthalten. | Erteilter Planungsauftrag. |
| Enger Implementierungscheck | Kompilierung und ein kurzer Smokecheck am geänderten Bossabschluss einschließlich expliziter Fortsetzung. Weitere kleine Läufe nicht zu einer breiten Runde aufsummieren. | Etwa 5–15 min nach Implementierung. | Innerhalb der späteren Umsetzungsfreigabe gemäß Projektregel. |
| Stimmrichtung | Beschrifteter Vergleich der oben festgelegten Beispiele mit menschlichem Urteil. | 10–15 min; neue Takes gegebenenfalls zusätzlich. | Als Vergleich in Paket A ausdrücklich mitfreigeben. |
| Boss- und Übergangs-QA | Zwölf echte Bossabschlüsse, vier erste Kapitelenden sowie ausgewählte Replay-, gehaltene Eingabe-, Pause-, stumme Sprache-, Schreibfehler- und Neustartfälle. Prüft Inszenierung und genau einmalige Speicherung. | Etwa 60–90 min einschließlich Einrichtung; Fehlerkorrekturen zusätzlich. | Ausdrückliche umfangreiche Testfreigabe. |
| Missions-QA | Sechs gezielt überarbeitete Einsätze 2-2/3-1/3-2/7-2/8-1/11-1 auf Pilot; gezielte Entdecker-/Rettungs-/Formation-/Frachtfälle. Menschliches Reisegefühl, aktive Dauer und Erwerbstempo getrennt von Botdaten erfassen. | Etwa 45–75 min einschließlich Ergebnisnotizen. | Ausdrückliche umfangreiche Testfreigabe. |
| Darstellung und Mischung | Kleine vorab begrenzte Auswahl: etwa 12–18 aussagekräftige Bilder in den unterstützten Formaten, 3 kurze Bewegungsbelege und 3–4 native Audiobeispiele für Befreiung, Zerstörung und Finale. Gleiche Flüge soweit möglich wiederverwenden. | Etwa 20–40 min. | Ausdrückliche Freigabe für Bild-/Audio-/Bewegungsreihe. |
| Gesamtkampagne/Performance | Vollständige 36-Missionen-Runde oder eigener Leistungstest nur bei konkretem verbleibendem Risiko oder Nutzerauftrag. | Vorher separat anhand des endgültigen Umfangs schätzen. | Kein automatischer Bestandteil. |
Zeitangaben sind Planungswerte und keine Laufgarantie. Breite automatisierte Testfilter, die mehrere Missionen intern ausführen, zählen ebenfalls als umfangreiche Tests. -ExtendedTestsApproved nur nach tatsächlicher Freigabe verwenden. Alle Spielprüfungen nutzen frische isolierte --spacehero-data-Verzeichnisse.
Vorhandene Prüfungen sinnvoll erweitern
- Boss-Flowtests (
ChapterTwoBossFlowTests,FinalBossFlowTests) erwarten bislang automatisch Results nach ungefähr 7/9 simulierten Sekunden. Neue bewusste Fortsetzung durch echte frische Eingabe prüfen; Timeouts nicht bloß erhöhen. MenuContinuationTests,StoryNarrationTests,BossAudioTestsundFlightAudioLifecycleTestsliefern Ausgangspunkte für Kapitelanschluss, Pausen und Sprachende.EscortFeedbackTests,ShipyardFlowTestsundConvoyFlowTestsprüfen reale Wege, Phasen und Formation. Neue Fälle müssen zusätzlich Ortswechsel und fortbestehende Fracht/Helfer belegen. Die vorhandene Werftprüfung mit 90–145 Sekunden ist eine feste Testkonfiguration, kein menschlicher Spielzeitnachweis.FinalMissionFlowTestsenthält bereits Strecken-/Begegnungsprüfungen für spätere Missionen. Diese als Schutz der vorhandenen Qualität erhalten.- Bei menschlicher QA nach dem Flug drei kurze Antworten notieren: „Welche Strecke bist du gereist?“, „Wen oder was hast du gerettet/verändert?“ und „Konntest du den Boss-Sieg kurz genießen?“. Konkrete Irritationsstellen mit Mission und Phase erfassen.
Liefer- und Abschlusskriterien
Die Verbesserung ist abnahmefähig, wenn alle zwölf Bosse ihre eigene sichtbare Wirkung besitzen, die umgebauten Reisen räumlich und spielerisch nachvollziehbar sind, die Computerstimme anhand der Originale akzeptiert wurde und kein Fortschritt durch den neuen Abschluss verlorengeht. Technische Prüfung und menschliches Urteil getrennt berichten; nicht ausgeführte Blöcke ausdrücklich nennen.
Bei beauftragter Lieferung Tools/Unity.ps1 und Tools/Package-Playtest.ps1 verwenden; Quellcommit und exakte Dateien vor Paketierung beziehungsweise freigegebener nativer QA einfrieren. Ausschließlich nach Artifacts/Releases liefern und mit Tools/Verify-Playtest.py gegen Manifest und Anleitungen prüfen. Erst eine neue verifizierte Lieferung ändert PROJECT-STATE.json und den aktuellen Abschnitt von DELIVERY.md. Plan und spätere Änderungen im gemeinsamen main halten, ohne fremde Arbeit zu überschreiben.
Empfehlung zur Freigabe: Mit Paket A beginnen und dessen begrenzten Stimmvergleich ausdrücklich einschließen. An der fertigen Boss- und Transportreferenz lässt sich die Richtung konkret beurteilen. Pakete B/C sowie die benannten umfangreichen QA-Blöcke können anschließend gezielt beauftragt werden. Bis dahin bleibt es bei diesem Plan.