Making-of Krautscape | Retro-Artikel

Rückblick: In der DP 04 : 2014 ließen wir im Rennspiel Krautscape von Entwickler Mario von Rickenbach und Michael Burgdorfer die Motoren röhren – mit dabei: prozedural generierte Rennstrecken. Ein Game-Projekt der Zürcher Hochschule der Künste.

Dieser Artikel von Maike Thies erschien ursprünglich in der DP 04 : 2014.

Rennspiele gibt es wahrlich viele: Aber in „Krautscape“ gewähren die Entwickler Mario von Rickenbach und Michael Burgdorfer den Spielern mehr Freiheit und Mitbestimmung beim Spielverlauf – dank prozedural generierter Strecken. Das Game-Projekt, das an der Zürcher Hochschule der Künste entstand, wurde auf Steam released.

Der besondere Clou bei „Krautscape“: Durch das Navigieren seines Renn- autos nimmt der Spieler Einfluss auf den Streckenverlauf. Dieser wird erst während des Rennens gebaut, und so entscheidet der jeweils führende Spieler, wo es künftig langgeht. Um dem Ganzen noch mehr Pfiff zu geben, wurden die einzelnen Rennautos mit Flügeln ausgestattet. Damit lassen sich ganze Streckenabschnitte mitsamt ihren Konkurrenten überspringen. „Krautscape“ ist als Multiplayer-Spiel konzipiert, das in drei Modi gespielt werden kann. Gilt es im „Snake“-Mode, möglichst viele Streckenteile zu bauen, um zu punkten, geht es im „Collector“-Mode darum, einen schwebenden Würfel zu erreichen, der eingesammelt und zum Streckenende gebracht werden muss. Im „Ping-Pong“-Mode wird die immer länger werdende Strecke in beiden Richtungen abwechselnd befahren. Für „Krautscape“ wählten die beiden Game Designer eine reduzierte visuelle Sprache, die Lowpoly-Geometrie mit knalligen Farben verbindet. Das Sound Design von Phil McCammon unterstreicht das Spielerlebnis mit einem fordernden Beat.

Grundidee und Konzept

Die Projektidee kam den Game Designern Mario und Michael 2009 im Rahmen eines Unterrichtsmoduls in der Studienvertiefung Game Design an der Zürcher Hochschule der Künste (ZHdK). Vorgegeben wurden die Parameter „Multiplayer“ und „netzwerkorientiertes Game Design“.

Unter der Leitung der Dozenten René Bauer und Max Moswitzer entstand ein erster funktionsfähiger Prototyp, gebaut in Unity. Dieser sah für die Navigation des Fahrzeugs folgende Anordnung vor: Das Fahrzeug fuhr auf einer kleinen Fläche, am Ende einer jeden wurde ein Trigger platziert, welcher im Prozess des Durchfahrens eine weitere Fläche generierte, die je nach Position und Geschwindigkeit des Fahrzeugs anders ausgerichtet wurde. Passierte das Auto beispielsweise die Fläche auf der linken Seite, so wurde dieses Element um die y-Achse (yaw) nach links rotiert, sodass eine Linkskurve entstand. Gleichzeitig war die lokale x-Rotation (pitch) des nächsten Elements abhängig von der Geschwindigkeit des Fahrzeugs, sodass es bei hoher Geschwindigkeit durch die Neigung nach oben abgebremst und umgekehrt wurde. Dieser erste funktionsfähige Prototyp wurde auf Basis eines Testfahrzeugs, das sich in vorangegangenen Physiktests bewährt hatte, in nur einem Nachmittag gebaut – und funktionierte auf Anhieb. Davor hatten die beiden Entwickler in Prototypen mit der Unity-Physikengine Fahrzeuge gebaut, um die Funktionen des in der Engine implementierten Wheel-Colliders zu testen.

Modeling in Blender

Das Fahrzeug wurde in Blender modelliert und animiert. Das Entwicklungsteam entschied sich für Blender, weil es ihrer Entwicklungsphilosophie entspricht: ein plattformunabhängiges, kompaktes Tool mit allen notwendigen Funktionen und problemlosem Export zu Unity, welches dazu noch gratis verfügbar ist. Zudem sind in Blender seit Version 2.5 inbesondere die Animationswerkzeuge sehr übersichtlich angelegt und gut designt. Besonders der einfache Wechsel zwischen Mac OSX und Windows war ein wichtiger Punkt, weil Mario, der für die meisten 3D-Modelle und das Fahrzeug zuständig war, zu Testzwecken regelmäßig von seinem Hauptcomputer, einem MacBook Pro, auf verschiedene Zweitcomputer mit Windows wechselte. Bei 3ds Max wäre das gar nicht möglich gewesen, bei Maya hätte es Lizenzproblemen geben können – bei Blender war es nur ein zehnsekündiger Download. Auch sonst war das ganze Projekt so angelegt, dass es mit einem Github-Zugang zum Game-Repository jederzeit innerhalb von 30 Minuten auf einem neu installierten System – egal ob Windows oder Mac – geöffnet werden kann, inklusive Download und Installation aller Software. Blender war für die beiden Entwickler zu Beginn des Projekts auch neu, aber es hat sich im Verlauf der Entwicklung und der Produktion der Modelle als sehr zuverlässig und flexibel erwiesen. Es gab weder Importprobleme noch größere Schwierigkeiten mit dem Programm selbst, abgesehen von einer kurzen Gewöhnungsphase zu Beginn. Mario wird wohl in den nächsten Projekten nicht zurück zu 3ds Max gehen, mit dem er vorher regelmäßig gearbeitet hat: „Die Zeiten von schwerfälligen, teuren 3D-Programmen, die nur auf einer Platform laufen, sind endgültig vorbei.“

Weiterentwicklung des Streckenbausystems

Wenngleich das entwickelte System zum Bau der Rennstrecke auf Anhieb funktionierte, resultierte aus dem Fehlen von echten Biegungen eine kantige Streckenoptik, die zudem durch die nicht vorhandenen Übergänge nur schwer zu fahren war. Die Lösung: auf einer kleinen Fläche, am Ende einer jeden wurde ein Trigger platziert, welcher im Prozess des Durchfahrens eine weitere Fläche generierte, die je nach Position und Geschwindigkeit des Fahrzeugs anders ausgerichtet wurde. Passierte das Auto beispielsweise die Fläche auf der linken Seite, so wurde dieses Element um die y-Achse (yaw) nach links rotiert, sodass eine Linkskurve entstand. Gleichzeitig war die lokale x-Rotation (pitch) des nächsten Elements abhängig von der Geschwindigkeit des Fahrzeugs, sodass es bei hoher Geschwindigkeit durch die Neigung nach oben abgebremst und umgekehrt wurde.

Dieser erste funktionsfähige Prototyp wurde auf Basis eines Testfahrzeugs, das sich in vorangegangenen Physiktests bewährt hatte, in nur einem Nachmittag gebaut – und funktionierte auf Anhieb. Davor hatten die beiden Entwickler in Prototypen mit der Unity-Physikengine Fahrzeuge gebaut, um die Funktionen des in der Engine implementierten Wheel-Colliders zu testen. Modeling in Blender Das Fahrzeug wurde in Blender modelliert und animiert. Das Entwicklungsteam entschied sich für Blender, weil es ihrer Entwicklungsphilosophie entspricht: ein plattformunabhängiges, kompaktes Tool mit allen notwendigen Funktionen und problemlosem Export zu Unity, welches dazu noch gratis verfügbar ist. Zudem sind in Blender seit Version 2.5 inbesondere die Animationswerkzeuge sehr übersichtlich angelegt und gut designt. Besonders der einfache Wechsel zwischen Mac OSX und Windows war ein wichtiger Punkt, weil Mario, der für die meisten 3D-Modelle und das Fahrzeug zuständig war, zu Testzwecken regelmäßig von seinem Hauptcomputer, einem MacBook Pro, auf verschiedene Zweitcomputer mit Windows wechselte. Bei 3ds Max wäre das gar nicht möglich gewesen, bei Maya hätte es Lizenzproblemen geben können – bei Blender war es nur ein zehnsekündiger Download. Auch sonst war das ganze Projekt so angelegt, dass es mit einem Github-Zugang zum Game-Repository jederzeit innerhalb von 30 Minuten auf einem neu installierten System – egal ob Windows oder Mac – geöffnet werden kann, inklusive Download und Installation aller Software. Blender war für die beiden Entwickler zu Beginn des Projekts auch neu, aber es hat sich im Verlauf der Entwicklung und der Produktion der Modelle als sehr zuverlässig und flexibel erwiesen. Es gab weder Importprobleme noch größere Schwierigkeiten mit dem Programm selbst, abgesehen von einer kurzen Gewöhnungsphase zu Beginn. Mario wird wohl in den nächsten Projekten nicht zurück zu 3ds Max gehen, mit dem er vorher regelmäßig gearbeitet hat: „Die Zeiten von schwerfälligen, teuren 3D-Programmen, die nur auf einer Platform laufen, sind endgültig vorbei.“ Weiterentwicklung des Streckenbausystems Wenngleich das entwickelte System zum Bau der Rennstrecke auf Anhieb funktionierte, resultierte aus dem Fehlen von echten Biegungen eine kantige Streckenoptik, die zudem durch die nicht vorhandenen Übergänge nur schwer zu fahren war. Die Lösung: gebogene Elemente, die an den Nahtstellen genau aufeinanderpassten. Mario und Michael generierten die Streckenelemente, indem sie Schnittformen/Shapes an einer Linie entlang extrudierten. Sie produzierten jeweils sowohl ein hochaufgelöstes Mesh, welches als Kollisionsobjekt fungierte, sowie ein niedriger aufgelöstes Objekt mit weniger Extrusionsschritten, das mit dem Level-of-DetailSystem von Unity in der Entfernung angezeigt werden konnte, um Leistung zu sparen.

Um den Spielspaß zu erhöhen, implementierten die beiden Game Designer die Möglichkeit, zwischen verschiedenen Shapes zu wechseln. Die Strecke verfügt so an gewissen Stellen über kleine Wände an der Außenseite, sodass mögliche Abstürze des Rennwagens verhindert werden können. Für dieÜbergänge werden manuell gestaltete Elemente eingesetzt, die den Wechsel von einer Form auf die nächste fahrbar machen.

Zudem setzten die Studenten auf spezielle Elemente und Hindernisse, welche durch die Verfolger aktiviert werden können, sodass der führende Spieler – ähnlich wie in „Mario Kart“ – ausgebremst wird. Die Hindernisse werden durch Schalter auf dem Boden aktiviert, welche regelmäßig auf der Strecke entstehen. Zu den Hindernissen zählen speziell geformte Elemente wie Loopings oder Schneisen als auch normale Streckenteile mit Attachments, wie etwa Wände.

Die beiden Game Designer implementierten außerdem automatisch generierte Stützen, die gelegentlich unten an die Streckenelemente gebaut werden, um der Spielumgebung mehr Struktur zu verleihen. Ziel war es aus Zeitgründen, im gesamten Produktionsprozess der Strecke mit möglichst wenig handgefertigtem Inhalt die gesamte Umgebung zu erstellen. Gleichermaßen konnten sie so auch den Umgang mit prozedural generierten Spielinhalten vertiefen. Besonders die manuelle Generierung der Strecken-Meshes per Code über die Unity Mesh-API entpuppte sich als sehr mächtiges Tool. Das Team konnte auf keine vorgefertigten Bibliotheken oder Engines zurückgreifen, weil die generierte Strecke sehr spezifische Bedingungen erfüllen muss, da sie große Auswirkungen auf das Gameplay und die Fahrphysik hat.

Networking & Server

Ein großes Thema technischer Natur stellte die Entwicklung eines netzwerkbasierten Spiels wie „Krautscape“ auf Serverebene dar: Wie werden die Spieler miteinander verbunden? Wie wird das Spielgeschehen synchronisiert? Was passiert, wenn Spieler online spielen möchten? Gibt es bereits vorhandene Server oder müssen die Spieler ihre eigenen starten? Da „Krautscape“ gänzlich auf den Multiplayer-Modus ausgerichtet ist, haben sich Mario und Michael dazu entschieden, das System so auszulegen, dass die Server vom Spiel gestellt werden. Ziel war es dabei, eine optimale Spielerfahrung und Performance zu gewährleisten und übliche Probleme mit Firewalls und Portfreigaben zu entschärfen.

Das Team stieß bei der Entwicklung der Netzwerkarchitektur schon früh auf Probleme: Unity unterstützt zwar netzwerkbasierte Projekte, doch die angebotenen Tools erweisen sich im Vergleich mit anderen Engines als rudimentär und beschränkt. So ist es zum Beispiel nicht möglich, auf einfache Weise mehrere Instanzen eines Spiels parallel zu starten und zu kontrollieren, was für die gleichzeitig stattfindenden Rennen jedoch notwendig ist.

Bei ihrer Recherche nach Alternativen wurden sie auf die Möglichkeit zum Netzwerkaufbau mit dem Photon-Framework aufmerksam. Dieses Serverangebot erwies sich zu Beginn als gut skalierbar und punktete mit seinem integrierten Lobbysystem, welches parallele Spielinstanzen ermöglicht. Die beiden Game Designer entschieden sich aber letztlich dennoch dagegen, da der Server vollständig unabhängig von Unity läuft. Sie hätten demzufolge die gesamte Physikberechnung der Strecke nochmals separat auf dem Server programmieren und synchronisieren müssen. Dies war für sie eindeutig mit einem zu hohen Zeit- und Mehraufwand verbunden, sodass sie sich schließlich für uLink & uLobby der Firma MuchDifferent entschieden. Die Server-Pattform bietet einen ausgezeichneten Mix aus guter Skalierbarkeit und praktischer Anwendung. Hinsichtlich ihres Netzwerkaufbaus sind sich das in Unity eingebaute System und uLink & uLobby sehr ähnlich. Dennoch überzeugen aber Erweiterungen wie der uLobby Server und der uZone Instance Manager sowie ein Login-System mit angehängter Datenbank.

Das Spiel konnte beim Umstieg auf die uLink-Library nahezu in der Struktur des bereits implementierten Unity Networking belassen werden. Mario und Michael standen aber bei dieser Variante die erweiterten Features des Frameworks zur Verfügung – ein großes Plus. Mit dieser Lösung konnte für jedes Rennen eine Instanz des eigentlichen Unity-basierten Spiels gestartet werden. Die Steuerung des Rennens erfolgte nun durch den uLobby Server in Zusammenarbeit mit dem uZone Instance Manager. Diese Variante funktionierte für die beiden Game Designer zufriedenstellend, obgleich das Framework nicht in allen Teilen gleichermaßen gut ausgereift ist.

Workflow Patcher

Mario und Michael wurden im Rahmen ihrer Spielentwicklung mit einem grundsätzlichen Workflow-Problem bei Multiplayer-Spielen mit Online-Servern konfrontiert. In der ersten Testphase von „Krautscape“ drängte sich schnell die Frage auf, wie sich neue Spielversionen einfach an Tester übermitteln lassen, um so sicherzustellen, dass alle immer die aktuellste Version spielen. Natürlich müssen auch die Server regelmäßig aktualisiert werden. Die beiden Game Designer testeten verschiedene Möglichkeiten: So produzierten sie beispielsweise in regelmä- ßigen Zeitabständen einen Build und stellten sicher, dass die Tester diese neueste Version umgehend herunterluden. Gleichzeitig musste in diesem Fall die richtige Version auf den Server geladen werden. Prinzipiell funktionierte diese Variante gut, doch sie nahm viel Zeit in Anspruch und war alles andere als flexibel.

Schließlich entwickelten Mario und Michael basierend auf dem M2H-Patcher aus dem Unity Asset Store einen erweiterten automatischen Patcher. Per Knopfdruck konnten sie von nun an einen neuen Build für alle Plattformen (PC/Mac/Linux) erstellen sowie Patches für alle Versionen generieren, diese entsprechend hochladen und die jeweilige Versionsnummer online aktualisieren. Mithilfe dieses Tools können also alle Tester nach einem Update einfach „Krautscape“ neu starten und finden automatisch die aktuellste Version vor. Das Gleiche gilt für den Server: Auch hier wird die Version stets auf den neuesten Stand gebracht, da sich diese ebenfalls beim Spielstart aktualisiert. Die Patches berücksichtigen alle Änderungen zur vorherigen Version, die das Programm „bsdiff“ beim Generieren des Patches für jedes File errechnet. Die Änderungen aller Files werden zusammen mit einer Liste sämtlicher Änderungen in einem Zip-File verpackt und als Patch zum Download freigegeben.

Bei jedem Spielstart wird online überprüft, welche der vorliegenden Versionen die aktuellste ist, entsprechend werden die passenden Patches gesucht, um so die neueste Online-Version spielen zu können. Mario fügte an, dass sich diese Scanning-Phase in Bezug auf kleinere Updates so schnell vollziehen würde, dass es der Spieler kaum bemerke.

Programmieraufwand

Trotz der offensichtlich gut ausgereiften Grundfunktionen des M2H-Patchers zeigten sich die beiden Game Designer nicht auf alDas Team setzte bewusst auf eine fiktive und exzentrische Umgebung, um „Krautscape“ von realitätsnahen Rennspielen abzuheben. Namensgebend für das Projekt ist ein gewisser Dr. Konrad von Krautkopf. Es muss um 1880 gewesen sein, Karl Benz würde noch einige Jahre brauchen, bis er sein erstes motorisiertes Automobil mit Verbrennungsmotor auf den Markt bringen würde, als dem wirren Kopf des Erfinders Dr. Konrad von Krautkopf eine zukunftsweisende Idee entsprang. Er imaginierte eine Maschine, die nicht nur mit hoher PS-Zahl auf der Straße fahren sollte, sondern zudem über kurze Distanzen zu fliegen vermochte. Krautkopf bezeichnete dieses Gefährt als „Krautomobil“ beziehungsweise „Krauto“. Zusätzlich sah er ein System vor, das die Fahrzeuge mit einem einfachen Kontrollmechanismus ausstatten sollte, welches den Fahrern ermöglicht hätte, beim Fahren Straßen zu bauen. Dr. von Krautkopf konzipierte sein System als eine effiziente und praktische Alternative zu bestehenden Fortbewegungsmöglichkeiten. Er spielte ebenfalls mit der Idee, für spezifische Anlässe, wie etwa Autorennen, außergewöhnliche Strecken mit dem System zu generieren. Glaubt man den Ausführungen auf der „Krautscape“-Website, so haben die beiden Game Designer Mario von Rickenbach und Michael Burgdorfer basierend auf den hochdetaillierten Originalplänen die nie realisierte Vision Krautkopfs im virtuellen Raum umgesetzt. Story zu „Krautscape“ Der erste Prototyp war noch sehr rudimentär, funktionierte aber schon erstaunlich gut. Abhängig davon, wo und mit welcher Geschwindigkeit das Fahrzeug durch den Trigger am Ende der Strecke fährt, hat das nachfolgende Element eine andere Ausrichtung. len Ebenen zufrieden. Sie vermissten einige für sie wichtige Features, die sie schließ- lich selbst entwickelten: Release-Kanäle, Patcher-Updates und diverse weitere Verbesserungen.

So war es mit der Grundversion nicht möglich, von verschiedenen Computern aus Builds zu releasen, und es gab nur einen ReleaseKanal. Im Rahmen des „Krautscape“-Projekts waren aber unterschiedliche Release-Typen mit verschiedenen Optionen geplant: So waren eine Betaversion für Tester, die interne Testversion für das Entwicklerteam als auch ein spezieller Master-Build für den uLobby-Masterserver angedacht. Alle diese Builds sind unterschiedlich konfiguriert, basieren aber auf dem gleichen Unity-Projekt.

Mario und Michael entwickelten auch eine Möglichkeit, um Updates des Patcher-Programms selbst durchführen zu können. Diese Patcher-Updates stellten sicher, dass die Patcher-Applikation selbst in regelmäßigen Abständen aktualisiert wurde, sodass die Flexibilität der Projektarbeit extrem erhöht werden konnte. Bugfixes sind in dieser Variante für das Patching-System möglich, was dazu führt, dass die Spieler in keinem Fall das Spiel noch einmal komplett herunterladen müssen. So war es möglich, in nur wenigen Minuten eine neue Version des Spiels zu veröffentlichen. Diese Lösung ist besonders bei kleinen Bugfixes und Online-Testsessions hilfreich.

Projektverlauf

Der erste Trailer zum Spiel konnte nach einer relativ kurzen Phase der Weiterenwicklung nach Ende des Studiums im Jahr 2010 fertiggestellt werden. 2011 reichten die beiden Game Designer ihr Projekt beim Call for Projects der Schweizer Kulturstiftung Pro Helvetia ein und konnten sich im Wettbewerb mit „Krautscape“ behaupten. Nur durch die Förderung war es den beiden möglich, das Projekt nach Abschluss des Studiums weiterzuführen. Im Rahmen der einjährigen Produktionszeit des Call for Projects programmierten sie große Teile des Games neu. Besonders beim Networking und beim Fahrverhalten gab es strukturelle Probleme, die einfacher zu lösen waren, indem diese Teile basierend auf den neuen Bedingungen neu programmiert wurden, anstatt sie mit inkrementellen Änderungen zu verbessern.

In dieser Phase des Spiels profitierten die beiden Game Designer von Projekt-Pitches und Gesprächen mit Experten auf Branchentreffen und Festivals. Sie vermochten es so, sich sukzessive dem marktfähigen Charakter des Spiels anzunähern. Ab Mitte 2012 wurden Mario und Michael mit „Krautscape“ zu Festivals und Ausstellungen eingeladen. „Krautscape“ war zum Beispiel in der Gaîte Lyrique (Paris) anlässlich der Ausstellung Play Along zu sehen und wurde darüber hinaus an der GDC Play (San Francisco) mit dem Best In Play Award ausgezeichnet. Als besonders gewinnbringend erwies sich eine Game-Präsentation auf der Tokyo Game Show. Dort setzt sich ein spielaffines Publikum mit den Spielen auseinander und gibt konstruktives Feedback.

Ende des Jahres 2012 verließ Michael aus beruflichen Gründen das Team und Mario setzte die Arbeit am Projekt alleine fort. Erst im Finalisierungsprozess des Spiels zog er im Sommer 2013 den Studienkollegen Flurin Jenal als Assistenz hinzu, um die baldige Fertigstellung des Games zu sichern. Ende Sommer 2013 ging „Krautscape“ auf Greenlight online und wurde von der Community akzeptiert. Durch diesen Schritt wurde der Publisher Midnight City (www.midnightcity.com) auf „Krautscape“ aufmerksam. Mittlerweile – Stand April 2014 – kann man auf Steam via Early Access spielen (store.steampowered.com/app/268360).

Zürcher Hochschule der Künste (ZHdK)

Die Zürcher Hochschule der Künste (www.zhdk.ch) bietet mit einem sechssemestrigen Bachelor-Studium und einem drei semestrigen Master-Studium in Game Design eine Ausbildung an, die das Computerspieldesign konzeptuell, gestalterisch, technologisch und in praktischer Anwendung thematisiert.

Die Vertiefung Game Design richtet ihren Fokus auf die Kultur und Gestaltung interaktiver Spiele. Innerhalb des Studiums werden grundlegende fachbezogene Kenntnisse im Rahmen von Spielentwicklungsprojekten erworben und durch das Studium von Analyse-, Planungs- und Umsetzungstechniken vertieft. Das Ziel aller Projekte ist generell die Entwicklung voll funktionsfähiger Spiele oder Spielprototypen. Das BA-Studium ist generalistisch angelegt. Durch das Angebot von Lernmodulen, die thematisch aufeinander aufbauen, werden die zentralen Komponenten des Game Designs abgedeckt.

Der Studiengang Bachelor of Arts in Game Design ist eine sechssemestrige Vollzeit-Ausbildung. Das Curriculum bietet Module und Kurse zu den folgenden Themenbereichen an: Game Culture, Storytelling, Game Mechanics, Programming, Usability Design, Game Conception, Game Analysis, Game Business, Media Management, Visual Techniques, Game Engine Programming, Game Design Projects, Character Design, 3D Modeling & Animation.

Das Masterprogramm Game Design ist ein Schwerpunkt innerhalb der Vertiefung Interaktion, das auf die Ausbildung vielseitiger und innovativer Experten in den Bereichen Interaction Design und Game Design spezialisiert ist. Der Master of Arts in Design bietet mit den Bereichen Collaborative Worlds, Game Production, Ludic Game Art und Serious Games vier Themenfelder, die in drei Semestern eine vertiefte praktische und wissenschaftliche Auseinandersetzung mit Bereichen des heutigen Game Designs garantieren

Kommentar schreiben

Please enter your comment!
Please enter your name here

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.