Strafkolonie Online

Hallo zusammen!

Einleitung:
Vorab, ich glaube das Thema gehört hier nicht hin, aber an anderen Stellen, wo es mir sinnvoller erscheinen würde, kann ich kein Thema erstellen... Also bei Bedarf, einfach verschieben .

Wie ja bekannt ist, haben wir (also das SKO-(Team) -- in Klammern, weil ich gehöre ja nicht zum Team) keinen Sourcecode von dem eigentlichen Multiplayer-Kern und daher so gut wie keine Möglichkeit manche neue Funktionen zu implementieren, die tieferen Eingriff in die Engine erfordern würden oder Fehler, wie beispielsweise die Lags, die mit der Laufzeit von Gothic2 skalieren und jedem bekannt sein dürften, zu beheben.

Daher habe ich angefangen einen neuen Kern für den Gothic Multiplayer zu schreiben mit dem Ziel, eines Tages Accrescere ablösen zu können und von da an mehr Möglichkeiten der Fehlerbehebung oder der Erstellung weiterer Funktionen zu haben.
Nur damit es keine Missverständnisse gibt: Ich tue dies in erster Linie für SKO, weil ich den Server gut finde -- Nicht um einen eigenen auf zu machen und hier auf Userfang zu gehen oder ähnliches. Nicht das der Eindruck entsteht.

Genaueres zur Entwicklung:
Es gibt ein hervorragendes Projekt namens Gothic Untold Chapter, dessen Sourcecode frei verfügbar ist und mir sehr viel Arbeit bei der Erstellung eines neuen Multiplayerkerns abnimmt. Mainclain, falls du das ließt, ernsthaft: Danke für deinen riesigen Beitrag durch die Offenlegung deines Codes und deine Reverse-Engineering Anstrengungen!

Dieses Projekt dient mir als Basis für den Durchgriff eines externen Programms auf Funktionen innerhalb von Gothic. Zunächst gibt es aber ein paar Design Entscheidungen für die neue Software:

Programmiersprache bzw. Environment:
- Mit dem Gedanken im Hinterkopf, dass der Gothic-Server auf einem Linux-Server und damit unter Wine lauffähig sein sollte, scheidet für mich Visual Studio mit .NET Kern aus. Die Version, die derzeit aktuell wäre (2015 oder neuer) verwendet eine Runtime, die noch nicht vollständig in Wine implementiert ist und daher Probleme verursachen könnte bei der Inbetriebnahme. Weiter ist Gothic Untold Chapter in C# implementiert, was zwar erstmal nicht schlimm ist, aber ein paar Nachteile mit sich bringt bei der Verbindung von Gothic2 mit dem neuen Programmteil. Vom größeren Aufwand abgesehen, einen separaten .NET Kern überhaupt zu starten in einer laufenden Gothic Instanz, muss zusätzlich für jeden Aufruf einer noch so popeligen Funktion innerhalb von Gothic für Gothic ausführbarer Code in den Speicher gelegt werden. Dieser kann dann ausgeführt werden über den Start eines neuen Threads in Gothic. Dies ist zwar möglich, aber doch ein sehr großer Aufwand damit vergleichen, dass auch nativ ausführbarer Code von vorn herein eingeladen werden kann.
Davon abgesehen kann C# unter Linux noch zusätzlich eine unnötige Hürde sein.

Daher habe ich mich für C++ entschieden, da ich mir davon die größtmögliche Performance verspreche (und weniger Aufwand bei Calls, Speicher Lese-Schreiboperationen usw.).

Compiler:
Tatsächlich wäre es vermutlich am einfachsten einen Compiler von Microsoft zu verwenden, da Gothic ziemlich sicher auch mit einem kompiliert wurde. Ich jedoch habe mich für MinGW (mit g++) entschieden unter anderem deshalb, weil ich unter Linux arbeite und MinGW einen anständigen Cross-Compiler anbietet.
Eine Sache wird dadurch komplizierter: Der sogenannte THISCALL. Die Call-Convention des This-calls ist so ziemlich die einzige, die sich etwas unterscheidet zwischen GCC und Msvc. Der This-Pointer liegt bei MinGW auf dem Stack, während Msvc (und damit Gothic) ihn im Register ECX erwartet. Durch die Verwendung eines STDCALLs mit vorherigem Inline-Assembler schafft man es aber, die Adresse ins Register zu schieben und anschließend mittels eines STDCALLs nur noch die benötigten Argumente auf den Stack zu verfrachten vor dem Call.

Architektur:
Nach ziemlich ausgiebiger Sichtung des Codes von Untold Chapter habe ich mich dazu entschieden, die Struktur des Codes weitestgehend beizubehalten. Bei der Übersetzung von C# nach C++ entstehen natürlich Unterschiede, aber die Struktur der Objektorientierung leuchtet ein und ist es daher auch wert so übernommen zu werden, finde ich.
Falls Mainclain ließt: Das einzige was ich noch nicht nachlesen konnte bzw. mir keinen Reim drauf machen konnte sind die Präfixe der Dateinamen... Gemerkt habe ich, dass Dateien mit Präfix oC meisst Spielrelevanten Code enthalten und zC Dateien eher strukturelle Sachen bzw. Supportfunktionen enthalten. Oder von oC Dateien werden Objekte erstellt und zC sind quasi nur die Eltern.. Mhh mal sehen. Behindert mich nicht, aber ich glaube da steckt ein tieferer Sinn dahinter, den ich eigentlich gerne wüsste .
Edit: Mittlerweile hab ich gesehen, dass die Namen aus Gothic selbst kommen. Es lohnt sich auf World of Gothic zum Thema Modden etwas zu stöbern.

Multiplayer-Funktionen:
Dieses "Kapitel" kann erst folgen, wenn der "Kern" soweit übersetzt ist, da es nicht sinnvoll ist Netzwerkfunktionen zu implementieren für Sachen, die man noch nicht steuern kann. Da die Bibliothek RakNet nun unter der BSD-Lizenz verfügbar ist werde ich wahrscheinlich wie GUC und Accrescere auch schon diese Bibliothek für den Netzwerkverkehr benutzen.

Skripting Interface:
Wie ich mitbekommen habe, ist Accrescere so populär und auch für den SKO-Server verwendet worden aufgrund der Anpassbarkeit durch LUA-Skripte. Die glaube ich letzte Api dazu, die noch online zu finden ist, ist glaube ich diese hier leider mit russischer Beschreibung. Durch die englischen Parameternamen versteht man es aber trotzdem. Diese API wird also zu späterem Zeitpunkt auch implementiert werden, wodurch ein Umstieg von Accrescere auf den neuen Kern einfach möglich sein sollte.

Roadmap:
Funktionales:
- Lade von externen Code in die Zielanwendung (erledigt)
- Normale Calls innerhalb von Gothic II (erledigt)
- This-Calls mit Objektzeigern von Gothic II (implementiert - getestet: RainController erstellt und es schneien lassen - Läuft! x'D)
- Detours / Hooks (erledigt - getestet - Rückgabedaten mittels Stackmanipulation aus Callbackfunktion heraus stehen noch aus, bzw müssen von den jeweiligen Hook-Callbacks implementiert werden.)
- Implementierung Server/Client System mit Kommunikation (nicht gestartet - RakNet geplant)
- Implementierung Lua-Skriptschnittstelle (nicht gestartet - Bibliotheken gesichtet für Export von C Funktionen für Lua und Import von Lua Funktionen für C -- Sollte machbar sein).
Derzeitig in Arbeit:
- Implementierung von allen steuer- und lesbaren Elementen von Gothic (in Arbeit -- Schätzungsweise 30% übersetzt)

Aber mancher wird sich jetzt fragen, wieso schreibt der Typ den Roman hier ?
Eigentlich möchte ich in erster Linie informieren, dass es etwas gibt, das in Arbeit ist und möglicherweise mal zur Verbesserung des Projekts beitragen kann. Zum anderen könnte es ja sein, dass es jemanden gibt, der C++ Erfahrung und x86 Architektur Verständnis hat oder Interesse hat, sich sowas anzuschauen und mitzuhelfen. Das ist möglich -- Ich versioniere mittels eines Gitlab-Servers . Falls jemand Interesse hat mitzuwirken schreibt doch bitte eine PM an mich, dann kann ich euch einen Gitlab-Konto erstellen, um mitarbeiten zu können.

Soviel dazu. Wollte ich mal gesagt haben.
Ups, der Post ist wohl etwas länger geworden
Ok, ich gebs zu, hab ich vorher gewusst

Grüße
Christian

Also entgegen meiner Erwartung habe ich erfahren, dass GUC wohl auch bei einer großen Spieleranzahl bzw. NPC-Anzahl keine Performanceprobleme hat durch die Calls -- Es gibt irgendwo auf WOG einen Post, wo Gif Grafiken angehängt sind mit ca. 150 NPC die einem Spieler hinterher laufen (finde ich jetzt natürlich nicht mehr).
Spricht dafür, dass durch die heutigen Prozessoren auch unschöne Lösungen wohl kein Problem mehr sind.

Also daher könnte man den C# GUC so schon verwenden, nur das Problem das bleibt ist die Kompatibilität mit Linux, also Wine bzw. Mono. Beim Kompilieren von GUC gibt es schon zwei Probleme, mit Elementen, die nicht implementiert sind in Mono.
Zum einen einen Fragezeichen Operator:
VobSystem/Instances/NPCInst.Server.cs(43,77): error CS1525: Unexpected symbol `?'
kommt von hier: return (NPCInst)this.baseClient.Character?.ScriptObject;
Dieser ist in .NET wohl relativ neu und sorgt dafür, dass wenn ein Attribut noch nicht sinnvoll initilisiert ist, es nicht zum Absturz kommt, sondern irgendwie eine NULL oder was ungefährliches zurückgeliefert wird. Könnte man im Code vielleicht durch etwas anderes ersetzen. Zumal dieser Codeteil aus den ServerScripten kommt, die man sowieso komplett überarbeiten bzw. selber neu schreiben würde.

Zum anderen fehlt eine Methode in der mscorlib (Das ist wahrscheinlich eher ein Problem):
System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeInterfaceAsIntPtr
Im neuesten wine mono Paket existiert eine Implementation davon, sodass eine kompilierte Variante sogar laufen würde damit. Nur der Compiler unter Linux kennt das Biest nicht. Als Workaround könnte man das unter Windows kompilieren und dann mit Wine starten.

Lieber wäre mit das Ganze trotzdem in C++, daher werde ich damit wohl weiter machen.
Wie man später genau Server- Clientskripte implementiert schätze ich kann man später noch entscheiden.
Bei GUC habe ich soweit verstanden, dass die Verzeichnisse ServerScripts und sowas eigentlich nur Script heißen, aber eigentlich Bibliotheken sind. Also die werden genau so programmiert, wie GUC selbst auch und sind hinterher über dlls einladbar. Ein Scriptinterface alla LUA habe ich noch nicht gefunden.

Mit meinem kurzfristigen Entwicklungsplan sieht es so aus, dass gerade ein paar Grundtypen übersetzt sind und die einfache Objekt-Calls (thiscalls). Jetzt würde ich schauen, dass noch etwas folgt, dass Text auf den Bildschirm schreibt, damit ich diese Klassen und die Stringklasse vernünftig testen kann.
Als wichtiger nächster Punkt kommen die Hooks. Es gibt viele Routinen, wo Hooks rein müssen (Ladebildschirm geht auf/zu, Laden der Welt (um eine eigene Welt zu starten), Player bekommt Schaden usw.).
So hätte ich in der nächsten Zeit geplant weiter zu machen.

"Hast du schon eine ungefähre Vorstellung davon, wann dein GMP spielbar bzw. testbar ist?"
Ist schlecht abzusehen momentan, aber wenn man dran bleibt vielleicht dieses Jahr noch
Nein, keine Ahnung ist schlecht einzuschätzen.

Bis dahin jedenfalls: "Ein neuer Tag und NICHTS hat sich geändert!"

Hallo,

da es ziemlich gut voran geht ist es glaube ich schon mal eine gute Idee, die Frage nach dem Scriptinterface zu klären.
Es wäre schön, wenn mir da jemand genauer sagen könnte, was genau in welchen Skripttypen laufen könnte und wo diese ausgeführt werden sollten.

Fragen die ich mir stelle sind:
- Wo sollte die Schadensberechnung laufen ?
- Wer steuert NPCs, wie zum Beispiel Minecrawler ? Am logischsten wäre es wohl, wenn das der Server macht, aber damit die Crawler nicht durch Wände laufen oder sowas bräuchte der Server eine laufende Spielinstanz oder ? Wie ich mir das vorstellen würde, würden die Crawler dann über Deadalus in einer Spielinstanz des Servers gesteuert und die Neuigkeiten dann zu den Clients übertragen.

Was gibt es noch zu wissen über Scriptinterfaces ? Wenn man das umsetzen will, sollte man glaube ich alles relevante darüber wissen

Gibt es Dinge, die im Client mit Daedalus gemacht werden sollten oder müssen ?
Vielleicht kann mir da jemand weiterhelfen, im Netz finde ich irgendwie nicht die Informationen, die ich gerne hätte.

Grüße

Also ich würde jetzt folgenden Plan verfolgen:

Allgemeiner Aufbau des Multiplayers:
Der Server startet eine Spielinstanz ohne grafische Ausgabe und spawnt Monster und Spieler in die Welt. Mittels Daedalus Skripten werden die Mobs gesteuert und nutzen daher die spieleigenen Kollisionsabfragen. Spieler werden in der Serverinstanz dann über die Netzwerkschnittstelle bewegt, sodass Monster die Spieler wahrnehmen und darauf reagieren können. Sollte so funktionieren und ist wahrscheinlich auch im gmpa so implementiert. Bitte korrigiert mich, wenn das nicht so ist.

Schadensberechnung:
Hier hätte ich zwei Konzepte, die man beide implementieren und bei Bedarf je nach Vorliebe oder Praxisbewährung umschalten kann:

Variante 1:
- Spieler machen auf Clientseite 0 Schaden und der Server führt den eigentlichen Schlag aus. Der Schaden wird dem Client dann mitgeteilt und quasi nachträglich angewendet. Ist manipulationssicher, hat aber den Nachteil, dass es eine mit der Netzwerk- und Serverauslastung skalierende Verzögerung zwischen Schlag und sichtbarem zugefügtem Schaden gibt.

Variante 2:
- Spieler berechnen den Schaden selbst und wenden diesen auch direkt auf den Gegner an. Der Server kann prüfen, ob es sich um gültigen Schaden handelt oder nicht und den Spieler ggfs. kicken/bannen falls manipuliert wurde. Beispiel: Spieler hat 15 Str und 0% 1H Skill und eine Waffe mit 5 Schaden. Der Spieler manipuliert seine Stärke auf 100 und macht daraufhin einen Schaden von 105 pro Schlag. Der Server kann nachrechnen, dass maximal 15 + 5 möglich sind (ohne 1H Bonus) und kann darauf reagieren. Diese Variante ist vielleicht die bessere. Nachteil: Anders als bei Variante 1 ist es hier wieder möglich, dass in einem zwei Kampf am ende beide Gegner K.O. zu Boden fallen. Bei Variante 1 ist dies anders, da der Server den Schaden anwendet und ein registrierter Schlag einer bereits umgefallenen Person nicht mehr anwenden würde.

Zu Yormunds Checkliste:
"- Ist es massentauglich ?[...]"
Mit meiner Implementierung sollte ein Maximum an Performance raus geholt werden und natürlich achte ich auch darauf. In jedem Fall ist der Vorteil einer Neuimplementierung mit Sourcecode, dass man Probleme nicht nur erkennen, sondern auch beheben kann. Im Vergleich mit GUC bzw. Sumpfkraut Online wird meine Version gerade auf LowLevel Ebene Vorteile haben, da ich keine Umwege über eine "virtuelle Maschine (.NET Kern)" gehen muss und für jeden Call Speicher reservieren, beschreiben und in einem separaten Thread starten muss.

"-wie viele Schreiber[...]"
Bisher schreibe ich alleine, aber selbst wenn jemand mitschreibt: Das Projekt steht unter der GNU-GPL wodurch es jedem ausdrücklich gestattet ist, den Code zu nutzen, lesen, modifizieren, verbreiten, ... Eingriffe in das Spiel stehen unter der Gothic Mod Lizenz -- mit bestem Dank an Piranha Bytes .

"[...] sicher für den Server [...]Clientmanipulationsgefahr [...]"
Das ist eines der Hauptziele Aber auch das sind Dinge die man nachträglich jederzeit verbessern kann, falls sich etwas als schlecht erweist.

"-ist das Script wirklich ausgereift [...]"
Wenn genug Arbeit reingesteckt wurde, wird es das sein .

Grüße

Also nach meiner subjektiven Einschätzung fehlen für den Kern (Verbindung zEngine <-> Eigenes Programm) nicht mehr sooo viele Sachen. Sind die restlichen Dinge noch übersetzt steht ein ausgiebiges Testen auf dem Plan.

Dafür Plane ich ein langes Testprogramm das mit Zeitverzögerung alle Funktionen abklopft, um zu testen ob die auch alle funktionieren und das tun was man erwartet.

Danach finde ich einen Benchmark-Test sinnvoll. Da werde ich dann haufenweise Instanzen erstellen, modifizieren und löschen und dabei den Arbeitsspeicher im Auge behalten. Explodiert er nicht, stehen die Chancen gut keine Speicherlecks zu haben.

Ja und danach wäre es dann soweit den eigentlichen Multiplayer-Aufbau zu starten.
So viel zu den Neuigkeiten.

Grüße
Xaga

P.S.: Der neue MP wird das Wetter steuern können. Atmosphäre +1