#146 Warum ist Doom so faszinierend für die Software-Entwicklung?

Doom - Das Spiel und warum es ein Engineering Meisterwerk ist

Das Spiel Doom beschäftigt viele Software-Entwickler*innen auch noch 31 Jahren nach seiner Veröffentlichung im Jahre 1993. Die Frage “Can it run Doom?” ist allgegenwärtig. Es ist eine Art Sport geworden, das Spiel auf jede Art von Device zu portieren. Doom läuft inzwischen auf einem John Deere Trecker, einem Satelliten und einem digitalen Schwangerschaftstest.

Doch was macht dieses Spiel so interessant?

Warum wird genau dieses Spiel für die Portierung genutzt?

Welche bahnbrechenden Implementierungsdetails haben John Carmack, John Romero und das Team verbaut?

Das war meine Ausgangsfrage. Das Resultat? Ein tiefes Loch voller Wow und WTF-Momente. Und diese Podcast-Episode. Es geht um Zufallszahlengeneratoren, Grafik-Engines, Doom-Fun-Facts, Doom Forks und wie du deinen eigenen Doom-Port erstellen kannst.

Bonus: Ist es eine Herausforderung ein Device zu finden, das Doom nicht laufen lassen kann?

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Die Faszination um das Spiel Doom

(00:04:20) Werbung/Info

(00:05:20) Was ist Doom?

(00:09:21) Was ist Doom technisch?

(00:12:15) Architektur: Trennung von Engine und Daten

(00:14:58) Determinismus und der Zufall

(00:21:07) Aufzeichnung der Benutzer-Eingaben und Multiplayer

(00:30:19) Grafik-Engine: Visible Surface Determination, Raytracing und Binary Space Partitioning

(00:45:30) Doom-Ports und die Weiterentwicklung des Spiels

(00:53:12) Can it run Doom?

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Buy us a coffee: https://engineeringkiosk.dev/kaffee
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Andy Grunwald (00:00:04 - 00:01:06)

Das Spiel Doom beschäftigt viele Softwareentwickler innen auch noch ein und dreiig Jahre nach seiner Veröffentlichung im Jahre 1903 und neunzigste. Die Frage can it run Doom? Ist allgegenwärtig. Es ist eine Art Sport geworden, das Spiel auf jede Art von Device zu portieren. Doom läuft inzwischen auf einem John deere Tracker, einem Satelliten und auf einem digitalen Schwangerschaftstest Ÿousand. Doch was macht dieses Spiel so interessant? Warum wird genau dieses Spiel für die Portierung genutzt? Welche bahnbrechenden Implementierungsdetails haben John Carmack, John Romero und das Team verbaut? Das war meine Ausgangsfrage. Das ein tiefes Loch voller Wow und Wtf Momente und natürlich diese Podcast Episode. Es geht um Zufallszahlengeneratoren, Grafikengines, Doom Fun Facts, Doom Forks und wie du deinen eigenen Doom Port erstellen kannst. Zieh dich warm an, es geht los. Viel Spaß. Lieber Wolfgang, in welchem Jahr wurdest du geboren?

Wolfi Gassler (00:01:06 - 00:01:10)

Du wirst mir jetzt nur outen, vor allem wie alt ich bin, aber 1902.

Andy Grunwald (00:01:10 - 00:01:34)

Und achtzigste, das trifft sich sehr gut. Dann warst du zu dem Ereignis, über das wir heute unter anderem sprechen, 11 Jahre alt. Und das müsste dann ungefähr die Zeit gewesen sein, wo du mit dem Thema auch in Kontakt gekommen bist. Denn es ist wieder passiert. Vor kurzem bin ich ja in einen Rabbit Hole gefallen, als ich mich mit Thema Zeit in der Informatik, Schaltsekunden und Co. Beschäftigt habe. Es ist leider wieder passiert, doch diesmal nicht mit der Zeit, sondern mit einem ganz anderen Thema.

Wolfi Gassler (00:01:34 - 00:01:35)

Und zwar welchem?

Andy Grunwald (00:01:35 - 00:02:22)

Mit einem Computerspiel. Und zwar mit Doom. Und da ist mir wirklich wieder klar geworden, dass Hacker, Nerds und Geeks einfach grandios und faszinierend sind. Denn speziell im Bereich Doom gibt es einfach unendlich viele Projekte, die einfach gemacht werden, weil es geht. Und ich finde es so, so unglaublich faszinierend viel Zeit da investiert wird. Denn man sieht an diesen Projekten, dass das auf Basis reiner Motivation, reiner Passion und wirklich reinem Feuer in den Augen gemacht wird. Und wie bin ich auf das Thema gekommen? Ich bin im Internet gesurft und irgendeine Webseite hat mir ein Capture angezeigt. Und in diesem Capture kam ein kleines Doom Fenster, wo ich per Webassembly vier Monster töten musste, damit ich weiter konnte. Das hat mich zu der weiteren Frage geführt, warum kann eigentlich Doom überall laufen?

Wolfi Gassler (00:02:22 - 00:02:27)

Moment, war das war das wirklich ein das originale Doom oder irgendwie ein nachgestelltes Doom?

Andy Grunwald (00:02:27 - 00:02:36)

Ich kann dir jetzt nicht sagen, ob ich in dem Capture das ganze Level hätte spielen können. Ich musste auf jeden Fall vier Monster töten, damit ich beweise, dass ich ein Mensch bin und dann weiterkomme.

Wolfi Gassler (00:02:36 - 00:02:42)

Aber es war wirklich das originale Doom Spiel und jetzt kein irgendwie killenbar Monster irgendwie neues Game.

Andy Grunwald (00:02:42 - 00:02:43)

Genau.

Wolfi Gassler (00:02:43 - 00:02:57)

Woher weißt du das überhaupt? Du bist viel zu jung für Doom, oder? Wir hatten ja die Counter Strike Episode, Episode 42, wo du erklärt hast, wie du als kleines Kind da quasi Counter Strike gespielt hast. Doom ist ja viel älter. Doom kennst du ja gar nicht, oder? Hast du mal Doom gespielt überhaupt?

Andy Grunwald (00:02:57 - 00:02:59)

Ich habe auch Doom gespielt, natürlich.

Wolfi Gassler (00:02:59 - 00:03:00)

Als Jugendlicher?

Andy Grunwald (00:03:00 - 00:03:01)

Als Jugendlicher?

Wolfi Gassler (00:03:01 - 00:03:04)

So als Retro Spiel, oder wie?

Andy Grunwald (00:03:04 - 00:03:13)

Nee, nee, nee, nee. Also damals war das Retro weiß ich gerade nicht mehr. Also es war auf jeden Fall verboten in Deutschland. Deswegen hatte das so ein bisschen was Radikales. Ja, für mich als rebellierender Jugendlicher.

Wolfi Gassler (00:03:14 - 00:03:20)

Ja, aber das war Wolfenstein d auch. Das war ja übrigens zweitausendein mein Einstieg und macht dir viel mehr Spaß als Österreicher bei Nazis erschießen.

Andy Grunwald (00:03:20 - 00:03:31)

Das habe ich aber auch schon mal gespielt. Und ja, es hat auch als deutscher Spaß gemacht, Nazis zu erschießen. Auf jeden Fall bin ich dann dieses rabbit Hole darunter und ich hab mich gefragt, warum kann Doom überall laufen? Beziehungsweise warum.

Wolfi Gassler (00:03:31 - 00:03:51)

Wir haben jetzt ein Problem, wenn wir verherrlichen, wenn man irgendwelchen erschießt. Ich glaube, das müssen wir jetzt zurücknehmen. Aber das Spiel war trotzdem lustig, obwohl ich eigentlich nie so auf Ego shooter gestanden bin. Also ich war eher immer so auf Strategiespiele und Adventures und so. Also wo man den Kopf anstrengen muss und nicht nur die zwei Finger. Aber da sieht man schon die Prioritäten bei uns. Ich war so mehr auf Monkey Island.

Andy Grunwald (00:03:51 - 00:03:55)

Vielleicht überzeuge ich dich ja noch, warum man Doom auch den Kopf anstrengen zumindest.

Wolfi Gassler (00:03:55 - 00:03:57)

Auf der technischen Seite im Hintergrund.

Andy Grunwald (00:03:57 - 00:04:16)

Ja, die ganze Thematik hat mich auf jeden Fall zu der Keyfrage gebracht, warum kann Doom überall laufen bzw. Warum wird es immer dafür genutzt? Und wenn ich mal zwei Schritte zurück was macht Doom eigentlich so relevant und interessant für die Softwareentwicklungswelt? Und da habe ich gedacht, Ÿousand, wir machen mal eine Episode über Doom das Spiel und warum es ein Engineering Meisterwerk ist. Bist du bereit?

Wolfi Gassler (00:04:16 - 00:04:20)

Bin bereit, dich zu challengen, dass es ein Meisterwerk war. Aber auf geht's.

Andy Grunwald (00:04:20 - 00:04:29)

Da du die Lebenserfahrung hast, erklär doch mal bitte unseren Hörerinnen und Hörern, was Doom eigentlich ist. Für die Leute, die es vielleicht nicht kennen, für Leute, die nach 2000 geboren sind.

Wolfi Gassler (00:04:29 - 00:05:01)

Zwei Sätze hast du ja, es war so eigentlich der erste Ego Shooter, der so richtig groß geworden ist, also wo man in Ego Perspektive in dem Fall Monster damals bekämpfen musste und hatte mehrere Waffen. Ganz klassisch wie jeder Ego Shooter. Und die Story kann ich mich eigentlich nicht mehr daran erinnern. Könntest du die jetzt auf Anhieb noch erklären oder hast du das nur in deinem Research rausgefunden? Die Frage ist sowieso immer, ob man da eine Story braucht. Immer. Aber ich kenn von keinem Ego Shooter eigentlich die Story im Hintergrund, die da gelaufen ist, zu erzählen.

Andy Grunwald (00:05:01 - 00:05:32)

Doch, von Half Life, die könnte ich dir auf jeden Fall noch erzählen, aber nie gespielt. Später bei Doom muss ich die researchen. Also wie du sagtest, es ist ein Spiel, 1993 released von id Software im Computerspiel und eine Art Ego Shooter. Und der Spielablauf war wie du selbst steuerst einen Soldaten, den sogenannten Doom Guy, der nach einem gescheiterten Forschungsexperiment zunächst auf den Marsmonden rumläuft und dann schließlich in der Hölle einzelne Monster bekämpfen muss, die halt Dämonen und Zombies sind. Also eigentlich rennt man die ganze Zeit rum und knallt irgendwelche Monster ab.

Wolfi Gassler (00:05:32 - 00:05:53)

Ich kann mich nur erinnern, dass da immer viel Feuer rundherum war und so Geschichten, zumindest ein paar Pixel, die Feuer dargestellt haben. Das war ja schon eine andere Zeit. Muss passiert auch Wolfenstein D, das übrigens ja auch von id Software ist, das ein bisschen früher war. Wenn man sich das heutzutage anschaut und man sieht den ganzen Screen auf den original Pixel anzahlen, dann schaut es ja wirklich extrem aus.

Andy Grunwald (00:05:53 - 00:06:29)

Du hattest schon IT Software genannt. Die Firma sollte vielen Software Engineers ein Begriff sein, denn id Software selbst hat Computerspiele wie die Commander Keen Reihe, Wolfenstein d oder Quake released und dort haben unter anderem auch John Carmack und John Romero gearbeitet. Wenn man die beiden Namen mal googelt, würde ich fast sagen Software Engineering Legenden. Das Spiel selbst wurde in Deutschland leider von 94 bis 2011 indiziert. Das bedeutet eigentlich offiziell dürftet ihr das alles gar nicht gespielt haben. Dennoch denke ich, dass ziemlich viele unserer Hörerinnen und Hörer schon mal Berührung mit Doom hatten.

Wolfi Gassler (00:06:29 - 00:06:55)

Ich glaube ja, dass eure Liste da sehr viel Anteil dran hat. Also ich glaube, das war ja fast so ein Ziel damals, auf diese indizierte Liste zu kommen, weil damit war das in den Medien und es hat geheißen, es ist verboten und alle wollten es noch mehr. Und wir Österreicher waren natürlich auch schlau, wir haben ja so einen Index nicht. Und unsere ganzen Game Firmen haben dann schön euch nach Deutschland die ganzen Games verkauft, weil bei uns war das alles legal und dann hat man sich das schön online bestellen können. Die Spielebox.

Andy Grunwald (00:06:55 - 00:07:37)

Es gibt natürlich von Doom etliche Teile, doch wir sprechen jetzt hier nur über das originale Doom, was 1993 rausgekommen ist. Alle anderen Teile wie Doom Eternal und so weiter lassen wir mal einfach weg. Und Doom selbst, und das ist jetzt das Faszinierende, wird als Meilenstein im Bereich der Computerspiele gefeiert. Auf der einen Seite war es der erste richtig kommerzielle, erfolgreiche First Person Ego Shooter. Wolfenstein D war früher, aber ging halt nicht so durch die Decke. Aber jetzt kommen wir mal zu dem interessanten Teil, warum das eigentlich, warum Doom so speziell ist. Auf der einen Seite gilt es als den ersten Ÿousand richtig kommerziell erfolgreichen First Person Ego Shooter. Auf der anderen Seite wird es als D Spiel gehandelt, obwohl es offiziell als d Spiel.

Wolfi Gassler (00:07:37 - 00:07:39)

Was ist denn D bitte?

Andy Grunwald (00:07:39 - 00:08:19)

D kommen wir gleich zu, wenn ich dir das mit der Grafik Engine erkläre, aber da sind wir gleich im technischen Teil. Dann 1993, du konntest mit Doom sogar Multiplayer im LAN zocken mit vier Leuten. Das war revolutionär damals. Und Fun Fact, durch das Spiel Doom hat einer der Entwickler den Begriff Deathmatch geprägt, weil sich Leute natürlich einen auf die Mütze gehauen haben. Und Achtung, den Begriff frag. Wenn man jemanden killt, fragt man jemanden. Leider wurde dieser Begriff aus dem Vietnamkrieg übernommen, weil der wurde da anscheinend auch öfters mal genutzt. Und ich glaube, Doom auf Basis meiner Recherche ist heute immer noch top aktuell im Bereich Speedruns. Hast du schon mal einen Speedrun gesehen?

Wolfi Gassler (00:08:19 - 00:08:21)

Ja, beim Klettern. Ist jetzt olympisch geworden.

Andy Grunwald (00:08:21 - 00:08:44)

Ich glaube, eSports Speedruns sind auch olympisch, mehr oder weniger. Aber es ist genau das gleiche. Ÿousand. Wie schnell kann man Doom durchspielen? Oder beziehungsweise ein Level? Und das geht teilweise runter bis auf 8 s. Also verlinken wir mal ein paar Links in den Show Notes. Aber Software Engineering. Was macht Doom so interessant für Software Engineers? Was ist denn Doom technisch? Kommen wir endlich mal zu den spannenden Sachen.

Wolfi Gassler (00:08:44 - 00:08:47)

In welcher Programmiersprache ist es denn geschrieben? Fangen wir mal ganz unten.

Andy Grunwald (00:08:47 - 00:08:54)

1993 gab es noch kein Rust, deswegen muss ich dich da leider enttäuschen. Es ist schön in 90 C geschrieben.

Wolfi Gassler (00:08:54 - 00:09:06)

Es wird wahrscheinlich heutzutage immer noch in C geschrieben, sowas. Aber gut, vielleicht dann zwei und neunzigste oder ist der aktuelle Standard, der so üblicherweise verwendet wird? Egal. Okay, klassisches C. Ja, ich glaube, heute.

Andy Grunwald (00:09:06 - 00:09:16)

Wird man das vielleicht als unsicheres c mit String Copy und so bezeichnen, aber da kommen wir gleich auch noch mal zu. Dann klassischerweise Single Threaded. Macht die ganze Thematik sehr einfach zu verstehen.

Wolfi Gassler (00:09:16 - 00:09:27)

Doom selbst ist deterministisch ich meine, single threaded ist natürlich auch eigentlich klar, oder? Damals hat es keine Prozessoren gegeben, die in irgendeiner Form sinnvoll das parallel abarbeiten haben können.

Andy Grunwald (00:09:27 - 00:09:32)

Ich musste gerade erst mal googeln, aber Ÿousand, laut Google kam der erste Dual Core 2007 raus.

Wolfi Gassler (00:09:33 - 00:09:47)

Und ich glaube, die Programmierung war damals auch einfach Multiprozess Programmierung, wenn man wirklich parallel, quasi pseudo parallel irgendwas machen wollte. Aber da verlassen wir jetzt auch, weil damals, wie ich so alt war, da war ich eher auf der Gaming Seite und nicht auf der Programmierseite.

Andy Grunwald (00:09:47 - 00:09:57)

Ich habe es auf jeden Fall mit reingenommen, weil heutzutage sollte man das erwähnen und das führt auch zum Erfolg. Und jetzt kommen noch zwei Punkte, die maßgeblich dafür verantwortlich sind, warum wir immer noch im Jahr 2024 über Doom sprechen.

Wolfi Gassler (00:09:58 - 00:10:02)

Und warum du in deinem Capture Doom dann spielen darfst, oder?

Andy Grunwald (00:10:02 - 00:10:33)

Auf der einen Seite, Doom ist deterministisch. Was das heißt, kommen wir gleich zu. Und Doom ist inzwischen voll open source. Es ist seit 2024 offiziell vom Lizenzgeber, was nicht mehr id Software ist, unter der GPL V released worden. Wir können uns das alle ansehen. Es gibt eine Kopie auf GitHub, verlinken wir natürlich auch in den Show Notes. Falls ihr also heute Abend im Bett liegt und sagt, ich habe mein Buch gleich durch, macht doch mal den Doom Source Code auf, scrollt da mal durch. Ich warne euch, relativ wenig Kommentare, aber sehr sauber geschrieben. Kriegt man schon gelesen.

Wolfi Gassler (00:10:33 - 00:10:36)

Was schätzt du, wie viel Zeilen Code Doom eins hat?

Andy Grunwald (00:10:37 - 00:10:39)

Ich weiß es nicht. Ja, schätze mal 1800.

Wolfi Gassler (00:10:39 - 00:10:51)

1800? Okay, das wäre ein bisschen gar wenig. Also ich habe jetzt unterschiedliche Quellen gefunden, aber ein paar sagen. Ein paar sagen, je nachdem, was man auch noch mitzählt, aber so in der Größenordnung.

Andy Grunwald (00:10:51 - 00:10:54)

Aber da merkt man, dass du wieder Berater bist. Wen interessiert die Lines of code?

Wolfi Gassler (00:10:55 - 00:11:15)

Ja, es ist schon spannend, wie viele Zeilen Code man so grössenordnungstechnisch braucht, um so ein Spiel eigentlich zu programmieren. Ich hätte nämlich ehrlich gesagt auch weniger geschätzt. Also 1800 vielleicht jetzt nicht gerade, aber irgendwo weniger, weil man sich überlegt, wie hart es damals auch war, Zeilen zu schreiben. Also es ist ja nicht irgendwie Java, was Server bose ist, sondern das ist ja schon hardcore, was man da schreibt.

Andy Grunwald (00:11:15 - 00:11:15)

Zweitausendein.

Wolfi Gassler (00:11:15 - 00:11:23)

Aber wenn man jetzt diese 150 Zeilen Code, Zeilen Code nicht ansehen will, was ist denn jetzt das Spezielle an diesen Codezeilen?

Andy Grunwald (00:11:23 - 00:12:48)

Ich bin mir gar nicht sicher, ob du das jetzt wirklich so rauslesen kannst, denn bzw. Wenn du den Code liest, dir das sofort auffällt. Wenn du dir heute Softwareentwicklung anschaust, dann sagt man ja eigentlich man soll alles voneinander entkoppeln und alles soll wiederverwendbar werden und so weiter und so fort. Aber 1993 war das vielleicht jetzt noch nicht das wichtigste Konzept der Softwareentwicklung. Doom jedoch hat es 1993 bereits gemacht. Und zwar was die gemacht haben, die haben das ganze Spiel im Hinblick auf Modifikationen der Spielinhalte, also Texturen, Level, Musik und so weiter entworfen. Die haben die Doom Engine selbst von den Spielinhalten getrennt und in mehrere Dateien ausgelagert. Die Doom Engine war eigentlich die executable, auf Windows würde man sagen Doom Exe. Und die Spielinhalte waren in sogenannten WAD Dateien, Watt Dateien. Wad steht für Where all the data ist mega gut. Und das bedeutet natürlich, dass du und ich, Wolfgang, wir können jetzt Level modden und Co. Und können uns diese Watt Dateien hin und her schicken. Die packe ich einfach in meinen Folder und die Engine lädt dann einfach diese Watt Datei. Und heutzutage wird man sagen, ja, das macht doch jedes Spiel. Counter Strike, da gibt es auch ein level Editor. Ja, aber wir reden jetzt hier von vor ein und dreiig Jahren. Und das hat schon irgendwie einen offenen Zugang zu den Spielressourcen ermöglicht. Das bedeutet, die ganze Community hat irgendwie Levels, die Benutzertools geschrieben, Level editoren geschrieben und hat eigentlich die Langlebigkeit des Spiels sichergestellt.

Wolfi Gassler (00:12:48 - 00:13:00)

Ich möchte darauf hinweisen, dass Monkey Island, beziehungsweise die Macher davon, schon 1987 solche Engines entwickelt haben, wo man das komplett trennen kann von dem Spiel und skripten kann.

Andy Grunwald (00:13:00 - 00:13:03)

Jetzt ist die Frage, wofür gibt es mehr Level? Für Monkey Island oder für Doom?

Wolfi Gassler (00:13:03 - 00:13:16)

Ja, ich glaube Monkey Island kann man gar nichts verändern in dem Sinne, aber es waren die die Methoden das ganze zu trennen, also die Engine und den eigentlichen Spielablauf, die gab es schon früher, aber im Ego shooter Bereich war das natürlich eine Neuerung.

Andy Grunwald (00:13:16 - 00:13:43)

Bei Doom wurde es gemacht und Achtung, es wird immer noch gemacht. Fun der kreativste level Editor ist ein Staubsaugroboter. Und zwar hat jemand Software für einen sogenannten Roomba geschrieben. Wenn der Roomba fährt, werden die Punkte aufgezeichnet, also der Fahrtweg. Diese Punkte übersetzt der Entwickler in eine Doom Map und lässt dadurch automatisch auf Basis der existierenden Doom Texturen eine Doomkarte erstellen.

Wolfi Gassler (00:13:43 - 00:13:46)

Das heißt, du kannst dann Doom in deinem Wohnzimmer spielen.

Andy Grunwald (00:13:46 - 00:13:58)

Ja, also natürlich jetzt ohne Couch und so weiter, schon mit Flammen und allem drum und dran, weil die Texturen natürlich von Dunkeln, aber die Struktur schon. Verlinken wir auch in den Shownotes. Meines Erachtens nach einer der kreativsten Art und Weisen, wie man Doom Levels erstellt.

Wolfi Gassler (00:13:58 - 00:14:15)

Wie nerdig kann man sein? Aber jetzt hast du bei deiner Einleitung schon kurz erwähnt, dass Doom deterministisch ist. Ist es nicht immer, wenn man Software programmiert, okay, die meiste Software ist weniger deterministisch, wenn man sich anschaut, wie sie sich dann verhält. Aber eigentlich, wenn man ja was programmiert, ist es doch immer deterministisch.

Andy Grunwald (00:14:15 - 00:14:22)

Wenn Software grundlegend deterministisch wäre, warum sind reproducible builds im Security Bereich immer noch ein Problem oder eine Herausforderung?

Wolfi Gassler (00:14:22 - 00:14:27)

Wegen den Zeiteneffekten. Wenn man irgendwie eine Zeit mit reinnimmt, eine aktuelle Zeit, ist man schon nicht mehr Determinist.

Andy Grunwald (00:14:27 - 00:14:36)

So sieht es aus. Aber Wolfgang, hol doch mal alle ab. Was heißt Determinismus in der Softwarewelt, beziehungsweise Determinismus generell vielleicht in der Mathematik?

Wolfi Gassler (00:14:36 - 00:15:20)

Ja, wenn du die gleiche Eingabe hast, bekommst du immer dieselbe Ausgabe. Das heißt, du kannst dich darauf verlassen, wenn du in irgendeine Funktion mit einem Parameter x reingibst, ist der Return Wert immer dasselbe. Das heißt, es wird z.B. nicht die aktuelle Zeit mit reingenommen in die Berechnung oder das aktuelle Wetter, weil das wäre dann nicht mehr deterministisch, weil jedes Mal, wenn du die Funktion ausführst, bekommst du einen anderen Retourwert. Jetzt ist meine Frage aber, wenn du sagst, okay, Doom war deterministisch, wie hat es dazu beigetragen, dass es so erfolgreich ist und jetzt auch noch verwendet wird in deinem Capture? Weil wenn da ein random Number Generator drin wäre, der dann nicht mehr deterministisch ist, weil er ja auf der Zeit auch basiert, wo wäre das Problem? Könnte man ja trotzdem in einem Capture rennen lassen.

Andy Grunwald (00:15:20 - 00:15:29)

Also innerhalb von Doom ist so eine Art random number generator, da kommen wir jetzt gleich zu. Deine Frage ist aber, welchen Anteil hat der Determinismus von Doom am Erfolg?

Wolfi Gassler (00:15:29 - 00:15:36)

Immer noch während dem Erfolg? Ja, genau. Oder dass man eben auf irgendwelche Uhren das Ganze laufen lässt oder keine Ahnung, kleine Displays.

Andy Grunwald (00:15:36 - 00:16:06)

Meines Erachtens nach relativ einfach, und zwar auf Basis der Verifikation. Und zwar, weil du immer dieselben Eingabeparameter reingibst, kommt immer dasselbe raus. Du portierst das jetzt auf meine Smartwatch und ich kann eins zu eins verifizieren, dass das komplette Spiel funktioniert, indem ich dieselben Eingabeparameter mache, wie auf meinem MS DOS System, wo das Spiel ursprünglich für released wurde. Und das macht es natürlich dann zur Verifikation sehr einfach, weil man kann sagen, ja, das ganze Spiel läuft auf meiner Smartwatch.

Wolfi Gassler (00:16:06 - 00:16:15)

Das heißt, eigentlich wird das Testen erleichtert und die Portierung dadurch wahrscheinlich auch, weil man eben nicht spielen muss, um Bugs zu finden in der Portierung. Sondern das einfach automatisiert durchtesten kann.

Andy Grunwald (00:16:16 - 00:16:41)

Genau. Fun Fact. Bing, bing, bing. Hörst du das? Es ist Zeit für ein Doom. Fun Fact, wusstest du eigentlich, dass die Firma id Software gar keine Qualitätssicherung hat? Und als John Carmack und John Romero gesagt haben, so, wir sind jetzt fertig, dann haben alle Mitglieder der Firma von id Software Doom für circa dreiig Stunden lang gespielt, da die einfach kein eigenes Team haben. Das war deren Qualitätssicherung. Dann haben sie das geschippt.

Wolfi Gassler (00:16:41 - 00:16:50)

Das waren noch Zeiten. Das sollte man heutzutage auch wieder einführen, wenn die ganzen Developer sagen, nö, möchte nicht testen. Das waren noch mal coole Zeiten. Das könnte man wirklich wieder einführen.

Andy Grunwald (00:16:50 - 00:17:05)

Kommen wir aber zurück zum Zufallsgenerator. Und zwar habe ich ja gerade gesagt, Doom ist deterministisch und das Spiel selbst beginnt wirklich immer und immer und immer mit denselben Einstellungen. Das bedeutet, die Gegner, also die Monster, starten immer an denselben Positionen, du hast dieselben Gegenstände und so weiter.

Wolfi Gassler (00:17:05 - 00:17:12)

Und wie funktioniert es dann, wenn, keine Ahnung, wenn da Monster rumlaufen? Die müssen ja irgendwie, die können ja nicht immer genau das gleiche machen, oder?

Andy Grunwald (00:17:12 - 00:17:58)

Doch, tun die eigentlich, sofern du natürlich die gleiche Eingabe machst. Denn eine gewisse Art von Zufall braucht ja so ein Spiel. Also es muss ja mehr oder weniger in Anführungszeichen unvorherbar sein, wann jetzt ein Gegner schießt oder ob er jetzt von links kommt oder von rechts kommt. Und Doom selbst hat eine statische Tabelle von 256 Zahlen im Source Code, hart verdrahtet, dann eine globale Variable und dann eine Funktion, die nennt sich m random. Die m random hat einen Integer als Return Wert und die besagt eigentlich, gib mir eine Zufallszahl. Wenn ich jetzt die m random Funktion aufrufe, dann wird die globale Variable um eins erhöht und retourniert mir dann die Zahl aus dem Tabellenindex. Das bedeutet eigentlich, die Zufallszahl ist nicht zufällig, weil du die Zufälligkeit ja hervorsagen kannst.

Wolfi Gassler (00:17:58 - 00:18:05)

Das heißt, du hast einfach einen Counter und Modulo Operator am Ende und wanderst dann eigentlich nur die Zufallszahlen durch die 256.

Andy Grunwald (00:18:05 - 00:19:22)

Ganz genau. Und wenn du bei der Zahl 255 bist, denn wir fangen bei null an zu zählen, dann flippt er wieder und fängt mir die erste Zahl zurück. Diese Zahlen steuern dann die Physik Engine, das Gegnerverhalten und so weiter und so fort. Und damit kann man natürlich immer bei denselben Eingaben auch immer dasselbe Ergebnis erwarten. Also eigentlich kann man sagen, dass Doom seine komplette Spiellogik auf festen Werten ohne wirklichen Zufall aufgebaut hat. Zusätzlich musst du wissen, Doom selbst funktioniert mit einer festen Bildrate von fünf und dreiig Ticks pro S. Der gesamte Spielzustand wird bei jedem Tick aktualisiert. Was sie im Source Code haben, nennt sich einen sogenannten Doom Loop. Das ist eine While Schleife mit der Bedingung von eins, die hört einfach niemals auf. Und das ist der haupt Game loop. Da wir ja gesagt haben, dass es single threaded, wird dieser Loop mindestens fünf und dreiig mal pro s komplett durchgelaufen. Das bedeutet, die Berechnung für deine Waffen, die Bewegung, Schaden, Kollisionsabfragen und so weiter und so fort wird alles in einem Loop Durchgang, einem sogenannten Tick durchgeführt. Die beiden Sachen in Kombination machen das Verhalten von Doom einfach zweitausendein vorhersagbar. Und das ist natürlich ein Traum für jeden, der irgendwie etwas portieren möchte bzw. Testen möchte oder Achtung, modifizieren möchte.

Wolfi Gassler (00:19:22 - 00:19:23)

Was hat es mit modifizieren zu tun?

Andy Grunwald (00:19:23 - 00:19:40)

Naja, du kannst dir einfach sicher sein, dass Seiteneffekte relativ minimal sind auf Basis von zufälligen Aktionen. Wenn du jetzt eine neue Waffe da hinzufügen möchtest, dann musst du jetzt nicht mit irgendwelchen Seiteneffekten rechnen, weil die ganze Sache sehr einfach programmiert ist und halt die random Zahl nicht da ist.

Wolfi Gassler (00:19:40 - 00:19:46)

Und das heißt, diese Leute, die dann diese Speedruns machen, um drei 8 Minuten irgendwie durch nach 8 s hast du gesagt, oder?

Andy Grunwald (00:19:46 - 00:19:51)

Ich glaube, der aktuelle Weltrekord für das allererste Level ist bei 8 s.

Wolfi Gassler (00:19:51 - 00:20:07)

Das heißt, die optimieren das dann dementsprechend. Die wissen ganz genau, was wo passiert. Vielleicht sogar eben deterministisch. Wobei du musst natürlich schon die deine Person steuern. Das hat ja natürlich schon andere Auswirkungen, oder? Also so deterministisch kannst du die Eingabe mit deinen Fingern eigentlich kaum machen.

Andy Grunwald (00:20:07 - 00:20:27)

Also ja und nein. Also es gibt auch sowas wie sogenannte Tool Assistant Speedruns. Dafür musst du wissen, wie Doom funktioniert. Und zwar kannst du jedes Doom Spiel aufnehmen lassen. Man sagt im Spielsektor okay, man nimmt eine Demo auf, damit ich dir zuschicke, damit du sehen kannst, wie ich gespielt habe und somit der Beweis da ist, dass ich jetzt den Speedrun innerhalb von 8 S gemacht habe.

Wolfi Gassler (00:20:27 - 00:20:34)

Aber das ist jetzt wirklich eine klassische Aufnahme. Das hat jetzt Doom noch nicht unterstützt, dass du einen Run aufzeichnen konntest.

Andy Grunwald (00:20:34 - 00:22:14)

Doch, hat es und zwar viele Ÿousand. Der klassische Anwendungsfall wäre, du nimmst irgendwie ein Video von deinem Bildschirm auf, spielst das durch und so weiter. Ich rede jetzt hier nicht von ja, wir können Video Editing machen und so weiter. Aber Doom hat damals eine Spielaufzeichnung bereits mit ins mit ins Game mit rein programmiert. Und zwar nennt sich das sogenannte Lump Files. LMP Files. In diesen LMP Files wird mitgeloggt, wann der User welchen User Input gemacht hat. Das bedeutet, Wolfgang, du hast den zweitausendein Key w, um nach vorne zu laufen, nach der dritten S gedrückt. Das wird darin gespeichert. Also eigentlich speichert der allen User Input zu, Achtung, jedem Frame. Wir hatten ja gesagt, Tickrate von dreiig oder fünf und dreiig Ticks, also fünf und dreiig Frames. Und der user Input wird zu jedem Frame gespeichert. Das bedeutet natürlich auch, dass wenn ich dir das Demo File schicke, dann kriegst du eigentlich nur ein bisschen Text und jetzt kein Video, was die ganze Sache natürlich enorm klein macht. Zweitausendein, die ganze Sache wird sequenziell in der Datei gespeichert und somit ist der Speicherbedarf pro laufende Spielsekunde eigentlich nur 280 Bytes. Und jetzt kommt das geile, es gibt natürlich Dokumentation darüber, wie diese Datei aussieht. Das bedeutet binär header und dann wie die einzelnen Records aussehen. Du kannst also diese Files auch reverse engineeren. Und wenn du sie reverse engineeren kannst, kannst du sie natürlich auch schreiben, programmatisch. Und das bedeutet, da sind wir dann im Bereich Tool Assistant Speedruns, dass du deine Eingaben Frame genau planst, zweitausendein, und diese so wiederholt werden, dann lässt der Computer die laufen, weil du als Mensch das eigentlich nicht schaffst. Also du entwickelst den optimalsten Weg durch das Level, Schritt für Schritt, programmierst das aber, um jedes Detail zu perfektionieren.

Wolfi Gassler (00:22:14 - 00:22:27)

Das heißt, du könntest dann auch eine AI das Ganze versuchen zu optimieren zu lassen. Also dass man einfach die. Ja, die macht ganz viele Wege, kann das durchrechnen, ist immer deterministisch und findet dann die perfekten Wege mit der Zeit.

Andy Grunwald (00:22:27 - 00:22:49)

Richtig, das geht. Und jetzt kommt es eigentlich auch, wenn du dir jetzt mal Gedanken über die Implementierung der Multiplayer Synchronisierung machst und du hast diese LAMP Files, reicht das da nicht einfach, dass die User Inputs übers Netzwerk geschickt werden und dass dein Computer meine User Interactions einfach replayt, dass dein Spiel weiß, wo ich in deinem Multiplayer Game eigentlich bin.

Wolfi Gassler (00:22:49 - 00:23:01)

Wobei du hast gesagt 280 Byte pro Spiel s. Das heißt, du brauchst da dann schon, wenn du ein vier Player Multiplayer Setup hast, dann brauchst du eigentlich 1 kb/s Übertragungsrate.

Andy Grunwald (00:23:01 - 00:23:10)

Zumindest der Multiplayer war, glaube ich, auf vier Spieler begrenzt, du bist ja einer, somit brauchst du ja nur drei Spielstände. Somit bist du bei 57 Byte pro.

Wolfi Gassler (00:23:10 - 00:23:12)

Spielsekunde, wenn es synchron ist. Ja, du musst ja deine auch senden.

Andy Grunwald (00:23:12 - 00:23:18)

Du sendest deinen deine 280 Bytes und empfängst 801 paar gequetschte Byte. Genau.

Wolfi Gassler (00:23:18 - 00:23:42)

Ich kann mich noch erinnern, zu meiner Zeit, wie man da Multiplayer gespielt hat, haben wir das ja über. Gute Frage, wie das geheißen hat. War so ein alter Druckeranschluss, so ein breiter werden das geheißen, das Zeug? Es hat null Modem gegeben, oder? Und dann hat es noch diesen anderen schnelleren. Ich glaube das war sogar ein Bus. Egal, ich habe gerade mal schnell gegoogelt. Null Modem Kabel hatte ungefähr 90 kb/s also gar kein Problem.

Andy Grunwald (00:23:42 - 00:24:04)

Also in meinem Kopf ist das immer noch dieser Exploding Head Emoji. 1993 hat jemand eine Lösung gefunden, die a heutzutage für Speedruns genutzt wird, b eine Art programmatische Schnittstelle, Doom Frame by Frame spielen zu können und c eine effiziente und stabile Multiplayer Erfahrung zu erschaffen mit begrenzter Bandbreite.

Wolfi Gassler (00:24:04 - 00:24:20)

Was mir interessieren würde, ist, ob das einfach damals so passiert ist, weil es nicht anders möglich war, weil man so viele Restriktionen hatte, auch das Ganze mit mit dem Pseudo Random Number Generator oder ob da irgendwelche bewussten Entscheidungen auch dahinter gelegen sind.

Andy Grunwald (00:24:20 - 00:24:51)

Das kann ich dir natürlich nicht beantworten. Aber was auf Basis dieser Lampfiles heutzutage gemacht wird, ist, dass die Community kreativ wird. Und zwar gibt es nämlich eine Software, die nennt sich xstar xdae, also ein Doom Replay Demo Editor. Und wo gibt es den? Auf GitHub natürlich. Da kannst du dir deine Demos anschauen, da kannst du dir die einzelnen User Inputs anschauen, modifizieren und dann die Demo noch mal laufen lassen. Wahnsinn, diese Szene. Ich bin auf jeden Fall geflasht von dieser ganzen. Was vor ein und dreiig Jahren eigentlich so möglich war.

Wolfi Gassler (00:24:51 - 00:24:56)

Ja, es ist nicht immer gut, dass unsere Prozessoren so schnell sind und der RAM so groß ist.

Andy Grunwald (00:24:56 - 00:25:34)

Ding, ding, ding. Da ist er wieder, der Doomfact. Wusstest du eigentlich, dass an der Game Story, die du mir nicht mitteilen konntest, unglaublich lange geschraubt wurde? Und zwar der damalige CEO der id Software hat eine sogenannte Doom bibel geschrieben. Und zwar war das ein 78 seitiges langes Dokument. Das haben wir natürlich auch in den Show Notes verlinkt. Die Doom Bibel. Und die beiden Hauptentwickler waren von dieser Doom Bibel eigentlich überhaupt nicht überzeugt, weil die beiden Hauptentwickler so eine andere Vorstellung von Doom hatte. John Carmack verglich die Hintergrundgeschichte eines Ego Shooters mit der eines Pornofilms. Erwartet aber unnötig.

Wolfi Gassler (00:25:35 - 00:25:36)

Ich stimme vollkommen zu.

Andy Grunwald (00:25:37 - 00:27:39)

Nun gut, machen wir mal ein bisschen weiter. Lass uns noch mal auf diesen Determinismus, auf diesen random Zahlen Generator, der eigentlich kein random Zahlen Generator ist, zurückkommen. Also ich meine, was sind die Vorteile von diesem ganzen Determinismus? Hatten wir ja schon gesagt, die Fehlersuche und Debugging, die Reproduzierbarkeit auch von den Doom Spielständen. Und das macht es natürlich enorm wertvoll für Wettbewerbe, weil die ganz genau reproduzierbar sind. Wird heutzutage unglaublich viel in der Speedrun und Demoszene genutzt, aber natürlich auch für etwas sehr, sehr spannendes und zwar für AI Training und Simulationen. Weil du kannst nämlich die künstliche Intelligenz in einer stabilen, konsistenten Umgebung trainieren, was natürlich mega gut ist, denn die KI kriegt dann immer dieselbe Bedingung und dann kannst du natürlich auch dein Modell testen. Und jetzt kam eine Frage auf bei meiner Research, die habe ich mir nicht gestellt, über die bin ich gestolpert. Was passiert eigentlich, wenn man diese vorgegaukelte Randomness, diese 256 Values, eigentlich durch eine Konstante ersetzt? Und als ich die Frage gelesen habe, habe ich gedacht, wie weit kann man das hier eigentlich treiben? Was hat also jemand gemacht? Jemand hat sich das Doom Spiel genommen, hat den Sourcecode modifiziert, hat in dieser mrandom Funktion diesen Inkrement rausgenommen und einfach return null oder return 255 gemacht. Also der hat einmal die ganze Sache mit return null gemacht und einmal mit return 255 und hat dann einfach nur geguckt, was passiert. Und das faszinierende ist, der hat das im Blogpost geschrieben, verlinken wir unten auch in den Show Notes. Die Monster verhalten sich anders. Bei der Value null machen die gar keinen Sound mehr, also die atmen laut und und husten und solche Geschichten. Und bei Value 255 sind die konstant dran am atmen, am husten und so weiter. Das gleiche ist mit diesen flackernden Lichtern. Bei der Value null flackert das alles komplett durch, bei value 255 ist alles statisch. Dann manche Waffen haben keinen Spread mehr. Du kennst das ja von den Spielen, wenn du eine Waffe hast und du hältst gedrückt, dann dann schießt sie nicht immer auf denselben Punkt, sondern die Waffe bewegt sich nach links und rechts und so weiter, damit du den Gegner verfehlst.

Wolfi Gassler (00:27:39 - 00:27:39)

Zweitausendein, wenn du das sagst.

Andy Grunwald (00:27:40 - 00:28:07)

Ja, das nennt man halt Spread, damit man nicht einfach mit Dauerfeuer durchs level rennt. Und wenn du einfach nur Zufall, wenn du einfach nur eine feste Konstante lieferst, dann haben halt manche Waffen einfach gar keinen Spread mehr, sondern die schießen einfach nur auf einen Punkt und dann kannst du halt einfach komplett durchleveln. Generell verhalten sich halt manche Elemente des Spiels wirklich weird. Interessanter interessantes Experiment meines Erachtens nach. Und das ist wieder so, fällt in die Kategorie, weil es geht. Und das fasziniert mich einfach.

Wolfi Gassler (00:28:07 - 00:28:39)

Es ist ja eigentlich auch jetzt rein vom Coding her ganz klar, weil du holst dir einen Wert von dem Number Generator und wenn du jetzt entscheiden willst, atme ich oder atme ich nicht, dann hast du irgendwie ein Modulo zwei. Und je nachdem, ob du halt den Rest hast oder nicht, atmet das Monster oder nicht. Und das hast du halt überall, wo du in irgendeiner Form Zufälle brauchst. Und wenn du immer denselben Wert zurückbekommst, dann ist dein Modulo auch immer derselbe Wert und damit verhalten sich alle immer gleich und es ändert sich nichts mehr. Also eigentlich ist es sehr, sehr logisch vom Coding und vom Funktionellen her.

Andy Grunwald (00:28:39 - 00:29:19)

Ich finde es trotzdem geil, dass sich immer die Zeit genommen hat, die ganzen Sachen zu testen. Ding, ding, ding. Es geht mal wieder um ein Doom Fact. Wusstest du eigentlich, dass Doom damals, so zumindestens die Theorie, die meist installierte Software weltweit war? Mehr als Windows fünf und neunzigste. Das sagen zumindest manche Gerüchte und die Gerüchteküche geht sogar weiter. Damals wollte Bill Gates id Software sogar kaufen, weil das die meist installierte Software war. Das ist jedoch nur ein Gericht. Was er wirklich wollte, ist, er wollte die. Er wollte Spiele auf Windows fördern und deswegen wollte er mit id Software strenger kooperieren. Aber ich kann mir schon sehr gut vorstellen, dass Doom 1995 sehr oft installiert wurde.

Wolfi Gassler (00:29:19 - 00:29:28)

So, aber jetzt bist du mir immer noch eine Antwort schuldig. Und zwar das d Spiel. Warum 2,5 und nicht drei und nicht zwei?

Andy Grunwald (00:29:28 - 00:29:46)

Ÿousand. Also jetzt gehen wir mal so ein bisschen in die Grafik Engine rein und ich hoffe, ihr habt noch nicht viel Bier getrunken, denn jetzt wird es schon ein bisschen kompliziert. Doom selbst ist kein echtes D Spiel, weil die Höheninformationen fehlen. Es simuliert nur einen dreidimensionalen Raum. Deswegen wird gesagt, Doom ist ein zweieinhalb.

Wolfi Gassler (00:29:46 - 00:29:48)

D Spiel, das heißt, du kannst nicht springen.

Andy Grunwald (00:29:48 - 00:30:07)

Eine Sprungfunktion gibt es in der Tat nicht. Muss ich auch gerade erst nachschlagen, weil ich habe auch für die Recherche Doom nicht gespielt. Ich gebe auch zu, seit ich die Episode recherchiert habe, musste ich mit mir kämpfen, Doom nicht zu installieren, weil ich wusste, dass es dann zu meiner Produktivität schlecht aussieht.

Wolfi Gassler (00:30:07 - 00:30:08)

Du hast eben Capture gespielt.

Andy Grunwald (00:30:08 - 00:31:51)

Das Capture habe ich ein bisschen gespielt, das ist richtig. So, lass uns wieder zur Grafik Engine kommen. Also generell wird Doom auch als Grafikwunder gehyped. Also auf der einen Seite, weil es einen dreidimensionalen Raum simuliert, auf der anderen Seite, weil die Grafik flüssig dargestellt wurde mit Objekten in einem d Raum und das auf leistungsschwachen Computern. Dann wurde im Spiel sehr, sehr viel mit Perspektiven und Lichtverhältnissen gespielt, aber auch mit dynamischer Beleuchtung und Schatten, speziell für die Spannung und für die Atmosphäre. Aber für die Leute, die jetzt noch nicht im Game Engine Bereich unterwegs sind, was ist eigentlich das Problem mit der Grafik? Und zwar, und zwar ist das Hauptproblem, wie findest du heraus, welche Objekte in einem dreidimensionalen Raum ÿousand sind für den Spieler zu sehen und welche nicht? Denn der Renderer muss es auf jeden Fall wissen, abhängig vom Blickwinkel. Die ganze Sache nennt sich Visible Surface Determination, VSD, könnt ihr mal googeln. Das ist generell ein Grundproblem für alle Grafikengines. Die ganze Thematik ist eigentlich keine Herausforderung, wenn du viel Zeit hast. Das Problem bei Spielen und bei Realtime spielen, die müssen das mindestens dreiig mal pro s tun. Die müssen dreiig mal pro S herausfinden, ist dieses Objekt für den Spieler sichtbar oder nicht. Und um diese Frage zu beantworten, hast du eigentlich zwei Herausforderungen. Die eine Geschichte ist, wie findest du heraus, welche Objekte nicht sichtbar sind, damit du die sofort verwerfen kannst, weil die interessieren dich ja gar nicht mehr für den Renderer. Und die zweite Geschichte ist, wie skalierst du diese Berechnung bei einer komplexen Szene, besonders jetzt bei einer großen Welt z.B. umso größer die Welt oder das Level, umso komplexer die Szene, umso mehr Objekte da sind, desto schwieriger wird das natürlich in einer effizienten Zeit zu errechnen.

Wolfi Gassler (00:31:51 - 00:32:01)

Mein naiver Ansatz wäre ja einfach, ich zeichne da ein Dreieck, das ist der View von von der aktuellen Position aus und dann schaue ich, welche Objekte sich überschneiden und sichtbar sind.

Andy Grunwald (00:32:01 - 00:32:03)

Was heißt überschneiden?

Wolfi Gassler (00:32:03 - 00:32:06)

Ja, das stimmt natürlich, wenn was im Weg ist, dann sehe ich es auch nicht.

Andy Grunwald (00:32:06 - 00:32:46)

Das, was du da machst, mehr oder weniger, nennt sich Raycasting. Und was Ray Casting eigentlich ist, zweitausendein, es ist eigentlich genau das eine Technik, um d Umgebungen, Videospielen effizient darzustellen von einem bestimmten Standpunkt. Also von dir als Spieler schießt du gerade Linien einfach geradeaus, sogenannte Rays. Und diese Strahlen bewegen sich durch den Raum, durch den d Raum, bis sie auf ein Objekt treffen oder auf eine Wand oder auf dem Hindernis. Basierend auf diesen Treffpunkten wird ein zweidimensionales Bild dieser dreidimensionalen Umgebung erzeugt. Und all das wird für jede vertikale Linie auf deinem Bildschirm gemacht. Das ist eigentlich das, was du da gerade beschrieben hast.

Wolfi Gassler (00:32:46 - 00:33:09)

Ja, was du zusätzlich noch hast, ist auch, dass du, wenn z.B. der Strahl länger benötigt auf dem Objekt, dann wird es dunkler. Also du hast da auch noch zusätzliche Informationen, die du berechnest. Ist ja nicht nur ja oder nein, ist nicht binär, sondern du hast da ja dann auch noch Schatten und Lichtquellen und solche Dinge. Und bzw. Damals Lichtquellen war wahrscheinlich jetzt noch weniger, aber zumindest das, was dunkler geworden ist in der Zweitausendein Entfernung. Das gab es damals auch schon.

Andy Grunwald (00:33:09 - 00:34:43)

Ja, genau. Und da weißt du halt, okay, das steht weiter weg und so weiter und dazwischen steht jetzt kein Objekt mehr. Aber Achtung, Raycasting wird in Echtzeit während der Spiellaufzeit berechnet. Und das ist natürlich relativ herausfordernd, wenn du jetzt schwache Computer hast. Und warum war das jetzt ein Problem? 1903 und neunzigste id Software, die ja auch Wolfenstein D rausgebracht haben, hatten den Auftrag, Wolfenstein D für die Super Nintendo Spielekonsole zu portieren. Die haben das eigentlich an eine andere Firma outgesourcet, die hat das aber nicht hingekriegt, deswegen haben die es selbst gemacht. Wolfenstein D basiert auf dem Computer, auf Raycasting, beziehungsweise man nennt das heute Ray Marching, weil es ist kein richtiges Ray Casting, wie ich das beschrieben habe, mit diesen Strahlen, die quer durch den Raum gehen, sondern du musst wissen, Wolfenstein D hatte nur einen Grundriss, der auf Rechtwinkligkeit beschränkt war. Du hattest keine schrägen Wände, Wolfenstein D, du hattest wirklich nur rechte Winkel. Das bedeutet auch, dass Wolfenstein D untendrunter ein Grid hatte. Und wie ich gerade beim Ray Casting beschrieben habe, werden Strahlen durch die vertikalen Linien deines Bildschirms gesendet, um zu gucken. Bei Ray Marching gehst du eigentlich nur das d grid lang. Da du ja nur rechtwinklige Elemente hast, ist das natürlich viel schneller. Und deswegen lief das für Wolfenstein D auf schwachen Computern. Das Riesenproblem war jetzt aber, also durch das D grid konntest du alles auf derselben horizontalen Ebene testen, ob da was im w steht oder nicht. Auch die Höhe bei Wolfenstein D war fix. Und deswegen hast du eigentlich mit einem d Grid gearbeitet bei deinem Raycasting bzw. Ray Marching. Du musstest also gar nicht quer durch den Raum.

Wolfi Gassler (00:34:43 - 00:34:47)

Aber du hast ja gesagt, bei Doom hast du auch keine Höhe, bei Doom.

Andy Grunwald (00:34:47 - 00:34:58)

Hast du aber diagonale Wände und Schrägen. Und deswegen kannst du bei Doom kein d Grid legen und du kannst nicht auf den Grid Linien beilaufen, um das Ray Marching herauszufinden, also das Raycasting.

Wolfi Gassler (00:34:58 - 00:35:02)

Und wie funktioniert das dann bei Doom? Auch mit Raycasting oder mit einer anderen Technologie?

Andy Grunwald (00:35:02 - 00:35:25)

Das ist jetzt super spannend. Und zwar die Firma id Software hatte den Auftrag, Wolfenstein D damals auf die Super Nintendo zu portieren. Erst war dieser Job abgegeben an eine andere Firma, die haben es nicht hinbekommen. Deswegen hat id Software gesagt, okay, machen wir selbst. Das Problem mit der Super Nintendo zum Vergleich Ÿousand von Computern von 1993 ist, dass die Super Nintendo noch schwächer auf der Brust war und noch weniger Compute Power hatte. Deswegen war John Carmack irgendwie auf der Suche nach etwas neuem.

Wolfi Gassler (00:35:25 - 00:35:29)

Aber war da das Spiel schon draußen oder war das noch in der Entwicklungsphase?

Andy Grunwald (00:35:29 - 00:35:35)

Das war noch in der Entwicklungsphase. Doom selbst war noch in der Entwicklungsphase. Wolfenstein D war bereits draußen.

Wolfi Gassler (00:35:35 - 00:35:42)

Okay. Und Wolfenstein D war, die Technik war eben nicht mehr möglich auf einer Konsole zu verwenden und darum hat man was neues gesucht, ÿousand.

Andy Grunwald (00:35:43 - 00:37:59)

Genau. Ray Marching bzw. Ray Casting war auf der SNES, da es ja zur Laufzeit errechnet wird, zu teuer performance technisch. Deswegen musste da was Neues her. Und zwar hat er dann ein paar wissenschaftliche Papers gelesen, John Carmack, und kam ist über eine Studie der Airforce, der US Air Force, gestolpert. Und zwar hatten die den Anspruch, Flugsimulationen zu entwickeln, also ebenfalls Objekte in einem dreidimensionalen Raum darzustellen. Finde ich auf jeden Fall eine super Sache, wenn man Flugsimulation machen. Und die hatten eigentlich genau das gleiche Problem. Ray Casting ist zu teuer für die aktuelle Computation Power. Und die sind über einen neuen Algorithmus gestolpert, der nannte sich BSP, Binary Space Partitioning, beziehungsweise haben diesen Algorithmus entwickelt. Das Problem war 1960 ist, dass sie den Algorithmus nicht anwenden konnten, weil die Elemente innerhalb des Algorithmus priorisieren mussten und dafür fehlte die richtige Datenstruktur. Warum man Elemente innerhalb des BSPs priorisieren muss, kommen wir gleich zu. Andere Forscher haben sich diese Forschung von 1960 genommen, 20 Jahre später, 1980, haben gesagt, hey, der Algorithmus ist ja super, lass den doch mal nehmen. Und haben dann aber mittels einem binären Baum die richtige Datenstruktur gefunden, um den Algorithmus wirklich ins Leben zu erwecken. Wenn wir uns jetzt einmal ansehen, was Binary Space Partitioning, BSP ist, dann wird auch klar, warum. Die Spielwelt in Doom selbst ist als zweidimensionales Layout definiert. Jetzt könnte man sagen Moment mal, hast du nicht gerade gesagt zweidimensionales Layout, dann kannst du auch dieses Ray Marching machen. Ja, theoretisch, wenn du auch ein rechtwinkliges Wendelayout hast. Hast du aber nicht, denn in der Doom Engine können Grundrisse Winkel beinhalten, also diagonale Wände. Es kann eine beliebige Raumhöhe umgesetzt werden. Also das ist halt grundlegend anders als Wolfenstein D. Deswegen kannst du dieses Ray Marching nicht machen. Müsstest eigentlich ray casting machen und das wäre wieder zu teuer. Deswegen, du hast ein Level bei Doom mit diagonalen Wänden und Schrägen. Und jede Karte besteht aus sogenannten Sektoren. Im Grundprinzip nimmst du das Level und teilst das. Somit kriegst du zwei kleine Level. Und diese zwei kleinen level nennst du Front Space und Backspace. Also einmal alle Sektoren, die sich auf einer Seite der Linie befinden und Backspace alle Sektoren, die sich auf der anderen Seite der Linie befinden.

Wolfi Gassler (00:37:59 - 00:38:15)

Wobei man da jetzt sagen muss, mit der Linie, das ist keine horizontale Linie wie zweitausendein, wenn ich in eine Welt hineinblicke und ich habe oben und unten, sondern nehme den Grundriss von einer Welt und schneide diese Welt auseinander. Und dann habe ich einen linken und einen rechten Teil. Z.B. einen hinteren und einen vorderen, wie man es auch immer sieht.

Andy Grunwald (00:38:15 - 00:38:34)

Ganz genau. Nimm dir einfach ein Blatt Papier, mal einfach einen großen Strich durch quer und dann hast du es geteilt. Ja, dann hast du einen linken, rechten Teil. Und das wird jetzt für jede Seite so lange gemacht, bis du sie nicht mehr teilen kannst. Oder bis man sagt, man hat ganz viele kleine Abschnitte. Also die Teilung geht rekursiv durch, einmal für die linke Seite, einmal für die rechte Seite.

Wolfi Gassler (00:38:34 - 00:38:45)

Und wenn ich jetzt weiß, dass sie z.b. einen gewissen Bereich gar nicht einsehen kann, dann kann ich alle Unterebenen, alle Unterelemente auch ignorieren und kann mich auf die andere Seite vom Binärbaum konzentrieren.

Andy Grunwald (00:38:45 - 00:39:18)

Ja, da kommen wir gleich zu. Jetzt hast du das Level in ganz viele kleine Unterlevel unterteilt. Und jetzt baust du den binären Baum auf. Ein binärer Baum hat eine Wurzel und hat ganz viele Äste. Und die Endknoten eines Baumes nennt man Blätter. Und jeder Knoten in diesem Baum repräsentiert also eine Teilungsebene, die ganz oben einmal in den Raum Front Space, also Vorderraum, und einmal in den backspace Hinterraum unterteilt wurde. Und die Blätter selbst sind sogenannt die Endknoten vom Baum, die dann halt den kleinsten unteilbaren Bereich, den Sektor der Spielwelt beeinflussen bzw. Repräsentieren.

Wolfi Gassler (00:39:18 - 00:39:24)

Aber sind es dann schon wirklich Monster oder so, die da in den Blättern hängen? Oder ist das noch ein Raum, das Blatt?

Andy Grunwald (00:39:25 - 00:40:23)

Das ist noch ein Raum. Die Monster sind ja mehr oder weniger eigentlich dasselbe wie. Wie du als Spieler bei Bsp. Der BSP funktioniert nur mit statischen Elementen, die sich nicht bewegen. Monster können sich bewegen, deswegen sind Monster nicht Teil des BSPs. Und das macht die ganze Sache fürs BSP so spannend. Ein BSP kann im Vorhinein berechnet werden und nicht zur Laufzeit, da es ja nur um statische Elemente handelt. Okay, jetzt haben wir den binären Baum und das Level in diesen binären Baum aufgeteilt. Wir wissen ja auch in welchem Sektor der Spieler sich befindet. In irgendeinem dieser geteilten Sektoren steht der Spieler ja gerade und schaut in irgendeine andere Richtung. Das bedeutet, er schaut auf andere Sektoren. Und jetzt kannst du sagen, ist der Spieler im Front Space, wird dieser zuerst gezeichnet, da er alle sichtbaren Sektoren hat. Also erst werden die Sektoren gezeichnet, in dem der Spieler ist, weil die werden ja sichtbar sein. Erst später können im Backspace die Elemente gezeichnet werden. Also eigentlich wird der Baum vom Spielerstandpunkt durchlaufen.

Wolfi Gassler (00:40:23 - 00:40:35)

Aber ich will mir trotzdem sparen, dass ich nicht alles zeichnen muss, oder? Also ich muss ja trotzdem irgendwie checken, okay, welche Elemente sind gerade sichtbar. Ich will die ganze Welt immer generieren, auch wenn es hintereinander passiert durch die Teilungsebene.

Andy Grunwald (00:40:35 - 00:41:02)

Und durch die Priorisierung der Elemente im Baum hast du beim Zeichnen auch so eine Sichtbarkeitsberechnung bzw. Eine Sichtbarkeitsprüfung. Und da kannst du, da kannst du ja sehen, okay, ich habe dieses Objekt, diesen Sektor bereits gezeichnet. Dieser Sektor steht vor einem anderen Sektor, deswegen kann ich den Backspace Sektor halt wegschmeißen und brauche den gar nicht zeichnen. Weil du ja durch die Tiefe des Baumes und durch den Standpunkt, wo der Spieler in dem Baum gerade steht, weißt du ja welche Elemente du bereits gezeichnet hast.

Wolfi Gassler (00:41:02 - 00:41:11)

Ja, vor allem du kannst testen ob du einen Sektor siehst und wenn du den großen Sektor schon nicht siehst, dann kannst du alle die darunter liegen auch automatisch nicht mehr zeichnen.

Andy Grunwald (00:41:11 - 00:41:11)

Ganz genau.

Wolfi Gassler (00:41:11 - 00:41:19)

Das heißt du musst nur grobe Checks machen und dann in die Tiefe gehen, welche Checks, also welche Sektoren wirklich sichtbar sind überhaupt.

Andy Grunwald (00:41:19 - 00:41:21)

Du lässt den kompletten Teilknoten dann einfach fallen. Genau.

Wolfi Gassler (00:41:21 - 00:41:29)

Wie wir alle wissen, Bäume sind immer logarithmisch, das heißt du sparst dir extrem viel, weil das exponentiell sinkt, die Anzahl der Elemente, die gerendert werden müssen.

Andy Grunwald (00:41:29 - 00:42:04)

BSP, also binary space partitioning, war mindblowing zu der Zeit, denn da die ganze Sache beim Laden des Spiels berechnet wird. Oder du kannst, du kannst den Baum ja bereits schon statisch in der Datei ablegen. Den kompletten Baum zu durchlaufen hat immer die gleiche Geschwindigkeit. Es ist völlig egal wo der Spieler im Baum in der Karte steht, die Geschwindigkeit bleibt immer gleich, da der BSP nur statische Objekte enthält, Wände, Blöcke und so weiter, die sich nicht bewegen. Und du kannst halt wie gerade sagte, Teile der Map einfach fallen lassen, da diese nicht sichtbar sind.

Wolfi Gassler (00:42:04 - 00:42:17)

Du könntest im Prinzip auch vorberechnen, welche Sektoren von welchen Sektoren auf keinen Fall sichtbar sind. Keine Ahnung, ob das gemacht wird, aber das ginge eigentlich auch, weil du kannst da schon dann viele ausschließen und das könntest du dann auch noch statisch bei.

Andy Grunwald (00:42:18 - 00:43:05)

Es gibt ein Buch, nennt sich Game Engine Black Book Doom. Da hat jemand den kompletten Doom Source Code gelesen und das in ein Buch gepackt und hat das erklärt. Und in diesem Buch steht unter anderem, dass John Carmack solche Optimierung, von denen du gerade gesprochen hast, bereits eingebaut hat. Der originale BSP Algorithmus sagt auch, dass du die Objekte in dem Baum erst von hinten nach vorne zeichnen solltest. John Carmic hat es einfach umgedreht, weil der fand das unlogisch. Der sagte, warum soll ich denn erst ganz hinten anfangen und vorne überzeichne ich die Elemente doch immer, wenn die doch gar nicht. Weil die hinteren Elemente nicht sichtbar sind. Deswegen hat er das Zeichnen von vorne nach hinten gemacht und nicht wie original im Paper von hinten nach vorne, weil der sagt halt, dann spare ich mir das ganze Überschreiben der Elemente sowieso. Also John Cummings selbst hat da schon diverse Optimierungen mit reingepackt.

Wolfi Gassler (00:43:05 - 00:43:28)

Da sieht man übrigens wieder, wie klein die ganze informatikwelt ist, weil diese ganzen Algorithmen werden natürlich genauso auch in den Datenbanken verwendet. Wenn du jetzt z.b. das GIS Modul von von Postgres oder so hast, das arbeitet meines Wissens, glaube ich, mit Quad Trees oder KD Trees vermutlich, was genau mit der gleichen Methodik arbeitet, einfach Räume zu zerteilen, um sie dann in den Baum anzuordnen und damit schneller zu machen.

Andy Grunwald (00:43:28 - 00:44:30)

Und nur noch mal zum Abschluss, wie sich jetzt Binary Space Partitioning, BSP von Ray Casting unterscheidet. BSP ist ein datenstrukturierter Ansatz auf Basis Binary trees. Raycasting ist mehr oder weniger so ein abtastungs basierter Ansatz. Und die Performance ist beim Binary Space Partition natürlich deutlich höher, da du vorberechnen kannst. Der Vorteil beim Raycasting ist natürlich, dass du es auch mit bewegenden Elementen machen kannst, was natürlich dann in modernen Spielen schon öfter gemacht wird. Aber auf der anderen Seite muss man sagen, die Rechenpower hat sich leicht erhöht seit 1993. Aber es ist mal wieder Zeit für einen Doom. Fun Fact, wusstest du eigentlich, dass der Doom Guy, also den Soldaten, den du spielst, bis 1995 gar keinen Namen hatte? John Romero, der das Leveldesign übernommen hat, hat gesagt, ach, der Typ ohne Namen, das sollte das Horror Theme noch realistischer machen. Und dann kam 1995 aber so eine Romanserie raus und dort wurde der sogenannte Doom Guy, also den Soldaten, den du spielst, Flynn Fly Taggart, genannt Flynn oder Finn Flynn, nicht wie Finn Kliemann.

Wolfi Gassler (00:44:30 - 00:44:43)

Halte mich meiner Meinung. Jetzt hast du schon erwähnt, Doom kann man überall spielen und Doom wird überall buddiert. Gibt es in der Fanwelt da draußen, nachdem es auch Open source ist, irgendwelche Erweiterungen? Also hat irgendwer weitergebaut an Doom?

Andy Grunwald (00:44:43 - 00:45:27)

Die Frage hast du falsch gestellt. Die Frage sollte wer hat nicht an Doom weitergebaut? Also neben dem Running gag can it run Doom? Wo wir gleich auch noch drauf zu sprechen kommen, kommen wir jetzt mal zu der Weiterentwicklung von Doom. Und zwar gibt es diverse Forks. Und zwar gibt es einmal Chocolate Doom. Chocolate Doom Ÿousand ist ein Fork von Doom, was das Ziel hat, so akkurat wie möglich an die originale Doom Version zu kommen, um aber auf modernen Computern laufen zu können. Also das hat keine spielerischen Erweiterungen, sondern ist wirklich eins zu eins kompatibel, auch mit dem Datenformat für die LMP, für die Lumpfiles, für die Speedruns, was vorhin erwähnt hatten. Und sogar, Achtung, Chocolate Doom ist sogar bug kompatibel, wo es geht.

Wolfi Gassler (00:45:27 - 00:45:30)

Aber das ist eine eigene Codebase.

Andy Grunwald (00:45:30 - 00:45:32)

Es ist ein Source Port, so nennt sich das.

Wolfi Gassler (00:45:32 - 00:45:34)

Aber warum nehme ich nicht den originalen Source Code?

Andy Grunwald (00:45:34 - 00:45:49)

Der originale Source Code hat unter anderem das Soundmodul nicht dabei, da das aus Lizenzbestimmungen nicht mitgeliefert werden durfte. Und der normale Source Code läuft halt auf aktuellen Systemen auch nicht mehr. Und chocolate DOM läuft z.B. auch auf Mac oder auf Linux mit neuen CPU architekturen und Co.

Wolfi Gassler (00:45:49 - 00:45:56)

Ja, wenn ihr natürlich jetzt MS DOS auf irgendeinem neuen Computer installiert, das würde natürlich schon funktionieren, aber Ÿousand auf Linux ist es natürlich schwierig.

Andy Grunwald (00:45:56 - 00:46:35)

Dann gibt es noch Crispy Doom. Crispy Doom ist wiederum ein Fork von Chocolate Doom. Und Crispy Doom läuft auch auf aktueller Hardware, aber auf höherer Auflösung. Was Chocolate Doom nicht macht. Wir erinnern uns, Chocolate Doom soll so akkurat wie möglich nah dran sein am Original und es entfernt statische Limits. Das bedeutet, die Original Doom Version hat z.B. ein Limit, das kann nur 20 Content Files, diese zweitausendein what Files, von denen ich gesprochen habe, wer all the data ist, laden. Und Crispy Doom kann 100 oder 200 und du kannst auch mehr Spieler im Multiplayer haben. Das Original Doom kann nur vier Spieler im Multiplayer. Crispy Doom kann mehr. Solche Limits werden da halt entfernt.

Wolfi Gassler (00:46:35 - 00:46:38)

Sind die eigentlich alle kostenlos oder muss man da was zahlen?

Andy Grunwald (00:46:38 - 00:47:48)

Alle open source, online verfügbar, kannst du herunterladen. Dann gibt es noch Z Doom. Z Doom ist so ähnlich wie Crispy Doom, jedoch mit etlichen neuen Features. Da wird das Spiel wirklich genommen und wirklich einfach weiterentwickelt. Wie z.b. gibt es von Z Doom wiederum einen Fork, der nennt sich GZ Doom. Der hat z.B. opengl Support für moderne Grafikkarten. Und Achtung, Scripting Capabilities. Da sind wir wieder bei deinem Monkey Island. Du sagtest ja, konnte man auch scripten, aber GZ Doom kann man jetzt auch wirklich scripten. Und das ist natürlich super interessant. Da kannst du das mal wirklich mit Quellcode steuern. Dann gibt es noch einen Fork von GZ Doom, der nennt sich Zandronum. Und das ist eigentlich ein Fork von Doom, der nur auf Multiplayer Gameplay ausgelegt ist. Da gibt es dann sowas wie Capture the Flag und allem drum und dran. Und Achtung, das ist auch der Port, der für die internationale Doom Liga genutzt wird. Also falls du Doom professionell spielen möchtest, dann kommst du um Zandronum nicht herum. Verlinken wir natürlich auch. Und wir wären ja nicht ein Software Engineering Podcast, wenn wir nicht mal ein bisschen an den educational party gehen würden. Und zwar gibt es jemand, der hat Doom von C nach C geportet.

Wolfi Gassler (00:47:48 - 00:47:54)

Warum, warum, warum? Ich frage mir immer diese Frage. Da hat irgendwer sehr viel Zeit.

Andy Grunwald (00:47:54 - 00:48:04)

Und zwar hat diese Person sich crispy doom genommen und langsam auf C geportet. Und jetzt die Frage, wie refactor man doom und stellt sicher, dass man nichts kaputt macht.

Wolfi Gassler (00:48:04 - 00:48:07)

Ja, kann man eh testen, alles verifizierbar.

Andy Grunwald (00:48:07 - 00:48:08)

Wie würdest du es machen?

Wolfi Gassler (00:48:08 - 00:48:12)

Ja, du kannst ja diese Input Files nehmen, die Watt Files, und dann dementsprechend das checken.

Andy Grunwald (00:48:12 - 00:48:17)

Die Watt Files sind die Content Files. Du meinst ja wahrscheinlich Lump Files, da wo die Spieler Interaktionen festgehalten werden.

Wolfi Gassler (00:48:17 - 00:48:21)

Genau, danach kannst du die Watt Files dann checken, oder ob die die richtigen Infos beinhalten.

Andy Grunwald (00:48:21 - 00:49:53)

Ja, ganz genau. Das hat er eigentlich gemacht und zwar mit einer Technik, die nennt sich Approval Testing. Approval Testing wird eigentlich genommen, wenn du eine Blackbox Software hast und nur den Output nimmst und du weißt gar nicht, wie die Software inneren funktioniert. Das wird halt immer eingesetzt, wenn Unit Testing ein bisschen schwierig ist. Weil wir können ja, Doom will nicht wirklich unit testen, wenn wir es refactoren. Und oft kommt das dann im Einsatz bei PDF Dokumenten, HTML Reports oder großen JSON Dateien. Und Approval Testing macht halt Arbeiten mit Legacy Code sehr, sehr einfach. Und was hat diese Person gemacht? Sie hat ein neues Command Line Flag implementiert, was Doom ohne Grafik Output laufen lässt. Das bedeutet, der spricht wirklich nur diesen Doom Loop an, diesen Ticker, von dem ich vorhin erwähnt habe, und füttert den mit den LAMP Files, also mit dem user Input, nur verwirft halt den Grafikoutput. Und am Ende jedes Doom Levels kommt so eine Statistik, Map Name, wie lange du gespielt hast, also Zeit, und dann deine Statistik über Kills, Items und gefundene Secrets, also Geheimnisse. Und du merkst schon, wohin das führt. Der hat einfach Demos genommen, hat die durchs richtige Doom Spiel gejagt, mit Screen Output, hat die den Statistik Screen genommen, aufgeschrieben, in der Datei gepackt, hat dann ein neues Command Line Flag in Doom gebaut, was die visuelle Repräsentierung wegschmeißt. Und wenn man sein Doom jetzt mit so einem Lamp File füttert, dann kommen die Kill Statistiken als Text File raus. Somit kann der sagen, ich refactor und schmeiße einfach fünf und dreiig User Interaction Files, also Lump Files rein und teste die einfach. Der hat sich halt vorher ein Testset aufgebaut.

Wolfi Gassler (00:49:53 - 00:49:55)

Das wäre sowas wie Acceptance Tests.

Andy Grunwald (00:49:56 - 00:50:40)

Genau, die nennen das Approval Tests, aber ist genau das gleiche eigentlich. Und jetzt kommt was lustiges. Das bedeutet natürlich auch, wir können die ganze Sache so schnell laufen lassen, wie wir wollen, weil wir haben ja, wir müssen ja auf keine Interaction von Monstern mehr warten oder ähnliches, weil wir keinen visuellen Output haben. Wir können ja einfach den Ticker hochschrauben von dem Doom Loop und somit kann die ganze Sache schnell laufen. Also eigentlich wird die ganze Sache ohne Maus, ohne Audio und ohne gerendertes Spiel gespielt. Du hast sozusagen, Achtung, ein Headless Doom, jeder kennt einen Headless Chrome, der sich schon mal mit browser Automation auseinandergesetzt hat. Für die Leute, die es noch nicht wissen, ein headless Chrome ist, du nutzt einfach die Chrome Engine, um eine Webseite zu evaluieren, ohne dass ein Chrome gestartet wird. Und der macht das eigentlich mit einem Headless Doom.

Wolfi Gassler (00:50:40 - 00:50:48)

C hat ja für mich noch keinen Sinn gemacht. Ein Headless Doom macht schon wieder mehr Sinn, weil er kann die KIs füttern und ähnliche Geschichten machen. Das macht schon wieder mehr Sinn.

Andy Grunwald (00:50:48 - 00:50:56)

Du denkst so kompliziert, mit einem Headless Doom kann man Doom in GitHub actions laufen. Lassen und das hat wofür? Das ist die falsche Frage. Die Frage ist, warum nicht?

Wolfi Gassler (00:50:56 - 00:51:03)

Ich sehe schon in der ganzen Episode stelle ich mir schon die Frage immer, warum? Aber es ist Zweitausendein, warum nicht? Okay, alles verstanden.

Andy Grunwald (00:51:03 - 00:51:11)

Also es gibt jemand, der hat GitHub Actions, Headless Doom in GitHub actions laufen lassen. Und ich verlinke den Talk auch gerne unten in den Show Notes. Wahnsinn.

Wolfi Gassler (00:51:11 - 00:51:15)

Ich kann leider nicht dein Bing, Bing, bing. Aber es wäre wieder Zeit für ein Fun Fact, oder?

Andy Grunwald (00:51:15 - 00:51:45)

Einen habe ich noch. Und zwar, als das Spiel Doom released wurde, haben super viele College Studenten das dauerhaft durchgespielt. Und da ging echt die Produktivität auch in diversen Firmen runter, weil Doom halt überall auf den Firmenrechner installiert wurde. Und jetzt kommt das geile, sogar bei id Software selbst war das der Fall. Es gibt eine Story, da sagt der CEO von id Software we had to have conversations with some of our people. Projects weren't getting done. Also auch id Software Mitarbeiter haben wohl ein bisschen zu viel Doom gespielt.

Wolfi Gassler (00:51:45 - 00:51:49)

Nun gut, das heißt, es war das Homeoffice, der er so ungefähr.

Andy Grunwald (00:51:49 - 00:52:12)

Also wer Bock hat, auch mal einen Doom Port zu erstellen, es gibt einen Repository, nennt sich Doom Generic. Und Doom Generic ist ein runtergescriptetes Doom, um deinen eigenen Doom Port zu erstellen. Du musst sechs Funktionen implementieren, zweitausendein. Und da gibt es genug Dokumentation, wie das gemacht wurde für FreeBSD, für Linux und so weiter. Und dann kannst du es eigentlich auf jede Plattform selbst portieren.

Wolfi Gassler (00:52:12 - 00:52:17)

Jetzt hast du gesagt, es gibt diesen bekannten Spruch Can it run doom? Kannst du den jetzt noch abschließend erklären?

Andy Grunwald (00:52:18 - 00:52:59)

Es ist mehr oder weniger zum Volkssport geworden, Doom auf allen möglichen technischen Devices laufen zu lassen. Nicht weil Captures, nicht nur in Captures, weil es halt deterministisch ist, weil du es halt nachvollziehen kannst, ob du Seiteneffekte hast und so weiter. Und es gibt so einen ganzen Subreddit, der nennt sich zweitausendein it runs doom. Mal ein paar Highlights, was ich gefunden habe auf einer Canon Kamera, also auf einer Spiegelreflexkamera, auf einem Thermomix Klon, auf einem iPad, auf einem Laufband, auf einer Ikea Trad Free Lampe. Also die Lampe hat genug Power, um Headless Crow, Headless Doom laufen zu lassen. Auf einem digitalen Schwangerschaftstest wurde es zum Laufen gebracht.

Wolfi Gassler (00:52:59 - 00:53:02)

Ist gar nicht so lange her, da kann ich mich noch dran erinnern, das war vor ein paar Monaten.

Andy Grunwald (00:53:02 - 00:55:21)

Es gibt einen Hacker, der hat das Computersystem eines John deere Traktors gehackt und hat darauf Doom laufen lassen. Finde ich schon mal mega gut. Und mein absoluter Favorite, der war Anfang 2014. Und zwar hat die europäische Weltraumorganisation einen Satelliten ins All geschossen, der nennt sich Ops Sat. Opsat ist ein Satellit, der ausschließlich der Erprobung und Validierung neuer Techniken für die Missionskontrolle und bordseitige Satellitensysteme gedacht war. Dieser ganze Satellit hat ungefähr eine Größe von so einem Handgepäckkoffer bei so einem Flug. Also ist echt nicht groß, ÿousand, und der ist auch nur dreiig cm hoch. Aber die Computer, die auf diesem Satellit laufen, sind zehnmal leistungsfähiger als der derzeitige Standard bei ESA Raumfahrzeug. So, und was ist da jetzt passiert? Die ESA hat gesagt, liebe Community, ihr könnt da eigentlich deployen, was ihr wollt. Müsst euch nur anmelden, dann helfen wir euch ein bisschen und dann geben wir euch einen Zeitabschnitt, wo ihr was deployen könnt. Das hat sich ein Entwickler nicht zweimal sagen lassen und hat Doom auf einem Satelliten laufen lassen. Das ist wohl wahrscheinlich der erste Satellit, der Doom laufen lässt. Und ich verlinke den Talk dazu mal, der ist nämlich ganz besonders grandios, denn er wollte natürlich nicht nur Doom auf dem Satelliten laufen lassen, er wollte natürlich auch ein Screenshot davon haben, dass Doom auf dem Satelliten läuft. So, und er hat es geschafft, ein Doom Screenshot zu kriegen, wo im Hintergrund sogar die Erde zu sehen ist vom Satelliten. Und während des Talks beschreibt er unter anderem, dass er Doom immer wieder starten musste, wenn der Satellit die richtige Ausrichtung zur Erde hatte. Mega gut. Seine Herausforderung beim Portieren von Doom auf den Satelliten waren eigentlich nur die C Libraries. Das bedeutet, er musste entweder die Libs nutzen, die Libraries, die TE Libraries, die auf dem Satelliten vorinstalliert waren, oder das Spiel musste alles mitbringen, also statisch kompiliert werden. Und da hatte er Hilfe von jemandem von der ESA, von einem Software Engineer, der ein bisschen mehr Ahnung hat, was auf so einem Satelliten eigentlich alles so läuft. Aber was haben die noch mit dem Satelliten gemacht? Die haben ein kleines Modell trainiert, die haben das erste in Orbit Schach Spiel gespielt und die haben die erste Börsentransaktion im Allgemecht. Alles auf diesem ESA Satelliten fand ich auch genial.

Wolfi Gassler (00:55:21 - 00:55:50)

Ich habe mal kurz schnell nachgeschaut, was man eigentlich wirklich braucht, um Doom laufen zu lassen. Es ist eigentlich relativ wenig. Du brauchst einen Prozessor, der 2,5 Millionen Instructions pro S handeln kann, also so ein er mit 25 MHz oder so, der schafft es schon, damit du die Frames auch pro second berechnen kannst. Und darum ist vielleicht die Trafi Lampe auch fähig, das laufen zu lassen. Wobei wir ja nicht wissen, ob das die Frames per second auch wirklich schafft oder ob das dann langsamer läuft.

Andy Grunwald (00:55:50 - 00:55:57)

Ich glaube, das läuft dann alles ein bisschen langsamer. Aber es läuft. Darum geht es ja, weil der digitale Schwangerschaftstest, der wird, glaube ich auch nicht so viel Rechenpower haben.

Wolfi Gassler (00:55:57 - 00:56:02)

Ja, da funktioniert es aber relativ gut, glaube ich sogar. Ÿousand, sehr komplexes Teil.

Andy Grunwald (00:56:02 - 00:56:15)

Was mich richtig umgehauen hat, ist, es gibt auch noch Doom in Grafana. Und zwar kann das Grafana Histogramm Doom spielen. Grafana selbst hat dieses Experiment gemacht. Verlinken wir auch in den Show Notes.

Wolfi Gassler (00:56:15 - 00:56:19)

Aber es gibt wirklich Leute, die haben zu viel Zeit. Und Firmen scheinbar auch.

Andy Grunwald (00:56:19 - 00:56:59)

Das ganze Ding mit Doom ist noch nicht zu Ende. Also da könnt ihr noch so viel Zeit, wie ihr wollt, reinstecken. Und ich denke, da werden wir in Zukunft auch noch ein paar richtige gute Sachen sehen. Wer immer noch nicht genug hat, kann in die Subreddits it runs doom oder in den Subreddit doom selbst gehen. Gibt es nur so Kram. Es gibt auch noch zwei gute Bücher, aber das Game Engine Black Book, da hat jemand den kompletten Doom Source Code gelesen. Könnt ihr euch kaufen, hat ein Code Review gemacht und hat euch und erklärt da einfach, wie alle Tricks funktionieren. Und dann gibt es auch noch ein Buch, nennt sich Masters of Doom, how to guys created an empire and transformed pop culture. Denn ich glaube, das kann man nicht Abstreiten, Doom hat eine Art Popkultur erzeugt.

Wolfi Gassler (00:56:59 - 00:57:15)

Ich habe mir jetzt gerade Doom als JavaScript geöffnet. Der Sound, der gerade in meinem Kopfhörer gekommen ist, der hat mir gerade meinen Kopf fast explodieren lassen. Aber ich werde es mal ausprobieren. Möchte auch mal wieder im Browser zumindest Doom spielen, was du nicht geschafft hast, dass ich wenigstens mal ein paar Schüsse abfeuere.

Andy Grunwald (00:57:15 - 00:57:58)

Ich bin zufrieden. Ich habe meine Antwort auf die Frage, warum ist Doom eigentlich so relevant und populär in der Softwareentwicklungswelt? Und irgendwie habe ich jetzt auch Lust, Doom mal auf irgendeine Plattform zu portieren. Ich muss mir jetzt nur irgendwas suchen. Ich habe hier so einen dokumenten Scanner, der hat auch einen Screen. Ich weiß nicht, vielleicht portiere ich dir mal darauf. Gibt uns mal Feedback, wie euch die Folge gefallen hat. Ist eine etwas andere Art einer Folge geworden. Etwas zur Popkultur kann man vielleicht sagen. Vielleicht hatte ihr ein bisschen Spaß oder ich habe euch in eure Kindheit zurückgeholt. Oder ihr zockt heute Abend eine Runde Doom oder Wolfenstein D. Von daher dabei wünsche ich auf jeden Fall viel Spaß. Kommt gerne mal in die Disco Community und korrigiert mich auch, wenn ich beim BSP Algorithmus was Falsches gesagt habe, denn ich bin kein Grafik Engineer. Zweitausendein, das muss ich zugeben, hat auch ein bisschen Anstrengung in meinem Kopf gebraucht.

Wolfi Gassler (00:57:58 - 00:58:12)

Und wir haben natürlich ganz, ganz viele Links von Andy in den in den Show Notes. Da könnt ihr euch rein nerden bis zum Gehtnichtmehr. Und wenn ihr dann Doom auf euren Herd oder auf eure Waschmaschine bodiert habt, bitte kommt zu uns in die Discord Community und sagt uns Bescheid.

Andy Grunwald (00:58:13 - 00:58:14)

Das war's von uns. Bis später.