Diffusionsmodelle sind Echtzeit-Spiel-Engines
(gamengen.github.io)- GameNGen erzeugt die Bildschirmübergänge des klassischen Spiels DOOM ausschließlich mit einem neuronalen Modell und ermöglicht so Echtzeit-Interaktion ohne separate traditionelle Engine
- Es läuft auf einer einzelnen TPU mit mehr als 20 fps und zielt darauf ab, Bildqualität und Reaktionsfähigkeit auch über lange Spielverläufe hinweg aufrechtzuerhalten
- Die Vorhersage des nächsten Frames erreichte PSNR 29,4, und menschliche Bewerter konnten in kurzen Clips echtes Spiel und Simulation nur geringfügig besser als zufällig unterscheiden
- Das Training basiert auf Aktions- und Beobachtungsprotokollen, die von einem RL-Agenten erzeugt wurden; das Diffusionsmodell generiert daraus anhand vergangener Frames und Aktionssequenzen den nächsten Frame
- Um den sich während der Inferenz aufsummierenden autoregressiven Drift zu verringern, wird den Kontext-Frames beim Training gaußsches Rauschen hinzugefügt; das spielt eine wichtige Rolle für die visuelle Stabilität über lange Zeiträume
DOOM-Simulation, die nur mit neuronalen Netzen läuft
- GameNGen ist eine auf neuronalen Modellen basierende Game-Engine, die Echtzeit-Interaktion entlang langer Trajektorien in komplexen Umgebungen ermöglicht
- Die Demo ist das Ergebnis einer Echtzeitaufnahme von Menschen, die DOOM spielen, die ausschließlich mit dem GameNGen-Neuronalmodell simuliert wurde
- Leistung und Qualität sind darauf ausgerichtet, die Unterscheidbarkeit vom echten Spiel zu verringern
- Simuliert DOOM interaktiv mit mehr als 20 fps auf einer einzelnen TPU
- Die Vorhersage des nächsten Frames erreicht PSNR 29,4
- Dieser PSNR liegt auf einem ähnlichen Niveau wie verlustbehaftete JPEG-Kompression
- Menschliche Bewerter konnten kurze Spielclips und Simulationsclips nur geringfügig besser als durch zufälliges Raten unterscheiden
- Weiteres Material gibt es im Paper und auf Arxiv
Trainingsdaten und Aufbau des generativen Modells
- Die Datenerfassung erfolgte nicht durch das Sammeln großer Mengen menschlicher Spielszenen, sondern durch das Training automatisierter RL-Agenten
- Aktionen und Beobachtungen aus den Trainingsepisoden der Agenten werden gespeichert
- Diese gespeicherten Aktions- und Beobachtungsprotokolle werden zu den Trainingsdaten des generativen Modells
- Das generative Modell verwendet das kleine Diffusionsmodell Stable Diffusion v1.4 erneut
- Es erzeugt den nächsten Frame unter Verwendung früherer Aktions- und Beobachtungs-Frame-Sequenzen als Bedingung
- Um den bei autoregressiver Inferenz entstehenden Drift zu reduzieren, wird beim Training den kodierten Kontext-Frames gaußsches Rauschen hinzugefügt
- Diese Rauschinjektion veranlasst das Modell dazu, aus dem vorherigen Frame gesampelte Informationen zu korrigieren, was entscheidend ist, um die visuelle Stabilität über lange Zeiträume zu erhalten
- Der vortrainierte Autoencoder von Stable Diffusion v1.4 komprimiert 8x8-Pixel-Patches in vier latente Kanäle
- Bei der Vorhersage von Spiel-Frames entstehen sichtbare Artefakte bei kleinen Details und insbesondere in der unteren HUD-Leiste
- Um die Bildqualität zu erhöhen, wird nur der Decoder des latenten Autoencoders mit einem MSE-Loss auf die Pixel des Ziel-Frames trainiert
1 Kommentare
Meinungen auf Hacker News
Ich bin überrascht, dass in Diffusionsmodellen offenbar mehr Ursache, Wirkung und Sequenzialität steckt, als ich erwartet hätte.
Dass Google als Kern des Diffusionsmodells SD 1.4 verwendet hat, ist auch ein guter Reminder, dass offene Modelle selbst für große Cloud-Monopolisten nützlich sind.
Beeindruckend fand ich in der Zusammenfassung: 1) dass sie einen Agenten Doom spielen ließen und so praktisch unbegrenzt Trainingsdaten erhielten, 2) dass sie Gaußsches Rauschen in die Original-Frames einfügten und belohnten, wenn die folgenden Frames wieder „korrigiert“ wurden; das war entscheidend für langfristig stabiles „Rendering“.
Besonders Letzteres ist interessant, weil es der Intuition entspricht, dem Modell Fehlerkorrektur und Stabilität beizubringen.
Ich frage mich auch, ob man dieses Modell als eine Art „Doom-Basismodell“ betrachten und es im fotorealistischen oder Raytracing-Stil feinabstimmen könnte, um ansehnlichere Renderings zu erhalten.
Der Spieler geht kaum zurück; wenn sich die Figur tatsächlich umdreht und dasselbe noch einmal sieht, hat sich vieles verändert. Besonders auffällig ist der Raum mit den grauen Wänden und dem dreieckigen Schild.
Das passt zum erwarteten Verhalten von Diffusionsmodellen. Es wurde mit Milliarden Frames Gameplay trainiert und kann auf Basis der letzten paar Frames überzeugende „nächste“ Frames erzeugen, versteht aber keine logischen Spielbeschränkungen im Sinne davon, sich die Levelstruktur zu merken.
In den Gewichten können zwar gewisse Konzepte wie Ursache und Wirkung kodiert sein, aber das Modell rendert jeweils nur einen Frame. Es ist schließlich ursprünglich ein Text-zu-Bild-Modell, kein Text-zu-Video-Modell.
Statt Text gehen der vorherige Zustand und die Frames als Eingabe für die Vorhersage des nächsten Frames hinein.
Das Rauschen wird dem vorherigen Frame hinzugefügt, bevor er in das SD-Modell gelangt; der Reinforcement-Learning-Agent hat das nicht „korrigiert“.
Denoising-Ziele sind im Machine Learning weit verbreitet und zwingen ein Vorhersagemodell intuitiv dazu, Kontext wie benachbarte Frames oder Wörter zu nutzen.
Hier hilft es, zu verhindern, dass kleine Fehler aus der Zufälligkeit des generativen Diffusionsmodells sich aufsummieren und zu autoregressivem Drift führen. In Figure 4 sieht man diesen Drift, wenn der Spieler stillsteht.
Es funktioniert nach dem Motto: „Man kann sich vorstellen, was als Nächstes passiert sein könnte.“
Ich würde es gern die ineffizienteste Videokompression der Welt nennen.
Was ich wirklich sehen möchte, ist echte Vorhersagekraft, also Vorstellungskraft. Im Abstract war davon nicht viel zu erkennen.
Das Modell wurde mit klassischen Map-Sets trainiert; was macht es, wenn man ihm ein paar Frames Gameplay aus einer unbekannten Map gibt? Wie gut kann es sich vorstellen, was als Nächstes passiert?
Dieses Paper hat vier Koautoren. Sie haben sicher ziemlich viele Ressourcen bekommen, mussten diese aber dennoch aus einem dem Forschungsbereich zugewiesenen Ressourcenpool teilen.
Selbst Google hat Gemini nur in einigen wenigen Versionen.
Dass das überhaupt funktioniert, ist schon absurd erstaunlich, und dass es sogar mit 20 fps Rendering läuft, ist ebenfalls beeindruckend.
Da der vorherige Frame und die Aktion codiert und bei jedem Schritt in das Modell eingespeist werden mussten, wirkt es wie eine Mischung aus Diffusionsmodell und rekurrentem neuronalen Netz.
Abstrakt betrachtet träumt das Modell ein Spiel, das es sehr viel gespielt hat, und die Echtzeit-Eingaben verändern den Zustand dieses Traums.
Da fragt man sich, ob Menschen nicht auch Maschinen zur Vorhersage des nächsten Moments sind, nur mit etwas mehr eingebautem Gedächtnis.
Dreht man die Logik um und betrachtet den nächsten Frame als Hypothese, die sich aus dem aktuellen Frame ergeben dürfte, ist es einfacher, die Differenz zwischen dieser „Hypothese“ und den tatsächlichen Sinneseindrücken zu verarbeiten, als den gesamten sensorischen Input.
Wie Richard Dawkins kürzlich in einem Podcast[1] sagte, sind Gene hervorragende Vorhersagemaschinen, weil Überleben von Vorhersage abhängt. Wenn man bedenkt, wie viele Ressourcen fürs Sehen aufgewendet werden, passt die Fähigkeit, visuelle Vorhersagen zu erzeugen, gut dazu.
Was sagt uns dann Aphantasie?
[1] https://podcasts.apple.com/dk/podcast/into-the-impossible-wi...
Der Lex-Fridman-Podcast „Counterintuitive Ideas About How the Brain Works“[2] ist hörenswert. Sie erklärt unter anderem, dass es am effizientesten ist, wenn das Gehirn über kontinuierliche Vorhersagen arbeitet statt über Reaktionen.
Sie ist auch eine hervorragende Wissenschaftskommunikatorin, sodass man weiter zuhören möchte.
[1] https://en.wikipedia.org/wiki/Lisa_Feldman_Barrett
[2] https://www.youtube.com/watch?v=NbdRIVCBqNI&t=1443s
Wie das im Vergleich zu einer High-End-Consumer-GPU wie der 3090 aussieht, ist nicht ganz klar, aber die INT8-TFLOPS scheinen ähnlich zu sein. Die TPU hat weniger Speicher (16 GB gegenüber 24 GB), bei den übrigen Spezifikationen bin ich mir nicht sicher.
Trotzdem passt da irgendetwas nicht. SD braucht normalerweise selbst auf einer 3090 mindestens ein paar Sekunden, um ein einzelnes hochwertiges Ergebnis zu erzeugen; hier ist es also fast um einen zweistelligen Faktor schneller. Das wirkt so, als würde die TPU die GPU bei dieser Aufgabe deutlich schlagen.
Offenbar werden Bilder mit niedriger Auflösung (320x240) erzeugt, aber es fühlt sich trotzdem viel zu schnell an.
Es fühlt sich so an, als würde man von AI ausgehen, rückwärts arbeiten und jede Form von Kognition in das Schema „Vorhersager für irgendetwas als Nächstes“ pressen.
Am Ende ist es nur eine Wiederholung der Debatte um stochastische Papageien.
Nachdem ich diesen Thread gesehen habe, halte ich es für erwähnenswert, dass dieses Paper kein System beschreibt, das Nutzereingaben in Echtzeit entgegennimmt und in die Ausgabe einfließen lässt
Allerdings fand ich, dass die Formulierung im Abstract stark nahelegt, dass genau das passiert
Es wird mit einem großen Datensatz trainiert, in dem Agenten DOOM spielen, und es werden Videobeispiele für Nutzerbewertungen bereitgestellt, aber es ist nicht so, dass Nutzer in Echtzeit Eingaben in die Simulation geben und so mit etwa 20 FPS „DOOM spielen“
Im Paper gibt es Hinweise wie „Kernfragen bleiben offen, etwa wie man ein Spiel überhaupt effektiv erstellt und wie man menschliche Eingaben am besten nutzt“ oder „das Endziel ist, menschliche Spieler mit der Simulation interagieren zu lassen“
Vor allem fehlt ein Abschnitt, der Gameplay durch Nutzer in Echtzeit beschreibt
Auch das Video oben auf https://gamengen.github.io/ beginnt mit „Dies sind Echtzeitaufnahmen von Menschen, die das Spiel spielen“
Nach diesen Aussagen zu urteilen, scheint es gegen Ende des Projekts ein spielbares System gegeben zu haben, das man Menschen vorsetzen konnte. Nur war das zum Zeitpunkt des arXiv-Preprints möglicherweise noch nicht der Fall
Dort steht: „A ist eine Menge von Tastatureingaben und Mausbewegungen …“ und „… um auf Aktionen zu konditionieren, lernen wir für jede Aktion ein Embedding A_emb“
Der Diffusionsprozess dieses Modells wird also nicht auf Wörter konditioniert, sondern auf ein Aktions-Embedding A, das aus Nutzeraktionen stammt
Anschließend wird das verrauschte Startbild in eine latente Darstellung enkodiert und als zweite Bedingung an die verrauschte latente Darstellung angehängt
Am Ende ist es ein Diffusionsmodell, das nur mit Doom-Bildern trainiert wurde und, konditioniert auf den aktuellen Doom-Frame und die Nutzeraktion, den Folge-Frame erzeugt
Insofern spielt der Nutzer tatsächlich
Dass das möglich ist, ist allerdings nicht überraschend. Im Grunde ist es eine neuronale Aufzeichnung des Spiels, aber eine coole Tech-Demo
Dort heißt es: „Beim manuellen Spielen des Modells sind einige Bereiche für beide sehr einfach, einige Bereiche für beide sehr schwierig, und in einigen Bereichen ist der Agent deutlich besser“
Vielleicht fehlt mir die Fantasie, aber mir fällt keine andere vernünftige Interpretation von „das Modell manuell spielen“ ein
https://www.youtube.com/watch?v=udPY5rQVoW0
„Playing a Neural Network's version of GTA V: GAN Theft Auto“
„Figure 1: a human player is playing DOOM on GameNGen at 20 FPS.“
Durch die mehrdeutige Formulierung im Abstract ist hier viel Verwirrung entstanden, aber das Paper ist an dieser Stelle eindeutig
Es ist ziemlich enttäuschend, dass in einem Forum mit vielen Technikexperten solche Fehlinformationen so viele Upvotes bekommen
Die Suche, Doom auf allem auszuführen, geht weiter
Technisch gesehen ist das doch das größtmögliche Anti-Doom, also das Doom mit den höchsten Hardwareanforderungen überhaupt, oder?
Wenn man die Hardwarespezifikationen auf eine lineare Achse legt, ist es lustig, dass Doom jetzt an beiden Enden steht
Also nicht im Sinne einer Portierung und Ausführung ohne die ursprüngliche Hardware- und Softwareumgebung von Doom, sondern gewissermaßen Doom ohne Doom selbst ausführen
Die nächste Stufe von Anti-Doom wäre ein Modell, das ein Modell erzeugt, das Doom-Ausgaben erzeugt
Doom-Systemanforderungen:
4 MB RAM, 12 MB Festplattenspeicher
Stable Diffusion v1 hat ein 860M-UNet und CLIP ViT-L/14 (540M), die Checkpoint-Größe beträgt 4,27 GB, vollständiges EMA 7,7 GB.
Es läuft auf TPU-v5e; die maximale Rechenleistung pro Chip liegt bei bf16 bei 197 TFLOPs und bei Int8 bei 393 TFLOPs, HBM2-Kapazität und -Bandbreite betragen 16 GB und 819 GB/s, die Verbindungsbandbreite zwischen Chips 1600 Gbit/s.
Angesichts der Geschwindigkeit ist das ziemlich beeindruckend, aber es gibt enorm viel Raum für Verbesserungen. Vom Speicherplatz her könnte es das Spiel Hunderte Male auswendig lernen, scheint es aber nicht vollständig memorisiert zu haben.
Daher gibt es bei Optimierungen sicher viel Spielraum. Da das Ziel hier allerdings Memorization ist, weiß man nicht, welche Auswirkungen solche Techniken auf bestehende Technologien hätten.
Interessant ist, dass das bedeutet: Wenn man ausreichend viel „spielt“, automatisiert und deutlich mehr Speicher und Rechenleistung einsetzt, kann man ein Spiel herauslösen.
Mich würde der Vergleich bei Kosten und Zeit interessieren, wenn man einen Engineer anstellt, der Doom per Reverse Engineering zerlegt. Unklar ist auch, wie viel Vorwissen man erlauben würde. Angesichts des vortrainierten Modells und der ViZDoom-Umgebung frage ich mich auch, ob der Doom-Quellcode in T5 enthalten war und welcher ViT-Checkpoint verwendet wurde.
Diesen Modell-Checkpoint würde ich unbedingt gerne sehen. Wenn Leute ihn auseinandernehmen, finden sie vermutlich wirklich interessante Dinge.
https://www.reddit.com/r/gaming/comments/a4yi5t/original_doo...
https://huggingface.co/CompVis/stable-diffusion-v-1-4-origin...
https://cloud.google.com/tpu/docs/v5e
https://github.com/Farama-Foundation/ViZDoom
https://zdoom.org/index
Im Vergleich zum ursprünglichen Spiel sind die Rechenkosten absurd, und es stimmt auch, dass grundlegende Dinge wie Vorberechnung oder Speicherung fehlen.
Aber man kann davon ausgehen, dass solche Dinge am Rand dieser Entdeckung gelöst werden, sich mit der Zeit von selbst verbessern oder als Flaschenhals weniger wichtig werden.
Der eigentliche Durchbruch ist, dass sich solche kontextbewussten Frame-Sequenzen modellieren lassen, ohne sie explizit zu codieren. Das gilt sowohl aus reiner Spieleperspektive als auch aus Sicht allgemeiner Simulationen.
Die größere Bedeutung ist, dass man Spiele aus realen Videos erzeugen kann.
Wenn man einen perfekten Flugsimulator braucht, muss man ein Jahr lang in jedes Passagierflugzeug-Cockpit eine GoPro hängen.
Es macht immer Spaß, bei solchen Beiträgen tote Kommentare zu lesen. Ich mag es, darauf hinzuweisen, wie sinnlos das ist.
Manche Leute sollten lernen, Dinge einfach aus Freude am Machen zu bauen.
Ist das nützlich? Eigentlich kaum. Ist es interessant? Auf jeden Fall.
Nicht alles muss für Profit gebaut werden. Es muss auch nicht gebaut werden, um die Welt besser zu machen.
Manchmal können Lernen, Herausforderung und das Ausloten von Möglichkeiten der Zweck sein.
Zeit, die man mit Spaß verbringt, ist niemals verschwendet. Es wird Menschen geben, die auf dem Sterbebett bereuen, nicht mehr Spaß gehabt zu haben.
In der Aussage „Das ist wirklich großartig“ steckt die Andeutung, man glaube, in naher Zukunft jede Software durch AI-Modelle ersetzen und damit jede vorstellbare Videospielerfahrung erschaffen zu können.
Realistisch betrachtet ist es die ineffizienteste und unzuverlässigste Form von Doom, die bisher gebaut wurde. Sie verbraucht buchstäblich millionenfach mehr Rechenleistung als frühe x86-PCs, die Doom in Echtzeit rendern und spielbar machen konnten.
Natürlich ist es ein unterhaltsames Kunststück.
Ein Stück weit ist das unvermeidlich. Die Lebenshaltungskosten steigen weiter, und Unternehmer werden wie Rockstars romantisiert, was zu dieser Hustle-Denkweise führt.
Aber ich erinnere mich an die Zeit, als Artikel über die Möglichkeit von „Internetradio“ erschienen. Statt wie früher Funkwellen in die Luft zu senden, auf die Tausende Radios eingestellt waren, schickte ein Server riesige Mengen an Paketen über extrem lange Kupferleitungen an Tausende Endpunkte.
Dass die Endpunkte sogar ACK-Pakete an den armen Server zurückschickten, um die Verbindung aufrechtzuerhalten, wirkte wie eine Verschwendung von Rechenleistung, Kabeln und Energie.
Und heute bingen wir Netflix-Filme über genau solche Kupferleitungen.
Ich sage nicht, dass Spiele durch Diffusionsmodelle ersetzt werden, die das nächste Bild auf Basis von Nutzereingaben erträumen, aber eine Variante davon könnte zu interaktiver Kunstschaffung oder einer neuen Form von Entertainment werden.
Beeindruckend, aber schwer zuzustimmen. Diffusionsmodelle sind keine Game Engines
Eine Game Engine ist die Komponente, die ein Spiel entlang der Zeitachse vorantreibt. Sie ist also vergleichbar mit einem Automotor, und daher stammt auch der Name
Ein Motor braucht kein fertiges Auto oder eine Straße, auf der er fahren kann, um Arbeit zu leisten
Das oben Gezeigte ist eher eine dynamische, interaktive Replikation dessen, was passiert, wenn man ein Auto auf eine vorgegebene Straße setzt, und dafür muss man mit einem funktionierenden Fahrzeug eine Million Testfahrten machen
Eine Engine müsste auch offroad funktionieren
Statt im Präsens zu sagen: „Es braucht ein funktionierendes Auto auf der Straße, um die Aufgabe zu erledigen“, wäre die Vergangenheitsform passender: „Es brauchte das, um darauf trainiert zu werden, diese Aufgabe zu erledigen“
Es ist auch nicht klar, warum eine Game Engine keine Game Engine mehr sein soll, nur weil sie Konzepte nutzt, die daraus gewonnen wurden, wie andere Engines funktionieren
Betrachtet man Diffusionsmodelle allgemein, gibt es keinen ersichtlichen Grund anzunehmen, dass dieser Ansatz außerhalb der trainierten „Teststrecken“ nicht funktionieren könnte — so wie Diffusionsmodelle normalerweise nicht nur exakt dieselben Bilder wie ihre Trainingsbilder erzeugen, sondern interpolieren oder einzelne Konzepte anwenden können, um neue Outputs zu erzeugen
In gewissem Sinne ist es eine simulierte Game Engine, die mit Daten aus einer echten Game Engine trainiert wurde
Aber wenn eine funktionierende simulierte Game Engine ein „Spiel vorantreiben“ kann, dann ist sie meiner Meinung nach selbst eine Game Engine. Wie das erreicht wird, ist nicht wichtig
Auf der einen Seite haben Menschen den Content erstellt, auf der anderen wird bestehender Spiel-Content imitiert, aber den Spielern ist das egal
Man kann sich vorstellen, dass eine solche „generative Game Engine“ auch offroad fahren kann. Sie extrapoliert, was passieren würde, wenn man an einen Ort kommt, den sie noch nicht gesehen hat
Vielleicht ist die Extrapolationsfähigkeit solcher Modelle sogar besser als die traditioneller Game Engines. Wenn man in einer normalen Game Engine versehentlich durch eine Wand geht, wird der Bildschirm leer, aber dieses Modell kann beim Weitergehen etwas erfinden
Im SD-Modell ist Text Conditioning nicht enthalten, weil es entfernt wurde, aber in naher Zukunft kann man sich vorstellen, allein mit Text-Prompts interessante neue Spiele zu erstellen
Um zu lernen, wie DOOM aussieht und funktioniert, musste Reinforcement Learning eingesetzt werden, aber das bedeutet nicht zwangsläufig ein Henne-Ei-Problem
Ähnlich wie ein LLM neue Geschichten schreiben kann, obwohl es nur mit bestehenden Texten trainiert wurde
Eine der größten Herausforderungen dieses Ansatzes werden wohl Open-World-Spiele sein, bei denen die Zahl möglicher Zustände praktisch unendlich ist
Auch das Paper sagt, dass es schwierig war, den Reinforcement-Learning-Agenten dazu zu bringen, jeden Winkel von DOOM vollständig zu erkunden
Factorio oder Dwarf Fortress werden wohl nicht so bald simuliert werden. Vermutlich
Vielleicht wäre sie sogar kleiner als der Quellcode selbst. Jemand aus diesem Fachgebiet könnte mich hier vermutlich korrigieren
An diesem Punkt würde man das Spiel im Grunde „rendern“, indem man den Quellcode im Latent Space interpoliert. Es wäre, als hätte man einen ganzen Latent-Space-Computer mit Engine, Assets, Texturen und Software-Renderer
Mit einem ausreichend leistungsfähigen Computer könnte man sich auch eine Latent-Space-Interpolation zwischen Spielen wie Factorio und TF2 vorstellen. Und man könnte diesen Latent Space anpassen, indem man ihn auf gewünschte Gameplay-Aspekte konditioniert
Eine solche Zukunft kommt in Teilen der Pipeline, etwa der letzten Rendering-Stufe, sehr schnell. DLSS ist zum Beispiel bereits kommerzialisiert
Vielleicht kehren Nvidias Umsätze irgendwann wieder zum Gaming zurück, wenn alle im neuronalen Metaverse festgeschraubt sind
Dass sie DOOM gewählt haben, gefällt mir wirklich
Dabei würde man die ganze Arbeit in die Spielmechanik stecken und nicht in die visuelle Qualität
Ich erwarte, dass so ein Ansatz besser darin wäre, visuelle Inkonsistenzen zu reduzieren, etwa dass sich ein rotes Monster in einen blauen Verbündeten verwandelt, wenn man den Kopf wegdreht und wieder hinschaut
Man kann auch mit einem vergleichsweise einfachen Plattformspiel wie Mario anfangen
Wenn man etwa 300 Seiten geschrieben hat und erst ungefähr die Hälfte erklärt hat, wird man verstehen, warum das Wunschdenken ist
Vielleicht kann eine einzelne Person im Gespräch mit einem Modell etwas erschaffen, das dem Niveau heutiger AAA-Titel entspricht
Man stelle sich den 2D-Sidescroller-Boom auf Steam vor, nur als immersive fotorealistische 3D-Spiele mit surrealer Physik (Wasserströmungen, sich ausbreitendes Feuer, Tornados) und vollständiger Möglichkeit zur Verformung und Konstruktion
Das Modell wäre mit realen Videos vortrainiert, und das Spiel wäre nur ein „Stil“, der die Prior-Verteilung für Aussehen, Setting und Geschichte ein wenig anpasst
Wenn man das Spiel bereits gebaut hat, ist das Diffusionsmodell dann eine Game Engine? Das Training des Modells braucht das Spiel. Ist das nicht Henne und Ei?
Man könnte eine nicht echtzeitfähige Version der Game Engine bauen und das neuronale Netz als Echtzeit-Approximation verwenden
Man könnte auch HUD-ähnliche Elemente in real gefilmtes Videomaterial hineinbearbeiten und das neuronale Netz darauf trainieren, nicht Doom, sondern die Realität zu simulieren
Dieses Paper verwendete 900 Millionen Frames, was bei 30 fps etwa einem Jahr Videomaterial entsprechen dürfte. Algorithmische Verbesserungen könnten die Trainingsanforderungen senken
Ein Jahr Videomaterial ist in der Praxis auch gar nicht so viel. Man könnte zum Beispiel 500 Leute rekrutieren, ihnen GoPros, Beschleunigungsmesser und Gyroskope an Kopf und Paintball-Gewehre montieren und sie ein Wochenende lang Paintball spielen lassen, um ein Jahr Videomaterial zu erhalten
Andere Modelle darüber würden dann nur noch Details finetunen, um Spiele anzupassen
Diffusionsmodelle können keine Game Engines sein. Denn eine Game Engine muss neue Spiele erstellen und die Regeln bestehender Spiele in Echtzeit ändern können.
Sie muss sogar Regeln ändern können, die auf dem Bildschirm nicht sichtbar sind.
Solche Tools sind interessant, aber wie bei allem AI-Hype braucht es einen Disclaimer.
Dieses Tool hat kein Spiel erstellt, sondern lediglich von Menschen erstellte Spiele gesampelt und daraus Frames sowie das äußere Erscheinungsbild von Spielmechaniken erzeugt.
„Nur“ erzeugt? Ich verstehe, dass es mechanisch gesehen simpel sein kann, aber die Tatsache, dass eine so reichhaltige bedingte Verteilung komprimiert wurde, wirkt überhaupt nicht simpel.
Wenn man sie mit mehreren Spielen trainiert und deutlich mehr Informationen zu jedem Spiel einbettet, könnte es möglich werden, einen Prompt anzugeben, der ein Spiel beschreibt, und es dann zu spielen.
So könnte man die Konsistenzprobleme beheben und trotzdem praktische Vorteile erzielen.