Willkommen zurück zur Quadratur des Kreises, dem quasi unmöglichen Versuch, das Ungesehene hinter der Erstellung eines Videospiels in kurzen Artikeln sichtbar zu machen. In Teil drei geht es um Programmierung sowie zum Spielablauf gehörende Entscheidungen, die damit zusammenhängen.

Hinter den digitalen Kulissen - Videospielmusik selbst komponiert

Unsere fünfteilige Serie zum Thema „Spiele machen“ ist kein Einsteigerguide für Spieledesigner, sondern eine Übersicht der wichtigsten Stationen hinter den Kulissen. Ihr sollt ein Gefühl dafür bekommen, wie viel Know-How und Mühe hinter 40 bis 60 Euro stehen, die ihr für ein Spiel auf den Ladentisch legt. Zwei Stationen liegen hinter uns, nämlich die grobe Planung eines Spiels und die ersten großen Schritte, das Geplante grafisch umzusetzen. Mit der Programmierung der Spielabläufe dringen wir zum Kern des Designprozesses vor. Die Grenzen zwischen diesen drei Themen verschwimmen jedoch, weil alles auf irgendeine Weise miteinander verknüpft ist. Man kann nicht wirklich sagen, wo Grafik anfängt und Programmierung aufhört.

Weiterführende Links

Da ich als Redakteur nicht allen Aufgaben der Spieleschöpfung gerecht zukommen kann (hey, ich koche auch nur mit Wasser), ziehe ich in diesem Kapitel meinen Kollegen Michele Pastow als Themenführer heran. Michele ist 23 Jahre jung, programmiert seit sechs Jahren vornehmlich in der Sprache C++, aber auch in C# und Java mit Fokus auf Spielen.

Unsere sehr einfach gehaltene Demo „Das kleine Grafikmuseum“ zeigte euch in Kapitel zwei, wie eng Programmierung und Grafik verknüpft sind. Gerade das „Unsichtbare“ in einem Programm birgt weit mehr Stolperfallen als sich viele Spieler ausmalen mögen. Denn mal ganz im Ernst: Was stellt ihr euch denn unter dem Programmieren von Spielen vor? Klar, man gibt dem Computer Befehle, was er zu tun hat. Nur was sagt man ihm eigentlich?

Wir wollen bei Spielen vornehmlich folgende Dinge erreichen: Grafische Objekte und Ton sollen je nach Bedarf rechnerisch generiert werden, flexibel sein und Einzelteile davon sollen miteinander interagieren, sei es durch manuelle Steuerung, durch feste Vorgabe oder durch Zufall. Alle Einzelteile sollen so gut miteinander harmonieren, dass sie eine schlüssige Spielfläche oder gar eine lebhafte Welt repräsentieren.

Hinter den digitalen Kulissen - Wie entsteht ein Videospiel? Teil #3: Programmierung und Gameplay

alle Bilderstrecken
Wischen für nächstes Bild, klicken um Infotext ein- / auszublendenBild 1/7Bild 1/71/7
Sieht aus wie ein Haufen kryptischer Text, ist aber ein "Drehbuch" füre unsere Checkpoint-Funktion.
mehr Bildersteckenalle Bilderstrecken

Wir haben euch in der kleinen Museumsdemo ein anschauliches Beispiel geliefert, nämlich unser Mini-Rennspiel „Rutsch Racer“. Diese Demo ist sowohl grafisch wie auch in ihrer Logik einfach gestrickt, legt jedoch die gleiche Problematik an den Tag wie jedes andere „große“ Spiel: Wir haben einen ganzen Haufen 3D-Objekte, die der Rechner im Handumdrehen zeichnet, abseits ihrer Namen aber nicht voneinander unterscheiden kann. Etwa die Landschaft, die Spielfigur, den Schalter, der das Rennspiel aktiviert, die Startlinie, Checkpoints und versteckte Trampoline für eine Abkürzung. Zusätzlich haben wir ein Zählwerk in Form eines Countdowns implementiert.

Unsere Spielregeln sehen vor, dass die steuerbare Figur drei Runden auf dem Kurs absolviert, während ein knapper Countdown die mögliche Spielzeit begrenzt. Gewinnen kann der Spieler nur dann, wenn er sein geringes Zeitkonto aufstockt, und zwar in dem er vor Ablauf des Countdowns durch einen von mehreren Checkpoints läuft.

Klingt einfach, nicht wahr? Das Problem an der Sache: Ein Mensch kann allein durch die Abstrahierung der Begriffe Rennen, Zeit, Countdown und Checkpoint einen logischen Zusammenhang stricken. Egal, wie sehr er sich Mühe gibt, er wird es nie einem Computer erklären können. Checkpoints? Spieler? Nie gesehen! Ja ja, Computer sind dumm, das alte Klischee. Aber was heißt das eigentlich?

Kommunikation mit einem Außerirdischen

Stellt euch einen künstlerisch hochbegabten Außerirdischen vor. Dieser außerirdische Spezies hat keinerlei Bezug zu Menschen, versteht also unsere Kultur nicht und kann natürliches Verhalten nicht von unnatürlichem unterscheiden. Er kann also nicht interpretieren, dass ein Auto vorwärts fährt oder ein Regentropfen nach unten fällt. Aber der muntere Kerl ist sehr aufnahmefähig, ein Profi in Mathe, kann sogar auf Basis von dreidimensionaler Geometrie blitzschnell Mosaik-Gemälde zeichnen. Wenn er weiß, was zu tun ist, erledigt er alles zusammen in einem Affenzahn. Das ist unser Computer oder gegebenenfalls unsere Spielkonsole.

Die ersten Kontakte mit dem Alien waren sehr mühselig, denn er verstand rein gar nichts. Wir mussten uns zuerst auf die Basis aller Kommunikation beschränken. Statt zu sagen „Zeichne ein Bild“, mussten wir vorab definieren, was die Worte Stift und Blatt bedeuten, und worum es beim Malen geht. Und zwar in zerlegten Einzelschritten: Nimm den Stift in die Hand, führe ihn zu Papier, zieh den Strich.

Ist aber ganz schön mühselig und für die meisten Anwender nicht mehr nötig. Da wir unser Alien inzwischen ein paar Jahre kennen, haben gewiefte Köpfe mehrere Formen eines Standard-Vokabulars festgelegt, die eine Kette von Einzelaktionen in komplexere Befehle kapselt. Dieses Vokabular nutzen wir in „Programmiersprachen“. Sie basieren auf englischen Begrifflichkeiten, somit kann sie fast jedermann erlernen. Fast, weil es nicht um Sprache im herkömmlichen Sinne geht. Man lernt nicht Computer-Chinesisch, sondern vielmehr „Mathe mit Buchstaben“, basierend auf einer Portion kreativer Problemlösung.

Hinter den digitalen Kulissen - Wie entsteht ein Videospiel? Teil #3: Programmierung und Gameplay

alle Bilderstrecken
Wischen für nächstes Bild, klicken um Infotext ein- / auszublendenBild 1/7Bild 1/71/7
Die neue Unreal Engine liefert einen Programm-Editor, so dass man theoretisch nicht eine Zeile Code selbst schreiben muss. Wer präzise und sparsam arbeiten will, kommt aber nicht um eigene Programmzeilen herum.
mehr Bildersteckenalle Bilderstrecken

Das Problem der kulturellen Lücke besteht nämlich noch immer. Unser Alien weiß inzwischen anhand eines fest definierten Vokabulars, welche Basisfertigkeiten wir ihm abverlangen, aber den Inhalt eines gezeichneten Bildes kann er noch immer nicht interpretieren. Ein Renn-Wettbewerb ist ihm fremd.

Was nun? Ganz einfach, wir nehmen mehrere Aktionen, die unser Alien aus dem Grundvokabular kennt und verkapseln sie erneut zu komplexeren Tätigkeiten. Bei Spielen haben wir nur zwei verlässliche Werte, nämlich Zeit (kann der Computer messen) und Raum (durch ein Koordinatensystem). Darum machen wir jede einzelne Regel unseres Spiels von Zeit und Geometrie abhängig.

Unser begabter Freund muss gar nicht kapieren, was ein Rennen ist und wann es erfolgreich verläuft. Er muss nur Objekte voneinander unterscheiden und ihnen Alibi-Zustände zuweisen. Quasi ein Zettel mit dem Vermerk: „Hier ist etwas anders als der Normalzustand“. Eine Veränderung kann alles Erdenkliche sein. Zum Beispiel, dass sich zwei Objekte berühren. Anschließend bilden wir eine kausale Kette mit dem einfachsten denkbaren Zusammenhang: Passiert Veränderung A an Ort B, dann verhält sich Objekt C nach unseren Wünschen. Quasi ein Drehbuch mit Angaben, die sich ausschließlich nach den Größen Raum und Zeit richten.

Genau genommen schreiben wir Befehlsketten und Befehlsschleifen, die der Rechner von oben nach unten durchliest und in eben jener Reihenfolge ausführt, in der er sie vorfindet. Solche linear zu lesenden Befehlssammlungen nennt man Scripts.

So bestimmt ein sogenanntes Character-Controller-Script in unserer kleinen Demo, wie schnell sich die First-Person-Spielfigur bewegt, wie hoch sie springt und wie weit sie schlittert, wenn das Rennspiel aktiv ist. Das Script enthält mehrere mathematische Aufgaben, die sich auf das vorgefertigte Vokabular unserer Programmiersprache beziehen – zum Beispiel Transformation durch Änderung der Koordinaten eines Objekts. Der veränderte Zustand, den wir dafür anweisen, ist schlichtweg der Druck eines Buttons auf der Tastatur. Michele hat Teile des Scripts eigenhändig geschrieben, weil unsere Spielfigur gewisse Regeln einhalten soll. Grundsätzlich wäre das nicht nötig gewesen, denn im Jahre 2014 haben das schon Millionen anderer Entwickler getan.

Zurück zu den Engines

Nach über 30 Jahren kommerzieller Spiele-Industrie ist das Schreiben eines Bewegungs-Scripts ein kleines wie unspektakuläres Stück Text. Ebenso wie ein Script, das Texturen verändert oder eines, das Licht vortäuscht. Sammelt man alle zu programmierenden Elemente für ein komplettes Spiel, kommt trotzdem ein unüberschaubarer Berg zusammen. Im Zeitalter der 3D-Grafik geht der Löwenanteil für Grafik drauf, und doch sind die hintergründig benötigten Funktionen mannigfaltig. Angefangen beim Berechnen einer künstlichen Physik über das Abspielen von Animationen bis hin zur Vortäuschung von Kamera-Brennweiten. Engines beinhalten Sammlungen solcher Problemlösungen, die miteinander verzahnt sind und wie eine Maschine ineinander greifen, aber unabhängig voneinander ansprechbar sind.

Die Unity-Engine, die wir für die Erstellung unserer kleinen Demo herangezogen haben, liefert hunderte solcher Programm-Puzzleteile von vornherein mit, so dass wir für viele Einstellungen nur noch variable Zahlenwerte verändern müssen. Was noch bleibt, ist der Spiellogik beizubringen, dem Countdown zusätzliche Sekunden zu spendieren, sobald die Spielfigur durch einen Checkpoint läuft. Theoretisch eine einfache Aufgabe. Vielleicht erinnert ihr euch an die „Collider“ aus der kleinen Museumsdemo. Sie dienen nicht nur als Begrenzungen, sondern auch als Auslöser, sogenannte Trigger. Wir geben unserer Spielfigur einfach einen Trigger in Form einer unsichtbaren Kiste und sagen folgende Aktionen an: Ist das Rennspiel aktiviert? Wenn nicht, dann mache nichts. Wenn doch, dann schau, ob die Trigger-Kiste den Checkpoint berührt. Ist das so, dann addiere einen Zeitbonus zum Countdown und aktiviere den nächsten Checkpoint.

Was tatsächlich geschieht, ist dass wir die sowieso schon komplexe Maschine hinter Unity um weitere Zahnräder ergänzen. Allein die Rennspielfunktion unserer Demo benötigt vier Scripts mit jeweils rund einer Din-A-4-Seite Text, die mehrere Anweisungen beinhalten und miteinander verknüpft. Enthält nur eines dieser Scripts ein Kommando, das die Engine falsch umsetzt, funktioniert unter Umständen das ganze Programm nicht mehr.

Hinter den digitalen Kulissen - Wie entsteht ein Videospiel? Teil #3: Programmierung und Gameplay

alle Bilderstrecken
Wischen für nächstes Bild, klicken um Infotext ein- / auszublendenBild 1/7Bild 1/71/7
Diese First-Person-Spielfigur hat noch keinen Körper, aber schon 5-Trigger, die das Kicken und Kontrollieren eines Fußballs ermöglichen. Diese Trigger in Form von kleinen Kisten sind für den Spieler unsichtbar.
mehr Bildersteckenalle Bilderstrecken

Das macht das Programmieren von Spielen nicht nur unheimlich kompliziert, sondern auch zu einer verdammt lustigen Angelegenheit. Sogenannte Bugs (Programmfehler) lassen sich oft auf falsch eingestellte Werte zurückführen, weil die Entwicklungsumgebungen nicht zwingend mit echten Maßeinheiten arbeiten. Längenangaben, Geschwindigkeiten und vieles mehr sind gegebenenfalls abstrakte Werte oder widersprechen dem, was die Programmierer eines Spiels nach Gefühl eingestellt haben.

Bestes Beispiel wäre Schwerkraft. Jeder, der in Physik aufgepasst hat, weiß, dass Fallgeschwindigkeit bei 9,81 Metern pro Quadratsekunde liegt. 9,81 als Wert in die Maske der Schwerkraftberechnung einzutragen hilft aber herzlich wenig, wenn unsere Polygonobjekte abstrakte Maße haben oder ihr Gewicht zugunsten gewisser Gameplay-Einstellungen gar nicht üblicher Schwerkraft entspricht.

Flüchtigkeitsfehler wie falsch gesetzte Vorzeichen können alles Mögliche bewirken. Von „alle Bleigewichte fliegen hooooch“ bis zu Spielcharakteren, die Spider-Man nacheifern. Hier sind Frustresistenz und Geduld Gold wert, andererseits lachen manche Programmierer Tränen, wenn Pferde plötzlich rückwärts galoppieren, Fußbälle bei geringster Berührung die Schallmauer durchbrechen oder die Animationsroutine eines Charakters schlichtweg beknackt aussieht. Und ihr wärt überrascht festzustellen, wie viele verrückte Spielideen falschen Programm-Einstellungen entspringen. So lange vergeigte Optionen nachvollziehbar bleiben, ist alles im grünen Bereich. Problematisch wird es erst, wenn man die Fehlerquelle nicht reproduzieren kann, oder wenn sie durch Konflikte mehrerer Scripts entsteht.

Bedenkt einfach mal, dass jedes interaktive Objekt eines Spiels, von der Hauptfigur bis zum kleinsten Schalter, mindestens einem Script unterliegt, wenn nicht gar dreien oder vieren, die mit den Scripts anderer Objekte interagieren.Viele gescriptete Objekte erkennt ihr gar nicht, weil sie unsichtbar sind. Fehler sind selbst bei gewissenhafter Arbeit unvermeidlich.

Ordnung ist das halbe Script

Einen Genremix samt simulierter Großstadt wie in GTA V zu schreiben, muss die Hölle auf Erden sein. Allein die benötigte Anzahl an Script sprengt jede Vorstellungskraft, und der wahre Horror beginnt erst beim Anordnen der Prioritäten. Wie schon erwähnt, liest der Rechner jedes Script von oben nach unten ab und behandelt deren Aufgaben der Reihe nach, sofern man es ihm nicht durch Ausnahmeregelungen ausdrücklich verbietet. Das kann zu Konflikten führen, weil einige Dinge in Spielen verdammt schnell vonstatten gehen.

Abgefeuerte Kugeln eines Gewehrs überbrücken innerhalb von Millisekunden riesige Strecken. Bei einem guten Shooter sollen sie an Wänden abprallen, sonst könnte man ja gedeckte Gegner umnieten. Steht die Spielfigur direkt vor einer Wand, benötigt eine Kugel weniger als eine sechzigstel Sekunde bis zum Collider, der sie aufhalten soll. Das entspricht bei 60 Bildern pro Sekunde weniger als einem gezeichneten Bild. Somit müssen wir dem Rechner mitteilen, wie oft er den Zustand eines gescripteten Gegenstands neu berechnet.

Eine für das Gameplay so wichtige Einstellung wie „kugelsichere Wände“ muss somit eine höhere Priorität erhalten als ein nebensächliches Element, damit es in jedem Rechenzyklus möglichst früh zur Sprache kommt. Andernfalls könnten vereinzelte Kugeln eine Wand passieren, weil das Thema schlichtweg zu spät auf den Plan kommt. Und das ist noch eine verdammt einfache Konstellation. Rennsimulationen wie Forza Motosport 5 oder das heiß erwartete Project Cars setzen auf ein ganzes Kartenhaus voller Rechenroutinen, die jede einzelne Funktion eines Autos nachstellen.

Hinter den digitalen Kulissen - Wie entsteht ein Videospiel? Teil #3: Programmierung und Gameplay

alle Bilderstrecken
Wischen für nächstes Bild, klicken um Infotext ein- / auszublenden6 Bilder
Unzählige verschachtelte Programmteile sorgen für realitätsnahes Fahrverhalten in Forza Motorsport. Man sieht sie nicht, aber sie saugen ganz schön an der Rechenleistung der Xbox One.
mehr Bildersteckenalle Bilderstrecken

Bei Forza Motorsport liegt der Update-Zyklus für Aufhängung, Reifendruck, Hitze, Beschleunigung, Federung und vieles mehr weit über der Framerate – ganze 360 Mal in der Sekunde vollzieht das Programm gigantische Fließkomma-Kalkulationsorgien. Jene Leute bei Turn 10, die entscheiden, was davon zugunsten einer glaubhaften Simulation zuerst berechnet wird, müssen verdammte Automobil-Genies sein.

Zumal Spielprogrammierung einigen Beschränkungen unterliegt. Dank ausgeklügelter Mathematik und Geometrie lässt sich beinahe jedes Verhalten und beinahe jede lineare Form durch eine Kombination von mathematischen Formeln ausdrücken. Je einfacher gehalten, desto schneller kann die Berechnung ausgeführt werden, deshalb beschränkt man zum Beispiel alles was auf Ganzzahlen basiert auch auf Rechenoperationen ohne Komma. Komplizierte Rechnungen wie das Ziehen einer Quadratwurzel dauern erheblich länger als etwa eine Multiplikation und werden eher gemieden.

Was aber, wenn man komplexe Berechnungen benötigt, etwa abgerundete Formen? Nun, da gibt es kreative Lösungen, von denen man als Spieler nicht das Geringste merkt. So bestehen die Reifen eines Rennspiels aus eckigen Polygonen (siehe Teil zwei dieses Specials). Würde man sie einfach so über einen aalglatten Asphalt rollen lassen, so wäre ihre Bewegung ziemlich zappelig, da die Flächen und Kanten des Polyongebildes auf unterschiedlicher Höhe den Boden berühren. Um das zu vermeiden, berührt der Reifen den Boden in Wirklichkeit gar nicht. An seiner Stelle übernimmt ein unsichtbarer „Wheel_Collider“ die Interaktion mit der Grundfläche.

Damit dieser Wheel-Collider ohne viel Rechenaufwand möglichst rund ist, wird er durch einen zweidimensionalen Raycast generiert. Das ist nichts weiter als ein Punkt, von dem viele Strahlen in zweidimensionaler Ausrichtung ausgehen. Begrenzt man die Länge der Strahlen und bestimmt deren Ende als Kollisionsgrenze, lässt sich ohne viel Aufwand ein beinahe perfekter Kreis zeichnen.

Isoliert betrachtet mag das eine kleine Sparmaßnahme sein. Im Konstrukt eines Spiels kommt es jedoch auf die Summe an. Wir wollen Grafik, Sound, interaktive Steuerung und Spielregeln in Echtzeit ausführen, und das für möglichst viele Kunden. Je sparsamer, desto kompatibler, und je besser geordnet, desto einfacher fällt es, zu jedem beliebigen Zeitpunkt Änderungen vorzunehmen.

Die Reißleine ziehen

Änderungen fallen während des Programmierens zwangsläufig an. So ziemlich jede Aktion unterliegt intensiven Testsitzungen und anschließenden Verfeinerungen. In den rund 30 Arbeitsstunden an unserer Museumsdemo gingen allein zehn Stunden für das Rutsch Racer-Rennspiel drauf. Fünf Stunden habe ich mich persönlich um das Ausrichten der Checkpoints und das Abstimmen der Zeitboni gekümmert, damit die Balance zwischen belohnendem Erfolg und Herausforderung gewahrt bleibt. Unter anderem, weil ich versteckte Trampoline untergebracht habe, die erlauben, einen Teil der Strecke zu überspringen. Diese „Abkürzung“ sollte durchaus einen Vorteil einbringen, aber nicht zu sehr ins Gewicht fallen. Dadurch war ich gezwungen, das Rennspiel gefühlte 100 Mal zu bewältigen (ich kann's inzwischen im Schlaf, egal in welche Richtung).

Ich hab also mächtig daran gefummelt und wähnte mich zufrieden. Die echten Macken unseres einfach gestrickten Programms kamen trotzdem erst zutage, als Unbeteiligte es ausprobierten. Es ging um viele Kleinigkeiten, die man im Eifer des Gefechts schlichtweg übersieht, was Änderungen an Scripts verlangte, die Michele längst als „fertig“ betrachtete. Zum Glück hatte Michele alles fein säuberlich dokumentiert (heißt: er hat die Aufgaben unseres Programms in verständlicher Sprache notiert).

Bei einer Profi-Produktion genügt diese Vorgehensweise häufig nicht. Auch hier wird sauber dokumentiert, finden ständig interne Proberunden statt (oder auch externe, die berühmte Beta-Phase). Nur wäre das Abklopfen jeder einzelnen Zeile Code bei einem monströsen Rollenspiel kaum zumutbar. Je größer die Produktion, desto modularer fallen dessen Einzelteile aus, damit man sie isolieren oder gegebenenfalls deaktivieren kann.

Hinter den digitalen Kulissen - Wie entsteht ein Videospiel? Teil #3: Programmierung und Gameplay

alle Bilderstrecken
Wischen für nächstes Bild, klicken um Infotext ein- / auszublendenBild 1/7Bild 1/71/7
Seit acht Jahren verändern ständige Updates das Programm hinter Herr der Ringe Online. Dass hin und wieder Teile fehlerhaft sind, ist unvermeidlich.
mehr Bildersteckenalle Bilderstrecken

Turbines MMO „Herr der Ringe Online“ erhält seit acht Jahren regelmäßig Updates mit neuen Tätigkeiten, veränderten Spielregeln und allerhand Anpassungen, die man unter Umständen gar nicht wahrnimmt. Die meisten Anpassungen kommen durch Updates des Hauptprogramms. Man lädt also veränderte Grafiken und umgeschriebene Programmteile herunter. Doch liegen bei einem derart riesigen MMO so viele mögliche Fehlerquellen offen, dass Turbines Programmierer zur Sicherheit weitere Fallnetze spannen.

Nathan Sitkoff, Engineering Manager bei Herr der Ringe Online:
Bei späten oder riskanten Änderungen am Programm bauen wir oft „Reißleinen-Code“ ein, der uns erlaubt, Parameter und Variablen eines Features anzupassen oder abzuschalten, ohne eine neue Version des Spiels zu veröffentlichen. Zum Beispiel, wenn wir einen Exploit finden. Wir können sogar ganze Spielpassagen umgehen, so dass Spieler Einzelteile einer Quest überspringen, während wir das kaputte Segment reparieren.

In der Einleitung dieses Specials hatte ich den grundsätzlichen Unterschied in der Darstellung eines Rennspiels und eines Actionspiels angeschnitten. Nun, hier habt ihr die Wurzel des Problems. Nicht nur Shader und künstlerischer Ansatz bestimmen den Stil eines Spiels. Sämtliche hintergründigen Funktionen tragen ebenfalls dazu bei, denn alle Programmteile beziehen sich auf Grafik. Selbst Kleinigkeiten wie unterschiedliche Soundeffekte für Schritte auf diversen Terrains hängen an unsichtbaren Grafikelementen. Sie mögen nicht ausgerendert werden, Rechenzeit schlucken sie trotz alledem – und zwar nicht zu knapp. Gehen wir auf das Beispiel mit den Kugeln und der Wand zurück, ist das einfach zu erkennen. Die Wand wird mit jedem Bildaufbau neu „abgefragt“, also 60 Mal die Sekunde – selbst wenn der Spieler gar nicht schießt.

Künstliche Intelligenz und Online-Verbindungen

Unser Checkpoint-Beispiel aus der Museumsdemo sollte für das Verständnis des allgemeinen Programmiervorgangs einfach genug sein. Bedenkt jedoch, dass es hunderte verschiedener Funktionen gibt, die man zum Bilden einer Logik nutzen kann. Was wir in Spielen als selbstverständlichen Komfort wahrnehmen, ist nicht selten ein monströses Code-Konstrukt. Denkt mal an so etwas wie Drag and Drop zwischen zwei Bildschichten, etwa dass ihr ein Objekt aus der 3D-Welt auflesen und es mit einer durchgehenden Mausbewegung in ein 2D-Menü schiebt. Zu begreifen, dass das Questsystem eines Action Adventures aus hunderten von „wenn-dann“ Aufgaben in Raum und Zeit besteht, verändert die Wahrnehmung beim Spielen maßgeblich. Ganz zu schweigen von „künstlicher Intelligenz“ bei Shootern, die allerhand künstliche Zusammenhänge strickt, aber nicht den geringsten Schimmer Intelligenz.

Das macht das Programmieren von Online-Modi übrigens zur Königsdiziplin, denn wenn alle Verschachtelungen unseres Spielkonstrukts von Raum und Zeit abhängen, sind zeitlich unvorhersehbare Verzögerungen mehr als ungünstig. Jedes Datenpaket, das über das Internet geschickt wird, benötigt eine gewisse Anzahl an Millisekunden für hin und Rückweg. Währenddessen soll das Spiel flüssig weiterlaufen. Somit bieten sich zwei Methoden zum Abgleich der Daten an.

Man kann im Voraus abschätzen, wohin sich bewegliche Spielelemente bewegen. Dazu sind allerdings komplexe Physikberechnungen vonnöten. Oder man wartet auf die tatsächlich übertragenen Daten der Teilnehmer, wodurch das Spiel asynchron läuft. Egal wie man es angeht, es ist nie ideal. Nun bleibt die Qual der Wahl, welche Methode für das eigene Spiel das geringere Übel darstellt. Beziehungsweise welche Methode unseren Programmfunktionen am ehesten entgegenkommt.

Alles steht und fällt mal wieder mit der Engine, denn nutzbare Funktionen hängen größtenteils von ihr ab. Programmiersprachen wie C# oder C++ nutzen wir im Grunde nur, um die Verknüpfung zwischen den Funktionen zu bestimmen.

Hinter den digitalen Kulissen - Wie entsteht ein Videospiel? Teil #3: Programmierung und Gameplay

alle Bilderstrecken
Wischen für nächstes Bild, klicken um Infotext ein- / auszublendenBild 1/7Bild 1/71/7
Künstliche Intelligenz? Käse! Egal ob Freund oder Feind, alle NPCs warten letztendlich nur auf vordefinierte Ereignisse. Je komplexer solche Ereignisse verschachtelt wurden, desto intelligenter wirken sie.
mehr Bildersteckenalle Bilderstrecken

Die verwendete Sprache hat wenig Einfluss auf das Ergebnis. Ganz anders sieht das beim Workflow aus, also bei der Herangehensweise an das Code-Kostrukt. So ist C++ zwar erheblich flexibler als C#, weil es sozusagen eine komplexere Grammatik (Syntax) mitbringt. Obwohl wir in Quasi-Englisch schreiben, wirft der kompilierte Code Maschinensprache aus, also die Mutterprache der Computerchips. Im Umkehrschluss setzt C++ ein genaueres und nachhaltiger geplantes Programmieren voraus. Man muss ständig „hinter sich aufräumen“, weil man sogar die Speichernutzung des Systems aktiv beeinflusst.

C# kommt im Vergleich komfortabler aber auch „gröber“ daher. Diese Sprache nimmt Programmierern viele Arbeitsschritte ab, die in C++ potentielle Fehlerkandidaten sind. Außerdem spuckt C# sogenannten Bytecode aus, der erst beim Start des Programms in Maschinensprache übersetzt wird. Der Vorteil dabei: Man kann bestimmte Vorgänge für die Chips einer Maschine optimieren. C#-Code ist also nicht zwingend langsamer auszuführen als C++.

Eine Wahl hat man als Programmierer leider selten. Wer auf der Unreal Engine programmieren will, muss C++ beherrschen, basta. Bei Unity wird C# vorausgesetzt, wobei man auch auf Unity Script ausweichen kann, was einer abgewandelten Form von Java Script gleichkommt. Neben den mitgelieferten Funktionen ein Grund mehr, eine Engine mit Bedacht auszusuchen. –

Genug für heute. Auch dieses Kapitel unseres Specials kann die die Natur des Programmierens von Spielen nur an der Oberfläche anreißen, doch irgendwo müssen wir Grenzen ziehen. In zwei Wochen beschäftigen wir uns mit Musik und Soundeffekten.