Mod-Entwicklung (von VALVe)

Dieser Artikel stammt im Original von Valve Software und wurde bei Planet Half-Life veröffentlicht. Der Artikel wurde nicht komplett ins Deutsche übersetzt, sondern nur die Tipps von Valve zum Erstellen eines Mods (Seite 2).

Kostenlose Ratschläge

Warum dieser Mod?

Die nützlichste Frage, die man sich als Mod-Autor stellen kann, ist: „Warum sollte jemand meinen MOD spielen?“. Diese Frage wahrheitsgemäß zu beantworten ist schwer. Wenn man es jedoch kann, ist man auf dem richtigen Weg. Man sollte sich andere Mods anschauen und herausfinden, was sie anzubieten haben. Bietet dein Mod dem Spieler etwas Neues? Hat er genug Neuheiten anzubieten, um Spieler von anderen Mods wegzulocken? Auch wenn man diese Frage nicht beantworten kann, wird einem das alleinige Nachdenken über diese Frage wahrscheinlich bei der Erstellung der Mod helfen.

Vorteile gegenüber kommerziellen Entwicklern

Man selbst hat Möglichkeiten, die kommerzielle Entwickler nicht haben: Man muss sich keine Gedanken über die kommerzielle Überlebensfähigkeit eines neuen Gameplays machen. Kommerzielle Entwickler müssen über die Attraktivität des Produkts im Einzelhandel, das Decken der Entwicklungskosten und andere unangenehme Dinge Sorgen machen. Daher besitzen die meisten Spiele ein bereits bewährtes Gameplay mit kleinen Veränderungen. Ein Mod-Team jedoch hat die Möglichkeit eine revolutionäre Gameplay-Idee zu verwirklichen, die dann möglicherweise der nächste Renner ist. Das ist der Vorteil gegenüber kommerziellen Entwicklern.

Mache dir deine Arbeit leichter, indem Du dich auf diesen Vorteil konzentrierst und versuche nicht kommerzielle Produkte in Gebieten zu schlagen, in denen diese naturgemäß stark sind. Die meisten MODs können nicht mit dem Niveau kommerzieller Produkte konkurrieren (z.B. bei Maps, Models, Sounds, etc). Die Industrie hat ganze Teams von Künstlern, die alle mehrjährige Erfahrung besitzen. Schlage sie mit deinem Gameplay. Spieler werden einen Mod spielen, der vom Inhalt her wenig bietet, aber ein wirklich cooles Gameplay hat. Vielen Leuten ist nicht bewusst, dass beinahe ein Jahr vergangen ist, bevor Team Fortress 1 (Models, Texturen etc.) neue Inhalte erfahren hat.

Veröffentlichungspolitik

Ein unabhängiges Entwickler-Team hat einen weiteren Vorteil gegenüber kommerziellen Entwicklern. Neue Versionen können viel schneller und in kürzeren Abständen herausgebracht werden. Valve Software hat diese Mod-Entwicklungs-Philosophie mit dem folgenden Satz zusammengefasst: „Veröffentliche schnell, veröffentliche oft“. Kommerzielle Entwickler arbeiten 2-3 Jahre, veröffentlichen ihr Spiel und hoffen, dass die Spieler es mögen. Du musst das nicht so machen. Du kannst deinen ganzen MOD designen, 25% davon fertigstellen und zu einer spielbaren Version aufpolieren, dem Mod veröffentlichen und dir unmittelbar danach Feedback einholen. Danach kann man anfangen den Rest des Designs nach und nach hinzuzufügen und parallel dazu das Feedback zur ersten Version durcharbeiten. Neue Versionen der Mod sollten in Abständen von etwa 1-2 Monaten veröffentlicht werden.

Indem man permanent die Verbindung zu den Spielern des Mods aufrecht erhält, kommt man niemals in die Situation, zu viel Zeit in ein Feature zu investieren, dass den Spielern möglicherweise nicht gefällt. Der Trick ist, die Mod scheibchenweise zu liefern. Die erste Version muss Spaß machen und spielbar sein, aber muss nicht jedes geplante Feature enthalten. Vorsicht: „Schnell veröffentlichen“ heißt nicht, dass man auch schlechte Qualität abliefern soll. Der Mod sollte in kleinen, sauberen Stücken veröffentlicht werden. Die erste Version von Counter-Strike hatte nicht einmal die Hälfte der Features, das es heute besitzt. Das CS-Team hat einen hochwertigen aber kleinen Mod veröffentlicht. Im letzten Jahr wurden dann regelmäßig neue Features hinzugefügt, als Reaktion ist die Spielergemeinde immer weiter angewachsen.

Verschieden ist nicht immer besser

„Verschieden ist nicht immer besser“. Wenn man über das Gamedesign nachdenkt, gilt nicht immer die Denkweise „verschieden ist besser“. Es gibt keinen Grund den Shotgun-Code neu zu schreiben und die Shotgun mit einem neuen Model zu versehen, solange es den Mod nicht in irgendeiner Form bereichert. Kehren wir zurück zur Frage „Warum sollte jemand meinen MOD spielen?“. „Mein MOD hat ein neues Kampf- und Bewegungssystem!“ ist nicht notwendigerweise eine gute Antwort. Abgesehen davon, dass das Kampfsystem deines Mods sich grundsätzlich von dem Kampfsystem von Half-Life unterscheidet … ist es besser? Macht der Mod dadurch mehr Spaß? Bringt das neue Bewegungssystem mehr Spaß? Spieler sind existierende Systeme gewöhnt und wenn sie ein neues lernen müssen, muss es sich für sie lohnen. Bevor man darüber nachdenkt etwas zu verändern, sollte man sich sicher sein, dass die Änderung eine Verbesserung herbeiführt und den Mod aufwertet. Habe keine Angst davor etwas so zu belassen, wie es bereits in Half-Life war.

Qualität statt Quantität

Man sollte sich realistische Ziele setzen. Man sollte sich darüber im Klaren sein, wie lange ein kommerzieller Entwickler braucht, um einen First-Person-Shooter mit zehn Waffen zu entwickeln. Man sollte es sich nicht unnötig schwer machen und lieber darauf verzichten, einen Mod mit 40 Waffen zu erstellen. Hier ist zu bedenken, „Qualität statt Quantität“. Spieler würden zehn Waffen, die einzigartig, ausbalanciert und spaßig sind, jederzeit 40 unausgewogenen Waffen vorziehen, die sich möglicherweise nur geringfügig unterscheiden.

Kleine Teams

Versuche, das Team klein zu halten. Das Team wird wahrscheinlich über die ganze Welt verteilt sein und seine Mitglieder mögen Jobs haben, die viel Zeit in Anspruch nehmen. Ein Team zu leiten ist eine Arbeit für sich und je weniger Zeit man dafür benötigt, umso mehr Zeit hat man für die Arbeit am Mod. Nachdem eine ersten Version der Mod veröffentlicht worden ist, kann man über eine Erweiterung des Teams nachdenken. Man sollte immer daran denken, dass eine Aufstockung der Mitgliederzahl die Zeit erhöht, die benötigt wird, um das Team zu koordinieren. Dies kann zur Folge haben, dass weniger Arbeit am Mod selbst erledigt wird.

Features streichen

Man sollte keine Angst davor haben, Inhalte oder Features zu streichen. Wenn es so aussieht, als würde der Mod niemals fertig werden oder einige Inhalte entsprechen nicht der allgemeinen Qualität, dann sollte man anfangen ein paar Dinge zu kürzen. Während der Entwicklung von Half-Life sind mindestens 30% der geplanten Inhalte/Features der Schere zum Opfer gefallen, weil es für Valve offensichtlich wurde, dass sie innerhalb der gesetzen Timeline nicht umzusetzen waren oder beschlossen wurde, dass sie die Entwicklungszeit nicht wert waren. Wie zuvor gesagt, „Qualtität statt Quantität“. Spieler möchten lieber drei gute, spielerprobte Maps haben, anstelle von 10 ungetesteten. Zudem verleiht diese Vorgehensweise der Mod einen Namen, der für qualtitative Inhalte steht. Es sollte vermieden werden, die schlechtesten Arbeiten der Öffentlichkeit zu präsentieren.

Die Engine verstehen

Man sollte die Engine, mit der man arbeitet, verstehen. Die im SDK enthaltene Dokumentation sollte man wirklich lesen. Es geht nicht darum, ob die Engine dieses oder jenes Feature besitzt, sondern vielmehr wie man dieses Feature in der Engine so umsetzt, dass es gut funktioniert. Man kann zwar eine Waffe erstellen, die 50 Raketen abfeuern kann. Wenn man jedoch nicht versteht, wie die Engine arbeitet, könnte man es auf eine Weise implementieren, die den Network-Traffic unnötig in die Höhe treibt. Das Verstehen der Engine ist für alle Team-Mitglieder wichtig. Wenn die Map-Ersteller die Engine nicht verstehen, könnten sie große Maps bauen ohne darüber nachzudenken, wie viele Daten an die Spieler über das Netzwerk geschickt werden müssen. Jeder wird den Code dafür kritisieren, dass er zu viele Daten über das Netzwerk verschickt. Für Programmier könnte es eine gute Idee sein, der HL Coders mailing list for SDK beizutreten. Dort hat man die Möglichkeit sich mit vielen anderen Mod-Programmieren auszutauschen, eventuell sogar mit Valve-Mitarbeitern. Die Mailing-Liste hat ein großes Archiv, das jede Menge Lösungen zu häufigen Mod-Problemen enthält.

Bemerkungen

Obwohl dieser Artikel bereits aus dem Jahr 2000 stammt, sind viele seiner Ratschläge auch heute noch gültig. Auch Valve selbst hält sich an diese Tipps. Bei der Veröffentlichung von Team Fortress 2 gab es gerade mal eine Hand voll Maps, die dafür ausführlich getesten worden sind. Auch neuartige Ideen setzen sich schnell durch, wie z.B. Portale in Spielen. Die Entwickler von Narbacular Drop sind von Valve eingestellt worden und berieten Valve Software bei der Entwicklung von Portal. Der große Erfolg von Portal soll außerdem Einfluss auf Prey 2 haben. Die Benutzung von Portalen soll im zweiten Teil ausgebaut werden.

Quellen

Die Verwendung aller Dokumente einschließlich der Abbildungen ausschließlich zu nichtkommerziellen Zwecken. Verbreitung des Dokuments auf Speichermedien, (insbesondere auf CD-ROMs als Beilage zu Zeitschriften und Magazinen oder sog. "Mission-Packs" etc.) ist untersagt.
 
Angemeldet als: ()
allgemeines_gamedesign/artikel/mod_entwicklung_von_valve.txt · Zuletzt geändert: 2008/08/06 21:11 von jibe