Reverse Engineering der NLT II

[Alrik Alrikson]

[...]
Außerdem brauchen wir so ein Hipster-Zeug nicht

...sprach der Mann mit dem Bart im Profilbild...

[Rabenaas]

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!

Wow, nicht alle gleichzeitig.

Ich würde etwas mithelfen, klar. Traditionell ist hier die Dichte der Forenteilnehmer mit gwissen Programmiervorerfahrungen relativ hoch. Aber, wie man an BrightEyes sieht, braucht so ein Projekt einen, der sich ernsthaft dahinter klemmt.

[Hindro]

Lustig wäre z.B. eine Realisierung in Java. Läuft auf vielen Plattformen (Java 6 läuft unter Android).
Nach der Umsetzung als Single-Player Spiel kann man versuchen das Spiel so zu erweitern (teil als Client- Teils als Server), dass sich mehrere Spieler zu einer Gruppe zusammenfinden können, die dann das Abenteuer bestreiten.

[aeyol]

Au ja, nach den Multiplayer-Sternen greifen.

Ich wäre ja eher für realistische kleine Ziele, solange man kein Vollzeit-Team hat, das wirklich regelmäßig Zeit dafür aufbringen kann.

Gerade nachdem ich mal wieder in Drakensang reingeschaut habe, finde ich es wieder verdammt schade, dass es kein - mit niedrigen Hürden - erweiterbares DSA Spiel gibt. Auch wenn zu Drakensang und auch zur NL"T" HD bereits Mods entstanden sind ... die Art von Erweiterbarkeit von der ich träumen würde, bieten beide nicht. Ganz Aventurien!

[Shihan]

@Rabenaas:
Ja, einer sollte federführend agieren. Ich ringe gerade mit mir, ob ich das machen kann und möchte.

@Hindro:
Die von mir gerade favorisierte Multimedia-Library (mit 2D-Graphik, Sound, Musik, Netzwerk,...) SFML läuft auch (mehr oder weniger) auf Android und iOS. Also wäre das kein Problem und es gäbe keinen Grund, Java zu nutzen

@aeyol und @Hindro->Multiplayer:
Ein realistisches Ziel wäre erstmal eine lauffähige Variante, die genau das Grundspiel umsetzt (ich stelle mir vor, Bright-Eyes immer wieder als Referenz zu nutzen, um herauszufinden, was im Game an welchen Stellen passiert). Dabei sollte man eine gewisse Erweiterbarkeit von Anfang an verfolgen.
Da stelle ich mir vor, man baut z.B. einen Level-Loader, der ein Level entweder aus der SCHICK.DAT laden kann (altes Level) oder aus einer XML/JSON/wasauchimmerfüreinformat-Datei (neues Level). Damit könnte man nebeneinander Original- und Mod-Levels laden.
Das Prinzip sollte sich dann durchziehen, d.h. Original-Bilder können aus SCHICK.DAT geladen werden, Bilder in Mods aus z.B. PNG.
Multiplayer sehe ich dann erst ganz am Ende (weil das ganz viele Fragen stellt, die geklärt werden müssen, und sehr aufwendig ist).


Mein Vorschlag zur Entwicklungsreihenfolge:

1. Meilenstein: Bisherige Arbeiten (Informationen im Wiki; Hennes Tools wie nltpack) in Loader einarbeiten, damit alle Originaldaten geladen werden können
   
2. Meilenstein: Für die Multimedia-Daten Loader hinzufügen, die PNG, WAV, OGG laden können
   
3. Meilenstein: GUI-Basis (Dialogfenster/Popups, etc.)
   
4. Meilenstein: Main-Screen mit Icons, Heldenportraits etc. aufbauen (dabei bleibt das "Fenster in die Welt", wo also die Stadt-Umgebung oder das Bild des Shops oder oder angezeigt wird, erstmal leer)
   
5. Meilenstein: Charakterbildschirm anzeigen (mit Inventory etc.)
   
6. Meilenstein: Kampfbildschirm anzeigen (noch kein Kampf mit Animationen etc.)
   
7. Meilenstein: Rendern von Shops, Gebäudeinneren, etc.
   
8. Meilenstein: Rendern der Stadt- bzw. Dungeonumgebung
   
9. Meilenstein: Rendern der Reisekarte (kann auch früher, ist eigentlich recht einfach)
   
10. Meilenstein: Reisefunktion zwischen Städten und in Dungeons
    
11. Meilenstein: Generierung  oder Kampfberechnung oder Questsystem
    

Also erstmal eine statische Welt erkundbar machen und dann die Quests am Ende einbringen. Wenn nämlich das Gerüst steht, sind Quests einfacher zu machen. Außerdem kann man Generierung/Kampfberechnung/Quests auch parallel entwickeln (da reicht ja zur Ausgabe zur Not eine Konsole; wir wollen ja Darstellung (Audio/Video) und Logik (Spielinhalte) sauber trennen). Bei ein wenig Gefühl für die Verzahnung der einzelnen Module ist das kein Problem.

Wenn man bei der Entwicklung ein wenig aufpasst und eine vernünftige Architektur aufbaut, kann man nachher bei Schweif und Riva viel bestehendes wieder verwenden (sollte das mal ein Thema sein und sollte Henne auch für Bright-Eyes-Schweif und Bright-Eyes-Riva noch Lust haben ).


Was meint ihr?

[Hindro]

Ich denke da wären vorher noch ein paar Schritte.

Ich hätte gerne eine kompilierbare EXE die man selber in eine bestehende DosBox kopieren kann.

Danach das Austauschen der Variablennamen gegen sprechende Variablennamen.

Das Schrittweise umwandeln der binären Datendateien in sprechende XML-Dateien. Dazu müssen alle Lade- und Speicherroutinen neu geschrieben werden. Hier bieten sich Objekte als Datenstrukturen an.

Die ganze Zeit müsste es möglich sein eine funktionierende DOS-Exe zu behalten.

Danach würde ich versuchen die DOS-Box zu verlassen und die Grafikroutinen so abstrahiert zu Kapseln, dass man das Spiel in einem 320x240 grossen Windows-Fenster spielen kann.

Der letzte Schritt den ich im Vorfeld tun würde, wäre dann solche Anpassungen zu etablieren, das man die Grafikauflösung auf 640x480 bzw. 1280x960 erhöhen kann, dazu muss man vermutlich alle existierenden Grafiken neu erstellen.

[gaor]

Bei all dem sollten wir immer bedenken, dass wir Originalnamen und -artwork aus einer vom User zur Verfügung zu stellenden SCHICK.DAT nachladen. Wir können solche Daten nicht verbreiten. Die Frage ist auch, inwiefern eine Implementierung eines DSA-Regelwerks mit den entsprechenden Bezeichnungen für Grundwerte, Talente, Charakterklassen usw. nicht auch Lizenzfragen aufwerfen wird. Eventuell sollten wir vor der tatsächlichen Durchführung eines solchen Vorhabens bei Ulysses anfragen, wie weit wir gehen können, ohne Probleme zu bekommen.

[Hindro]

Die Originaldaten zu Artwork liefert man nicht aus, sondern einen Konverter der die SCHICK.DAT die der Nutzer hat ins neue Format konvertiert.

Die Software dürfte bevor man sie außerhalb der Entwickler verteilt keine Zeile des Originalen Codes enthalten, so dass da erstmal auch kein Problem ist.

Das DSA-Regelwerk braucht natürlich eine Genehmigung, bevor man den Vertrieb beginnt.

[Rabenaas]

Erstmal sollte allen Beteiligten klar sein, dass es sich um ein Fanprojekt handelt, das allein dazu dient, dass wir weiterhin mit unserer NLT in angemesener Weise auf moderner Hardware spielen und ggf. modden können, etwa z.B. einen Mehrspielermodus hinzufügen.

Deshalb habe ich Schwierigkeiten mit dem Begriff "Vertrieb". Es sollte klar sein, dass keiner auch nur einen müden Pfifferling dafür erwartet. Außerdem sollten wir strikt die Finger vom originalen Artwork lassen. Einen Loader für das alte Amiga-Format zu schreiben, wird nicht so schwierig sein. Und eine NLT in HD gibt's auch schon. Wenn wir selbst was malen, dann vermutlich lieber in LD mit Retrocharme.

Ich denke, dass es sich lohnen würde, wenn wir BrightEyes weiter aufpolieren. Der kürzeste Weg zu einer modernisierten Engine ist aber mMn eine Neuimplementierung. Sonst könntee man auch meine Ansatze mit Lua als proof of concept nehmen. Das hat ziemlich gut geklappt.

Ansonsten kann man Python nativ in CPython, in einer JavaVM als Jython, im Verbund mit C++ als Skriptsprache via Boost und schnell mit PyPy ausführen. Und es kann vermutlich die Mehrheit hier damit umgehen. Nur mal so als Randnotiz.

[Hindro]

"Vertrieb" war ein Witz.
Du darfst machen was immer du willst, mit Art-Work und Software, solange du es nicht weiter gibst oder öffentlich vorführst.

Man kann vermutlich erfolgreich den Standpunkt vertreten, dass eine Gruppe Fans die gemeinschaftlich ein Fanprojekt bauen, nicht die Öffentlichkeit sind.
Jede Vergrößerug des Kreises könnte als Veröffentlichung oder Vertrieb gewertet werden.

[Hindro]

Aufbohren vs. Neuimplementierung

Der Vorteil von Aufbohren ist, dass einfach viel Material schon da ist (Handlung etc.) und dass man auch aus der alten Software etwas lernen kann.

Neuimplementierung geht vermutlich schneller, wenn die Beteiligten die notwendige Erfahrung in der Spielentwicklung haben.

[Rabenaas]

Natürlich, aber irgendwann willst Du es doch sicher auch noch anderen zeigen. Die Schnittmenge der Mengen (Interessenten), (C++-Programmierer) und (Forenmitglieder) dürfte so im mittleren einstelligen Bereich liegen.

Dann doch lieber gleich so planen, dass alle was davon haben.

[Boneman]

@Hindro:
Die von mir gerade favorisierte Multimedia-Library (mit 2D-Graphik, Sound, Musik, Netzwerk,...) SFML läuft auch (mehr oder weniger) auf Android und iOS. Also wäre das kein Problem und es gäbe keinen Grund, Java zu nutzen

Wäre es für die 3D-Ansicht nicht sinnvoll, (zusätzlich) einen 3D-Renderer zu nutzen? Auch wenn man dann einige Texturen neu erstellen müsste (vgl. hier), aber das steht ja eh zur Diskussion.

[Hindro]

3D erhöht die Kompexität und den Arbeitsaufwand erheblich.

[Shihan]

Aufbohren vs. Neuimplementierung

Der Vorteil von Aufbohren ist, dass einfach viel Material schon da ist (Handlung etc.) und dass man auch aus der alten Software etwas lernen kann.

Neuimplementierung geht vermutlich schneller, wenn die Beteiligten die notwendige Erfahrung in der Spielentwicklung  haben.

Aus dem Beitrag vor diesem (den ich aus Platzgründen nicht zitieren wollte) und diesem hier schließe ich, dass Du eher Fan des Aufbohrens wärst
Das finde ich ok und einen ganz validen Ansatz. Allerdings ist man durch die Art und Weise, wie die Software geschrieben wurde, ziemlich eingeschränkt bzw. muss verdammt viel umbauen, bevor man überhaupt an Erweiterungen denken kann. Evtl. geht das ein oder andere schon früh, aber je umfangreicher die Änderungen sind, desto wilder und schwieriger ist es. Ob man aus der alten Software was lernen kann, weiß ich nicht. Höchstens, warum man heute anders programmiert
Aber ich will mich da nicht gegen stellen (auch wenn ich denke, dass Neuimplementierung wirklich schneller geht; dafür hab ich aber keine Begründung, nennt es ein Gefühl).

Die Originaldaten zu Artwork liefert man nicht aus, sondern einen Konverter der die SCHICK.DAT die der Nutzer hat ins neue Format konvertiert.

Die Software dürfte bevor man sie außerhalb der Entwickler verteilt keine Zeile des Originalen Codes enthalten, so dass da erstmal auch kein Problem ist.

Das DSA-Regelwerk braucht natürlich eine Genehmigung, bevor man den Vertrieb beginnt.

Den Konvertierungsvorgang würde ich auch nicht offline gestalten, sondern online. Damit meine ich, dass der jedes Mal, wenn das Spiel die Daten lädt, durchgeführt wird. Somit bleibt ein absolutes Muss, dass man das Originalspiel besitzt! Das ist den Rechteinhabern sehr wichtig und eine klare Absichtsbekundung unsererseits, dass wir keinen Schaden anrichten, sondern nur virtuelle Denkmalpflege betreiben wollen.

Da finde ich das OpenMW-Projekt als Beispiel ganz angenehm. Die bauen die Engine von "The Elder Scrols - Morrowind" nach, brauchen aber auch auf jeden Fall die alten Assets. Sie halten sich von Konsolen fern, haben aber dafür von Bethesda (Rechteinhaber) die Erlaubnis, das Projekt fortzuführen.

Erstmal sollte allen Beteiligten klar sein, dass es sich um ein Fanprojekt handelt, das allein dazu dient, dass wir weiterhin mit unserer NLT in angemesener Weise auf moderner Hardware spielen und ggf. modden können, etwa z.B. einen Mehrspielermodus hinzufügen.

Deshalb habe ich Schwierigkeiten mit dem Begriff "Vertrieb". Es sollte klar sein, dass keiner auch nur einen müden Pfifferling dafür erwartet. Außerdem sollten wir strikt die Finger vom originalen Artwork lassen. Einen Loader für das alte Amiga-Format zu schreiben, wird nicht so schwierig sein. Und eine NLT in HD gibt's auch schon. Wenn wir selbst was malen, dann vermutlich lieber in LD mit Retrocharme.

Ich denke, dass es sich lohnen würde, wenn wir BrightEyes weiter aufpolieren. Der kürzeste Weg zu einer modernisierten Engine ist aber mMn eine Neuimplementierung. Sonst könntee man auch meine Ansatze mit Lua als proof of concept nehmen. Das hat ziemlich gut geklappt.

Ansonsten kann man Python nativ in CPython, in einer JavaVM als Jython, im Verbund mit C++ als Skriptsprache via Boost und schnell mit PyPy ausführen. Und es kann vermutlich die Mehrheit hier damit umgehen. Nur mal so als Randnotiz.

HD würde ich auch auf jeden Fall vermeiden! Lauffähigkeit des alten Spiels ist das Primärziel. Kleine kosmetische Änderungen. Aber nichts allzu wildes und abgefahrenes, was der neuen HD-NLT Kunden abgreift. Sowas muss auf jeden Fall vermieden werden!
Python ist für mich übrigens immer noch im Rennen

Wäre es für die 3D-Ansicht nicht sinnvoll, (zusätzlich) einen 3D-Renderer zu nutzen? Auch wenn man dann einige Texturen neu erstellen müsste (vgl. hier), aber das steht ja eh zur Diskussion.

SFML kann auch den OpenGL-Kontext bereitstellen und damit alles, was für 3D notwendig ist. Das wäre also noch möglich, wie auch ich da lieber vorsichtig wäre.


Insgesamt wäre ich auch dafür, von Anfang an Open-Source zu gehen (mit Github). Bei einer Neuimplementierung steht dem nichts im Wege (solange da kein Code vom alten Spiel drin steckt, ist das auch in Ordnung). Dateiformate sind nicht schützbar (hat der EuGH entschieden), deshalb sind Loader auch in Ordnung.
Was die Regeln angeht: Das ist in der Tat ein anderes Ding.

[Rabenaas]

3D erhöht die Kompexität und den Arbeitsaufwand erheblich.

Nicht unbedingt. Eine einfache Engine wie Coin3D, Panda3D oder Irrlicht benötigt vermutlich wesentlich weniger Zeilen Code, als eine eigene Pseude-3D-Engine, um texturierte Quader auf den Blidschirm zu bringen.

vgl. Thorwal als Doom WAD

[Hindro]

3D erhöht die Kompexität und den Arbeitsaufwand erheblich.

Nicht unbedingt. Eine einfache Engine wie Coin3D, Panda3D oder Irrlicht benötigt vermutlich wesentlich weniger Zeilen Code, als eine eigene Pseude-3D-Engine, um texturierte Quader auf den Blidschirm zu bringen.

vgl. Thorwal als Doom WAD

Das tolle am Schachbrett Design von Schick ist, dass die Position der Gruppe immer ganz klar ist. du ziehst von Feld zu Feld. Die Position der Gruppe in der auf Dreiecken basierenden 3D-Darstellung zu bestimmen ist sagen wir mal anders. Alle 3D-Objekte müssen gemäß der Vorgabe der Engine neu gezeichnet werden. du hast entweder simple Strukturen mit vielen gezeichneten Texturen oder Objekte aus vielen Polygonen die viel Leistung kosten für ziemlich wenig aussehen.
Die Crafties haben für Schweif HD zig Stunden gebraucht um irgendwelche Ritzen durch die Licht schien zu beseitigen. Die Performanceprobleme in Lowangen sind ganz klar auf zu viele 3d-Objekte (in dem Fall Bewohner) zurück zu führen. Und die haben die meisten 3D-Objekte gekauft.

Kurz ich schreib Software und male keine Texturen oder entwerfe 3D-Objekte.Ich finde das Komplex.

[Rabenaas]

Ich habe sicher nicht vor, von dem Schachbrettmustar abzuweichen. Die Grafik darf mMn auch schrittweise umschalten. Die Häuser sind Quader mit acht Ecken und einer Textur. Vernünftige Engines brauchen dafür einen Funktionsaufruf pro Gebäude, der sich nur in den Koordinaten unterscheidet, und erledigen Perspektive und Zeichnen dann automatisch. Du verschiebst mit jedem Schritt einfach nur den Standpunkt der Gruppe um einen bestimmten Vektor. Einfacher als eine DungeonMaster-ähnliche Engine zu implementieren. Es gibt genug Engines. Wir müssen das Rad nicht noch mal neu erfinden. Dafür brauchen wir dann eine Hand voll neuer (unverzerrter) Texturen.

[Shihan]

Pro Haus acht Triangles (die vier Seite), plus eine geringe Anzahl an Triangles für den Boden (denke mal hier kann man auch mit sehr wenigen auskommen). Selbst Thorwal wird keine 1000 Triangles haben, vermute ich. Wenn man dagegen bedenkt, dass alle Rechner (selbst die schwächsten) der letzten 5 Jahre und die Smartphones und Tablets der letzten Zeit eine Fillrate im Millionenbereich haben, muss man keinerlei Angst vor "viel Leistung kosten" haben. Das ist alles kein Problem, ehrlich nicht. Grafikchips der letzten Jahre sind (auch die abgespeckten für reine Office-PCs) haben kein Problem mit Trianglefill. Vor allem, wenn die Texturen eine Kantenbreite unter 256 Pixeln haben...

Kannst Du ruhig glauben, Hindro. Das ist alles andere als komplex, weil die Graphik-APIs (DirectX und OpenGL) einem das meiste abnehmen. Dafür braucht man noch nicht mal eine Engine. Ich werd die Tage als kleinen Proof-of-Concept mal einen 3D-Renderer für Grid-based Movement ala Schick (und Dungeon Master und Grimrock und und und) bauen.

Ich finde es viel aufwendiger und komplexer, den Code von Bright-Eyes zu verstehen und umzubauen

[Shihan]

So, meine lieben Mitstreiter, erste Ergebnisse.
Hat etwas gedauert, weil ich zwischenzeitlich im Urlaub in Schweden und deshalb erst diese Woche wieder da war

Hier findet ihr ein kleines Video (liegt auf meinem Server):


Das Programm basiert auf C++14 mit SFML 2.4 und OpenGL 3.3 (mit kleinen Anpassungen plattformunabhängig für Win, Linux, Mac, Android, iOS).
Die Texturen sind original aus der SCHICK.DAT geladen, außer Wasser, Gras und Steinboden (das sind CC-Funde aus dem Internet).
Auch das Stadtlayout wird aus der SCHICK.DAT geladen. Die Minimap und die 3D-Umgebung holen ihre Informationen aus der Klasse city_map (die wiederum das Stadtlayout, die aktuelle Position und Richtung verwaltet) und zeichnen nach jeder Bewegung den aktuellen Stand (bzw. interpolieren die Rotation).

Ich habe mich erstmal entschieden, die Texturfilterung im Pixel-Art-Style zu lassen. So sieht es authentischer aus. Der leichte Nebel ist nur aus Spaß drin. Der Wegweiser sieht deshalb so schräg aus, weil es eigentlich eine Box wie die anderen Gebäude ist, bei der aber auf jeder Seite das Bild aus der SCHICK.DAT aufgeklebt ist. Hier könnte man ein Billboard machen, was dem Betrachter immer die Front zu neigt.

Was man verbessern könnte:

• der Schritt nach vorn/hinten/links/rechts könnte ähnlich flüssig sein wie die Rotation
  
• das Wasser könnte animiert sein
  
• wie erwähnt: Billboards für die Wegweiser
  
• unterschiedliche Texturen je nach Haus (wie im Original auch)
  
• Wolken und Sonne am Himmel
  
• Häusertexturen haben mitunter einen Sockel (schwarzer Rand unten), den müsste man noch entfernen
  
• Kanten zwischen Gras, Straße und Wasser sind zu hart; könnten weicher sein
  

Die Ortschaft kennt ihr bestimmt

Was meint ihr dazu?




PS:
Das Video ist mit h.264 kodiert. In Wirklichkeit sieht das Bild etwas weniger matschig aus.
Reine Arbeitszeit für das Programm bis hier: zwei lange, aber erfreuliche Abende am Rechner.
Source ist noch zu "prototypig", den will ich mal noch aufräumen. Dann zeig ich euch den auch