Anatomie einer KI-Spielengine: Was tatsächlich hinter dem Prompt steckt

Von Mariana Muntean, CEO von Cinevva

Am häufigsten sagen Leute, die Cinevva noch nicht kennen, es sei nur ein KI-Wrapper. Sie landen auf der Startseite, sehen ein einzelnes Eingabefeld mit der Aufschrift „Beschreibe dein Spiel“ und glauben, das Produkt verstanden zu haben. Verstanden haben sie die Eingangstür. Das Produkt ist all das, was man nicht sieht, wenn man diesen Satz eingibt – und seit dieser Woche außerdem eine offene Welt, die deine Spieler betreten, um dein Spiel überhaupt erst zu entdecken.

Hinter dieser Eingabe stecken eine vollständige Spielengine, ein Orchestrator mit 26 typisierten Tools, eine ganze Flotte generativer Modelle, eine gebündelte Asset-Suche über elf Anbieter hinweg, ein Live-Spiel-Iframe, das der Agent lesen und verändern kann, sowie ein Storefront-Feed, in dem derselbe Agent dein fertiges Spiel als durchwischbares Gameplay-Reel veröffentlicht. Nichts davon ist exotisch. Es ist alles Infrastruktur. Die interessante Arbeit bestand darin, zu entscheiden, was womit verbunden wird.

Dieser Beitrag führt von oben bis unten durch die gesamte Maschine. Es ist dieselbe Erklärung, die wir technisch versierten Investoren geben, und dieselbe, die wir Entwicklern geben, die über einen Beitrag zum Projekt nachdenken. Beide wollen dieselbe Antwort.

1. Der Prompt ist die Oberfläche, nicht das System

Die erste Designentscheidung bestand darin, alles zu verbergen, bis der Nutzer bereits etwas investiert hat. Die Startseite hat genau eine Aufgabe: Sie soll einen Satz entgegennehmen und daraus ein Projekt machen. Wir haben das Erlebnis in einen öffentlichen Bereich – den Prompt, die Showcases und den Storefront-Feed – und einen Creator-Bereich – die IDE, die Asset-Tools und den Veröffentlichungsablauf – aufgeteilt, damit Menschen, die einfach nur spielen wollen, nicht ins Cockpit schauen müssen.

Deshalb wechselt der Platzhalter zwischen Beispielen wie „Erstelle ein Snake-Spiel mit Neon-Grafik“ und „Top-down-Zombie-Shooter“. Das sind keine Tutorials. Sie geben die Erlaubnis, einfach loszulegen. Der Nutzer erkennt, dass auch eine „seltsame Arcade-Idee“ eine gültige Eingabe ist.

Sobald du die Eingabe absendest, geschehen drei Dinge. Das System erstellt ein neues Spielprojekt mit einer stabilen ID. Es legt eine leere Dateistruktur an (index.html, game.js, style.css, assets/, GDD.md). Und es leitet deinen Satz an den Orchestrator weiter, zusammen mit einem Projekt-Kontextfenster, das auf diese leeren Dateien verweist. Von diesem Moment an sprichst du mit einem Agenten, der selbst handeln kann.

2. Hinter der Eingabe steckt eine vollständige Browser-IDE

Der Creator-Arbeitsbereich ist eine IDE mit drei Bereichen, die vollständig im Browser läuft. Links befindet sich der Dateibaum, in der Mitte der Code-Editor, rechts das Live-Spiel-Iframe und am unteren Rand eine Chat-Eingabe. Wir haben dieses Layout bewusst gewählt. Menschen, die bereits programmieren, erkennen es sofort. Wer nicht programmiert, kann den mittleren Bereich ignorieren und ausschließlich den Chat verwenden.

Der Dateibaum ist keine Metapher. Jedes Projekt ist tatsächlich eine kleine statische Website aus HTML, JS, CSS, generierten Bildern, GLB-Modellen und Audiodateien, die über einen Cloudflare Worker direkt aus R2 ausgeliefert wird. Es gibt keinen Build-Schritt. Der Grund dafür ist wichtig. So kann der Agent genau die Dateien lesen und schreiben, die du tatsächlich ausliefern würdest. Gleichzeitig läuft dasselbe Artefakt im Iframe, auf einem mit Capacitor verpackten Smartphone, auf Steam in einem Tauri-Wrapper und innerhalb von Discord als Embedded Activity. Ein Dateisystem, sechs Vertriebsziele.

Jedes von uns generierte Spiel muss zwei Funktionen über window bereitstellen. getGameState() gibt ein einfaches Objekt zurück, das den aktuellen Spielzustand beschreibt – Spielerposition, Punktzahl, Leben, Gegner und Timer. setGameState(patch) wendet eine partielle Aktualisierung auf das laufende Spiel an. Diese winzige API ist der Vertrag, durch den der Agent ein laufendes Spiel untersuchen und verändern kann, ohne es neu zu laden. In Abschnitt 6 kommen wir darauf zurück, warum das wichtig ist.

3. Der Orchestrator, in dem die eigentliche Engine steckt

Was Menschen übersehen, wenn sie Cinevva als „KI-Wrapper“ bezeichnen, ist, dass die KI nicht einfach Code schreibt, sondern vielmehr ein kleines Orchester dirigiert. Der Orchestrator ist eine Tool-Calling-Schleife, die mit einem Frontier-Modell arbeitet. Dazu gehören ein etwa tausend Zeilen langer System-Prompt und eine typisierte Tool-Oberfläche mit 26 Funktionen. Die Tool-Definitionen sind die Engine. Das Modell ist der Dirigent.

Die 26 Tools lassen sich in fünf Gruppen einteilen. Dateisystem-Tools (list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files) ermöglichen es dem Agenten, dein Spiel wie jede andere Codebasis zu behandeln. Projekt-Tools (create_new_game, list_games, open_game, ask_user, game_ready) verwalten den Lebenszyklus eines Projekts und die Übergabe zurück an den Menschen. Generative Tools (generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles) rufen spezialisierte Modelle auf, die wir im nächsten Abschnitt behandeln. Wissens-Tools (search_fonts, list_library_docs, search_library_docs, list_generations) liefern dem Agenten zuverlässige, indexierte Quellen der Wahrheit statt halluzinierter APIs. Und Laufzeit-Tools (read_console_logs, execute_js) ermöglichen es dem Agenten, das laufende Spiel zu sehen und direkt darauf einzuwirken.

Ein typischer erster Durchlauf sieht ungefähr so aus: Der Nutzer gibt „Erstelle einen Neon-Weltraum-Shooter“ ein. Das Modell gibt einen write_files-Aufruf mit einer GDD.md aus, die das Design beschreibt, und ruft anschließend erneut write_files für index.html, game.js und style.css auf. Es ruft generate_music mit prompt="synthwave space shooter, 120 BPM, driving bassline" auf, wodurch ein Job bei ElevenLabs Music gestartet wird, der eine MP3-URL innerhalb von R2 zurückgibt. Es ruft generate_skybox mit einem Stil von Blockade Labs Model 3 für das Sternenfeld auf. Danach ruft es game_ready(title, message) auf, um das Iframe auf den neuen Build umzuschalten, und schließlich read_console_logs, um zu bestätigen, dass das Spiel fehlerfrei gestartet ist. Wenn es einen Stacktrace entdeckt, kehrt es zu edit_files zurück und behebt den Fehler, bevor der Nutzer überhaupt etwas meldet.

Die interessante Eigenschaft dieses Designs besteht darin, dass nur der System-Prompt und die Tool-Schemas produktspezifisch sind. Tauscht man das Modell aus, funktioniert weiterhin alles. Wir sind im vergangenen Jahr zwischen drei Frontier-Modellen migriert, ohne die Oberfläche zu ändern, denn die Oberfläche gehört uns.

4. Die Asset-Seite: Auffächerung auf mehrere Modelle

Der Agent generiert Bilder, Musik, Sound oder 3D-Inhalte nicht selbst. Er ruft Spezialisten auf. Die Asset-Seite von Cinevva fächert Anfragen auf mehrere führende Modelle auf und verbindet sie so miteinander, dass die Ausgabe eines Modells eine gültige Eingabe für das nächste ist.

Für Bilder und Sprites ruft generate_image Flux Pro 1.1 mit einer Breite und Höhe auf, die immer ein Vielfaches von 32 sind. Das Ausgabeformat wechselt zu PNG, wenn der Prompt Transparenz verlangt. Für vollständige Songs ruft der Agent ElevenLabs Music mit einem stilistischen Prompt und einer Dauer in Sekunden auf. Für einzelne Effekte erzeugt ElevenLabs SFX innerhalb von fünf bis fünfzehn Sekunden einen Clip aus Texten wie „Laserwaffe wird abgefeuert, Sci-Fi-Blaster“. Für 360-Grad-Umgebungen ruft generate_skybox Blockade Labs mit einem von etwa neunzig Stilen auf; standardmäßig wird Model 3 Digital Painting verwendet. Für 3D-Charaktere sendet rig_model eine GLB-Datei an Tripo, um sie als Zweibeiner, Vierbeiner, Sechsbeiner, Achtbeiner, schlangenartiges oder aquatisches Wesen zu skinnen und zu riggen. Anschließend spielt apply_animation eine von fünfzehn Voreinstellungen ab – Leerlauf, Gehen, Laufen, Springen, Klettern, Tauchen, Schlagen, Schießen, Verletztwerden, Fallen und Drehen sowie die Marschbewegungen für Nicht-Zweibeiner.

Jeder dieser Aufrufe ist ein Job und kein synchroner Aufruf. Sie dauern Sekunden bis Minuten. Der Orchestrator startet sie, kehrt sofort mit einer jobId zurück, und ein separater Kanal leitet das Ergebnis in die Unterhaltung, sobald das Asset fertig ist. Dadurch fühlt sich der gesamte Ablauf völlig anders an. Der Agent kann weiter an der Spiellogik arbeiten, während im Hintergrund das Rigging eines 3D-Modells abgeschlossen wird. Der Nutzer muss nie auf einen einzelnen kritischen Vorgang warten.

Alle Artefakte landen am selben Ort: in R2 hinter cdn.cinevva.com, erreichbar über einfache URLs. Dadurch kann der nächste write_files-Aufruf des Agenten einfach <audio src="https://cdn.cinevva.com/audio/abc.mp3"> einbetten, und das Spiel funktioniert sofort. Kein SDK, kein Asset-Bundler, kein Manifest.

5. Asset-Suche über elf Anbieter hinweg

Generierung eignet sich hervorragend, wenn du etwas Bestimmtes brauchst. Eine Suche ist schneller, wenn bereits etwas Passendes existiert. Die Asset-Bibliothek ist eine föderierte Suche über elf Anbieter kostenloser und lizenzierter Inhalte hinweg, deren Ergebnisse in einem einzigen sortierten Feed erscheinen.

Das Anbieterregister befindet sich im Worker und führt jede Anfrage parallel bei PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, der Smithsonian-3D-Sammlung, TurboSquid, Synty und Jamendo aus. Jeder Anbieter implementiert eine gemeinsame Schnittstelle (search, getMetadata, isBrowsable, getSupportedTypes), sodass zum Hinzufügen eines neuen Anbieters nur eine einzelne TypeScript-Datei nötig ist. Die Aggregationsschicht verarbeitet die cursorbasierte Paginierung bei Anbietern mit unterschiedlichen Paginierungsverfahren, dedupliziert Lizenzen, normalisiert Asset-Typen in einer gemeinsamen Taxonomie – Modell, Textur, Audio, HDRI und Sprite – und versieht jedes Asset mit seiner Lizenz, damit der Agent niemals etwas auswählt, das er nicht weiterverbreiten darf.

Als ChatGPT dieses Tool im vergangenen Quartal als einen der besten kostenlosen Asset-Finder für Spieleentwickler empfahl, haben wir uns die Empfehlung angesehen. Beim entscheidenden Punkt lag sie richtig. Es geht nicht darum, dass wir eine Suchleiste über einer einzelnen Bibliothek anbieten. Entscheidend ist, dass ein Indie-Entwickler bei der Suche nach „Steinwandtextur“ Ergebnisse von PolyHaven und AmbientCG direkt neben Kenneys stilisierter Version und einer Photogrammetrie-Option des Smithsonian erhält – mit einer einzigen Anfrage und konsistenten Lizenzmetadaten. Der Agent kann denselben Endpunkt nutzen und Assets genauso auswählen wie ein Mensch.

Dieser Teil der Engine wird häufig unterschätzt. Die meisten Spiele-KI-Demos generieren alles von Grund auf und enden mit einem einheitlichen, glänzenden und leicht unheimlichen Look. Die interessanten Spiele auf Cinevva kombinieren generierte Assets mit echter CC0-Photogrammetrie des Smithsonian und einem handgefertigten Low-Poly-Baum von Quaternius. Der Orchestrator kann das in einem einzigen Durchlauf erledigen.

6. Der Agent spielt das Spiel

Dieser Teil überrascht die meisten Entwickler, wenn wir ihn zeigen. Der Agent schreibt nicht nur Code in Dateien. Er führt das Spiel in einem Sandbox-Iframe aus, liest dessen Konsole, erstellt getrennte Screenshots für die Benutzeroberfläche und die 3D-Szene und führt JavaScript innerhalb der Live-Laufzeit aus, um den Zustand zu untersuchen oder zu verändern. read_console_logs gibt die letzten fünfzig Zeilen von console.log, console.warn, console.error sowie nicht abgefangene Ausnahmen aus dem iframe zurück. Nach jedem Aufruf von game_ready muss der Agent laut System-Prompt read_console_logs aufrufen und sämtliche Fehler beheben, bevor er das Ergebnis an den Nutzer übergibt. Allein diese eine Regel verhindert die meisten jener „Die KI sagte, sie sei fertig, aber der Bildschirm ist schwarz“-Fehler, die bei anderen Tools auftreten.

execute_js ist das leistungsfähigere Tool. Es führt beliebiges JavaScript im globalen Gültigkeitsbereich des Spiels aus. Da jedes Spiel getGameState und setGameState implementieren muss, kann der Agent mit JSON.stringify(getGameState()) den vollständigen Zustand des laufenden Spiels auslesen und anschließend mit setGameState({player: {x: 500, y: 100}}) den Spieler teleportieren, mit setGameState({lives: 99}) Unverwundbarkeit gewähren oder mit setGameState({level: 3}) zu einem späteren Level springen. Er kann auch auf tieferen Ebenen nachsehen, etwa mit scene.children.map(c => c.type), um den Three.js-Szenengraphen zu untersuchen, oder mit document.querySelectorAll('canvas').length, um zu bestätigen, dass der Renderer eingebunden wurde.

Warum das wichtig ist, liegt auf der Hand. Wenn ein Nutzer sagt: „Der Spieler bleibt in Level zwei in der Wand stecken“, muss der Agent nicht raten. Er öffnet Level zwei, führt getGameState() aus, untersucht die Kollisionsdaten, testet mit einem execute_js-Patch eine Korrektur und schreibt sie erst dann auf die Festplatte. Er debuggt so, wie du debuggen würdest. Wir behandeln das iframe als gleichwertigen Partner, nicht als bloßes Ziel.

7. Bibliotheksdokumentation, die langweilige Quelle der Wahrheit

Wir indexieren die offizielle Dokumentation der Bibliotheken, die Spiele tatsächlich verwenden – Three.js, Tone.js, Cannon und zunehmend weitere – in einem strukturierten, durchsuchbaren JSON-Speicher. Der Agent greift auf search_library_docs("threejs", "Mesh") zurück, bevor er das offene Web durchsucht. Das ist schneller, versionsgebunden und halluziniert niemals eine Methode, die vor zwei Nebenversionen umbenannt wurde.

Das ist nicht glamourös. Aber genau darin liegt der Unterschied zwischen einer KI, die funktionierenden Code erzeugt, und einer KI, die überzeugend aussehenden Code produziert, der in Zeile vierzig abstürzt. Ein Großteil der sichtbaren Qualität von mit Cinevva erstellten Spielen beruht auf genau dieser Entscheidung.

8. Von spielbar zu auffindbar: Reels und der Store

Ein Spiel, das niemand spielt, ist ein privates Hobby. Das schwierigste ungelöste Problem in der Indie-Entwicklung ist heute nicht mehr die Erstellung von Spielen. Es ist ihre Verbreitung. Deshalb endet die Engine nicht bei „spielbar“. Sie endet bei „vor den Augen der Spieler“.

Jedes Projekt auf Cinevva besitzt eine stabile Freigabe-URL wie play.cinevva.com/{game-id}, die den neuesten Build des Spiels in einem ganzseitigen iframe mit einem kleinen Overlay für Likes und Teilen öffnet. Wenn der Agent game_ready aufruft, aktiviert er nicht nur die Vorschau in der IDE. Er bietet außerdem an, ein 15-sekündiges Gameplay-Reel im Cinevva-Store zu veröffentlichen. Das Reel ist eine echte Aufzeichnung des gespielten Spiels, die direkt aus dem iframe aufgenommen wird – wir liefern ein kleines Recorder-Skript mit, das der Agent in die Laufzeitumgebung des Spiels injiziert. Was Betrachter beim Scrollen sehen, ist also echtes Gameplay und kein Marketing-Schnitt.

Das verändert den Arbeitszyklus eines Entwicklers. Der alte Ablauf lautete: programmieren, bauen, paketieren, hochladen, eine Steam-Seite verfassen, mit einem Algorithmus kämpfen und einen Wunschlistenzähler beobachten. Der neue Ablauf lautet: einen Satz eingeben, dem Agenten beim Erstellen zusehen, auf „Veröffentlichen“ klicken und beobachten, wie das eigene Spiel im selben Swipe-Feed neben allen anderen erscheint. Die Entdeckung findet im selben Produkt statt wie die Erstellung, unter derselben URL und mit demselben Login.

Für Leser aus der Entwickler-Community ist dies der Teil, den ihr euch genauer ansehen solltet. Distribution war schon immer der Burggraben, den Spiele-Engines nicht mitlieferten. Unity liefert einen Editor, du veröffentlichst das Spiel auf Steam. Unreal liefert einen Editor, du veröffentlichst es im Epic Store. Cinevva liefert beide Hälften. Engine und Store kommunizieren über denselben Orchestrator miteinander, der auch das Spiel erstellt hat.

9. Top-Performer: das Schwungrad der Entdeckung

Der Reels-Feed ist die eine Hälfte des Schwungrads. Die Top-Performer-Rangliste ist die andere. Sie ordnet Spiele nach „Im Trend“, „Neu“ und den besten Ergebnissen aller Zeiten, gewichtet nach Abschlussrate – also danach, ob ein Spieler eine Sitzung beendet hat – statt nach reinen Klickzahlen. Die Abschlussrate lässt sich schwerer manipulieren als Installationen. Ein Spiel, das die Aufmerksamkeit sechzig Sekunden lang hält, schlägt eines, das geöffnet und sofort wieder geschlossen wird.

Jedes Signal fließt in den nächsten Durchlauf des Orchestrators zurück. Wenn der Agent sagt: „Lass uns ein Power-up hinzufügen“, greift er nicht auf eine feste Musterbibliothek zurück. Er greift auf ein Modell zurück, das beobachtet hat, welche Mechaniken Spieler auf Cinevva in diesem Monat tatsächlich halten. Das Schwungrad ist keine Rangliste am Ende der Seite. Es ist das Trainingssignal für die gesamte Engine.

Für Investoren ist das der Daten-Burggraben. Wir verfügen nicht nur über generierte Spiele. Wir verfügen über generierte Spiele mit echten Interaktionsmetriken auf Sitzungsebene, verknüpft mit den Prompts, aus denen sie hervorgegangen sind, mit den Asset-Entscheidungen des Agenten und mit den Spielern, denen sie gefallen haben. Jede Schleife verstärkt die nächste.

10. Die Engine wird selbst zum Spiel

Hier kommt der Teil, den ich seit Monaten in den sozialen Medien andeute. Alles in den Abschnitten 1 bis 9 beschreibt ein System, das Spiele erstellt. Schwieriger zu beschreiben – bis man es selbst sieht – ist, was geschieht, wenn das System selbst zu einem Ort wird.

Spieleentwicklung ist harte Arbeit, selbst mit allem, was wir bereits ausgeliefert haben. Wenn du noch nie zuvor ein Spiel erstellt hast, bist du plötzlich für die Handlung, die Charaktere, die Welt, die Mechaniken, die Aufgabenverteilung und das Timing, das Verhalten des Lichts, die Überlagerung der Spezialeffekte, die Musik, die Soundeffekte und die Kamerabewegungen verantwortlich. Das ist eine Menge. Und zusätzlich soll sich das Ergebnis wie dein eigenes Werk anfühlen, nicht wie eine Vorlage, die das Tool eines anderen ausgespuckt hat. Prompt und Orchestrator übernehmen den Großteil der mechanischen Arbeit für dich. Was sie allein nicht können, ist deinem fertigen Werk eine Bühne zu geben, auf der es steht, während andere Menschen zuschauen.

Also haben wir diese Bühne gebaut. Während des größten Teils dieses Jahres haben Oleg und das Engine-Team ihre Arbeit in einer 14-teiligen Serie darüber veröffentlicht, wie man eine offene Welt in den Browser bringt. Geformtes Terrain, das du in Echtzeit bearbeiten kannst. Biome, die sich abhängig von Neigung und Höhe selbst mit Fels oder Gras bemalen. 80.000 Grashalme, die sich im Wind über rechnergeneriertem Terrain wiegen. Ein Charakter, der im selben Schritt über Heightmap- und volumetrisches Terrain geht, sprintet, springt und gleitet. Nichts davon war ein Selbstzweck oder eine reine Tech-Demo. Es war die Grundlage hierfür.

Heute ist die offene Welt in einer frühen Form live. Du wählst einen Avatar und betrittst sie. Deine veröffentlichten Spiele erscheinen als besuchbare Räume um dich herum, so wie sie heute in den Store-Reels und der Top-Performer-Rangliste erscheinen – nur dass du sie zu Fuß erreichst, statt dorthin zu swipen. Du kannst direkt aus der Welt in das Spiel eines Fremden eintauchen, ohne die Welt zu verlassen. Du kannst neben der Person stehen, die das gerade von dir gespielte Werk erstellt hat, und ihr sagen, was du als Nächstes hinzufügen würdest. Du kannst gemeinsam mit jemandem, den du gerade erst kennengelernt hast, ein Stück Terrain formen und daraus den Keim eines neuen Projekts machen. Entdeckung ist kein Feed mehr. Sie wird zu einem Spaziergang.

Unsere Engine war im technischen Sinne schon immer eine Spiele-Engine. Heute wird sie es auch im wörtlichen Sinne. Das, was dein Spiel erstellt, ist nun selbst ein Spiel. Derselbe Orchestrator aus Abschnitt 3, dieselben Asset-Leitplanken aus Abschnitt 4, derselbe getGameState-Vertrag aus Abschnitt 6, dieselben Reels aus Abschnitt 8 und dieselbe Rangliste aus Abschnitt 9 fügen sich zu dem einen Ort zusammen, an dem sich deine Spieler bewegen. Die Grenze zwischen Erstellen und Spielen war schon immer künstlich. Jetzt ist sie verschwunden.

Was wir unserer Meinung nach richtig gemacht haben

Das Erste, was wir richtig gemacht haben, war, den Prompt als UI-Einstieg statt als Produkt zu behandeln. Das Produkt besteht aus dem Orchestrator, der Tool-Oberfläche, den Asset-Leitplanken und dem Store. Der Prompt ist die einfachste und günstigste Möglichkeit, einen Nutzer in das System zu bringen.

Das Zweite war unser Beharren auf einem flachen, browsernativen Dateisystem ohne Build-Schritt. Deshalb kann ein Cinevva-Spiel aus einer einzigen verlässlichen Quelle für Mobilgeräte, Desktop, Steam und Discord ausgeliefert werden. Deshalb kann der Agent lesen, was er geschrieben hat.

Das Dritte war der Vertrag, nach dem jedes generierte Spiel getGameState und setGameState implementiert. Diese eine Zeile im System-Prompt sorgt dafür, dass sich der Agent wie ein Mitentwickler statt wie ein Codegenerator anfühlt. Der Agent kann spielen – und ein System, das spielen kann, kann auch debuggen.

Das Vierte war die Einbindung des Stores in denselben Kreislauf wie die Engine. Wir werden nicht allein durch die reine Modellqualität gewinnen. Zwei Monate Vorsprung vor einem Open-Weights-Generator sind kein verteidigbarer Vorteil. Wir gewinnen, wenn derselbe Agent, der dein Spiel erstellt, es auch veröffentlicht, misst und daraus lernt, wie fremde Menschen es gespielt haben.

Wenn du die ganze Maschine in Aktion sehen möchtest, ist der Prompt auf der Startseite weiterhin der Haupteingang. Gib einen Satz ein. Beobachte, was dahinter geschieht. Komm anschließend hierher zurück und sag uns, über welchen Teil der Engine wir als Nächstes schreiben sollen.