Es scheint wie das Einfachste der Welt – ein Charakter in einem Plattformer wie Super Mario oder Celeste kann springen. Doch was nach einer einfachen Spielmechanik aussieht, ist meistens mit viel Kleinstarbeit und Feintuning verbunden. Das ­Problem ist, dass die Spielenden eine sehr genaue Anforderung an einen guten Sprung haben, ohne aber selbst zu wissen, wie der auszusehen hat. „Es muss sich gut anfühlen“, ist die Aussage, aber wie übersetzt man gutes Gefühl in Spielcode? Die einfachste Methode, in den meisten modernen Spiele-Engines einen Sprung einzubauen, ist, sich der physikalischen Berechnungen zu bedienen, die die Engine eh schon anstellt.

Man addiert auf die Spielfigur eine Kraft, die sie nach oben katapultiert und die Gravitation der Spielwelt lässt sie – ganz nach Newton – wieder zurück auf den Boden fallen. Das Problem ist, dass sich das meist sehr schlecht „anfühlt“. Die Bewegung der Figur wird als „schwebend“ bezeichnet, als „befände man sich auf dem Mond“. Und wenn man bei einem physikalischen Realismus bleibt, dürfte man die Spielfigur im Flug auch nicht mehr wirklich steuern können. Das nimmt aber den Spielenden ein großes Maß an Kontrolle und das Spiel frustriert schnell.

Die Lösung dafür ist, sich nicht auf realistische Berechnungen zu verlassen, die vorgegebenen Systeme der Engine über den Haufen zu werfen und seinen Sprung komplett selbst zu implementieren – inklusive Kontrolle über alle möglichen Parameter. Es gibt kein ultimativ bestes Rezept für einen perfekten Sprung, aber auf ein paar Grundregeln scheinen sich die meisten Entwickler:innen und Spieler:innen geeinigt zu haben.

Dieser Artikel ist zuerst im t3n Magazin Nr. 74 erschienen, das sich im Schwerpunkt mit der Frage beschäftigt, wie nutzerfreundlich unsere Städte sind. Mehr zum Thema und dem Heft erfährst du hier.

Es hat sich etabliert, dass der Absprung direkt nach einem Knopfdruck erfolgt, ohne größere Verzögerung und ohne großartige Animation. Das gibt den Spielerinnen und Spielern ein großes Gefühl von Kontrolle durch das sofortige Feedback. Dann sollte der Aufstieg des Sprungs im Vergleich zum Fall recht langsam sein, der Fall dafür umso schneller. Das wirkt dem „Schweben“ der Spielfigur entgegen und macht viel vom Spielgefühl aus. Schon die ersten Super-Mario-Games haben dieses Konzept etabliert. Sehr wichtig sind auch kleine Partikel, die bei Absprung und Landen der Spielfigur in der Spielwelt auftauchen. Dadurch bekommt die Spielfigur ein Gewicht und der Sprung fühlt sich nicht so willkürlich an.

Was viele nicht bemerken: In den meisten 3D-Plattformern wird ein Schatten direkt unter den Charakter in der 3D-Welt platziert. Der hat nichts mit der Richtung der Sonne in der Spielwelt zu tun und ist komplett unrealistisch – ist aber dafür da, dass die Spielenden die Position des Charakters im Sprung verorten können. Denn die Dreidimensionalität der Spielwelt geht auf den 2D-Bildschirmen, auf denen sie betrachtet werden, sehr schnell verloren. Und ohne diesen „Blob-Shadow“ verpassen eine Vielzahl an Spielenden den Sprung auf eine Plattform – ohne zu wissen, woran das liegt. Überhaupt, Plattformen: Wie wenige wissen wohl, wie schwierig es ist, einen Charakter zu programmieren, der sich auf einer bewegenden Plattform richtig bewegt und nicht runterrutscht oder weggeschleudert wird? Das Thema ist schier unendlich.

Mein persönlicher Favorit unter kleinen ­Nervereien wird von den Spielern selten bemerkt, weil er oft schon vor dem Release repariert wird: die korrekte Setzung von Pivots bei Assets. Pivots sind quasi „Nullpunkte“ bei Grafikassets, beispielsweise kleine Objekte, und werden von der Gaming-­Engine als Mittelpunkt identifiziert.

Wenn also zum Beispiel wie in The Elder Scrolls: Skyrim im Inventar ein Objekt rotiert werden kann, wird der Pivot als Basis genommen. Sitzt er falsch, sitzt die Rotation nicht mittig und das Objekt schlingert oder rotiert um eine unsichtbare Achse außerhalb des Objektes. Das kann auch dazu führen, dass Objekte im Level dann falsch platziert sind. Oft entstehen solche Probleme, weil Mitarbeiter (und ­Schüler) aus früheren Jobs andere Workflows haben. So gibt es zwei Standards: Der Pivot sitzt in der Mitte des Objektes oder bei der 0,0,0-Koordinate im Object-File im Programm, also außerhalb des Assets.

Das wird gerne aus schneller Gewohnheit übersehen. ­Wichtig sind hier also Abnahmeprozesse, die genau das überprüfen, was aber gerade vor einem wichtigen Milestone aus Zeitgründen gerne mal weggelassen wird. Deshalb müssen die Artists und die Programmierer sich zu Beginn einer Produktion verpflichtend auf eine Pivot-­Position einigen und so ihre Workflows synchronisieren und genauer darauf achten.

Beim Inventartext geht es in der Regel um eine Infobox, in der alle wichtigen Informationen an den Spieler weitergegeben werden sollen. Dabei soll dem Spieler vermittelt werden, um was für einen Gegenstand es sich handelt und welche Attribute er mit sich bringt. Das ist enorm wichtig, da es hilft, seine Bedeutung, Anwendung und Relevanz richtig einzuordnen. Im schlimmsten Fall ist der Spieler sonst überfordert und empfindet die Gegenstände als wertlos.

Alle relevanten Informationen müssen so präsentiert sein, dass sie leicht durchdringbar und vergleichbar sind. Um das zu erreichen, gibt es neben der händisch eingetragenen Gegenstands­beschreibung als Fließtext oft noch ein Datenblatt mit relevanten Eckdaten. Beim Fließtext sollte man möglichst vermeiden, Eckdaten zu beschreiben, die sich im Laufe der Spieleentwicklung oder durch Updates noch verändern könnten. Das Datenblatt sollte die Eckdaten der aktuellen Spielversion automatisch darstellen können, ohne dass jemand nach jeder Änderung noch ­händisch rangehen muss.

In der Theorie hört sich das alles recht einfach an, jedoch können sich die Gegenstände im Spiel sehr unterscheiden, wodurch die Schnittmengen der relevanten und vergleichbaren Eckdaten teilweise zu klein und unterschiedlich sind. Ein Kleidungsstück hat etwa wenig mit einem Powerup gemein. Um dieses Problem zu umgehen, werden Gegenstände möglichst sinnvoll kategorisiert und die wichtigsten gemeinsamen Eckpunkte erarbeitet, die angezeigt werden sollen.

Ein weiteres Problem ist, dass die relevanten Daten manchmal zu komplex oder zu abstrakt sind, um sie in leicht verdauliche Eckdaten umzuformulieren. Einige Daten können zum ­Beispiel durch die Übersetzung in Power-Leisten vereinfacht und abstrahiert werden. Statt Zahlen sehen die Spieler dann etwa die bekannte Gesundheitsanzeige.

Doch die Umformulierung von komplexeren Daten mit vielen Sonderfällen lässt sich oft nur schwer automatisieren und zu solchen grafischen Darstellungen umwandeln. Oft muss dann ein Kompromiss zwischen händischen und automatisierten Einträgen gefunden werden, da der Arbeitsaufwand, um ein voll auto­matisiertes System zu implementieren, möglicherweise den Arbeits­aufwand des händischen Eintrags deutlich übersteigt.

Das größte Problem: Zum einen ist es ratsam, sich den Problemen der Inventartexte so frühzeitig wie möglich zu stellen, zum anderen ist es aber besonders schwer, alle Anforderungen und benötigte Funktionen von einem Spiel, das noch in Entwicklung ist, zu erkennen. Im Nachhinein, wenn alle Spielsysteme stehen, wirkt alles diesbezüglich immer sehr trivial und es ist schwer nachvollziehbar, wie viel Überlegung und Arbeit in so was ­hineingeflossen ist.

Als Spieleentwickler bin ich stets auf das Game-Design-­Document und eine akribische Zeitplanung angewiesen. Ohne diese Planung ist es eigentlich kaum möglich, am Ende ein fertiges Spiel zu haben. Sie bietet nicht nur eine klare Struktur für das Projekt, sondern beeinflusst auch direkt die Finan­zen und die Realisierbarkeit von Ideen.

Doch auch bei bester Vorbereitung kann es immer wieder unvorhergesehene Wendungen geben. Das präzise Einschätzen spezifischer Features erweist sich für viele Entwicklerinnen und Entwickler als echte Herausforderung. Was anfänglich als ein bis zwei Stunden Arbeit kalkuliert wird, kann sich unerwartet zu einem ein bis zwei Tage andauernden Prozess entwickeln. Dabei können unvorhergesehene Bugs in der Engine oder im eigenen Code auftreten.

Nervig kann auch das „Polishing“ eines nahezu fertigen Projekts sein. In dieser Phase, in der es um Bugfixing, Lokalisierung und Feinabstimmung geht, spürt man oft das Verlangen, schon das nächste Projekt anzugehen und der Kreativität freien Lauf zu lassen, anstatt sich um einen Text zu kümmern, der nicht in allen Sprachen in die vorgesehene Box passt.

Das ständige Ringen mit dem Budget raubt uns allerdings die meisten Nerven. Das Budget legt oft fest, wie viel Zeit man in die Optimierung einer Spielmechanik stecken kann. Selbst wenn man erkennt, dass eine Mechanik Verbesserungen benötigt und man am liebsten noch mehrere Monate daran arbeiten würde, kann ein schmaler Geldbeutel bedeuten, dass man Kompromisse eingehen muss. Es ist dieses ständige Abwägen zwischen Vision und praktischen Gegebenheiten, das den Alltag in der Spieleentwicklung so herausfordernd macht.

„Schnell mal was anpassen“

Am längsten dauert es bei mir meistens, bestehende Dinge im Nachhinein noch mal anzupassen. Beispielsweise ein 3D-Modell, eine Animation oder einen Blueprint. Besonders, wenn man das Asset schon eine Weile nicht mehr angefasst hat, muss man sich da zum einen erst wieder in der Arbeitsdatei zurechtfinden. Da lohnt es sich auf jeden Fall, gleich beim ersten Mal die Objekte in der Szene richtig zu benennen und in entsprechende Ordner zu packen.

Zum anderen zieht es einen längeren Rattenschwanz hinter sich her, weil man auch damit verbundene Dinge noch mal angleichen muss. Bei einem 3D-Modell muss man das Ganze beispielsweise unter Umständen erneut exportieren und in der Texturierungssoftware reimportieren, die Texturen neu backen und alles dann noch mal in der Gaming-Engine neu hochladen. Außerdem kann es passieren, dass dadurch etwas, das vorher noch gut funktioniert hat, kaputt geht und noch mal debuggt werden muss.

Dadurch läuft es manchmal darauf hinaus, dass man Dinge drei Mal macht. Das frisst natürlich viel Zeit. Was dabei helfen kann, sind Workflows, bei denen man zusätzliche Software außen vor lassen kann. Zum Beispiel mit sogenannten Trimsheets oder Vertex Colors. Die werden verwendet, um einem Objekt mit ansonsten einfacher Geometrie schnell Details hinzuzufügen. Da kann man sich ein paar Schritte sparen.

Es ist richtig nervig, wenn das sorgfältig ausgetüftelte User-Interface deines Spiels plötzlich zerschossen ist, sobald du andere Sprachen einfügst. Das trifft ganz besonders zu, wenn es sich um eine Sprache bestehend aus einem anderen Zeichensatz, wie etwa Chinesisch, handelt. Dazu ist dann meist die Wahl eines anderen Fonts nötig und die sorgsam platzierten und aufeinander abgestimmten Textfenster sehen plötzlich gar nicht mehr so gut aus. Zudem unterscheiden sich manche Übersetzungen massiv in der Textlänge voneinander, was auch schon mit so manchem Textfeld kollidiert ist.

Der beste Lösungsansatz dafür ist es sicherlich, schon bei der Planung des UI an andere Sprachen und variable Textlängen zu denken. Dabei können zum Beispiel Textfelder nützlich sein, in denen die Zeichen skalieren, um zu verhindern, dass der Inhalt übersteht oder abgeschnitten und somit nicht mehr zu lesen ist. Außerdem hilft es schon bei der visuellen Gestaltung des UI, auch mal mit anderen Sprachen und Fonts herumzuspielen, um sicherzustellen, dass es auch dann stimmig und passend aussieht. Das fällt erfahrungsgemäß bei stärker erklärungsbedürftigen Spielen schwerer, als wenn eh kaum UI benötigt wird.

Aus meiner Sicht führt darum kein Weg herum, dies frühzeitig und möglichst flexibel einzuplanen, denn wenn irgendwann überraschend die Entscheidung kommt, Chinesisch ins Spiel einzubinden, was aus wirtschaftlicher Sicht sehr oft viel Sinn ergibt, dann macht das schöne, aber unflexible UI in der Regel deutlich mehr Arbeit.