DevBlog: Wie wir ein Anno designen

Hey Anno Community,

in den letzten Wochen haben wir über Features und Designs gesprochen – und werden dies auch bald wieder tun! Aber lasst uns mal in der Hinsicht eine kurze Pause einlegen – und stattdessen über den Designprozess von Spielmechaniken sprechen: Lasst uns über Game Design sprechen!

In unserem Blogbeitrag vom letzten Jahr haben wir über die Ursprünge von Anno 117: Pax Romana berichtet und darüber, wie wir die kreative Vision und die grobe Basis für ein neues Anno–Spiel entwickeln. Wir empfehlen euch dringend, diesen Beitrag zu lesen, bevor ihr mit diesem Blog weitermacht.

Heute verlassen wir – erneut mit unserem Game Director Jan Dungel – die Anfangsphase der Vision und tauchen in die tägliche Arbeit des Game-Design-Teams ein. Ein Schwerpunkt liegt dabei auf der Erstellung von Design-Dokumenten – und wir haben dafür auch ein Beispiel aus unserem aktuellen Projekt.

Was ist eigentlich Game Design?

Wir haben Aspekte dieser Frage bereits in Teil eins behandelt, als wir die Aufgaben von Manuel (Creative Director) und Jan (Game Director) vorgestellt haben – aber wir haben noch viele weitere Experten in unserem Team.

Das Game-Design-Team erstellt die Spielregeln – und übersetzt die gewünschte Erfahrung, die der Spieler haben soll (z. B. das Gefühl von Frieren/Kälte/Verzweiflung in Frostpunk oder das Gefühl von Wachstum/Fortschritt/Erkundung in Anno 1800). Es übersetzt die Spielerfahrung in verständliche Dokumente („Träume werden Wirklichkeit“) – aber es baut das Spiel nicht. Das übernehmen andere Abteilungen auf der Grundlage der Entwürfe.

Das “Religion”-Feature wird von Game Designer Markus als Feature Koordinator geleitet. Gameplay Programmierer Jannik koordiniert hingegen das Multiplayer–Feature.

Natürlich besteht das Team aus verschiedenen Spezialisten und Spezialistenteams, genauso wie man beispielsweise in der Architektur (einem Bereich, in dem Jan zuvor gearbeitet hat) zwischen mehreren Teilbereichen unterscheidet: Architekten für den Garten, Innenräume, Städte usw.

Im Bereich Design haben wir sowohl System-Designer für die Wirtschaft und generelle Balance („Excel-Fans“) als auch Feature-Designer, die bestimmte Features entwickeln (in der Regel ebenfalls unter intensiver Nutzung von Excel). Je nach Spielgenre gibt es unterschiedliche Arten von Spezialisten oder sogar Spezialistenteams: Ein Hack-&-Slash-Spiel hat beispielsweise eigene Kampfdesigner, da der Kampf in diesem Spieltyp eine so große Rolle spielt.

Dann gibt es noch Narrative Designer und Writer, die Inhalte (Story, Kampagne, …) erstellen und Features unterstützen (z. B. Bewohnertypen). Wir haben auch einen speziellen UX/UI-Designer im Game Design Team, der eine starke abteilungsübergreifende Verbindung zum UX/UI-Team herstellt.

Und dann gibt es noch Themen wie Multiplayer, Retention, Menüstrukturen, Postlaunch usw., für die ebenfalls jeweils ein Spezialist zuständig ist.

Generell versuchen wir, Spezialisten den Features zuzuweisen, die sie am besten beherrschen und am liebsten machen.

High Concepts

Es ist an der Zeit, über den Designprozess zu sprechen, insbesondere über die Designdokumentation. Zunächst kommt das „High Concept“ (auf deutsch etwa grundlegendes Konzept).

Jedes einzelne Feature im Spiel erhält ein eigenes Designdokument in unserem internen „Wiki“. Das bedeutet, dass alles, von neuen Features wie „Romanisierung“ bis hin zu Handelsrouten, Wohnhäusern, dem Platzieren/Zerstören von Gebäuden sowie Baugebieten usw., eine eigene Seite erhält.

Das High Concept ist der erste Schritt auf dem Weg vom „Traum zur Realität“ und im Grunde genommen ein leicht verständliches Dokument mit nur wenigen einfachen Aussagen, die einen Überblick über das Feature geben. Das High Concept soll auch die Frage nach dem „Warum“ beantworten (siehe das Thema Ziele aus dem ersten Blog) und Verknüpfungen zu anderen, verwandten Features herstellen.

Werfen wir einen Blick auf die High Concept-Seite für den Blaupausen-Modus:

Wie ihr sehen könnt, ist so ein High Ceoncept recht knapp gefasst und daher auch nützlich, um Personen außerhalb des Entwicklerteams einen schnellen Überblick zu verschaffen. Oben werden normalerweise die Mitglieder des Feature-Teams (hier entfernt) und der Feature-Koordinator aufgeführt (mehr zu Feature-Teams findet in unserem DevBlog zum Produktionsteam).

Jedes Designdokument muss zunächst von den Design Leads genehmigt werden, bevor die Designer an den DDDs (Detailed Design Documents = Detaillierte Design Dokumente) arbeiten können, und ein DDD muss genehmigt werden, bevor mit der Arbeit am Feature begonnen werden kann. Dieser Status wird ebenfalls oben aufgeführt.

Der Genehmigungsprozess stellt sicher, dass die Features mit der Gesamtvision, aber auch mit dem Umfang und den Zielen des Projekts übereinstimmen. Dieser Prozess bietet Designern jedoch auch die Möglichkeit, z. B. Jan von einem Feature oder einer Herangehensweise an ein Feature zu überzeugen.

Feature-Ansatz

Beim Betrachten des Screenshots ist euch vielleicht auch die Spalte „Feature Approach” (Feature-Ansatz) aufgefallen.

Für Anno 117: Pax Romana (und bereits damals für Anno 1800) unterteilen wir unsere Features in drei Kategorien: Tradition, Iteration und Innovation.

Schließlich haben wir eine Serie mit langer Tradition und etablierten Features, was bedeutet, dass wir jedes Feature sowohl mit der DNA der Serie als auch mit der Vision für das nächste Spiel abgleichen müssen. Die drei Kategorien sind wie folgt definiert:

• Tradition: Macht den größten Teil aller Features des Spiels aus. Features in dieser Kategorie funktionieren weitgehend wie in Anno 1800 (oder älteren Anno–Spielen) und erhalten nur sehr geringfügige Änderungen (z. B. der Transport von Gütern oder der oben erwähnte Blaupausen-Modus).
• Iteration: Bestehende Features/Mechaniken, die größere Änderungen erhalten (z. B. Arbeitskraft oder Wohnhäuser).
• Innovation: Hierbei handelt es sich entweder um völlig neue Features oder um bestehende Features, die sehr starke Änderungen erfahren (z. B. Romanisierung).

Die Idee hinter diesem System ist es, sicherzustellen, dass wir ein Anno-Spiel entwickeln, das alle Features enthält, die unsere Fans von einem Anno-Spiel erwarten, aber auch, dass wir nicht stagnieren und die Formel weiter verbessern.

Detaillierte Design-Dokumente (DDDs)

Okay, unser High Concept für den Blaupausen–Modus wurde genehmigt – Zeit für das DDD!

Das detaillierte Design-Dokument ist die nächste Stufe im Designprozess für ein Feature: Es ist in mehrere Regeln mit detaillierten Beschreibungen für jede einzelne unterteilt. Schauen wir uns das DDD für den Bluaupausen-Modus an, bevor wir fortfahren:

Diese Regeln sind wichtig für den nächsten Schritt: das Erstellen der eigentlichen Spielinhalte. Dazu gehört beispielsweise die Abteilung Gameplay Programming, die dafür sorgt, dass diese Regeln im Spiel selbst umgesetzt werden.

Wie das „High Concept” hat auch das DDD einen Genehmigungsstatus. Erst dann gehen wir zur nächsten Phase über: dem Kick-off-Meeting mit den Feature-Teams (d. h. mit anderen Abteilungen). Kick–off–Meetings dienen der Besprechung des Features und seiner Umsetzung und dienen daher auch als Realitätscheck für das Feature und den voraussichtlichen Aufwand für alle Teams. Darüber hinaus können Fragen und Bedenken zu weiteren Iterationen des Designs führen.

Auch wenn die meisten Features nach der Genehmigung und Besprechung des DDD keine großen Änderungen erfahren, kommt es gelegentlich vor, dass wir nach Beginn der Entwicklung: „Oh, das macht doch nicht so viel Spaß wie erwartet.“

Wir haben bereits erwähnt, dass jedes einzelne Feature eine eigene Seite in unserem “Wiki”erhält, und ihr könnt euch vorstellen, dass sich das im Laufe der Zeit zu einer RIESIGEN Menge summiert (etwa 200 Feature-Seiten mit jeweils Dutzenden von Aspekten). Diese Dokumente werden nicht unbedingt kontinuierlich aktualisiert, und in Fällen wie dem oben genannten arbeiten wir mit einem speziellen „Change Request”-Workflow (Arbeitsprozess für Änderungs-Vorschläge) mittels JIRA, um alle Änderungen an den Designs zu dokumentieren.

Um Jan zu zitieren: Man sollte immer bedenken, dass „die Entwicklung von Spielen nicht perfekt sein kann”.

Und so sieht der Blaupausen-Modus schließlich in Anno 117: Pax Romana aus.

Prototypen

Natürlich können nicht alle Design-Dokumente gleichzeitig fertiggestellt werden. Daher befinden sich verschiedene Features in unterschiedlichen Implementierungsphasen, während das Game Design Team für andere mit den DDDs fortfährt. Die Reihenfolge und die Fortschrittsziele (wir nennen sie „Qualitätsstufen“) für jedes Feature werden im Voraus vom Produktionsteam zusammen mit der Kerngruppe geplant.

Das ist ein Thema, das wir im oben erwähnten DevBlog zur Arbeit des Produktionsteams behandelt haben.

Neben der Erstellung dieser Entwürfe überwacht das Team auch die Umsetzung der Entwürfe und Regeln, nimmt weitere Anpassungen vor und kümmert sich beispielsweise um Themen wie die Spielbalance.

Einige Features erhalten zunächst einen Prototyp, bevor mit der „richtigen” Entwicklung begonnen wird. Dies ist großen, wichtigen Features vorbehalten, die entweder schwierig erscheinen oder sehr neu sind. Die diagonalen Straßen waren beispielsweise ein solcher Fall, wie in den DevBlogs erwähnt, die wir dazu veröffentlicht haben. Die Prototyping-Phase ist in der Regel sehr arbeitsintensiv (man möchte schnell einen funktionierenden Prototyp, führt aber auch regelmäßige Iterationen durch, die manchmal mehr, manchmal weniger radikal sind), aber auch äußerst nützlich – und hat eine Erfolgschance von etwa 80 %.

Diese Phase dauert so lange, bis man entweder scheitert – oder das Gefühl hat, dass alles sicher ist und man etwas hat, das ein ordentliches Designdokument und letztendlich eine Implementierung im eigentlichen Projekt erhalten kann. Das Schwierige dabei ist, herauszufinden, ob es einfach nicht funktioniert … oder ob es einfach NOCH nicht funktioniert.

Wie in anderen Blogs möchten wir auch hier einen allgemeinen Hinweis hinzufügen: Alle Prozesse, die Struktur des Teams usw. sind zu 100 % spezifisch für Anno. Andere Teams und Entwickler haben wahrscheinlich andere Ansätze, die für sie und ihr Projekt am besten funktionieren – für uns hat sich dieser Ansatz als effizient und effektiv erwiesen.

Neben diagonalen Straßen haben wir zunächst auch mit Prototypen für Landeinheiten gearbeitet. Wir mussten ausprobieren, wie dieses Feature in unserem Spiel am besten umgesetzt werden kann.

Als Game Designer arbeiten

Eine letzte Frage wollten wir Jan noch stellen: Wie werde ich Game Designer, wenn ich mich für diesen Bereich interessiere?

Ein Wechsel aus einer anderen Abteilung ist ein gängiger Weg, beispielsweise aus der QA, wie es einige in unserem Team getan haben. Heutzutage gibt es jedoch auch spezielle Kurse an Schulen/Universitäten, in denen man die Grundlagen und die gesammelten Erkenntnisse aus mittlerweile mehreren Jahrzehnten der Videospielentwicklung vermittelt bekommt.

Außerdem ist es von Vorteil, ein Portfolio zu haben: Sei es, dass ihr Mods für Spiele erstellt oder euer eigenes Brett- oder Kartenspiel entworfen habt. Dabei lernt ihr auch viel darüber, was es bedeutet, Designer zu sein: Es geht nicht nur darum, Ideen zu entwickeln, sondern diese in Form von Regeln und Features in ein Spiel umzusetzen – und die Ideen eurem Publikum zu „verkaufen”.