Ein Spiel, das sich im Browser öffnen lässt, ist nicht zwangsläufig ein Projekt, das sich weiterentwickeln lässt. Die nächste sinnvolle Frage lautet: Kann jemand es reproduzieren, seine Regeln erklären und eine Funktion ergänzen, ohne die ursprüngliche Spielrunde zu beschädigen? Prüfen Sie das anhand eines gesicherten Ausgangsstands und einer eng definierten Erweiterung. Ein Screenshot oder die Zusicherung, der Code sei bearbeitbar, reicht dafür nicht. Dieser Artikel beschreibt einen reproduzierbaren Fortsetzungstest für ein kleines Sternesammelspiel. Er ist kein abgeschlossener Praxisbericht: Für diesen Entwurf lagen weder ein Quellprojekt noch ein Ausgangslauf oder ein Erweiterungspatch vor. Die Anforderung an reale Ergebnisse ist weiterhin nicht erfüllt. Nutzen Sie das Protokoll, um die fehlenden Belege zu sammeln; verstehen Sie seine Abnahmekriterien nicht als Ergebnisse über SEELE oder ein generiertes Projekt.
1. Projekt und ursprüngliche Regeln festlegen
Verwenden Sie ein klar abgegrenztes Testszenario: ein Desktop-Browserspiel mit Steuerung über die Pfeiltasten, fünf einsammelbaren Sternen, einer 30 Sekunden langen Runde, Sieg nach dem Einsammeln aller fünf Sterne, Niederlage bei Zeitablauf und sauberem Neustart. Dies ist das vorgesehene Testszenario, kein vorhandener Build. Beschaffen Sie das tatsächlich bearbeitbare Projekt, seine Assets, Abhängigkeitsdeklarationen und Startanweisungen. Halten Sie die Version des Generators oder Werkzeugs fest, sofern sie angezeigt wird, sowie Projektrevision, Laufzeitumgebung, Browser und Betriebssystem.
Unterscheiden Sie Quelldateien von einer gehosteten Vorschau oder einem kompilierten Paket. Fehlende Assets, nicht dokumentierte Abhängigkeiten oder eine nicht verfügbare Übergabe des Quellcodes sind Befunde, die Sie festhalten sollten, statt die Lücken stillschweigend zu schließen. Weicht das gelieferte Projekt vom Testszenario ab, dokumentieren Sie seine vorhandenen Regeln, bevor Sie eine gleichwertige, begrenzte Erweiterung wählen. Bewahren Sie eine unveränderte Kopie und eine separate Arbeitskopie auf, damit spätere Änderungen die ursprünglichen Belege nicht beseitigen.
2. Den Ausgangsstand vor jeder Reparatur reproduzieren
Befolgen Sie die mitgelieferten Einrichtungsanweisungen in einem sauberen Verzeichnis. Speichern Sie die exakten Befehle, die Installationsausgabe, das Startprotokoll und die Browserkonsole. Erfinden Sie keinen Befehl, nur weil das Projekt einem vertrauten Framework ähnelt. Schlägt die Einrichtung fehl, bewahren Sie die Fehlermeldung auf und dokumentieren Sie jeden Eingriff gesondert. Ein von der prüfenden Person reparierter Ausgangsstand ist ein reparierter Ausgangsstand und kein uneingeschränkter Erfolg des gelieferten Projekts.
Führen Sie vier Szenarien aus: einen Stern einsammeln und an seiner Position bleiben; alle fünf einsammeln; die Zeit ablaufen lassen; nach jedem Spielende neu starten. Prüfen Sie, dass jeder Stern nur einmal gezählt wird, sich nach Spielende nichts mehr bewegt und jeder Rundenzustand zurückgesetzt wird. Notieren Sie für jedes Szenario Aktion, erwartetes Ergebnis, beobachtetes Ergebnis und Revision. Bewahren Sie Fehlschläge genauso sorgfältig auf wie erfolgreiche Durchläufe.
3. Die zu ändernde Regel nachvollziehen
Suchen Sie den tatsächlichen Code oder die bearbeitbare Logik, die Bewegung, Kontakterkennung, Sammelzustand, angezeigten Zähler und Siegprüfung verbindet. Verwenden Sie in Ihren Notizen die tatsächlichen Dateinamen oder Ereigniskennungen. Erklären Sie, welche Komponente den Timer verwaltet und welche Rücksetzaktion ihn wiederherstellt. Eine plausible Erklärung der KI genügt nicht: Überprüfen Sie sie am Projekt.
Suchen Sie nach doppelten Zählern oder Rücksetzlogik, die über sachfremde Systeme verteilt ist. Das sind Fragen für die Prüfung, kein automatischer Beweis für schlechte Architektur. Praktisch geht es darum festzustellen, wo ein Bonusobjekt hingehört und welches bestehende Verhalten unverändert bleiben muss. Halten Sie Unklarheiten fest, bevor Sie den Patch anfordern.
4. Einen blauen Bonusstern zum selben Projekt hinzufügen
Speichern Sie die Revision des Ausgangsstands und fordern Sie dann diese eine Änderung an. Das Beispiel trennt die neue Wirkung auf den Timer bewusst vom bestehenden Sammelzähler:
Erweitere dieses bestehende Spiel um einen blauen Bonusstern. Entferne ihn beim ersten Kontakt während einer aktiven Runde und addiere drei Sekunden zur verbleibenden Zeit. Er darf weder den Zähler für normale Sterne erhöhen noch die Siegschwelle von fünf Sternen ändern. Ein Neustart stellt den Bonusstern wieder her. Eine beendete Runde darf nicht wiederbelebt werden. Erhalte Bewegung, normale Sterne, Zeitablauf und alle ursprünglichen Regeln für das Spielende. Ermittle die tatsächlich betroffenen Projektdateien oder Ereignisse, bevor du den kleinstmöglichen Patch vorschlägst. Ersetze weder das Spiel noch Assets, die mit der Änderung nichts zu tun haben.Prüfen Sie die vorgeschlagene Änderung vor ihrer Ausführung. Halten Sie geänderte Dateien oder Ereignisse, hinzugefügte Abhängigkeiten und etwaige Umstrukturierungen fest. Fragen Sie nach, warum sich ein sachfremdes Teilsystem geändert hat. Ein neues eigenständiges Spiel mit einem blauen Objekt belegt keine Fortsetzung des Ausgangsstands, selbst wenn seine Vorschau ähnlich aussieht. Bewahren Sie Patch und Erklärung zusammen auf, damit eine andere prüfende Person dieselbe Revision untersuchen kann.
5. Ursprüngliches Verhalten, neue Grenzfälle und Rücknahme erneut prüfen
Wiederholen Sie alle Szenarien des Ausgangstests. Sammeln Sie dann den Bonusstern einmal ein und bleiben Sie an seiner früheren Position: Die Zeit darf nur einmal steigen und der normale Zähler darf sich nicht ändern. Starten Sie neu, sammeln Sie ihn erneut ein und prüfen Sie die Rücksetzung. Testen Sie den Kontakt kurz vor Zeitablauf und nach Spielende; das neue Objekt darf eine beendete Runde nicht fortsetzen. Dokumentieren Sie Annahmen zur Reihenfolge der Frames, falls gleichzeitige Ereignisse das Ergebnis beeinflussen können.
Schlägt eine Prüfung fehl, sichern Sie die fehlerhafte Revision und eine kurze Anleitung zur Reproduktion, bevor Sie eine weitere Reparatur anfordern. Kehren Sie zum gesicherten Ausgangsstand zurück und führen Sie ein Ausgangsszenario erneut aus. Erst nach dieser Prüfung können Sie berichten, dass die Rücknahme reproduziert wurde. Hier wurden weder ein erfolgreicher Patch noch ein regressionsfreies Ergebnis, eine Reparaturdauer oder ein Ergebnis der Rücknahme festgestellt.
Was SEELE beitragen kann und was geprüft werden muss
SEELE beschreibt einen Workflow zur Spielerstellung in natürlicher Sprache, der Szenen, Assets und Spielcode einbezieht. Ein kleines generiertes Spiel ist daher ein passender Ausgangspunkt für diesen Test. Geben Sie zunächst die knappe Spielbeschreibung ein und prüfen Sie dann, was der aktuelle Workflow tatsächlich übergibt: ein spielbares Ergebnis, ein bearbeitbares Projekt, Quelldateien oder ein anderes Artefakt. Diese Ergebnisse sind nicht austauschbar.
Geben Sie bei der Fortsetzung den Kontext des bestehenden Projekts und die einzelne Anforderung für den Bonusstern an. Untersuchen Sie die resultierende Änderung, statt anzunehmen, dass eine Revision in natürlicher Sprache den Zustand korrekt erhält. Projektzugriff, Engine-Kompatibilität und Exportdetails müssen anhand des tatsächlichen Kontos und Ergebnisses bestätigt werden. Die Produktbeschreibung spricht dafür, den Workflow auszuprobieren; sie belegt weder Reproduzierbarkeit noch Architektur oder Wartbarkeit dieses Projekts.
Die Belege für eine belastbare Schlussfolgerung
- Archiv des ursprünglichen Quellcodes oder bearbeitbaren Projekts, erforderliche Assets und eine stabile Revision des Ausgangsstands.
- Tatsächliche Einrichtungsanweisungen, Umgebungsdetails, Befehlsausgaben sowie Startfehler oder Reparaturen.
- Protokoll der Ausgangsszenarien und ununterbrochene Laufzeitbelege für Sieg, Niederlage und Neustart.
- Eine Erklärung anhand tatsächlichen Codes oder tatsächlicher Ereignisse, die genaue Erweiterungsanfrage und der überprüfbare Patch.
- Revisionen vor und nach der Änderung, Beobachtungen zu Regressionen und Grenzfällen sowie eine reproduzierte Rücknahme.
- Eine auf dieses Projekt und diese Erweiterung begrenzte Schlussfolgerung einschließlich ungelöster Fehler.
Alle diese ergebnisrelevanten Artefakte fehlen derzeit. Eine erfolgreiche Bonusstern-Änderung würde eine eng begrenzte Aussage zur Fortsetzung stützen, aber kein Versprechen über Netzwerkfunktionen, Migration von Spielständen oder Entwicklung im Produktionsmaßstab. Eine unvollständige Übergabe sollte im Bericht sichtbar bleiben, statt durch die pauschale Aussage „KI-Code ist bearbeitbar“ ersetzt zu werden.
Fazit: Erst Belege für die nächste Änderung sammeln
Beurteilen Sie die Fortsetzung anhand einer Änderung, die Überprüfung und Regressionstests besteht. Beginnen Sie mit reproduzierbaren Projektmaterialien, bewahren Sie die ursprünglichen Regeln und halten Sie die Erweiterung klein genug, damit unerwartete Änderungen auffallen. Dieser Entwurf liefert die Methode, nicht das fehlende Ergebnis: Ein praktisches Urteil zur Wartbarkeit bleibt unmöglich, bis Projekt, Patch und Laufzeitbelege vorliegen. Nutzen Sie als nächsten Schritt die kurze Beschreibung des Sternesammelspiels in SEELE und bewahren Sie die tatsächliche Übergabe auf, bevor Sie den Bonusstern anfordern. Stoppen Sie bei fehlendem Quellcode oder gescheiterter Einrichtung, dokumentieren Sie das Hindernis und betrachten Sie eine ansprechende Vorschau nicht als Beweis für die Fortsetzbarkeit der Entwicklung.
Fortsetzungstest: Zu sammelnde Belege
Diese Tabelle ordnet die im Artikel vorgeschlagenen Prüfungen. Sie berichtet nicht über einen abgeschlossenen Test.
| Prüfung | Erwartete Beobachtung | Aufzubewahrende Belege |
|---|---|---|
| Einrichtung des Ausgangsstands | Das gelieferte Projekt lässt sich anhand seiner eigenen Anweisungen öffnen und ausführen. | Projektrevision, Einrichtungsschritte, Abhängigkeiten und Laufzeitnotizen. |
| Ursprüngliche Runde | Bewegung, fünf Sammelobjekte, Timer, Sieg, Niederlage und Neustart entsprechen dem festgelegten Testszenario. | Ein wiederholbares Testprotokoll und die Ausgangsrevision. |
| Begrenzte Erweiterung | Die angeforderte Bonusstern-Regel funktioniert, ohne sachfremdes Verhalten zu ändern. | Änderungsanfrage, Patch oder Revision und Prüfungen der neuen Regel. |
| Regression und Rücknahme | Die ursprünglichen Tests bestehen weiterhin und die Änderung lässt sich erkennen und rückgängig machen. | Testergebnisse vor und nach der Änderung sowie die Referenz für die Rücknahme. |
Häufig gestellte Fragen
Kann eine gehostete Vorschau belegen, dass ein Spiel wartbar ist?
Nein. Eine gehostete Vorschau kann beobachtbares Spielverhalten zeigen, belegt aber weder die Vollständigkeit des Quellcodes noch eine reproduzierbare Einrichtung oder die Folgen einer Codeänderung. Nutzen Sie sie als einen Teil der Dokumentation. Eine Aussage zur Fortsetzbarkeit benötigt außerdem die bearbeitbaren Materialien, den gesicherten Ausgangsstand, eine überprüfbare Änderung und Regressionstests in der vorgesehenen Laufzeitumgebung.
Brauche ich eine programmierende Person für diesen Test?
Spielersichtbare Szenarien können Sie auch ohne Programmierkenntnisse dokumentieren. Eine zuverlässige Prüfung von Quellcode und Abhängigkeiten erfordert jedoch jemanden, der mit der Sprache oder dem Editor des Projekts vertraut ist. Trennen Sie diese Aufgaben. Lassen Sie die tatsächliche Änderung von einer qualifizierten Person prüfen, statt eine selbstsichere KI-Erklärung oder einen funktionierenden Startbildschirm als Architekturprüfung zu betrachten.
Was, wenn die Erweiterung funktioniert, die Einrichtung aber undokumentiert bleibt?
Berichten Sie von einem Teilerfolg, nicht von einer einwandfreien Übergabe. Die Erweiterung kann in einer bereits eingerichteten Umgebung funktionieren, während eine neue entwickelnde Person sie noch immer nicht reproduzieren kann. Bewahren Sie die erfolgreiche Revision auf, notieren Sie die tatsächlich verwendeten Einrichtungsschritte und wiederholen Sie sie anhand der gelieferten Materialien, bevor Sie das Projekt als unabhängig reproduzierbar bezeichnen.
