Impressum
Während man kleine Mods, die nur wenige Einträge in ein oder zwei Dateien ändern, noch problemlos aus dem Stand heraus anfertigt, wird es bei größeren Projekten schnell aufwendiger als anfangs gedacht. Es ist daher zielführend planvoll vorzugehen. Dieses Kapitel liefert daher Tipps bei der Erstellung eines Mods, angefangen bei der Idee bis hin zur Qualitätssicherung, der Dokumentation und dem Umgang mit Kritik und Anregungen Außenstehender.
Meist beginnt die Arbeit an einem Mod damit, dass der Modautor eine brillante Idee hat und er auch schon so in etwa weiß wie er sie umsetzen könnte. Aus dieser Idee ergeben sich dann wiederum Anstöße für weitere Features, die in den Mod eingefügt werden könnten und so wächst der Mod Stück für Stück. Was sich hier jetzt so toll anhört, ist es in Wirklichkeit oft nicht.
Die Unbestimmtheit, mit der sich der Mod weiterentwickelt, kann leicht zu einer Featuritis führen, also dem dauernden Hinzufügen immer neuer Features, wodurch sich schnell Fehler einschleichen können. Es ist daher sinnvoll nicht wild draufloszumodden, sondern planvoll vorzugehen und die anfängliche Euphorie zu nutzen, um die Idee auch kritisch zu betrachten.
Mindmaps sind gut geeignet, um den Einfluss, den der Mod auf das Spielgeschehen haben kann, zu visualisieren. Dazu nimmt man ein Blatt Papier, schreibt in die Mitte des Blattes seine Idee als Schlagwort und ordnet dann darum damit in Zusammenhang stehende Begriffe ein. Man geht dabei vom Oberbegriff zu Details. Ist man fertig, so dürfte man ein relativ gutes Bild davon haben, worauf die Umsetzung der Idee Einfluss haben könnte.
Aus der Mindmap ergeben sich dann vielleicht sogar noch weitere Ideen wie der Mod ausgebaut werden könnte. Auch hier ist es wichtig diese Ideen ein wenig auseinanderzunehmen und zu überlegen, worauf man damit Einfluss nehmen würde. Es kann natürlich auch vorkommen, dass das Ergebnis ernüchternd ist und man aufgrund bestimmter Effekte die Idee sehr schnell wieder begraben muss. Dies sollte jedoch positiv gesehen werden: Anstatt die Zeit in den Aufbau des Mods zu investieren und erst auf halbem Wege festzustellen, dass die Idee nicht so gut war wie gedacht, zeigt sich schon am Anfang, dass man es sein lassen sollte.
Sind diese grundsätzlichen Dinge geklärt, geht es darum die Idee zu präzisieren. Wichtigstes Ziel hierbei ist eine Zieldefinition, also eine Beschreibung dessen, was später im Mod vorhanden sein soll. Dies ist wichtig, um nicht vom Weg abzukommen, die nötige Selbstdisziplin vorausgesetzt. Spätestens jetzt sollte geprüft werden, ob sich der Mod auch tatsächlich als Mod umsetzen lässt oder ob Eingriffe in den Quelltext von Warzone 2100 nötig sind. Funktioniert dies ohne Eingriffe in den Quelltext kann mit dem nächsten Schritt fortgefahren werden.
Je genauer der Mod geplant wird, umso leichter ist es eine Liste der zu erledigenden Aufgaben zu erstellen. Diese Liste ist ein wichtiges Mittel, um den Arbeitsaufwand und den Projektstand abschätzen zu können. Auch wenn die Erstellung einer solchen Liste bereits Modding-Erfahrung voraussetzt, so ist es nicht von Nachteil sich über die benötigten Schritte Gedanken zu machen.
Steht die Arbeitsliste, so dürfte relativ genau bekannt sein, welche Fähigkeiten benötigt werden. Müssen 3D-Modelle erstellt werden, so braucht man jemanden, der PIE-Dateien bearbeiten kann, müssen KI-Scripts geschrieben werden, so wird jemand benötigt, der sich mit der Skriptsprache auskennt. Werden Karten benötigt, so sollte man jemanden haben, der diese zeitintensive Arbeit übernimmt. Sind eigene Grafiken geplant, so werden auch noch Grafiker benötigt, die bereit sind Grafiken unter den verlangten Bedingungen bereitzustellen. Neben der qualitativen Abschätzung der benötigten Arbeit, sollte man aber auch versuchen abzuschätzen wie groß der zeitliche Aufwand ist.
Neben diesen ersten Abschätzungen sollte man bereits jetzt schon sein Publikum im Visier haben: Für wen macht man sich die Arbeit? Handelt es sich um einen Mod, den man nur mit wenigen guten Freunden spielen möchte, steht der Aufwand unter Umständen nicht mehr in Relation zum Nutzen. Möchte man den Mod aber einem großen Publikum zur Verfügung stellen, so gelten mitunter andere Anforderungen. Im folgenden wird nur beschrieben, wie man für ein großes Publikum vorgehen sollte.
Gerade bei der Arbeit an verschiedenen Textdateien wird man nach Testrunden immer wieder etwas ändern wollen. Wenn man größere Änderungen testweise vornimmt, muss man sich allerdings entweder merken, wie die Änderungen aussehen, oder eine Kopie der Datei vor den Änderungen anlegen für den Fall, dass etwas schief geht. Gerade bei längerer Entwicklungsdauer und vielen bearbeiteten Dateien werden beide Methoden impraktikabel.
Stattdessen empfiehlt sich die Nutzung eines Versionskontrollsystems wie sie auch vom Warzone 2100 Project genutzt wird, um den Warzone-2100-Quelltext zu verwalten. Man unterscheidet dabei grundsätzlich zwischen Systemen mit einem zentralen Sammelpunkt für die Daten, dem Repository, (zum Beispiel SVN) und jenen, die dies verteilt erledigen (zum Beispiel git). Beide haben Vor- und Nachteile, die den entsprechenden Seiten zu diesem Thema im Internet entnommen werden können.
Aus der Versionskontrolle ergeben sich viele Vorteile für die Modentwicklung: Jeder fest gespeicherte Stand einer Datei kann jederzeit wiederhergestellt werden. Mithilfe des diff-Features lassen sich Unterschiede zwischen zwei gespeicherten Ständen sichtbar machen, was bei der Fehlersuche enorm hilfreich sein kann. Zudem können mehrere Leute gleichzeitig an einem Repository arbeiten und ihre Änderungen beitragen. Es ist somit nicht nötig, dass eine Person sich darum kümmert die neuen, veränderten und gelöschten Dateien der anderen Modder in seine Vollversion einzupflegen und diese danach wieder unter allen zu verteilen. Über mit einer gespeicherten Version verknüpfte Nachrichten kann auch jeweils in kurzen Worten beschrieben werden, welche Änderungen vorgenommen wurden.
Neben der internen Versionsverwaltung ist es auch wichtig die offiziell herausgegebenen Versionen sinnvoll zu benennen. Persönlich nutze ich das Datum der Veröffentlichung in Form von YYYY-MM-DD gerne als Versionsnummer, vor allem da es keine parallel entwickelten Versionen gibt. Hat man Großes im Sinn, so empfiehlt es sich aber mithilfe der Haupt- und Nebenversionsnummern zu arbeiten, um direkt anhand der Version deutlich zu machen, ob es sich um größere Veränderungen seit der letzten veröffentlichten Version handelt oder nicht.
Für die kostenlose Entwicklung von Mods mag man mitunter denken, dass Qualitätssicherung als eigenes Feld nicht notwendig ist, ist ja schließlich kostenlos. Doch auch wenn etwas nichts kostet, sorgen Fehler bei den potentiellen Modnutzern nicht nur für Frust, sondern auch für einen Vertrauensverlust. Ein viel wichtigerer Aspekt ist aber, dass man durch einen möglichst fehlerfreien Mod hinterher weniger Arbeit damit hat: Ohne Fehler keine Fehlerberichte, die man lesen müsste, keine Nutzer, die fragen, wann der Fehler behoben sein wird, keine zusätzliche Arbeit mit der Veröffentlichung einer neuen Version und viel mehr Zeit, um noch ausstehende Arbeiten zu erledigen.
Eine einfache Methode herauszufinden, ob der Mod so arbeitet wie gewünscht, stellen Tests dar, die überprüfen, ob der Mod so ist wie er in der Zielbeschreibung definiert ist. Gibt es Abweichungen, so kann entsprechend gehandelt werden. Dies ist auch einer der Gründe für die Aufstellung einer solchen Zielbeschreibung. Je genauer die Zielbeschreibung ist, desto einfacher lässt sich der Mod auf Einhaltung dieser testen.
Gerade in der Open-Source-Umgebung ist mangelhafte Dokumentation ein häufig anzutreffendes Problem. Oftmals sind die Entwickler vollkommen damit beschäftigt den Code so hinzukriegen, dass er tut, was sie wollen, sodass keinerlei Zeit mehr für Dokumentation bleibt. Man muss dabei zwei Arten von Dokumentation unterscheiden: Entwicklerdokumentation mit Implementationsdetails und Nutzerdokumentation, was im Endeffekt einer Anleitung gleichkommt.
Die Entwicklerdokumentation dürfte für Mods in der Regel überflüssig sein und erstreckt sich daher höchstens auf Kommentare in unterschiedlichen Dateien wie zum Beispiel KI-Scripts. Dennoch kann es nie schaden interessante oder besonders trickreich gestaltete Dinge gesondert zu erwähnen. Entwicklerdokumentation dient vor allem weiteren interessierten Moddern dazu einen leichteren Einstieg in den Mod als solchen zu haben. Sie ist besonders dann erforderlich, wenn ein Modder sein Projekt auf- oder abgibt.
Wesentlich aufwendiger fällt die Erstellung der Nutzerdokumentation aus. Je größer die Veränderungen gegenüber dem Originalspiel ausfallen, umso länger wird auch die Nutzerdokumentation, da ja alle neuen/geänderten Features auch dokumentiert werden müssen. Es lohnt sich aber allemal, denn auch wenn es Nutzer gibt, die lieber in ein Board oder an eine E-Mail-Adresse spammen anstatt einmal die Dokumentation zu lesen, gibt es haufenweise Nutzer, die lieber die Dokumentation lesen. Man merkt von diesen Nutzern selbstverständlich weniger, da diese eben seltener auf Direkthilfe angewiesen sind. Man sollte auch eine Angabe des Datums der letzten Änderung an der Dokumentation nicht vergessen, damit Nutzer abschätzen können, ob die Dokumentation noch gültig ist oder einfach mit jeder Version mitgeschleift wurde.
Bleibt die Frage, in welchem Format man die Dokumentation erstellen soll. Die Wahl sollte auf jeden Fall auf ein Format fallen, das auf möglichst vielen Rechnern problemlos gelesen werden kann. Damit fallen sämtliche Officeprogramme komplett durch. Wenn man aber dennoch gerne mit einem solchen Programm Dokumentation erstellen will, bietet es sich an eine PDF zu erstellen. PDFs können heutzutage auf so gut wie sämtlichen Rechnern gelesen werden. Andere Möglichkeiten umfassen HTML-Dokumente oder einfach normale Textdateien.
Ist der Mod endlich veröffentlicht, wird es nicht lange dauern bis die ersten Nutzer Rückmeldung liefern. In welcher Form dies möglich ist, hängt von den eigenen Vorlieben ab. Reichen E-Mails der Nutzer aus, so braucht man nicht über die Angabe einer entsprechenden E-Mail-Adresse hinausgehen. Ist der Mod ein wenig größer, bietet sich eine Mailingliste an. Auch ein Blog kann der Rückmeldung dienen, wenn in Blogposts Fragen an die Leserschaft gestellt werden.
Neben einer Vielzahl sinnvoller Rückmeldungen und angebrachter Kritik wird es aber auch immer Vollpfosten geben, die der Meinung sind, dass keinerlei Anstand nötig ist und man als Modder am besten noch die Modinstallation samt Download vorzunehmen hätte. Wie mit solchen Menschen umgegangen wird, muss jeder selbst entscheiden. Wichtig ist mir immer, dass ich möglichst wenig Lebenszeit dafür verschwende.
Kommentare zu diesem Artikel abgeben (benötigt Boardaccount)
Dieses Werk ist unter einer Creative Commons-Lizenz (Namensnennung + nicht kommerziell + Weitergabe unter gleichen Bedingungen) lizenziert.