Wählen Sie ein Werkzeug zur Spielerstellung anhand des Spiels, das Sie spielen, der Änderung, die Sie vornehmen, und des Projekts, das Sie behalten können – nicht allein anhand eines Screenshots. Ein fairer Vergleich beginnt mit einem kleinen gemeinsamen Briefing und prüft dieselben für Spielende sichtbaren Regeln, bevor er das Aussehen beurteilt. Er dokumentiert außerdem manuelle Arbeit, Tarifbeschränkungen und den tatsächlichen Inhalt eines Exports. Dieser vorgeschlagene Test umfasst SEELE AI, Rosebud AI, GDevelop und Buildbox, die vier im bestehenden Vergleich genannten Werkzeuge. Für diesen Entwurf lagen keine kontrollierten Durchläufe oder Exportprüfungen vor. Ergebnisse und Empfehlungen stehen daher noch aus: Es gibt keine Bewertungen, beobachteten Fähigkeitsunterschiede oder einen Sieger. Die folgenden Abschnitte legen fest, was auszuführen und aufzubewahren ist, damit ein späterer Vergleich die Auswahlfrage ehrlich beantworten kann.
Das gemeinsame Briefing und die Kontrollbedingungen
Verwenden Sie für jeden Durchlauf einen Desktop-Browser, eine feste Ansichtsgröße und dasselbe Eingabegerät. Legen Sie vor dem Öffnen eines Werkzeugs erlaubten Tarif, Ausgabenobergrenze, Eingriffslimit und Abbruchbedingung fest. Notieren Sie Kontostufe, Datum, angezeigte Werkzeugversion und tatsächliche Kosten. Nehmen Sie nicht an, dass gleich viele Prompts denselben Aufwand bedeuten, wenn ein Workflow visuelle Bearbeitung erfordert.
Erstelle Lantern Delivery, ein 2D-Browserspiel auf einem Bildschirm in Draufsicht. Verwende einen eigenen Kurier und einfache eigene Kulissen. Bewege dich mit WASD oder den Pfeiltasten. Sammle fünf Laternen und weiche dabei einer beweglichen Gefahr aus. Zeige die Anzahl gesammelter Laternen und einen 45-Sekunden-Timer. Kontakt mit der Gefahr oder Zeitablauf beendet den Versuch. Das Sammeln aller fünf Laternen führt zum Sieg. Füge sichtbare Anweisungen und Neustart hinzu. Behalte denselben Kurier und dieselbe künstlerische Richtung durchgehend bei. Verwende weder lizenzierte Figuren noch heruntergeladene urheberrechtlich geschützte Grafiken.Behandeln Sie dies als Spezifikation, nicht als generiertes Ergebnis. Starten Sie im Test den Timer bei der ersten Bewegung, sperren Sie die Eingabe nach beiden Spielausgängen und stellen Sie beim Neustart den gesamten Zustand wieder her. Kann eine Oberfläche das Briefing nicht direkt annehmen, dokumentieren Sie die Umsetzung im jeweiligen nativen Workflow. Gewähren Sie einem Kandidaten nicht stillschweigend zusätzliche Vorbereitung und ersetzen Sie das Briefing nicht durch eine vollständigere Vorlage.
Die zu vervollständigenden Datensätze der vier Kandidaten
SEELE AI: Die Übergabe nach dem Prompt prüfen
SEELE beschreibt die Erstellung von Spielszenen, Assets und Spielcode in natürlicher Sprache. Für diesen Vergleich ist die Frage relevant, ob dieser Workflow die vorgegebene Lantern-Delivery-Spielschleife erzeugt und die kontrollierte Änderung im selben Projekt unterstützt. Geben Sie das unveränderte Briefing über den verfügbaren Erstellungsworkflow ein und bewahren Sie ursprüngliche Anfrage, Antwortverlauf, ersten zugänglichen Build und Kontobedingungen auf.
Leiten Sie aus der Positionierung des Produkts weder Quellcodezugriff noch Engine-Kompatibilität oder einen erfolgreichen lokalen Start ab. Untersuchen Sie die tatsächliche Übergabe und notieren Sie das Format. Sind zusätzliche Klärungen oder Reparaturen nötig, zählen und bewahren Sie diese vor der Schildänderung auf. Eine spätere hilfreiche Empfehlung würde beobachtete Spielbarkeit, Überarbeitungsaufwand und Reproduzierbarkeit mit den Bedürfnissen der Lesenden verbinden. Derzeit existieren diese Beobachtungen nicht; daher erhält dieser Kandidat weder Punkte noch einen zugeschriebenen Vorteil.
Rosebud AI: Den tatsächlichen Erstellungs- und Änderungsweg festhalten
Führen Sie das gemeinsame Briefing mit dem Workflow aus, der im getesteten Rosebud-AI-Konto verfügbar ist. Dokumentieren Sie das anfängliche Eingabeformat, notwendige Einrichtung und jeden Eingriff, der für einen zugänglichen Build erforderlich ist. Ziehen Sie aktuelle offizielle Dokumentation zu Tarifbedingungen heran, halten Sie dokumentierte Aussagen aber getrennt von den Beobachtungen der prüfenden Person. Dieser Entwurf stellt nicht fest, welche aktuellen Funktionen oder Exportformate verfügbar sind.
Sobald eine Basisversion spielbar ist, bewahren Sie sie auf, bevor Sie dieselbe Schildanfrage stellen. Notieren Sie, ob die Überarbeitung das bestehende Projekt ändert und ob Kurier, Regeln und Karte erhalten bleiben. Untersuchen Sie für die Übergabe das Artefakt, das der getestete Workflow tatsächlich liefert; nennen Sie einen gehosteten Link nicht „Quellcode“. Fehlender Zugang in einem Konto ist eine tarifspezifische Beobachtung und kein Beweis dafür, dass ein Produkt eine Fähigkeit nie anbietet. Für diesen Artikel wurde keine Rosebud-Generierung, -Überarbeitung oder -Exportierung durchgeführt.
GDevelop: Arbeit im Editor sichtbar machen
Bewerten Sie den aktuellen GDevelop-Workflow so, wie er der testenden Person erscheint, nicht als angenommene Kopie eines dialogbasierten Generators. Dokumentieren Sie Szenenaufbau, Ereignisbearbeitung, Asset-Vorbereitung und Vorlagenauswahl, die zur Umsetzung des Briefings nötig sind. Bietet der Workflow unterstützte Erstellung, bewahren Sie deren Eingaben und Ausgaben neben manuellen Aktionen auf. Dieser Artikel hat die aktuellen Optionen oder ihre Tarifbedingungen nicht überprüft.
Eine bearbeitbare Ereignisstruktur kann für Nutzende eines visuellen Editors die relevante Übergabe sein; sie sollte nicht allein deshalb verworfen werden, weil sie sich von einem Verzeichnis handgeschriebener Skripte unterscheidet. Umgekehrt beweist ein Editorprojekt allein nicht, dass ein geteilter Browser-Build funktioniert. Halten Sie Basisversion, kontrollierte Ereignis- oder Projektänderung, spielbare Prüfungen und tatsächlichen Exportinhalt getrennt fest. Der spätere Vergleich sollte Aufwand und Ergebnis dieses Workflows zeigen, ohne ihn aufgrund der Bezeichnung „No-Code“ zu bestrafen oder zu belohnen. Ein GDevelop-Testergebnis liegt hier nicht vor.
Buildbox: Projektbearbeitung von veröffentlichtem Ergebnis unterscheiden
Verwenden Sie den tatsächlichen Workflow des getesteten Buildbox-Kontos, um Lantern Delivery umzusetzen, und dokumentieren Sie erforderliche Einrichtung und aus Vorlagen stammendes Verhalten. Prüfen Sie aktuelle Dokumentation und Kontobedingungen, bevor Sie Veröffentlichungs- oder Exportoptionen beschreiben. Gehen Sie nicht davon aus, dass Prompt-Oberfläche, Dateiorganisation oder lokale Startanweisungen eines anderen Werkzeugs hier gelten. Bewahren Sie die erste auswertbare Projektrevision einschließlich manueller Vorbereitung auf.
Dokumentieren Sie für die Schildänderung die bearbeitbare Logik oder Projektunterschiede, die den Schutz umsetzen, sowie Belege dafür, dass die ursprünglichen Regeln intakt bleiben. Benennen Sie die resultierende Übergabe genau: ein Editorprojekt, ein gehosteter Build, ein kompiliertes Artefakt oder Quelldateien, je nachdem, was tatsächlich geliefert wird. Ist ein Ziel oder Export nicht zugänglich, nennen Sie den getesteten Tarif und die genaue beobachtete Beschränkung. So können spätere Lesende den Workflow anhand ihrer Bedürfnisse beurteilen. Derzeit wurde kein Build, keine Überarbeitung und keine Übergabe von Buildbox untersucht; ein Urteil über Fähigkeiten ist nicht begründet.
Dieselben Prüfungen für Spiel, Änderung und Übergabe durchführen
Testen Sie zuerst Anweisungen, beide Bewegungsarten, einmaliges Einsammeln, Kontakt mit der Gefahr, Sieg bei fünf Laternen, Zeitablauf und Neustart nach jedem Ausgang. Wiederholen Sie dies nach einem neuen Laden. Markieren Sie jede Prüfung als bestanden, fehlgeschlagen oder nicht getestet und fügen Sie die Build-Revision hinzu. Bewahren Sie eine ununterbrochene Aufzeichnung einschließlich Fehlern auf. Eine Seitenantwort oder attraktive Szene ist keine vollständige Prüfung der Spielschleife.
Führen Sie anschließend eine kontrollierte Änderung durch: Fügen Sie ein einsammelbares Schild hinzu, das genau einen Kontakt mit der Gefahr abfängt und beim Einsammeln verschwindet. Zeigen Sie an, ob der Schutz aktiv ist. Bewahren Sie Kuriergrafik, Karte, Steuerung, Laternenzahl, Timer und Neustart. Legen Sie fest, dass vor dem Neustart kein zweites Schild erscheint. Testen Sie das Einsammeln, den ersten geschützten Kontakt, den nächsten ungeschützten Kontakt, Zeitablauf bei aktivem Schutz und die Wiederherstellung beim Neustart. Wiederholen Sie alle Basisprüfungen. Speichern Sie den nativen Revisionsunterschied, ob Code, Ereignisse oder ein anderes überprüfbares Projektartefakt.
Unterscheiden Sie schließlich zwischen spielbarem Link, kompiliertem Build, bearbeitbarem Projekt und menschenlesbarem Quellcode. Speichern und untersuchen Sie den gelieferten Export. Öffnen oder starten Sie ihn mit den dokumentierten Werkzeugen in einem sauberen Verzeichnis und notieren Sie tatsächliche Befehle, Versionen, fehlende Assets und manuelle Korrekturen. Ein erfolgreicher Download allein belegt kein reproduzierbares Projekt. Bewahren Sie aktuelle Dokumentation neben der Beobachtung auf, ohne sie an die Stelle des Tests zu setzen.
Vergleichen Sie Gleiches mit Gleichem: erstes zugängliches Ergebnis mit erstem zugänglichem Ergebnis und repariertes Ergebnis mit repariertem Ergebnis, wobei Eingriffe offenzulegen sind. Anfänger können verständliche Iteration und eine funktionierende Spielschleife bevorzugen; Entwickler reproduzierbaren Quellcode; Editor-Nutzende überprüfbare Ereignisse. Berichten Sie über diese Abwägungen erst, wenn die Artefakte vorliegen. Angaben zu Zeit und Credits brauchen dokumentierte Start- und Stoppregeln statt nachträglicher Schätzungen. Ein einzelner Durchlauf kann einen begrenzten Fallvergleich stützen, aber keine allgemeine Zuverlässigkeitsaussage.
Beleg-Checkliste: Keine Ergebniszelle ist vollständig
- Je Kandidat: Kontostufe, Testdatum, angezeigte Version, Browser, Budget und tatsächlicher Verlauf der Eingriffe.
- Ursprüngliches Briefing, Basisprojekt oder Build und vollständige Aufzeichnung der Abnahmeprüfungen.
- Genaue Schildanfrage, Revisionen davor und danach, überprüfbare Änderung und Regressionsbeobachtungen.
- Tatsächliches Export- oder Übergabeartefakt, Einrichtungsprotokoll in sauberer Umgebung und beobachtetes Startergebnis.
- Aktuelle offizielle Dokumentation als Beleg für Aussagen zu Tarifen oder Formaten.
- Erkenntnisse je Werkzeug und bedingte Empfehlungen, erst nach diesen Prüfungen verfasst.
Alle vier Kandidatendurchläufe stehen für diesen Artikel noch aus. Die Checkliste ist ein Sammelplan, keine Ergebnistabelle. Es gibt keine getestete Rangliste, kein schnellstes Werkzeug, kein günstigstes abgeschlossenes Spiel und keinen überprüften Exportsieger zu berichten.
Fazit: Die Empfehlung zurückstellen, bis Belege vorliegen
Der nützliche Vergleich fragt nicht, welches Werkzeug am vollständigsten klingt, sondern welcher getestete Workflow zum Projekt passt, das Sie fortsetzen möchten. Bewahren Sie das gemeinsame Briefing auf, legen Sie Unterstützung offen und trennen Sie spielbares Verhalten von der überprüfbaren Übergabe. Dieser Entwurf kann keinen Sieger wählen: Die vier kontrollierten Durchläufe, Änderungen und Exporte fehlen noch. Nachdem Zugang und gegebenenfalls Budget genehmigt sind, verwenden Sie das gemeinsame Lantern-Delivery-Briefing in SEELE und wiederholen es unverändert bei den anderen Kandidaten. Halten Sie Fehlschläge und Beschränkungen fest. Grenzen Sie die Auswahl erst dann anhand beobachteter Spielbarkeit, Bearbeitungsaufwand und Projektzugang ein statt anhand einer angenommenen Rangliste.
Vergleichsbogen: Eigene Belege dokumentieren
Diese Tabelle ordnet die im Artikel vorgeschlagenen Prüfungen. Sie berichtet nicht über einen abgeschlossenen Test.
| Bewertung | Bei jedem Kandidaten dieselbe Prüfung anwenden | Dokumentieren |
|---|---|---|
| Spielbares Ergebnis | Das gemeinsame Briefing ausführen und die für Spielende sichtbaren Regeln prüfen. | Was funktionierte, was fehlschlug und die Belege jedes Durchlaufs. |
| Aufwand und Kosten | Tarif, tatsächliche Ausgaben, Prompts und manuelle Bearbeitung festhalten. | Kontostufe, Datum, Kosten, Eingriffe und Zeitaufwand. |
| Überarbeitung | Dieselbe begrenzte Änderung anfordern und die Basisprüfung wiederholen. | Änderungsanweisungen und Testergebnisse vorher/nachher. |
| Übergabe | Untersuchen, was nach Export oder Übergabe tatsächlich verfügbar ist. | Dateien, Bearbeitbarkeit, Abhängigkeiten und geltende Bedingungen. |
| Entscheidung | Die dokumentierten Belege mit den eigenen Prioritäten vergleichen. | Offene Prüfungen benennen, statt einen unbegründeten Sieger zu bestimmen. |
Häufig gestellte Fragen
Bedeutet eine Export-Schaltfläche, dass ich bearbeitbaren Quellcode erhalte?
Nein. Der Export kann ein kompilierter Build oder ein für einen bestimmten Editor vorgesehenes Projekt sein. Laden Sie das tatsächliche Artefakt herunter, untersuchen Sie es und öffnen oder starten Sie es mit den dokumentierten Werkzeugen. Notieren Sie getesteten Tarif und Format, damit eine begrenzte Beobachtung auf Kontoebene nicht mit einer allgemeinen Produktfähigkeit verwechselt wird.
Kann offizielle Dokumentation einen praktischen Vergleich ersetzen?
Nein. Dokumentation kann eine Aussage über eine aktuelle Funktion oder einen Tarif stützen, aber nicht zeigen, dass dieses konkrete Spiel korrekt funktionierte oder die Schildänderung überstand. Bewahren Sie Dokumentation und beobachtete Ergebnisse in getrennten Notizen auf. Markieren Sie ein nicht ausgeführtes Szenario als nicht getestet, statt Vertrauen aus einem Werbebeispiel oder einer Funktionsliste abzuleiten.
Sollte jeder Kandidat genau gleich viele Prompts erhalten?
Verwenden Sie dasselbe anfängliche Briefing und dieselbe Änderungsspezifikation, legen Sie aber jede zusätzliche Unterstützung und manuelle Arbeit offen. Unterschiedliche Oberflächen können unterschiedliche Aktionen erfordern, daher ist die Promptzahl allein kein faires Aufwandsmaß. Legen Sie Eingriffs- und Budgetgrenzen im Voraus fest und bewahren Sie den Verlauf auf, statt die Regeln nach Sichtung der Ergebnisse anzupassen.
