De/Making a Mod

Dieser Artikel wurde erstellt, um dir den Anfang einer Source Engine Modifikation (auch Mod) zu erleichtern. Als erstes geht es um die Organisation einer Modifikation und der Zusammenstellung eines Teams. Des weiteren behandelt dieser Artikel eine Reihe an Tipps und Informationen zum Design deiner Modifikation. Zum Abschluss findest du einen Schritt-für-Schritt Guide um deine Mod zu vervollständigen, was der schwerste Teil der Entwicklung ist.

Der Anfang

Schauen wir uns zuerst an, wie man ein Team bildet. Die Leitregel hierbei ist es klein zu denken. Ein Team zu leiten ist ein Vollzeit-Job, selbst wenn alle Personen im gleichen Gebäude wohnen würden. Wenn du mit einem online Team arbeitest, kannst du schnell all deine Zeit in das Management verbrauchen, was bedeutet, dass du keine Zeit mehr haben würdest an deiner Mod zu arbeiten. Mehr Personen in dein Team aufzunehmen bedeutet nicht, dass du auch produktiver arbeiten kannst. Je mehr Personen du in deinem Team hast, desto mehr Zeit musst du für das Management aufwenden. Team Fortress' Entwicklungsteam bestand aus 3 Leuten. Counter-Strike's Entwicklungsteam bestand aus nur einer Person!

Beim Ausschau halten nach Teammitgliedern solltest du nur die wichtigsten Leute aufnehmen. Die, ohne die deine Mod nicht überleben könnte. Dein erster Gedanke wird sicher sein, dass du dich nach Leuten umschaust, die Coden können, oder modellieren, oder Maps erstellen. Doch für deine erste Version brauchst du sehr wahrscheinlich maximal eine Person in jeder dieser Bereiche (Code, Sound, Modelle, Maps). Eventuell brauchst du nicht einmal neue Modelle, Sounds oder Maps. Nehme niemanden auf, bevor du nicht Arbeitsproben der Person gesehen hast. Stell sicher, dass sie bereits Arbeiten vervollständigt haben. Wenn du einen Modelliere findest, der an 20 Modellen gearbeitet hat, aber noch keins vollendet, dann willst du ihn nicht!

Mod design

Als ein Modersteller gibt es eine wichtige Frage, die du dir immer wieder stellen musst. "Warum sollte jemand meine Mod spielen?". Es ist sehr schwer, diese Frage ernsthaft zu beantworten. Aber wenn du dies schaffst, bist du auf dem richtigen Weg! Schaue dir andere Mods auf dem Markt an und was sie zu bieten haben. Gibt deine Mod dem Spieler eine neue Möglichkeit zu spielen? Ist das, was du dem Spieler bietest genug um ihn bei Stange zu halten? Selbst wenn du dir diese Fragen noch nicht beantworten kannst ist es für die Produktion sehr hilfreich, an diese Leitfragen zu denken.

Mit Gameplay spielen

Du hast die Möglichkeiten, die kommerzielle Entwickler nicht haben: Du musst dich nicht um die kommerzielle Möglichkeiten neuer Gameplay-Elemente kümmern. Kommerzielle Entwickler müssen immer darauf achten, dass ihre Inhalte auf dem Markt Platz haben und von genug Personen genutzt werden. Dies ist der Grund, warum viele Spiele nur kleine Änderungen an ihrer Gameplay-Formel machen. Darüber musst du jedoch nicht nachdenken! Du kannst neue Gameplay-Stile und Elemente ausprobieren wie du möchtest, eventuell wird es ja das nächste "Große Ding". Dies ist dein Vorteil gegenüber kommerziellen Produktionen. Versuche eine neue Erfahrung zu schaffen, statt dich in übersättigten Bereichen mit großen Titeln zu messen. Viele Mods können sich inhaltlich (Maps, Models, Sounds etc.) nicht mit kommerziellen Produkten messen. Sie haben große Teams mit jahrelanger Erfahrung. Schlage sie mit deinem Gameplay! Spieler spielen eine Mod, die wenig neuen Inhalt aber dafür ein besonderes oder spaßiges Erlebnis haben. Etwas, was viele Leute vergessen ist, dass Team Fortress 1 über ein Jahr lang nach Release keine besondere Grafik bot.

Veröffentliche häufig, Veröffentliche oft

Du hast eine andere Möglichkeit, die kommerziellen Entwicklern verwehr bleibt. Du kannst oft veröffentlichen, deutlich früher und deutlich häufiger, als sie es können! Diesen Vorteil haben wir abgekürzt mit "Veröffentliche häufig, Veröffentliche oft". Kommerzielle Entwickler arbeiten für 2-3 Jahre an einem Titel, veröffentlichen ihn und beten zu Gott, dass die Spieler den Titel mögen. Du musst nicht so weit gehen! Du kannst deine Mod planen, sie zu 25% fertigstellen, in einen Spielbaren Zustand bringen und anfangen Feedback zu sammeln. Danach kannst du deine weiteren Design-Elemente Stück für Stück hinzufügen während du auf das Spieler-Feedback eingehst und jeden bis jeden zweiten Monat Updates veröffentlichst. Du bist jederzeit mit deinen Spielern verbunden, deswegen wirst du niemals in der Situation sein wo du viel Zeit an einem Projekt arbeitest, was schlussendlich niemand Spielen will. Der Trick ist, deine Mod in kleine Teile zu schneiden. Die erste Version muss nur spielbar sein und Spaß machen, sie braucht nicht jede coole Idee die du bereits geplant hast.

Vorsichtig! "Veröffentliche häufig" bedeutet nicht, dass du schnell Inhalte veröffentlichst, die in schlechter Qualität sind. Es geht darum dein Projekt in kleinen Meilensteilen zu bearbeiten. Die erste Version von Counter-Strike hatte nicht einmal halb so viele Features wie jetzt. Das CS Team veröffentlichte eine hoch qualitative aber keine große Mod. Das Jahr danach arbeiteten sie stetig an dem Projekt, packten Features hinzu und gleichzeitig wuchs ihre Spieler-Base.

Anders ist nicht immer besser

Wenn du über dein Spieldesign nachdenkst, versuche nicht in die Falle zu laufen und zu denken, dass "Anders immer Besser ist". Es gibt keinen Grund den Shotgun Code neu zu schreiben und ein neues Model zu erstellen, wenn es dein Spiel nicht interessant erweitert. Denk an die Leitfrage "Warum sollte jemand meine Mod spielen?". Die Antwort "Meine Mod hat ein neues Kampfsystem und ein neues Bewegungssystem" ist nicht unbedingt eine gute Antwort. Dein Kampfsystem ist also ein anderes als in Half-Life. Okay. Aber ist es auch besser? Macht es dadurch mehr Spaß? Fühlt sich dein Bewegungssystem besser an? Spieler haben sich an bestimmte existierende Systeme gewöhnt, etwas völlig neues zu erschaffen ist schwierig und es nicht immer wert, von dem Spieler neu gelernt zu werden. Bevor du dir also Gedanken über eine Änderung machst musst du dir im klaren sein, dass die Änderung auch besser für deine Mod ist. Hab keine Angst, wenn du Teile des Gameplays unverändert wie in Half-Life lässt.

Realistische Ziele

Habe persönliche realistische Ziele! Überlege dir wie lange ein kommerzieller Entwickler braucht um ein FPS shooter mit 10 Waffen zu erstellen. Wenn deine Mod 40 Waffen haben soll, machst du es dir nur unnötig schwer! Der wichtige Gedanke hierbei ist "Qualität vor Quantität". Es ist für den Spieler besser 10 einzigartige ausbalancierte spaßige Waffen zu haben als 40 unbalancierte Waffen, welche nur kleine Änderungen voneinander aufweisen.

Sei nicht besorgt, Inhalte und Features zu streichen. Wenn deine Mod scheinbar nie die Produktion beenden kann oder wenn du erkennst, dass Inhalte nicht dem Qualitativen Standard entsprechen, solltest du sie streichen. Während der Entwicklung von Half-Life wurden mehr als 30% der originalen Features gestrichen, da es klar wurde, dass sie niemals in das Zeitfenster der Produktion hätten passen können oder weil beschlossen wurde, dass sich die Entwicklungsarbeit der Features nicht lohnt. Wie bereits zuvor gesagt, "Qualität vor Quantität". 3 sehr gut getestete Maps sind auf jeden Fall besser als 10 ungetestete und dies hebt die Qualität deiner Inhalte. Zeig der Welt nicht deine schlechtesten Sachen!

Versteh die Engine

Du solltest auf jeden Fall die Dokumentation der SDK ansehen. Dabei liegt der Fokus nicht darauf, dass du lernst wie du X machen kannst, sondern wie du X richtig machen kannst. Du kannst vielleicht eine Waffe erstellen, die 50 Raketen abfeuert aber wenn du die Engine nicht verstehst, könnte es passieren dass du zum Beispiel die Netzwerkauslastung deiner Mod deutlich übersteigst. Dies ist für alles in deiner Mod wichtig. Wenn deine Map-Ersteller die Engine nicht verstehen, machen sie riesige Maps ohne daran zu denken, wie die Daten verarbeitet werden und wie man dies performant lösen kann. Wenn du ein Coder bist ist es sinnvoll der HL Coders Email-Liste beizutreten wo du dich mit vielen anderen Mod Entwicklern und Valve-Mitarbeitern austauschen kannst. Die Email-Liste hat ein langes und großes Archiv mit vielen Inhalten für bereits gelöste Probleme.

Fertigstellen

Wir sehen viele Mods die stark starten, viele tolle Inhalte produzieren aber nie den letzten Schritt wagen in die Hände der Spieler zu gelangen. Dieser Abschnitt wird dir helfen in einen Veröffentlichungs-Modus zu gelangen, um deine Inhalte präsentierbar ausliefern kannst.

Wir haben fünf Wochen als eine geeignete Zeitspanne genommen. In dieser Zeit arbeitest du an deinem Projekt, um sie von der Entwicklungs-Version zu einer Auslieferbaren Alpha-Version zu bekommen. Du wirst nach der Zeit sicher deutlich besser und schneller mit diesen Schritten umgehen können. Wenn deine Mod sehr groß ist oder dein Team international verteilt ist kann es sein, dass du mehr als fünf Wochen brauchst, wobei die Schritte selbst gleich sind. Wenn Möglich solltest du während dieser Zeit versuchen jedes Team-Mitglied ein paar Stunden jeden Tag an das Projekt zu setzen. Wenn ein Mitglied dafür keine Zeit hat solltest du ihn aus dem Veröffentlichungs-Prozess rausnehmen. Verteile seine Aufgaben auf andere, die mehr Möglichkeiten haben. Ein Projekt zu veröffentlichen, selbst ein kleines, ist hart und benötigt eine große Menge an Engagement.

Viele Sachen in diesem Abschnitt können drastisch oder hart klingen. Dies ist bedauerlich, zeigt aber wie hart der Prozess ist. Die Informationen und Anweisungen sind eine Zusammenfassung von Lektionen die bei vielen verschiedenen Projekten gelernt wurden. Sie sind meist das Resultat von schmerzhaften Fehlern, die das Release-Datum verschoben haben. Wenn du dich fragst, ob ein Rat wirklich nötig ist kannst du dir sicher sein, dass wir dazu "Nein" geantwortet haben, was das Projekt verlängert hat.

Dies ist auch etwas, was zukünftige Arbeitgeber interessiert. Es ist eine Sache zu sehen, dass ein Mod-Entwickler etwas cooles kreiert hat. Es ist etwas völlig anderes zu sehen, dass jemand nicht nur etwas cooles kreiert hat sondern dies tatsächlich ausliefern konnte und Spieler es spielten. Die coolsten Inhalte sind nutzlos, wenn du den letzen Meter, den Absprung nicht schaffst.

Keine Angst, das alles wird nach der Zeit immer einfacher, solltest du es einige male durchgegangen sein. Bei deiner vierten oder fünften Veröffentlichung solltest du schon ein Experte sein.

Noch fünf Wochen

Besitz klären

Du solltest eine Person aus deinem Team als Shipping Leader also Veröffentlichungs-Leiter (auch SL) ernennen. Diese Person wird den Prozess der Veröffentlichung in den nächsten fünf Wochen steuern. Alle Änderungen an der Mod sollten von nun an auf Befehl des SL's basieren und alle Änderungen sollten durch diese Person gehen. Kein Team-Mitglied sollte eine Änderung tätigen, egal wie klein sie ist, ohne dies mit dem SL abzusprechen. Dies bedeutet nicht, dass die restlichen Mitglieder im Team ihren Willen verlieren. Der SL ist immer noch Teil des Teams und wird Feedback sammeln. Der Sinn hinter dem SL ist, dass alle Änderungen durch eine einzige Person gesteuert wird. Dies verhindert Probleme wie Map-Entwickler, die eine ganze Map in der letzen Minute zerstören, da er nicht wusste, dass jemand den Code geändert hat. Der SL wird den Status jeder einzelnen Komponente des Projekts zu jederzeit während dieser 5 Wochen wissen um dies zu verhindern.

Einen SL zu bestimmen ist nicht einfach. Hier sind ein paar Tipps:

• Gehe nicht davon aus, dass der aktuelle Teamleiter die beste Wahl zum SL ist. Besonders wenn die Mod seit einigen Monaten entwickelt wird und nicht näher zum Release kam.
• Spiel Coder sind wahrscheinlich die beste Wahl. Nähe der Veröffentlichung werden die meisten Änderungen im Spiel-Code getätigt.
• Der SL sollte hochmotiviert, diszipliniert, organisiert und so Ego-frei wie möglich sein. Der SL muss fünf Wochen seiner Zeit für diesen Prozess opfern können.
• Der SL sollte globale Entscheidungen für die Mod treffen können. Der SL sollte verstehen, dass dies oft bedeutet Features und Inhalte streichen zu müssen, um veröffentlichen zu können

Einen Build-Prozess etablieren

Du musst einen Prozess entwickeln um deine Mod zu Builden. Builden ist der Prozess der alle arbeiten in eine installierbare, funktionierende Version deiner Mod verarbeitet (häufig in Form einer installierbaren Datei). Dies sollte die nächsten fünf Wochen nur der SL übernehmen und der SL sollte einen strikten Prozess haben, der immer befolgt wird. Einen strikten Prozess zu haben verhindert ein stundenlanges suchen von Bugs die nur das Resultat davon sind, dass jemand etwas anders gebuildet hat als die vorherige Person.

Der SL sollte von nun an die Finale/Release Version deiner Mod pflegen. Alle Änderungen sollten zu ihm geschicht werden und er sollte diese nacheinander in seine Kopie der Mod einpflegen und sich zu jederzeit die Ausmaße der Änderungen bewusst sein. Denk daran alle Inhalte regelmäßig zu sichern!

Der SL sollte die Mod täglich für Playtests builden. Mehr dazu später.

Inhalte festlegen

Die Veröffentlichung ist der Prozess des Festlegens von Bereichen deiner Mod. "Gelockt" bedeutet, dass dieser Bereich von nun an nicht mehr angerührt werden darf. Bugs in "gelockten" Bereichen sollten vorsichtig durchdacht werden. Sollte der Bug kein "Gamebreaker" sein (also das Spiel in einer massiven Art schädigen), sollte er einfach aufgeschrieben werden und im nächsten Update gefixt werden. Auch wenn die Versuchung groß ist eine "einfache Behebung" des Bugs durchzuführen sollte man davon absehen. Bereiche den "Gelockt" Status zu entziehen sollte bestmöglich vermieden werden.

Zu diesem Zeitpunkt des Veröffentlichungs-Prozesses (Fünf Wochen vor der Veröffentlichung) sollten auch die Features "gelockt" sein. Dies bedeutet, dass du keine weiteren Features in deine Mod aufnehmen solltest. Wenn ein Teil deines Teams nicht an dem Veröffentlichungs-Prozess teilnimmt und trotzdem weiter an Features arbeiten möchte, sollten sie dies in einem Separaten Bereich tun. Die meisten Versionsverwaltungssysteme unterstützen das sog. "Branching", also einen zweiten Entwicklungszweig einzustellen (Ja, wir raten dir stark ein Versionsverwaltungssystem zu nutzen). Jede Änderung an der Mod von nun an sollte eine Behebung eines Bugs sein. Der SL soll dies gewährleisten. Auch wenn ein Entwickler ein cooles Feature hat, dass nur 10 Minuten zum implementieren braucht, soll er es nicht tun. Selbst wenn er dem SL einen Bug-freien und getesteten Code schickt. Füge ihn nicht ins Spiel sondern speichere ihn für die nächste Version.

Eine gesunde Einstellung für den SL ist es zu sagen, dass jeder neue Inhalt die Veröffentlichung der Mod um zwei Tage verschieben wird.

Playtesting

Ab jetzt solltest du tägliche Playtests oder zumindest jeden zweiten Tag machen. Playtests sollen auf der installierbaren Version des Spiels, gebuildet vom SL basieren. Lass die Team-Mitglieder nicht von ihrer persönlichen Version des Spiels testen. Jeder sollte eine Version benutzen, die von einem Build des SL stammt (diese Version werden die Spieler installieren und nutzen, deswegen solltest du diese testen). Du wirst Stunden daran vergolden Bugs zu Beheben die von einer inkompatiblen Version stammen wenn du dies nicht befolgst.

Um es einfacher zu machen, sollte deine Mod zu jederzeit in einem Spielbaren Status sein. Sei sehr sehr besorgt um jeden Tag, wo deine Mod nicht in diesem Status ist. Wenn ein Coder oder Map-Ersteller eine Änderung tätigt, die die Mod zerschießt, überlege dir ob diese Änderungen in den Build des SL's gelangen sollen. Wie lange wird die Mod unspielbar bleiben? Wie viele Playtests werden dadurch nicht gemacht. Wie viele Teammitglieder können nicht weiterarbeiten, weil die Mod nicht spielbar ist? Die Mod nicht zu zerschießen sollte im Team von höchster Priorität sein.

Wenn du Playtests machst, achte darauf, dass so viele Teammitglieder wie Möglich testen. Jeder, der an der Mod arbeitet sollte sie regelmäßig spielen. Achte auch darauf externe Spiele zu haben. Aktiviere die Server-Logdateien (Setze "log" auf "on" in der server.cfg Datei). Dies wird alle Ausgehenden Informationen des Servers in eine Datei in dem gamedir/logs Ordner schreiben (Der genaue Name wird durch das Datum festgelegt). Wann immer ein Spieler einen Bug entdeckt, sollten sie in der Konsole den Kommand "say" nutzen um "BUG: Beschreibung des Bugs" in die Logdatei zu schreiben. Dadurch kannst du nach dem Playtest nach "BUG" suchen und die Ursache sofort nachschauen.

Bugs und Änderungen

Der SL sollte eine komplette Liste aller Bugs, Änderungen und deren Status haben. Vorzugsweise sollte dies in einer echten Datenbank hinterlegt sein. E-Mails sind völlig unzureichend für das Bug-Tracking, da die Informationen zu de-zentral sind. Nach jedem Playtest sollte der SL Bugs und nötige Änderungen aus den Logdateien übernehmen und diese an Teammitglieder verteilen. Sollte ein Bug behoben worden sein sollten die neuen Inhalte an den SL übermittelt werden, welcher überprüft, ob der Bug behoben wurde und dann den Status auf der Bugliste verändern.

Die Bugliste ist ein wunderbares Werkzeug um zu erfahren, wie gut es voran geht. Es kann genutzt werden um zu ermitteln, wer besonders viele Aufgaben zu bewältigen hat, wer unterbelastet ist, wer seine Bugs nicht behebt, welche Bereiche deiner Mod am weitesten von einer Veröffentlichung entfernt sind und so weiter. Lösche nichts von der Bugliste, selbst wenn etwas behoben wurde (Du solltest dies dann natürlich als "Behoben" markieren). Es ist sehr wertvoll zu sehen welche Bugs in der Geschichte eines Projekts behoben wurden. Etwas könnte einen Bug erneut hervorrufen und zu wissen, wer den Bug das letzte mal beseitigt hat macht es einfacher ihn erneut zu beheben. Am Ende eines Projekts sollte es möglich sein alle behobenen Bugs und alle getätigten Änderungen während des Veröffentlichungs-Prozesses zu überblicken. Der SL sollte nicht erlauben unkategorisierte Bugs in seiner Master-Kopie zu beheben.

Für die pflege einer Bugliste gibt es entsprechende Software-Lösungen. Alternativ kann man auch eine Excel oder Spreadsheet Datei nutzen. Wie bereits angesprochen ist E-Mail eine schlechte Wahl.

Streiche oder verschiebe kaputte Features

Der schwerste, fiesteste und leider wichtigste Part des Veröffentlichens ist es realistisch zu denken und Features streichen zu müssen. Wir haben bei Valve ein Sprichwort das besagt, dass ein jeder Lieblings-Feature vom Spiel gestrichen wird. Während dies nicht zutrifft hilft es den Leuten klar zu machen dass sie Features streichen müssen die sie sehr mochten oder an denen sie lange gearbeitet haben. Dein Spiel kann nicht jedes tolle coole Feature beeinhalten und trotzdem in einer realistischen Zeitspanne erscheinen. Der SL sollte die Entscheidung treffen welche Features gestrichen werden und welche vollendet werden, basierend auf den Status der Entwicklung.

Je näher du der Veröffentlichung stehst solltest du dir über jeden Bug den du findest Gedanken machen. Ist der Bug in einem Feature, was ein absolutes Muss in dieser Version ist? Wie viele Tage wird das Team brauchen um diesen Bug zu beheben? Kann dieses Feature gestrichen werden oder zu einem späteren Zeitpunkt hinzugefügt werden?

Arbeite smart, nicht hart

Wie wir bereits immer wieder betont haben, der Veröffentlichungs-Prozess ist hart wenn du nicht vorsichtig entscheidest an was du arbeitest. Viel arbeiten ist kein Ausgleich für das bedachte angehen von der Behebung von Bugs, oder welche Inhalte gestrichen werden sollten. Der SL muss sehr genau darauf achten an welchen Bugs/Änderungen gearbeitet wird und von wem. Verbringe nicht eine Woche daran ein kleines Problem in einem Feature zu beheben weil das Feature cool ist. Behebe lieber Abstürze oder Bugs die dein Spiel maßgeblich stören (Gamebreaker). Behebe Bugs die es deinen Teammitgliedern nicht ermöglicht ihre Bugs zu beheben. Der SL sollte an Kategorien von Bugs arbeiten um die richtigen Entscheidungen zu treffen. Eine gutes Beispiel dafür wäre: Muss behoben werden, Wichtig, Mittelmäßig, Unwichtig, Egal, Zu einem späteren Zeitpunkt.

Je näher das Projekt der Veröffentlichung steht sollte der SL genau festlegen an welchem Bug als nächstes gearbeitet werden soll. Denk daran, dass jede Behebung eines Bugs weiteres Playtesting sowie weitere Bugs hervorrufen kann. Wenn du zwei Wochen vor der Veröffentlichung einen Bug findest der in drei Tagen und 500 Zeilen Code erst behoben werden kann, wirst du es sehr sicher nicht bis zu dem Veröffentlichungsdatum schaffen.

Noch drei Wochen

Inhalte festlegen

Ab jetzt sollte dein Projekt "Content Complete" sein. Dies bedeutet, dass alle Inhalte in deinem Spiel, außer dem Code selbst, in einem "Gelocktem" Zustand sind. Alle Maps, Modelle, Texturen, Sounds, HUD Grafiken, Launcher Grafiken und so weiter sollten fertig sein und in der SL Master-Kopie sein.

Abschalten

Dies wurde bereits bei der fünf Wochen Marke thematisiert, ist nun jedoch noch viel wichtiger. Der SL ist die einzige Person, die die Master-Kopie des Spiels anfassen darf und sollte nur noch Behebungen von Bugs von den Codern übernehmen. Die Coder sollten nur noch die ihnen zugewiesenen Bugs beheben.

Playtesting

Die Mod sollte täglich mindestens zwei Stunden getestet werden. Zwischen jetzt und der Veröffentlichung sollen so viele Leute wie Möglich deine Mod auf Herz und Nieren prüfen. Es ist zu spät um Design-Änderungen durchzuführen, versuch es gar nicht erst!

Noch eine Woche

Keine "Last-Minute" Änderungen

Der SL soll jede Änderung genauestens prüfen und entscheiden sie eventuell für die nächste Version zu verschieben. Noch einmal, eine realistische Einschätzung ist es, dass jede Änderung, selbst wenn es nur eine Zeile im Code ist die Veröffentlichung um zwei Tage verschiebt.

Zwei Tage Sicherheitsperiode

Nachdem jeder Bug der behoben werden soll behoben wurde und alles andere verschoben wurde, bist du noch nicht fertig. Nun wartest du mindestens 48 Stunden, in denen du so viel Playtesting betreibst wie möglich. Versuche jeden dazu zu bringen deine Mod zu zerstören. Wenn du einen Bug entdeckst, der behoben werden sollte, behebe ihn und starte die 48 Stunden erneut.

Wenn deine Mod die 48 Stunden von starkem Playtesting übersteht, bist du bereit für die Veröffentlichung!

Nach der Veröffentlichung

Du hast dein Projekt also veröffentlicht, die Spieler lieben es und Webseiten überall reden darüber wie toll deine Mod ist. Ob du nun fertig ist liegt ganz an dir. Von unseren Erfahrungen im Online Multiplayer Bereich können wir sagen, dass eine Mod nur so lange relevant bleibt, wie sie supportet wird. Egal wie gut deine Mod ist, sie wird sonst keine Spielerschaft mit der ersten Version sammeln können. Spielerzahlen wachsen mit der Zeit durch Updates, neue Inhalte, die Behebung von Bugs und natürlich Community Support. Counter-Strike und Team Fortress haben einmal klein angefangen und sind mit der Zeit gewachsen. Nach jeder neuen Version probieren mehr und mehr Spieler diese Spiele aus und starten sie zu spielen.

Zu wissen was man behebt, was man ändert und wie man auf seine Community hört ist ein stetiger Lernprozess.

Viel Glück!

Siehe auch

• Shipping Leader In Detail
• Mod Packing & Shipping
• Category:Modding