es geistern hier einige Threads herum, die ganz tolle Ideen und Ansätze haben,
deren Umsetzung sich allerdings als schwierig zeigt. Da wäre einmal Bones Thread
zur Vereinfachung des Moddens ohne Sourcecode durch z.B. Auslagerung von Daten,
die in der ja2.exe liegen. Zum anderen gibt es die Ideensammlung im Thread zur
Masterexe, welche einiges in spielerischer und moddingtechnischer Hinsicht zu
bieten haben soll.
Ideal wäre sicherlich eine Kombination, die die weitergehende Moddingfeatures
aus der Masterexe mit der leichten Handhabbarkeit von ausgelagerten Spieldaten
vereint.
Wie wir wissen, ist Jagged Alliance 2 in C geschrieben und die Programmierer
haben vielleicht nicht unbedingt die beste Arbeit hinsichtlich eines flexiblen
Sourcecodes geleistet. Das mag teils an der Umsetzung selbst liegen, teils aber
auch sicherlich an den Möglichkeiten der Programmiersprache C. Das soll nicht
heißen, dass C eine schlechte Wahl war, oder dass es sich dabei um keine gute
Sprache handelt, nein. Vielmehr ist es so zu sehen, dass vieles in JA2 mit C++
und dem Konzept der Klassen hätte besser und einfacher umgesetzt werden können
- auch in Bezug auf späteres Modding sowohl mit als auch ohne Sourcecode.
Es kommt mir besonders auf letzteres an: das Modden ohne Source und mit den
herkömmlichen Mitteln bzw. idealerweise mit ausgelagerten Dateien, die man mit
einem Texteditor bearbeiten kann. Würde man den JA2-Sourcecode auf C++ mit dem
Einsatz von Klassen umschreiben, könnte man sich der vielen Statik und großen
Unflexibilität entledigen und eigene Vorstellungen dadurch besser umsetzen.
Da das wohl ziemlich unanschaulich sein mag, hier nun ein Beispiel:
Jeder JA2-Modder wird wissen, dass auf dem Itemslot 51 die LAW liegt. Soweit
schön und gut, der Modder kann diesen Raketenwerfer nun aufpeppen und nach
seinen Vorstellungen anpassen ... solange er den Raketenwerfer beibehält. Was
aber, wenn er auf diesem Slot eine ganz andere Waffe haben will, oder er einen
weiteren Raketenwerfer auf einem anderen Slot einbauen will? Tja, in diesem Fall
hat der Modder nun Pech gehabt, denn ohne Weiteres ist dies schlichtweg nicht
möglich. Grund dafür ist eine Abfrage, irgendwo in den Weiten der ja2.exe
versteckt, die kontrolliert, ob es sich beim Abfeuern einer Waffe um Slot 51
handelt. In diesem Fall wird dann die Raketenwerferanimation eingesetzt und gut.
Aus Sicht der Originalprogrammierer sicherlich nicht schlecht, denn für ihre
Zwecke völlig ausreichend. Für den geneigten Modder ein Unding, denn dieses
Verhalten kann er so leicht nicht ändern. Darum hat er keine Möglichkeit wie
oben genannt auf Slot 51 eine andere Waffe als einen Raketenwerfer einzubauen,
oder einen weiteren Raketenwerfer irgendwoanders einzubauen.
Mit dem C++ und dem Klassenkonzept hätte alles anders ausgesehen. Man würde
zum Beispiel eine Klasse "Waffe" haben und davon eine Klasse "Raketenwerfer"
ableiten. Jeder Raketenwerfer im Spiel würde dann der Raketenwerferklasse
angehören. Dies hat zur Folge, dass man, anstatt auf Slot 51 zu prüfen, auf
die Klasse "Raketenwerfer" prüfen kann. Der Modder würde sich freuen, denn nun
ist er nicht mehr slotgebunden, sondern kann nach Lust und Laune seine Waffen
als Raketenwerferobjekt erstellen und die oben erwähnten Einschränkungen fallen
einfach weg.
Ein weiteres Beispiel sind die Waffenattachments wie das Zielfernrohr und der
Laserpointer. Auch hier hat der Modder kaum eine Möglichkeit, Einfluss auf die
Bonusverteilung zu nehmen. Diese sind ähnlich wie die Slotabfrage für die LAW
irgendwo als Abfrage in den Sourcecode eingetragen. Das Spiel schaut beim
Abfeuern einer Waffe, ob DAS Zielfernrohr auf der Waffe montiert ist und
reduziert entsprechend dem Zustand den Sight-Range-Penalty um festgelegte
Werte. Genauso beim Laserpointer - hier wird geprüft, ob DER Laserpointer
montiert ist, entsprechend wird ein fester Bonus auf die Trefferchance verteilt.
Die Artikel vor Zielfernrohr und Laserpointer sind aus einem bestimmten Grund
groß geschrieben. Richtig - auch diese Abfragen sind slotgebunden. Der Modder
hat also auch hier keine Chance auf die Items und deren Wirkung Einfluss zu
nehmen.
Mit den Klassen aus C++ würde das - man mag es sich denken - wieder anders
aussehen. Man könnte z.B. von einer "Attachment"-Klasse eine "Zielfernrohr"-
Klasse und eine "Laserpointer"-Klasse ableiten, über deren Eigenschaften er
auch über die Höhe der Boni entscheiden kann. Dadurch fällt wieder die
Slotgebundenheit weg - der Modder kann an beliebigen Stellen viele Zielfernrohre
und Laserpointer erstellen, die auch über unterschiedliche Verhaltensweisen in
der Boniverteilung verfügen, so dass z.B. verschieden starke Fernrohre möglich
wären, die unterschiedlich große Boni einbringen.
Die Liste dieser Beispiele lässt sich noch um einiges fortsetzen, trotzdem noch
ein weiteres besonderes Beispiel der Klassen.
Bisher gibt es eine Itemtabelle, die allgemeine Daten wie Gewicht, Bild usw.
enthält, und spezielle separate Tabellen für Waffen, Munition, Rüstungen und
Sprengstoffe, die jeweils die weitere Daten wie Reichweite, Magazingröße oder
Sprengradius enthalten. Um diese Tabellen miteinander zu verbinden, ist es
nötig in der Itemtabelle mitanzugeben, an welcher Position in der speziellen
Tabelle die erweiterten Daten stehen. Dies ist nicht nur nicht so schön, es
bringt auch einige Besonderheiten mit sich. So verweisen die beiden T-Shirts
in der Itemtabelle auf den gleichen Eintrag in der Rüstungstabelle und weisen
somit die gleichen erweiterten Eigenschaften auf.
Mit dem Klassenkonzept würde man eine Klassen "Items" aufsetzen, die die ganzen
regulären Informationen zu den Items enthält, und entsprechend davon eine
"Waffen"-, eine "Munition"-, eine "Rüstungs"- und eine "Sprengstoff"-Klasse
ableiten, die jeweils die spezielle Daten ergänzen. Statt mit vielen einzelnen
Tabellen zu jonglieren, wäre es dann nur nötig seine Items mit samt ihren
Werten in der jeweiligen Klasse zuzuordnen.
Wie gesagt, sind das nur Beispiele. Es wird sehr wahrscheinlich noch unzählige
andere Dinge geben, die man mit Klassen einfacher und besser lösen kann. Wenn
man bedenkt, dass der Sourcecode mehr als 200 Strukturen enthält, welche man
alle als potentielle Kandidaten für Klassen sehen kann, ist an eine komplette
Klassenportierung natürlich nicht zu denken. Vielmehr müsste man eine Auswahl
treffen, bei welchen Sachen es sinnvoll und lohnenswert ist, diese durch den
Klasseneinsatz zu lösen.
Dies soll als Gedankenspiel dienen und vielleicht Berücksichtigung finden bei
einem größeren Projekt, das die zu Beginn genannten Ansätze umsetzt.
Meinungen, Kommentare und Fragen, bitte.
Führer der SoS 
"I believe in the golden rule. The man with the gold . . . rules!" - Mr.T 
