Reverse Engineering der NLT II

[gaor]

Naja, ich dachte eben, Modding ist vor allem dann stark vereinfacht, wenn der Code schön modular aufgebaut ist. Da denk ich nunmal direkt an Objektorientierung, auch wenn es natürlich auch anders ginge.

[Hindro]

Objektorientierung ist schön, modularer Aufbau sicher auch.

Das Ziel sollte mMn sein, so viel wie möglich über Konfiguration und so wenig wie möglich über Code zu realisieren.
Für Schick HD sind sie ja den Weg mit den Bibliotheken und neuprogrammierung gegangen. Die Idee mit XML-Dateien und Javascript erlaubt ja eine Menge für Modder.

Ich meine ich hätte ende der 90er Jahre mal einen Editor für Schick Städte und Dungeons gesehen. Auf so einem Raster kann jeder Laie eine Stadt oder einen Dungeon entwerfen, ein paar Monster und Schätze einbauen. Noch ein paar Tipps in die Kneipendialoge, eine Verknüpfung mit der Karte das wäre dann wirklich keine Raketenwissenschaft.

[Shihan]

Das Ziel sollte mMn sein, so viel wie möglich über Konfiguration und so wenig wie möglich über Code zu realisieren.
Für Schick HD sind sie ja den Weg mit den Bibliotheken und neuprogrammierung gegangen. Die Idee mit XML-Dateien und Javascript erlaubt ja eine Menge für Modder.

Das ist ja auch mittlerweile der Königsweg. Jedes AAA-Spiel macht das so, dass die meisten Sachen nicht mehr über Code, sondern über Daten erzeugt werden. Moderne Entity-Component-Systeme sind geradezu prädestiniert für Modding.

Allerdings ist der Ansatz so einfach nicht und braucht eine saubere und wohldurchdachte Architektur auf Code-Ebene (meist über OOP) und in einer Datenbank (wobei da sowohl relationale wie auch nicht-relationale DBMS genutzt werden). Anders gesagt: Ohne objektorientierte Architektur mit modularem Aufbau würde es fast nicht möglich sein. Also wäre das nicht nur "schön", sondern eigentlich verpflichtend

Also ist es schon sinnvoll, dass ein Quelltext-Klon von SCHICK erzeugt wird. Denn nur damit kann man genau nachvollziehen, was dort an Regeln umgesetzt wird. Ohne das wird es schwierig, gleichartiges Verhalten zu erzeugen (wenn man das denn will).

[gaor]

Also ist es schon sinnvoll, dass ein Quelltext-Klon von SCHICK erzeugt wird. Denn nur damit kann man genau nachvollziehen, was dort an Regeln umgesetzt wird. Ohne das wird es schwierig, gleichartiges Verhalten zu erzeugen (wenn man das denn will).

Um das nochmal klar zu machen: Einen solchen Quelltext-Klon haben wir de facto bereits jetzt. Die 5 Funktionen, die noch leichte Abweichungen vom Original-Kompilat aufzeigen, sind komplett verstanden. Bei den Abweichungen handelt es sich um Compiler-spezifische Abweichungen im Maschinencode. Die Funktionen tun schon exakt das gleiche wie die Originalfunktionen, nur der Maschinencode unterscheidet sich ganz leicht an einzelnen Stellen.

Falls also jemand anfangen will, "gleichartiges Verhalten zu erzeugen" - legt los! Jetzt ist der richtige Zeitpunkt, um zu diskutieren: Will man wirklich alles neu schreiben oder will man den existierenden Code nur "modernisieren" (also inkrementell verändern)? Will man bei C bzw. C++ bleiben, oder will man eine andere Programmiersprache einsetzen? Will man Objektorientierung oder gibt es passendere Programmierparadigmen? Wie genau setzt man die gewünschte MODifizierbarkeit technisch am besten um?

[Shihan]

Falls also jemand anfangen will, "gleichartiges Verhalten zu erzeugen" - legt los! Jetzt ist der richtige Zeitpunkt, um zu diskutieren: Will man wirklich alles neu schreiben oder will man den existierenden Code nur "modernisieren" (also inkrementell verändern)? Will man bei C bzw. C++ bleiben, oder will man eine andere Programmiersprache einsetzen? Will man Objektorientierung oder gibt es passendere Programmierparadigmen? Wie genau setzt man die gewünschte MODifizierbarkeit technisch am besten um?

Meine Erfahrung mit Legacy-Code (aus dem industriellen Umfeld) sagt mir bei sowas instinktiv: Neumachen! Alte Algorithmen übernehmen und anpassen, aber vieles andere wie Datenorganisation auch neu machen. Habe schon zu viel Zeit versenkt alten Code inkrementell zu ändern. Neuschreiben wäre da bisweilen wirklich sinnvoller gewesen. Das erfordert aber oft auch Mut (ähnlich wie Refactoring). Und wenn man keine Deadline hat, finde ich es schöner, es dann direkt sinnvoll und nicht dirty zu machen.

Nur sind das meine Erfahrungen. Insbesondere rein prozeduraler Code macht mich oft fertig. Scheinbar denke ich zu sehr objektorientiert
Aber YMMV! Andere kommen evtl. besser damit klar.

In jedem Fall fände ich es sinnvoll, jetzt auf objektorientierte Architektur umzusteigen, wenn man insb. das Modding im Blick hat. Rein prozedural ist das wohl sehr aufwendig.

[Rabenaas]

Ich will keinem seine Objektorientierung madig reden, aber der Begriff ist so ein gummiartiges Buzzword. Bedeutet OOP das Paradigma von Smalltalk, JavaScript, Common Lisp oder C++? Saubere Modularisierung lässt sich auch mit rein imperativen Sprachen wie *schluck* Pascal und rein funktionalen wie Haskell umsetzen. Interessant ist der Aufsatz von Janestreet Capital, warum die bei Ocaml bewusst auf das O verzichten.

Aber wie auch immer. Als vernünftige Sprachen für eine Neuimplementierung sehe ich im Moment Python oder Rust.

[gaor]

Python oder Rust? Welche Computerspiele sind denn in Python oder Rust programmiert (ganz ehrlich, ich habe eigentlich keine Ahnung von dem Thema)? Wenn man eine einigermaßen performante Grafikengine haben will, vielleicht mit Hardwarebeschleunigung, dann doch eher nicht, oder? Natürlich ist Grafik und generell Performance keine Priorität bei einem Klon von Schick, aber man weiß andererseits nie, wo das noch hingeht...

Nicht falsch verstehen: Ich bin ein großer Python-Fan und programmiere fast alles, was ich so programmiere, in Python. Das würde sicher auch dazu führen, dass ich hier aktiver mitmachen könnte. Aber am Ende wär's halt blöd, wenn die Performance spürbar unter dieser Wahl leidet.

Und Performance ist bei Python prinzipiell schon ein Thema. Ich implementiere mit NumPy aufwendige numerische Dinge und stelle da schon immer wieder fest, dass man genau wissen muss, wo bei Python die Flaschenhälse sind (zum Beispiel for-Schleifen), sonst kann man  böse reinfallen - im Gegensatz zu Sprachen wie C und Julia, wo man quasi das tut, was einem am natürlichsten erscheint (zum Beispiel for-Schleifen!) und es läuft dann auch automatisch ziemlich schnell.

[Boneman]

Wie wär's mit Unity?

[Rabenaas]

Python oder Rust? Welche Computerspiele sind denn in Python oder Rust programmiert (ganz ehrlich, ich habe eigentlich keine Ahnung von dem Thema)? Wenn man eine einigermaßen performante Grafikengine haben will, vielleicht mit Hardwarebeschleunigung, dann doch eher nicht, oder? Natürlich ist Grafik und generell Performance keine Priorität bei einem Klon von Schick, aber man weiß andererseits nie, wo das noch hingeht...

https://en.wikipedia.org/wiki/Yo_Frankie!
https://en.wikipedia.org/wiki/Frets_on_Fire
https://en.wikipedia.org/wiki/Sintel_The_Game
https://en.wikipedia.org/wiki/A_Vampyre_Story

Moment mal, wir unterhalten uns über eine Reimplementierung der alten Engine mit den alten Assets, oder?
Das Spiel ist von '92 und hat keine Echtzeitanforderungen. Die Performance von Python ist absolut unkritisch.

Es gibt eine Reihe von Spiele-Engines für Python, u.a. PyGame, Blender Game Engine (Yo Frankie!) und Panda3D. Nebula kann man auch damit ansprechen.

Rust ist ein modernes drop-in für C/C++, also systemnahe Programmierung. Damit sollten alle Bibliotheken funktionieren und die Performance auch nicht schlechter sein als C++, wenn man vernünftig programmiert.

[Hindro]

die erste Frage ist halt, wo man hin will

Vermutlich wird fast immer der erste Schritt sein die "DSA-Engine", die "Visualisierungs-Engine" von den Daten zu trennen
um ein Abstraktionsniveau zu erreichen wo man beliebige Kartenausschnitte, Städte und Dungeons übergeben kann.

[Rabenaas]

Die gesamte Spielelogik ist auf Raster ausgelegt. Wenn wir davon abweichen wollen, dann wäre es wohl in der Tat einfacher, man fängt ganz bei 0 an. Oder man folgt Bones Rat und spielt die HD.

[gaor]

Ja genau, es gibt schon ein Remake, das sollten wir immer im Kopf behalten. Noch ein Remake macht nur Sinn, wenn wir die Einfachheit des Originals beibehalten. Ob man da dann hexagonale oder quadratische Schlachtfelder macht, ist nicht entscheidend. Aber die große Stärke der 2D-Rasterstädte und der festen Reiserouten auf einer Reisekarte in Vogelperspektive wäre, wie einfach man neue Erweiterungen machen könnte, wenn man das konsequent durchzieht. Man muss sich nicht so viel mit Kosmetik herumschlagen, sondern kann sich ganz auf geile Dialoge und Hintergrundgeschichten konzentrieren. Man könnte die Spielwelt ziemlich easy erweitern, weil es ja nur eine 2D-Reisekarte mit Linien (Routen) und Punkten (Städten, Dungeons) ist, wobei die Städte/Dungeons wiederum aus simplen Klötzen zusammengesetzt sind. Dafür kann man auch mal eben einen leicht zu bedienenden Spieleditor implementieren. Bei echtem 3D-Krams oder frei begehbaren 3D-Spielwelten ist die Hürde für MOD-Newbies viel höher, würde ich meinen.

Sehr wichtig wäre dementsprechend meiner Meinung nach, dass man Quests mit anspruchsvollen Dialogen, abwechslungsreiche Zufallsereignisse/-begegnungen und anderen inhaltlichen Krams komfortabel modden kann. Sehr cool fände ich auch mehr Möglichkeiten bei der Charaktererschaffung. Tja und dann kommt die Frage nach dem Regelwerk. Soll die auch modular sein? Dann könnte man DSA 1, 2, 3, ... auswählen. Aber das ist wahrscheinlich zu krass, oder?

EDIT: Da fällt mir grad auf, dass wir die GEN.EXE noch nicht reverse engineered haben. Sollten wir das noch tun?

[Hindro]

Genau die Einfachheit fände ich spannend, man kann das Raster vielleicht etwas vergrößern und die Auflösung der Grafiken aktuellen Monitoren anpassen. Man könnte beliebige 2D-Karten Laden. Wege als Polygonzug aus einer XML Datei laden und Wegstücken Zufallsbegegnungen und Landschaft zuweisen. Städte vergleichbar definieren und so Abenteuer überall in Aventurien stattfinden lassen.

Klar Modular und Objektorientiert übergibst du das DSA-Engine-Objekt an den Hauptverwaltungs-Thread und da könnte man in der Tat ein Abstraktes Basisobjekt haben und wahlweise eine DSA-Engine der Version DSA 1,2,3,4,5 übergeben. Es würde aber jedem spieler möglich sein, seine Lieblingsengine zu nehmen.

Die GEN.EXE würde ich nicht reverse engeneeren, was die tut/ tun soll ist ziemlich klar, die ist vielleicht schneller neu geschrieben.

[Shihan]

Ihr schreibt viel zu viel. Jetzt muss ich die Antwort themenspezifisch aufteilen

Thema Technologie:
Irgendwann geisterte hier im 1. Thread mehrmals die Idee  C++ als Basis und skriptbar mit Lua herum. Die finde ich persönlich immer noch sehr gut. Mit Lua sind verdammt viele (auch sehr große) Spiele erfolgreich geskriptet worden. Es ist leicht erlernbar (ähnlich wie Python, zugegeben) und ziemlich einfach einbettbar (besser als Python).

Für die Basis, also Audio und Video, wäre eine Nicht-Skriptsprache wahrscheinlich besser. Bspw. würde ich das Laden von Ressourcen modularisieren, mit Loadern für die Originaldaten und Loadern für neue Formate (PNG bei Bildern, OGG/MP3/WAV bei Sounds & Musik). Somit könnte man für neue Daten (Landkarten, Städtetexturen, NPC-Bilder,...) in modernen, vernünftigen Formaten haben und sie trotzdem im Spiel ganz parallel zu den existierenden Daten nutzen, ohne dass ein Unterschied merkbar ist.
Diese Aufteilung bzw. Architektur ist meiner Erfahrung nach mit einer Sprache wie C++ besser zu machen.


@Rabenaas: Was genau ist denn an Rust so gut, dass Du das vorschlägst? Ich weiß außer der Tatsache, dass es für die Rendering-Engine vom Firefox verwendet wird, recht wenig darüber. Die Syntax hab ich mal grob angesehen, die ist reichlich hässlich. Aber irgendwas kann die Sprache ja bestimmt. Wenn Du da Erfahrungen hast, immer raus damit


Thema Aufbau:
Was wäre denn, wenn man alles Engine-spezifische in einen systemnah geschriebenen Teil legen würde? Damit meine ich, dass Darstellung der verschiedenen Screens (Reiseansicht, Stadtansicht, Inventar, Kampf, etc.) völlig unabhängig vom Regel/Quest/Simulations-Teil abläuft? Die Screens nehmen einen Snapshot der Welt und stellen den dar. Mehr würde da nicht passieren.

Daneben gibt es dann einen Skript-Teil, der die Regeln darstellt, Quests durchführt, NPCs agieren lässt, die Welt simuliert und Kämpfe berechnet. Komplett ohne Ausgabe, die ist hier nicht wichtig. So könnte man diesen Teil ganz gut mehrfach erstellen, je ein Set an Skripten für jedes verschiedene Regelwerk. Und die eigentliche Schick-Engine wäre davon losgelöst.

Die Auftrennung sieht am Anfang evtl. etwas komplex aus. Aber mit der Zeit merkt man immer mehr, was man sich für Ärger und Probleme erspart hat.
So wurde in fast allen Firmen, in denen ich war, Software gebaut. Hab mir das übernommen und bring das gerade meinem Azubi bei


Was denkt ihr?

[Rabenaas]

@Rabenaas: Was genau ist denn an Rust so gut, dass Du das vorschlägst? Ich weiß außer der Tatsache, dass es für die Rendering-Engine vom Firefox verwendet wird, recht wenig darüber. Die Syntax hab ich mal grob angesehen, die ist reichlich hässlich. Aber irgendwas kann die Sprache ja bestimmt. Wenn Du da Erfahrungen hast, immer raus damit

Es ist nicht C++. Die coolen Jungs spielen damit. Es wäre ein kompilierter Kompromiss.

An Lua habe ich auch gedacht. Ich mag Lua. Aber bei Python gibt es viel mehr Programmierer und Bibliotheken. Das einzige, was gegen Python spricht, sind mMn diffuse Ängste vor Performanceverlusten. Aber alles schnelle findet eh in den Bibliotheken statt.

"The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones."
"I invented the term 'Object-Oriented', and I can tell you I did not have C++ in mind." Alan Kay
"How C++ is like teenage sex:
1. It is on everyone's mind all the time.
2. Everyone talks about it all the time.
3. Everyone thinks everyone else is doing it.
4. Almost no one is really doing it.
5. The few who are doing it are: A. Doing it poorly. B. Sure it will be better next time. C. Not practicing it safely."

[Shihan]

Großartig!

Aber mal ernsthaft: Das Argument für Python ist auch eins gegen Rust. Kaum Bibliotheken und Programmierer. Zumindest frag ich mich, ob hier tatsächlich jemand Rust genug beherrscht oder neben der eigentlichen Entwicklung noch lernen möchte. Ich z.B. habe großes Interesse, an diesem Projekt zu arbeiten. Aber ob ich Zeit, Lust und Muße habe, erst noch eine Sprache zu lernen, weiß ich nicht. Parallel lernen führt i.d.R. zu grobem Unfug und sollte deshalb vermieden werden.

Außerdem brauchen wir so ein Hipster-Zeug nicht

[Hindro]

Die Wahl der Programmiersprache sollte abhängen von:
- der Zielplattform
- der vorhandenen Bibliotheken (wer will dauernd das Rad neu erfinden)
- technischen Anforderungen des Projektes
- für alle leicht verfügbare einheitliche Entwicklungsumgebung

Die Anforderungen hier sind mMn (ohne Anspruch auf Vollständigkeit):
- Objektorientierung
- dynamisch ladbare Klassen und Bibliotheken
- 2D- Grafikausgabe
- XML Unterstützung

Eclipse, github, C++ wäre sicher eine Variante

[Rabenaas]

Jeder kann nehmen, was ihm Spaß macht. Ich will keinen missionieren. Aber die richtigen Gründe für C++ sind mMn (in aufsteigender Reihenfolge) Hardwarenähe, extreme Geschwindigkeitanforderungen, legacy code und Masochismus. *Letzter Kommentar in diese Richtung.*

Übrigens kann Rust auf C-Bibliotheken zugreifen.

EDIT: https://www.cliki.net/Humor

[Shihan]

Meiner Meinung nach ist einer der wichtigsten Gründe nicht genannt (und wird generell bei solchen Diskussionen gern vergessen):

Was können die Leute?

Da ich z.B. seit >15 Jahren mit C++ arbeite, ist mir das am liebsten. Und für mich am sinnvollsten. Aber das hängt an der Gruppe. YMMV.


Also wäre noch vor einer solchen Entscheidung zu klären, wer überhaupt mitmachen will, ob wir daraus ein "offizielles" Projekt machen oder jeder für sich was macht, wer welche Vorerfahrung hat, wer was beisteuern kann und will,...


Äußert euch!




(Generell tendieren solche Projekte ja leider dazu, wieder einzuschlafen. Deshalb sollte man sich m.M.n. nicht zu viel vornehmen und die Einstiegshürden nicht zu hoch setzen.)

[Mirko]

Hallo,

eigentlich wollte ich mich die letzten zwei Monate immer mal melden, hab mich aber dann immer wieder von anderen Dinge ablenken lassen. Ich hatte mich ja im Oktober/November ein wenig mit der Wegfindung im Kampfsystem beschäftigt und da noch was gefunden, wo ich hier immer noch einen Text zu schreiben wollte. Außerdem habe ich noch ein paar lokale Änderungen (2 Bugfixes, die ich hier schon mal beschrieben hatte + umbenannte Funktionen/Variablen), die ich mal noch hochladen müsste, aber das würde ich gerne vorher noch mal sauberer organisieren. Ostern haben wir hier aber Besuch, bis dahin wird das also vermutlich nichts mehr.

Zum Thema "Nächste Schritte": Soweit ich es bei meinen Versuchen sehen konnte, haben wir dank Henne einen C-Quellcode der Schicksalsklinge, mit dem man das Spiel kompilieren und (in gewissen Grenzen) auch modifizieren kann. Der Code an sich ist aber an vielen Stellen nicht wirklich einfach zu verstehen, da viele Funktionen und Variablen eher schematisch benannt sind (z.B seg036_00ae als Funktion, ptr2 als Zeigervariable) als nach ihrer Aufgabe. Es wäre also notwendig, die Funktionsweise bestimmter Algorihmen zu untersuchen und den Code insgesamt lesbarer zu machen, bevor man an Erweiterungen denkt. Der Speicherzugriff sieht auch kompizierter aus, als er sein könnte (ich denke mal, dass das daran liegt, dass das ganze immer noch auf Dosbox-basiert und gleichzeitig binär-identisch kompilierbar sein soll) . Dann stellt sich auch noch dir Frage, wie man mit den Bugs des Originals umgeht. Henne hatte dort eine Präprozessordefinition verwendet mit der man bestimmte Fehler beseitigen kann, aber dabei unterscheidet der Compiler nicht zwischen Fehlern, die auf modernen Systemen zum Absturz führen (müssen mMn. zwingend behoben werden) und Fehlern, die eher die Spiellogik betreffen (eher Geschmackssache, ob man die beheben will oder nicht).

Zum Thema Wünsche: Mir wäre eine nativ auf modernen Systemen lauffähige NLT als erster Schritt am wichtigsten. In einem Zweiten Schritt würde ich dann vielleicht die Spielregeln (spontan fallen mir da jetzt die größere Freiheit im Kampfsystem insbesondere im Fernkampf und die im ersten Teil noch eingeschränkteren Ausrüstungsslots ein) und vielleicht bestimmte grafische Elemente (Dialogboxen, Inventarbildschirm) zwischen den Teilen angleichen (sozusagen eine "NLT Deluxe", die wie aus einem Guss wirkt, aber dafür müssten dann natürlich auch die anderen Teile Fortschritte machen...). Einfaches Modding oder modulare Erweiterbarkeit sind dann natürlich nette extras, aber für mich persönlich nicht wirklich wichtig.

Zur Programmiersprache: Die Wahl einer Programmiersprache ist sicherlich davon abhängig, was man vorhat. Soll das ganze nur portiert werden, würde ich bei C/C++ bleiben, weil man dann vermutlich bestimmte Teile beibehalten kann. Wenn man das Programm komplett neu schreiben möchte, dann wäre die Wahl wohl einerseits vom Zielsystem abhängig (ich weiß z.B. nicht auf man auf Smartphones mit C++ klar käme, aber das wäre auch nicht mein bevorzugtes Zielsystem), andereseits aber auch davon, was man erreichen will (ein 1 zu 1 Port wäre sicher weniger leistungshungrig als z.B. eine echte 3D-Umsetzung). Für eine Moddingschnittstelle wäre eine Skriptsprache aber sicherlich die beste Wahl, da möchte man ja nicht immer alles neu kompilieren müssen.

Wie gesagt, ich hoffe demnächst mal wieder etwas mehr hier zu tun, aber das kann noch etwas dauern. Ich wünsche euch aber schon mal schöne Osterfeiertage!

Viele Grüße,
Mirko