Also ich war mal auf einer Lesung und die Autorin wurde gefragt „Warum spielen ihre Bücher immer in London, sie leben doch in Deutschland?“. Und die Antwort von ihr war „Weil ich dann die Reisen nach London von der Steuer absetzen kann“
Scheint also zu klappen…
Ja ich sehe schon das nächste SF Special zu der Geschichte der GDC, die gibt es ja auch schon seit 1987. Das könnte man natürlich auch mit dem Treffen \ Interviews mit alten Spieleentwicklern verbinden. Dann gibt es auch wieder neue Anekdoten
te Und das ganze ohne den Stress irgendwelche Click-Bait-Stories am besten live von der Veranstaltung zu machen.
Hallo zusammen,
vielleicht gibt es hier jemanden, der mir bei einer (technischen) Verständnisfrage helfen kann.
Immer mal wieder bei Simulationen heißt es: Was genau das Spiel im Hintergrund macht oder welche Auswirkungen XY auf das Spiel hat, weiß man nicht.
Ist der Code von Spiele so verschlüsselt? Oder schlicht zu umfangreich?
Bei RCT scheinen die Sachen ja aber klar zu sein. Siehe Video von Marcel Vos der erklärt, welchen maximalen Preis ich für welche Attraktion nehmen kann. Hat das mit dem offenen Code aus OpenRCT zu tun? Und existiert der nur, weil er von Hand nachgebaut wurde (so verstehe ich das erwähnte reverse engineering)?
Danke für ein paar erhellende Eindrücke!
Soweit ich das verstehe:
- Den Original-Assemblercode von RCT kennt niemand, den hat Chris Sawyer nicht veröffentlicht.
- OpenRCT2 ist ein Reverse-Engineering-Projekt, das aber wohl sehr nah am Original dran ist. Dessen Code kann man einsehen und daraus dann natürlich auch alle Mechaniken ableiten.
- Wenn wir in unserer Folge sagen, “Was das Spiel im Hintergrund macht, weiß man nicht”, dann meint das “man” hier “den Spieler / die Spielerin”.
Man kann Programme durchaus auch Disassemblieren, also von Maschinensprache in Assemblercode zurückübersetzen. Man erhält dabei zwar nicht den originalen Ursprungscode, aber mit Ahnung von Assembler kann man damit den Programmablauf aufwändig Schritt für Schritt analysieren. Auch kann man das Programm mit einem Debugger laufen lassen, um bspw. nachzuverfolgen, welche Daten im Speicher sind und wann das Programm welche Daten wie ändert. Zusätzlich kann man sich auch mit einem Hex-Editor die Programmdaten im Detail angucken. Ist halt klassisches Reverse-Engineering und nicht gerade trivial und zudem sehr zeitaufwändig.
Generell sind Spiele nicht in dem Sinne „verschlüsselt“. Das Problem ist, dass Assembler selbst nicht Maschinencode (die berühmten 0en und 1en), sondern eine primitive Programmiersprache ist, die prozessorspezifisch ist und direkt Prozessorbefehle anspricht. z.B. wird folgender Code
pub fn add_numbers(a: u32, b: u32) -> u32 {
a + b
}
zu folgendem Assembly (das ist jetzt sogenannter Intel Assembler):
example::add_numbers:
subq $24, %rsp
movl %edi, %eax
movl %eax, 16(%rsp)
movl %esi, 20(%rsp)
movl %eax, %edi
addl %esi, %edi
movl %edi, 12(%rsp)
cmpl %eax, %edi
jb .LBB0_2
movl 12(%rsp), %eax
addq $24, %rsp
retq
Da rennt jetzt schonmal gleich jeder der Assembly kann nach draussen, das ist keine gute Addier-Routine, weil ich den Compiler angewiesen habe nicht zu optimieren. Und früher waren die Compiler nicht so gut im optimieren, deswegen wurde noch viel zu Assembly gegriffen (und wohl bei RCT zum letzten Mal). Das ist heutzutage um Meilen besser.
Dieser Code wird dann von einem anderen Tool (dem Assembler) zu (Intel)-Maschinencode übersetzt, das ist annähernd unlesbar. Wortwörtlich baut der Assembler/Assemblierer das Programm zusammen. (Programmiernerds die mitlesen - ja, da sind noch mehr Programme beteiligt, aber die tun hier nichts zur Sache)
Man kann das auch umgekehrt machen, dazu gibt es sogenannte (es steckt im Namen) Disassembler - die zerlegen das Programm dann wieder in Assembly. Es gibt sogar Tools, die das dann wieder in eine Hochsprache, z.B. C übersetzen.
Das Problem: Den Code zu haben bringt einem im Sinne von Verständnis erstmal nichts - es fehlt Dokumentation, eine Idee, was der intendierte Programmablauf ist, usw, usw. Insofern ist das Problem in der Tat die Größe der Ausgangsbasis. Stell dir mal hunderttausende Zeilen dieser Basissyntax da oben vor. „Bewege Zahl an Platz 4“… Da siehst du vor lauter Bäumen den Urwald nicht mehr.
Insofern ist strukturiertes re-engineering oft einfach der bessere Weg. Sicherlich hat in dem Prozess jemand einen Disassembler oder einen Debugger (ein Tool, mit dem sich der Programmablauf beobachten lässt) mal angeworfen.
Das letzte was im Weg steht ist das Urheberrecht. In dem Moment, in dem ich die Originalquellen gelesen habe, mache ich kein reverse engineering mehr, sondern baue eine Ableitung des Originals. Und dann kann Chris Sawyer daran (zu Recht!) seine Rechte einfordern.
OpenRCT ist aber wahrscheinlich für alle Seiten ein Gewinn, weil es ja eben immernoch die Spieldaten des Originals braucht.
Aber eine stillschweigende Vereinbarung in dieser Szene ist eben auch, dass man eben mit den Originalautoren nicht in Kontakt tritt, um eben solche rechtlichen Sachen sehr sauber zu halten.
Gib es zu: Mháire und Rahel arbeiten doch schon LÄNGST an einer Folge “Die Welt von… Freizeitparks”! ![]()
Das ist eben der Fluch der Kompetenzzuschreibung. Demnächst werdet Ihr vermutlich als Experten zur Lösung des Rentenproblems angefragt. ![]()
Wo Du es erwähnst, da gab’s schon mal eine recht ausführliche Doku zu von Jörg Langer.
Ich find es übrigens sehr erstaunlich, dass es sowohl zu Transport Tycoon, Rollercoaster Tycoon als auch Locomotion jeweils ein eigenes Open-Source-Projekt gibt, das die Spiele weiterpflegt. Welcher andere Spieleentwickler hat so einen Track Record? (auch wenn er scheinbar kein so großer Fan davon ist)
Eine interessante Folge, vielen Dank dafür! Ich habe weder Themepark noch Rollercoaster Tycoon damals gespielt, obwohl ich bei beiden durchaus geliebäugelt habe. Umso schöner, die Spiele jetzt ein bisschen zumindest als Hörer kennen zu lernen. Interessant auch das eingebettete Entwickler-Interview.
Ich finde das nicht so abseitig, aber offensichtlich bin ich damit allein ![]()
Oder als lustigen Stay Forever Technik Exkurs ![]()
Selten war ich so 100% mit Gunnar auf einer Wellenlänge wie bei der Intro zu diesem Cast, kann alles bis einschließlich „Wir sollten mal wieder ein Warhammer-Spiel besprechen“ unterschreiben (solltet ihr, Chaos Gate bzw. Final Liberation wann?) und ich habe auch ordnungsgemäß für Homeworld abgestimmt (was ich super spannend finde, allerdings nicht die nötigen PC-Spielergene besitze um mehr als die ersten 3 Missionen jemals zu Gesicht bekommen zu haben, weil es da schon 4D-Schach für mich wird).
Den Cast fand ich trotzdem super, ganz besonders die erklärenden Worte eures Gastes zu den Programmier-Tricks im RCT fand ich toll. Ich liebe solche Detail-Analysen.
Definitiv. Initial meiner Einschätzung nach nicht nur ein paar mal sondern das war elementar dafür dass OpenRCT existiert: Wenn du dir den ersten Commit nicht komplett falsch verstehe funktionierte das so, dass die original exe mit dem Rest vom Code zusammengelinkt wurde. Dank nicht vorhandener Address Space Layout Randomization landet RCT Code immer an den gleichen Adressen und called dann (aus mir nicht ganz ersichtlichen Gründen) StartOpenRCT(). Dessen jetzt in C geschriebener Code popelt dann ziemlich wüst direkt im Adressraum rum um den Hauptgameloop durch eigenen Code zu ersetzen. Das alles bekommt man nur hin, wenn sich jemand vorher sehr genau den dekompilierten Assemblycode angeguckt hat.
Dieser initiale Linux Support Commit ist auch faszinierend: Da werden dann verschiedene Bereiche aus der Exe direkt mittels mmap in Zieladressbereiche gemapped. Da mindestens der platformabhängige Code zu dem Zeitpunkt schon soweit in C/C++ nachprogrammiert war, funktioniert das trotzdem, weil es dem noch nicht angefassten Maschinencode egal ist, ob er innerhalb von Linux oder Windows läuft. Solange es x86 ist.
Das Programm auf der Diskette ist wie ein fertig gebackener Kuchen. Man kann erstmal nicht ohne weiteres auf das Rezept schließen. Mittels aufwändiger Analysen kann man vielleicht die genauen Zutaten und sogar deren Mengen ermitteln, aber für ein Rezept braucht es immer noch jemanden der sich alles anschaut und versucht zu daraus schlau zu werden und aus den reinen Zutaten wieder ein Rezept baut, dass man auch verwenden kann.
Ingenieur (für Hydraulikfilter) hier: wir benutzen Solidworks, Excel und browserbasierte Auslegungssoftware. Und bei allem ist die Antwort: Nein! ![]()
Und zu hören was Gunnar und alles zutraut, gibt einem ja Impostersyndrom! ![]()
Edith: das war als Antwort auf Chris’ Frage gedacht, ob wir mehrere Überwachungsfenster gleichzeitig offen haben, aber irgendwie ist meine Antwort nach unten gerutscht.
Vielen Dank für die wirklich hilfreichen Erläuterungen. Das hat mir weitergeholfen. Von den detaillierten Infos bis hin zur Kuchen Analogie. Danke @Chris @mibbio @skade @dividuum @EarMaster Einfach eine gute Community hier!
Ich liebe oft die Metaphern hinter „Aufbauspielen“, bin leider aber immer total schlecht. Habe damals Theme Hospital, Transporter Tycoon, Zoo Tycoon und eben auch RCT ausprobiert. RCT war das einzige Spiel, bei dem mich das Szenario so gefesselt hat, dass ich es immer wieder probiert habe (mit teils größeren Abständen von Jahren) bis es irgendwann klick gemacht hat und ich mehr oder wenig gut darin geworden bin. ![]()
Tolles Game - kann man immer wieder spielen. ![]()
Gerne. Macht auch Spass. Ich mach Compiler beruflich und es ist schon eine gute Übung, das mal für Leute zu grob zu erklären, die nicht vom Fach sind.
(Schade finde ich allerdings, dass niemand drauf reagiert hat, dass ich dem Rollercoaster-Thema entsprechend als Beispielsprache natürlich… Rust verwendet habe!)
Hat jemand von Euch Erfahrung mit der Switch-Version? Seit ich die Switch habe, sind mir PC-Spiele zu anstrengend; ich sitze eh schon den ganzen Tag vor dem Rechner. Aber irgendwie kann ich mir RCT nicht auf einer Konsole mit Controller vorstellen…
Tolle Folge! Ich war damals selbst Mitglied im European Coaster Club und im RCCGB, und auch bei den American Coaster Enthusiast. Letztere haben 1997 mit 4 Reisebussen durch England alle Holzachterbahnen (und fast alle aus Stahl) abgeklappert, und ich hab mich da mit drangehängt. Damals gab’s übrigens keine einzige Holzachterbahn in Deutschland. (Und selbstverständlich haben auch Holzachterbahnen sogenannte “upstops”, also Vorrichtungen dass die Wägen nicht nach oben abheben können. Andernfalls wäre kaum “Airtime” möglich.)
Jedenfalls hatten wir in allen Parks sogenannte “Exclusive Ride Time”, also ne Stunde auf der jeweils angesagten Achterbahn vor oder nach den offiziellen Öffnungszeiten des Parks. Nicht auszudenken, dass da vielleicht Chris Sawyer dabei war…
Als 1999 RC Tycoon rauskam, hab ich mich sooo darauf gefreut dass ich mir das Spiel auf dem Flughafen in Singapur gekauft hab, nur damit ich im Flieger nach Hause schonmal die Anleitung in den Händen habe. Die Schachtel habe ich jetzt noch im Schrank stehen.
Gespielt hab ich’s ausschliesslich als Sandbox, d.h. ich hab das erste Szenario nie abgeschlossen (oder vielleicht einmal), weil ich einfach nur meinen Park gestalten wollte und den Leuten beim Rumwuseln zuschauen wollte. Ich finde übrigens, im Podcast ist das Thema Anstehschlangen zu kurz gekommen. Mir hat es auch viel Spass gemacht, die Wege dafür (die ja die einzigen mit Kollisionsabfrage waren), interessant zu gestalten und nicht einfach nur ein langweiliges Zick-Zack auf nem grossen Platz.
Noch was zu Loopings: der erste Achterbahnlooping war wirklich aus Holz und hat auch funktioniert. Nur war die Konstruktion so aufwändig, dass sich das Konzept bis zur Stahlachterbahn nicht durchgesetzt hat.