Gothic Mod Manager

#1

Moin : ]

Ich hoffe, dem ein oder anderen Forenmitglied ist das Computerspiel “Gothic” von Piranha Bytes ein Begriff. Ich bin Mitglied im Team der Gothic Reloaded Modification (GRM). Unser Ziel ist es, das schon etwas in die Jahre gekommene Spiel grafisch komplett zu überholen, soweit möglich. Mehr Infos zur Mod gibt es hier: Website und Forum

Um die ganzen Aufgaben und Assets zu verwalten, arbeite ich momentan am Gothic Mod Manager (GMM). Der GMM ist eine Taskverwaltung mit integrierter Gothic-Asset-Verwaltung (Texturen- und 3D-Modelle), oder das soll er zumindest werden. Er wird mit Hilfe von Spring Framework und JSP als Java-Servlet realisiert. Mehr Infos hier: Forum
Source und Anleitung, wie man das Servlet lokal zum Laufen bekommt, hier: https://github.com/Katharsas/GMM

Momentan suche ich nach Java-Jüngern, welche mich beim Entwickeln unterstützen wollen. Das Projekt ist nicht-kommerziell und basiert komplett auf Begeisterung und Gothic-Fanboyismus. Sollte die Mod noch zu Lebzeiten der Beteiligten fertig gestellt werden, gibt es als Belohnung für Mitarbeit möglicherweise Credits in irgendeinem Video.
Status: Bisher wurde ein guter Teil der Taskverwaltung realisiert, aber es gibt auch noch genug zu tun.

Ich würde mich also sehr freuen, falls sich hier der ein oder andere Gothic-Fan mit Java-Kenntnissen versteckt, der etwas Zeit hat um mir zu helfen :slight_smile:

#2

Es gibt einen ersten Release, welcher mit wenigen Klicks ausprobiert werden kann.

Anleitung & Download: https://github.com/Katharsas/GMM/releases/tag/0.2.0-SNAPSHOT

Damit könnt ihr euch einen Blick über den momentanen Stand verschaffen, wenn euch das Projekt interessiert.

#3

(Sorry, kein “echtes”, “relevantes” Feedback - nur etwas, was mir beim Drüberbrowsen aufgefallen ist: Sowas wie public interface Collection<E> extends java.util.Collection<E> finde ich zumindest “gewagt”…)

#4

Inwiefern?

Ich brauche die Copy/Clone-Methode, da ich teilweise Collections neu instanzieren muss, die im jeweiligen Code nur als generische Typen bekannt sind, sprich ich habe keine Konstruktoren (benötigt z.B. im package gmm.service.filter) und die Typen können unbekannte Implementationen von Interfaces sein, ich kann also auch nicht clone() Methoden benutzen, die es nicht z.B. in java.util.List gibt.

Die ganze Lösung ist zugegebenermaßen hässlich, weil ich mit Generics sowieso nur schlecht zurecht komme (wobei ich manchmal denke, das liegt nicht an mir) und ich auch die eigenen Collections nicht ohne SupressWarnings hinbekomme, aber eine bessere Lösung habe ich bisher nicht gefunden.

(Achja, wenn du “gewagten” Code sehen willst, lege ich dir die Methode gmm.util.ELFunctions#instanceOfClass(String) ans herz :D)

#5

Ich glaube, es ging @Marco13 um die Benennung deines Interfaces. Es hat den gleichen Namen, wie das Interface, von der du erbst. Nur die Packages unterscheiden sich. Sowas ist zu vermeiden.

#6

Ja, es ging erstmal nur um den Namen. Die Intention ist durchaus nachvollziehbar: Ganz generisch eine Kopie erstellen zu können, egal, welcher Typ es denn ist. Allerdings habe ich noch nicht geschaut, WO und WIE du diese copy-Methode im Moment verwendest, und ob es da irgendeine elegantere Lösung gäbe.

#7

Achso, okay, das ist nachvollziehbar.
Hatte keine Lust den Namen zu “verstümmeln”, weil es ja eigentlich die gleichen Klassen sind (abgesehen von der copy-Methode). Ich zähle auch gerne die packages zum Namen dazu, weil ich keine Lust auf sowas habe:

gmm.util.collection.GmmCollectionUtilList

(übertrieben natürlich)

#8

Aber eine GCollection wäre doch sicherlich verkraftbar!? Ich denke ein kleines durchgängigs Präfix (G, Gr, Gmm, etc… max 3 Buchstaben) kann sehr helfen Verwirrungen zu vermeiden. Und die Vorgeschlagene GCollection (GList, GMap, GSet, ect… was du eben brauchst) sieht imo nicht gerade “verstümmelt” aus.

Zumindest würde ich das Prefix einer Namensgleichheit vorziehen, da man sich so langfristig Frust bei der API-Nutzung erspart. Mir geht das aktuell schon bei List und Date im JDK auf den Wecker.

#9

Hmm, ich schreibe grundsätzlich nur die Klasse hin und lasse dann Eclipse alle packages finden, und wähle dann halt das richtige aus.
Ich sehe da jetzt ehrlich gesagt workflow-technisch keinerlei Probleme mit gleich benannten Klassen.

Selbst wenn ich nicht der einzige wäre, der am Java-Code arbeitet:

  • Wer ein Interface von mir implementiert/benutzt, bekommt doch in jeder IDE automatisch die richtigen Packages vorgeschlagen/importiert.
  • Wer alten Code von sich selbst ins Projekt einbringen will, muss sich sowieso einen Adapter copy-pasten, wenn er Interfaces mit meinen Collection ansprechen will, da kann er die packages auch gleich mit pasten.
  • Gibt auch keinen Grund, beide Collections gleichzeitig zu verwenden, wenn man für das Projekt neuen Code schreibt.

Im JDK gibts List & Date 2mal? Das würde mich jetzt interessieren, hast du API-Links?

#10

geh auf eine API-Seite, etwa http://docs.oracle.com/javase/7/docs/api/index.html?java/util/List.html
verwende Frames, dann hast du links eine alphabetische Liste aller Klassen, Interface usw., nur noch eine Scrollaufgabe

java.util.List
java.awt.List

java.util.Date
java.sql.Date

#11

[QUOTE=SlaterB]geh auf eine API-Seite, etwa http://docs.oracle.com/javase/7/docs/api/index.html?java/util/List.html
verwende Frames, dann hast du links eine alphabetische Liste aller Klassen, Interface usw., nur noch eine Scrollaufgabe

java.util.List
java.awt.List

java.util.Date
java.sql.Date[/QUOTE]

Interessant.
Naja, aber die könnte man auch gleichzeitig benutzen.

Neues Release:

#12

Kleines Update:

Es gab bisher eine Reihe weiterer Releases, die insbesondere den JS-Client und die Client-Server-Kommunikation verbessert haben (Event-System synchronisiert Server-Sessions aller Nutzer untereinander sowie die Clients mit Ihrer jeweiligen Server-Session).

Momentan wird an einem PlugIn-Interface gearbeitet, wodurch das “Storage-Backend” für die Assets austauschbar wird, man kann also statt FileSystem auch ne DB oder ein Versionierungssystem wie Git oder SVN benutzen, um seine Assets zu benutzen (implementiert wird aber aktuell nur SVN, weil wir das für unsere Assets benutzen). Insbesondere wird sich der GMM mit beliebigen externen Änderungen der Assets (z.B. über einen SVN-Client anstatt über den GMM) synchronisieren können.

3D-Modelle werden mittlerweile per WebGL direkt im Browser dargestellt und können so sehr einfach verglichen werden (alt vs. neu), momentan aber nur solid / Wireframe Ansicht (ohne Texturen).

#13

Worum es hierbei allgemein geht, hat sich mir noch nicht ganz erschlossen, aber …

3D-Modelle werden mittlerweile per WebGL direkt im Browser dargestellt und können so sehr einfach verglichen werden (alt vs. neu)

enthält ein paar Stichworte, die hier eine Antwort von mir triggern: Wie genau wird das gemacht? D.h. was ist das Austausch- oder Deliveryformat? Ich meine ja nur, weil https://github.com/KhronosGroup/glTF/ gerade an Fahrt gewinnt, und z.B. Blender-Exporter und Three.js-Importer dafür erstellt werden…

#14

Ich benutzte Three.js (und auch bereits Blender) ^^

Es wird vom GMM eine Blender-Instanz (ohne GUI) gestartet, in der ein Plugin installiert ist, was die 3D-Modelle von Gothic lesen kann. Die Blender-Instanz startet über ein Python-Skript einen kleinen lokalen TCP-Socket-Server, mit dem sich der GMM verbindet und alle benötigten Modelle als Dateipfad übergibt. Blender konvertiert die Modelle über den three.js Exporter, und der GMM liefert die an den Browser aus.

Edit: Three.js kann anscheinend auch direkt glTF laden.

Edit2: Beispiel-Bild:

#15

Ok, kapier’ ich nicht so ganz… aber wie genau werden die Modelle an den Browser geliefert? (D.h. in welchem Format?)

#16

Im Three.js Format (Three.js hat sein eigenes JSON-basiertes Format). Der Three.js Exporter für Blender kann Blender-Modelle zu diesem Format exportieren. Ist für mich aber prinzipiell egal, was das für ein Format ist, solange Three.js es lesen kann und solange es einen Blender Exporter gibt, der das Format schreiben kann. Aber ein Standard für alle WebGL Bibliotheken wäre natürlich trotzdem sinnvoll.

#17

Ja, glTF ist eben auf dem Weg, so ein Standard zu werden. Viele Engines und Libraries (nicht nur WebGL, sondern OpenGL allgemein, aber auch Vulkan-basierte) unterstützen den schon. Eine Liste gibt’s unter https://github.com/KhronosGroup/glTF#loaders-and-viewers

Aber das soll keine Werbung sein, natürlich kann man auch andere Formate verwenden. (Vermutlich wird vieles, was unter glTF - What the ...? Eine Übersicht über die Grundlagen des GL Transmission Formats augelistet ist, für deinen Anwendungsfall gar nicht benötigt)

#18

Wenn das Format sich durchsetzt, dann ist auf jeden Fall viel gewonnen. Wichtiger als das Format für Meshes/Szenen finde ich eigentlich, dass PBR als Material/Shading Standard auserkoren wurde. Einheitliches programmübergreifendes Shading (in unterschiedlicher Qualität und Performance je nach implementierung) ist verdammt sinnvoll. Das Problem, dass man bei Asset-Änderungen erst erfährt wie es wirklich aussieht, wenn es in der Endanwendung gerendert wird, gehört schnellstmöglich gelöst, und glTF könnte dabei eine weitere treibende Kraft sein.

Für meinen Anwendungsfall allerdings äußerst ungeeignet (völlig Overkill und das Shading der Gothic-Engine ist nicht PBR).

Btw: Die SVN-Integration ist größtenteil fertiggestellt und es gibt eine neues Release: