SaxonDragon über Prophesy of Pendor: „Modding hat mir beigebracht, ohne Autorität zu führen"

Nach zwei Artikeln wisst ihr bereits, was Prophesy of Pendor 2 ist und was es vorhat. Aber um zu verstehen, warum SaxonDragon die Person ist, die es bauen kann, müssen wir zurückgehen: zu dem Mod, der alles ins Rollen brachte, zu der kreativen Disziplin, die ihn geprägt hat, und zu den hart erkämpften Erkenntnissen darüber, wie man Menschen führt, die niemand bezahlt.

Diese dritte Folge behandelt den universellsten Teil des Interviews: wie ein großartiger Mod wirklich entsteht, was Modding und kommerzielle Entwicklung gemeinsam haben (mehr als man denkt) und die menschlichen Seiten der Spieleentwicklung, die in keinem Designdokument auftauchen. Egal ob ihr tausend Stunden in Pendor verbracht habt oder Mount & Blade noch nie angefasst habt – dieses Gespräch spricht jeden an, der jemals versucht hat, gemeinsam mit anderen etwas aufzubauen.

Die ehrliche Antwort lautet: Prophesy of Pendor hat so stark resoniert, weil ich dieselben Designprinzipien angewendet habe, die mein Denken seit jenen Sandbox-Kampagnen in den 1970ern geprägt hatten – diesmal aber mit einem zusätzlichen Werkzeug, das die meisten Spieledesigner damals nicht explizit nutzten: einem formalen psychologischen Rahmen, um zu verstehen, warum Menschen überhaupt Spiele spielen.

Ich hatte viel Zeit damit verbracht, McClellands Motivationsmodell – ursprünglich entwickelt, um menschliche Leistungs-, Zugehörigkeits- und Machtbedürfnisse zu erklären – entlang weiterer Achsen auszubauen, um die ganze Bandbreite der Bedürfnisse abzubilden, die Spiele ansprechen. Wenn man diese Bedürfnisse systematisch kartiert und ein Spiel dann gegen diese Karte hält, passiert etwas Klärendes: Die Lücken werden sichtbar. Die Stellen, an denen das Design Spielerbedürfnisse unerfüllt lässt, hören auf, vage Unzufriedenheitsgefühle zu sein, und werden zu konkreten, behebbaren Schwachstellen.

Als ich dieses Modell auf Mount & Blade und Warband anwandte, war das Bild eindeutig. Das Basisspiel hatte außergewöhnliche Grundlagen: das Kampfsystem, die offene Weltstruktur, die Reiterkämpfe. Aber die Präsentationsebene wies erhebliche Lücken auf. Das Lore war dünn. Die Welt erklärte sich nicht selbst. Das Gefühl von Konsequenz – einer lebendigen politischen und kulturellen Realität, die sich um den Spieler herum entfaltet – war unterentwickelt.

Die Spieler beschäftigten sich mit dem Skelett einer Welt, obwohl sie eine Welt mit Fleisch auf den Knochen verdient hätten. Prophesy of Pendor war im Kern der Versuch, dieses Fleisch zu liefern – die Lücken zu füllen, die das Motivations-Mapping sichtbar gemacht hatte.

Was die Umsetzung besonders herausfordernd machte – und ich möchte hier transparent sein – war das Umfeld, in dem der Mod entstand. Ich hatte kein Budget. Keine professionellen Ressourcen außer meiner eigenen Zeit. Ich lernte eine neue Programmiersprache im laufenden Betrieb. Und ich leitete ein Entwicklungsteam aus knapp zwei Dutzend Mitwirkenden, die ich nur als Nutzernamen in einem Forum kannte – Menschen, denen ich nie begegnet war, über Zeitzonen verteilt, einzig und allein durch die gemeinsame Begeisterung für das verbunden, was wir zusammen aufbauten. Eine solche verteilte, ehrenamtlich getriebene kreative Arbeit zu führen, ist eine eigene Disziplin – und eine, für die es keine Anleitung gibt.

Das Ergebnis war nicht das, was ich als perfekt bezeichnen würde. Ich kannte seine Grenzen besser als irgendjemand sonst, denn ich wusste, wonach das Design griff – und genau wo es zu kurz fiel. Aber Perfektion war nie das eigentliche Ziel. Das Ziel war zu beweisen – mir selbst genauso wie allen anderen –, dass die Fähigkeiten noch da waren. Dass ich nach Jahren außerhalb der Branche immer noch etwas bauen konnte, mit dem sich Spieler intensiv beschäftigen und zu dem sie immer wieder zurückkehren würden. Prophesy of Pendor hat diese Frage nachdrücklicher beantwortet, als ich zu hoffen gewagt hatte.

Was es außerdem tat: Es zeigte mir mit großer Klarheit, was die nächste Iteration sein musste. Prophesy of Pendor war der Machbarkeitsnachweis. Was als Nächstes kommt, ist der vollständige Ausdruck der Idee.

Das ist eine faszinierende Frage, und da ich ausgiebig auf beiden Seiten dieser Linie gearbeitet habe, kann ich eine Antwort geben, die viele überraschen dürfte: Der Unterschied ist weniger grundlegend, als die meisten annehmen. Es geht in erster Linie um Umfang und Maßstab, nicht um einen kategorialen Unterschied in der kreativen Philosophie.

Man denke daran, wie die meisten kommerziellen Spiele heute gebaut werden. Die überwältigende Mehrheit nutzt Middleware – Engines wie Unity oder Unreal –, und wer innerhalb dieser Engines baut, arbeitet per Definition im Haus eines anderen. Man bewegt sich in einem Rahmen, den man nicht entworfen hat, unterliegt Einschränkungen, die man nicht gesetzt hat, und ist abhängig von Systemen, über die man keine vollständige Kontrolle hat. Das Haus hat andere Möbel als das eines Mods und deutlich mehr Quadratmeter – aber die strukturelle Realität ist bemerkenswert ähnlich. Es gibt immer Wände, die man nicht verschieben kann.

Beim Modding ist die spezifische Einschränkung das, was Entwickler die Black Box nennen – die fest codierten Kernsysteme des Originalspiels, die schlicht nicht zugänglich für Modifikationen sind. Man arbeitet um sie herum, man arbeitet mit ihnen, man findet kreative Lösungen, die die eigenen Designziele innerhalb ihrer Grenzen erreichen – aber man kann sie nicht neu schreiben. Das erfordert eine besondere Art disziplinierter Kreativität: mit dem Strich eines Systems zu arbeiten statt dagegen, die Räume zu finden, in denen die eigene Vision und die Architektur der Engine produktiv koexistieren können.

Der tiefere Unterschied hat meiner Erfahrung nach weniger mit kreativer Freiheit zu tun als mit der Natur von Verbindlichkeit. Wenn man ein hauptberufliches professionelles Entwicklungsteam hat, besitzt man etwas enorm Wertvolles, das man leicht als selbstverständlich betrachtet: Verlässlichkeit. Die Arbeit ist dokumentiert. Die Prozesse sind etabliert. Jedes Teammitglied erscheint, erledigt seine zugewiesenen Aufgaben und ist zuverlässig. Die Maschine läuft gleichmäßig.

Ein Modding-Team funktioniert auf einem völlig anderen Fundament. Die Mitwirkenden sind bedingt dabei – sie sind da, weil sie das Projekt lieben, und in dem Moment, in dem das Leben konkurrierende Anforderungen an ihre Zeit stellt, wartet das Projekt. Das Fähigkeitsniveau variiert enorm. Die Verfügbarkeit schwankt ohne Vorwarnung. Die Dokumentation ist bestenfalls lückenhaft. Man leitet im Grunde eine Freiwilligenorganisation, die durch gemeinsame Begeisterung zusammengehalten wird – und gemeinsame Begeisterung ist, so real sie auch sein mag, ein zerbrechlicheres Bindemittel als ein Gehaltsscheck und ein Vertrag.

Aber hier wird das Bild nuancierter, denn Modding-Teams bringen etwas mit, das professionelle Teams nicht immer haben – und das wichtiger ist, als man gemeinhin anerkennt: Leidenschaft. Menschen schließen sich einem Modding-Team an, weil sie das Basisspiel lieben und an die Vision glauben, die man gemeinsam verwirklicht. Diese Leidenschaft ist selbstselektierend und selbsttragend.

Niemand bewirbt sich darum, einen Mod für ein Spiel zu machen, das ihm gleichgültig ist.

Was Modding mich letztlich gelehrt hat, war, ohne Autorität zu führen – wie man beständige Beiträge von Menschen inspiriert, die man nie getroffen hat, mit nichts als der Qualität der Vision und der Kultur der Community als Werkzeuge. Das ist eine Fähigkeit, die sich direkt in jedes Entwicklungsumfeld überträgt, ob kommerziell oder nicht – und ich würde es gegen nichts eintauschen wollen, dass ich sie auf diesem Weg gelernt habe.

Das ist eine Frage mit vielen ehrlichen Antworten, und ich möchte der Versuchung widerstehen, euch nur eine zu geben – denn die größten Herausforderungen in der Spieleentwicklung, ob beim Modding oder kommerziell, kreisen um einen gemeinsamen Kern, über den in Designkreisen viel zu wenig gesprochen wird. Wir reden sehr viel über Technologie, Systeme und Pipelines. Wir reden viel zu wenig über die menschlichen Dimensionen des Spielemachens – und dort werden meiner Erfahrung nach die eigentlichen Kämpfe ausgetragen.

Führung ist das Fundament, auf dem alles andere ruht. Nicht die Art von Führung, die Autorität behauptet oder Visionen von oben herab durchsetzt, sondern die Art, die die Bedingungen schafft, unter denen gute Arbeit entstehen kann.

Das erfordert vor allem die Fähigkeit zum Zuhören – und zwar im umfassendsten Sinne des Wortes. Sich selbst zuhören, damit Instinkte und Designprinzipien während eines Entwicklungszyklus, der sein Bestes tut, sie auseinanderzureißen, aufeinander abgestimmt bleiben. Dem Team zuhören, denn die Menschen, die der Arbeit am nächsten sind, sehen Dinge, die der Design-Lead aus der Distanz nicht sehen kann. Den Spielern zuhören, denn sie werden einem klar, beharrlich und manchmal unhöflich sagen, genau wo Vision und Erlebnis auseinandergefallen sind. Und allen anderen zuhören – den Kritikern, den Skeptikern, den Stimmen, um die man nicht gebeten hat –, denn das sind oft genau die, die die Informationen tragen, die man am dringendsten hören muss.

Die vielleicht am meisten unterschätzte Herausforderung ist es, eine konsistente Vision über einen Entwicklungszyklus aufrechtzuerhalten, der sich über Jahre erstrecken kann. Scope Creep ist real. Teamfluktuation ist real. Die Versuchung, Trends hinterherzujagen, auf jedes Spielerfeedback mit einer Designänderung zu reagieren, die Vision an den Rändern verschwimmen zu lassen, während Zeit und Druck sich ansammeln – all das ist real.

Die Linie zu halten, was das Spiel im Kern ist, während man gleichzeitig wirklich offen dafür bleibt, wie es besser gemacht werden kann – das ist eine Balance, die ständige, bewusste Aufmerksamkeit erfordert.

Und dann ist da das Ego. Es an der Tür zu lassen ist keine einmalige Entscheidung – es ist eine tägliche Praxis. In dem Moment, in dem man mehr daran interessiert ist, recht zu haben als etwas Großartiges zu schaffen, hat man den Faden verloren.

Die Realität anzuerkennen, dass man nicht alles weiß – dass Teammitglieder Lösungen sehen werden, die man selbst nicht bedacht hat, und Probleme identifizieren werden, die man nicht bemerkt hat – ist kein Eingeständnis von Schwäche. Es ist die strategisch klügste Position, die ein Design-Lead einnehmen kann.

Die Machtdistanz zwischen sich selbst und dem Team zu verringern – ein Umfeld zu schaffen, in dem Feedback in alle Richtungen frei fließt und niemand Angst hat zu sagen, dass etwas nicht funktioniert – führt konsequent zu besseren Ergebnissen als jede Menge individueller Brillanz, die isoliert angewendet wird.

Bei der kommerziellen Entwicklung verschieben sich die Herausforderungen in ihrer Gewichtung, wenn auch nicht in ihrer Art. Sich verändernde Technologie ist ein konstanter Druck. Effektiv mit dem Auftraggeber zu kommunizieren – den Menschen, die die Entwicklung finanzieren und deren Vertrauen man hält – ist eine eigene Disziplin. Sie müssen verstehen, was sie bekommen, wann sie es bekommen und welche Risiken zwischen hier und dort bestehen. Das erfordert ein Maß an Transparenz, das sich unangenehm anfühlen kann, denn die ehrliche Antwort auf viele Entwicklungsfragen lautet: Das wissen wir noch nicht.

Und schließlich: Meilensteine. Erreichbare, realistische Meilensteine, die Raum für das Unvorhergesehene einplanen – denn in der Spieleentwicklung ist das Unvorhergesehene nicht die Ausnahme, sondern die Regel. Jeder Entwicklungszeitplan, den ich je gesehen habe, wurde vom Unerwarteten auf den Boden der Tatsachen geholt. Der Unterschied zwischen Teams, die solche Momente überstehen, und Teams, die es nicht tun, hängt von einer einzigen Sache ab: ob sie Raum für die Realität in ihre Pläne eingebaut haben. Puffer ist kein Pessimismus. Er ist das Narbengewebe der Erfahrung.