• Kapitel 17

  Data Locality (Datenlokalität)

• Kapitel 18

  Dirty Flag (Veraltet-Flag)

• Kapitel 19

  Object Pool (Objektpool)

• Kapitel 20

  Spatial Partition (Räumliche Aufteilung)

Die Hardware wird immer schneller und für den größten Teil der darauf betriebenen Software gilt, dass sich die Programmierer hinsichtlich der Performance keine großen Gedanken zu machen brauchen. Spiele stellen hier eine der wenigen verbliebenen Ausnahmen dar. Die Anwender verlangen nach einem immer vielfältigeren, realistischeren und aufregenderen Spielerlebnis. Es gibt zuhauf Spiele, die um die Aufmerksamkeit – und das Geld! – der Spieler wetteifern. Und nicht selten macht dasjenige Programm das Rennen, das die Hardware am besten ausreizt.

Die Performanceoptimierung ist eine tiefgründige Kunst, die mit sämtlichen Aspekten der Software in Verbindung steht. Bei maschinennaher Programmierung müssen die unzähligen Eigenheiten der verschiedenen Hardwarearchitekturen gemeistert werden. Unterdessen konkurrieren Algorithmenforscher darum, mathematisch zu beweisen, wessen Verfahren am leistungsfähigsten sind.

Ich stelle in diesem Teil des Buches einige Patterns mittleren Schwierigkeitsgrads vor, die häufig eingesetzt werden, um ein Spiel zu beschleunigen. Das Kapitel 17 Data Locality (Datenlokalität) führt Sie in die Speicherhierarchie moderner Computer ein und zeigt, wie Sie sie zu Ihrem Vorteil nutzen können. Die Patterns Dirty Flag (Veraltet-Flag, Kapitel 18) und Object Pool (Objektpool, Kapitel 19) sollen Ihnen dabei helfen, überflüssige Berechnungen bzw. Speicherreservierungen zu vermeiden. Und durch Spatial Partitioning (Räumliche Aufteilung, Kapitel 20) soll schließlich die räumliche Aufteilung der Objekte sowie der Einwohner der virtuellen Welt beschleunigt werden.

• Kapitel 14

  Component (Komponente)

• Kapitel 15

  Event Queue (Ereigniswarteschlange)

• Kapitel 16

  Service Locator (Dienstlokalisierung)

Wenn Sie bei einer Programmiersprache erst einmal den Bogen raushaben, ist es tatsächlich ziemlich einfach, Code zu schreiben, der wunschgemäß funktioniert. Schwierig wird es jedoch, wenn es darum geht, Code zu schreiben, der sich leicht anpassen lässt, wenn sich die Anforderungen ändern. Dass eine perfekt ausgearbeitete Liste der Funktionalitäten vorliegt, bevor der Texteditor gestartet wird, ist leider ein höchst seltener Luxus.

Uns steht jedoch ein leistungsfähiges Tool zur Verfügung, um Modifizierungen zu erleichtern: die Entkopplung.​ Wenn davon die Rede ist, dass zwei Codeabschnitte »entkoppelt« sind, ist damit gemeint, dass Modifikationen in einem dieser Abschnitte für gewöhnlich keine Änderungen im anderen nach sich ziehen. Und wenn der Code nur an wenigen Stellen geändert werden muss, ist es einfacher, Funktionalitäten eines Spiels zu ändern.

Das Pattern Component (Komponente, Kapitel 14) entkoppelt verschiedene Bereiche eines Spiels mittels eines einzigen Informationsobjekts, das alle Aspekte der Bereiche umfasst. Event Queues (Ereigniswarteschlangen, Kapitel 15) ermöglichen es, zwei miteinander kommunizierende Objekte zu entkoppeln, insbesondere auch zeitlich. Und ein Service Locator (Dienstlokalisierung, Kapitel 16) gestattet es, einen Dienst in Anspruch zu nehmen, ohne an den Code gebunden zu sein, der ihn bereitstellt.

• Kapitel 11

  Bytecode

• Kapitel 12

  Subclass Sandbox (Unterklassen-Sandbox)

• Kapitel 13

  Type Object (Typ-Objekt)

Sobald Sie die Kulissen Ihres Spiels aufgebaut, es mit Akteuren bestückt und mit Requisiten ausgestattet haben, kann es endlich losgehen. Dafür ist jedoch Verhalten erforderlich – ein Drehbuch, das den Akteuren Ihres Spiels mitteilt, was sie tun sollen.

Natürlich stellt letzten Endes jeglicher Code »Verhalten« dar – sämtliche Software definiert ein Verhalten. Bei Spielen gibt es allerdings häufig einen wichtigen Unterschied, nämlich den enormen Umfang des Verhaltens, das implementiert werden muss. Ihre Textverarbeitung mag eine Menge Features bieten, sieht jedoch im Vergleich zu der in einem typischen Rollenspiel vorhandenen Anzahl von Einwohnern, Gegenständen und Aufgabenstellungen ziemlich alt aus.

Die in diesem Kapitel vorgestellten Patterns sollen dabei helfen, eine Vielzahl unterschiedlicher Verhaltensweisen zu definieren und weiterzuentwickeln, die sich gut warten lassen. Mithilfe des Patterns Type Object (Typ-Objekt, Kapitel 13) lassen sich Verhaltensweisen ohne die mit der Definition einer Klasse einhergehenden Zwänge implementieren. Eine Subclass Sandbox (Unterklassen-Sandbox, Kapitel 12) stellt einen Satz elementarer Operationen zur Verfügung, die Sie dazu verwenden können, ein breites Spektrum von Verhaltensweisen zu definieren. Und die anspruchsvollste Option ist das Pattern Bytecode (Kapitel 11), das das Verhalten aus dem Code entfernt und es komplett in Daten umwandelt.

• Kapitel 8

  Double Buffer (Doppelter Buffer)

• Kapitel 9

  Game Loop (Hauptschleife)

• Kapitel 10

  Update Method (Aktualisierungsmethode)

Videospiele sind vor allem deswegen spannend, weil sie uns in eine andere Welt entführen. Ein paar Minuten lang (na ja, seien wir ehrlich, in der Regel doch viel länger) werden wir zu Einwohnern einer virtuellen Welt. Sich solche Welten auszudenken, gehört zu den größten Freuden bei der Arbeit als Spieleprogrammierer.

Einem Aspekt schenken die meisten dieser Spiele Beachtung: der Zeit – die künstliche Welt lebt und wandelt sich in ihrem eigenen Rhythmus. Als Weltenerbauer müssen wir die Zeit erfinden und eine Mechanik ersinnen, damit der Lauf der Dinge in der Spielwelt nicht zum Stillstand kommt.

Die Patterns in diesem Teil des Buches sind Werkzeuge, die genau das leisten sollen. Die Game Loop (Hauptschleife, Kapitel 9) ist der Dreh- und Angelpunkt des Spiels, der die Uhr antreibt. Die Objekte hören deren Uhrwerk dank des Patterns Update Method (Aktualisierungsmethode, Kapitel 10) ticken. Und die sequenzielle Natur des Computers lässt sich mittels des Patterns Double Buffer (Doppelter Buffer, Kapitel 8) hinter einer Fassade aus Momentaufnahmen verbergen: Die gesamte Spielwelt wird scheinbar zeitgleich aktualisiert.

• Kapitel 2

  Command (Befehl)

• Kapitel 3

  Flyweight (Fliegengewicht)

• Kapitel 4

  Observer (Beobachter)

• Kapitel 5

  Prototype (Prototyp)

• Kapitel 6

  Singleton

• Kapitel 7

  State (Zustand)

Das Buch Design Patterns: Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software ist inzwischen über 20 Jahre alt. Würde es sich dabei um einen Wein handeln, wäre er inzwischen wohl alt genug, um ihn genussvoll trinken zu können – in der schnelllebigen Softwarebranche ist das praktisch schon antik. Die anhaltende Popularität des Buches zeigt aber auch, wie zeitlos Design doch im Vergleich zu vielen Frameworks oder so manchem anderen Verfahren ist.

Zwar sind die Design Patterns nach wie vor von Bedeutung, wir haben in den letzten beiden Jahrzehnten aber auch dazugelernt. In diesem Abschnitt werden wir uns einige der ursprünglichen Patterns der Gang of Four ansehen, und ich hoffe, zu jedem einzelnen von ihnen den einen oder anderen nützlichen Beitrag leisten zu können.

Ich bin der Ansicht, dass manche Patterns (Singleton, Kapitel 6) überbeansprucht und andere (Command, Kapitel 2) unterschätzt werden. Einige sind hier aufgeführt, weil ich ihre Bedeutung für die Spieleprogrammierung aufzeigen möchte (Flyweight und Observer, Kapitel 3 und 4). Und in manchen Fällen ist es einfach nur interessant zu sehen, wie die Patterns mit dem Gesamtbild der Programmierung verwoben sind (Prototype und State, Kapitel 5 und 7).

• Kapitel 1

  Architektur, Performance und Spiele

Im fünften Schuljahr standen in unserem Klassenzimmer ein paar ziemlich ramponierte TRS-80-Computer herum, die meine Freunde und ich benutzen durften. Ein Lehrer, der unsere Begeisterung wecken wollte, gab uns einen Stapel Ausdrucke einiger einfacher BASIC-Programme, mit denen wir experimentieren konnten.

Die Kassettenlaufwerke der Rechner waren defekt, d.h., wenn wir Code ausführen wollten, mussten wir ihn immer sehr sorgfältig komplett neu eingeben. Das führte dazu, dass wir bevorzugt auf Programme zurückgriffen, die nur einige wenige Zeilen lang waren:

10 PRINT "BOBBY IST EIN RADIKALER!!!"
20 GOTO 10

Trotzdem war das Ganze Glückssache. Wir hatten keine Ahnung von Programmierung, und schon der kleinste Syntaxfehler war für uns unergründlich. Wenn ein Programm nicht funktionierte, und das kam des Öfteren vor, fingen wir einfach von vorne an.

Am unteren Ende des Papierstapels mit Ausdrucken fanden wir schließlich ein richtiges Ungeheuer: ein Programm, das aus mehreren eng mit Code bedruckten Seiten bestand. Es dauerte ein Weilchen, bis wir überhaupt den Mut aufbrachten, es einzugeben, aber es war einfach unwiderstehlich, denn der Titel am Anfang des Listings lautete »Tunnels & Trolls«. Wir hatten keinen blassen Schimmer, worum es bei dem Programm ging, aber es klang nach einem Spiel, und was könnte cooler sein als ein selbstprogrammiertes Computerspiel?

Leider haben wir es nie zum Laufen bekommen und im darauffolgenden Schuljahr zogen wir in ein anderes Klassenzimmer um. (Jahre später, nachdem ich etwas BASIC gelernt hatte, wurde mir klar, dass es sich seinerzeit gar nicht um ein Spiel gehandelt hatte. Das Programm erzeugte bloß verschiedene Persönlichkeiten für das eigentliche Rollenspiel.) Dessen ungeachtet waren die Würfel gefallen: Ich hatte mir in den Kopf gesetzt, Spieleprogrammierer zu werden.

Als ich ein Teenager war, schaffte sich meine Familie einen Macintosh mit QuickBASIC an, später kam dann THINK C​ dazu. Ich habe fast meine gesamten Sommerferien damit verbracht, Spiele zusammenzuhacken. Es war mühsam, auf mich allein gestellt zu lernen und es ging nur langsam vorwärts. Anfangs war es gar nicht so schwer und ich bekam schnell etwas zum Laufen – vielleicht eine Landkartendarstellung oder ein kleines Puzzle. Aber sobald die Programme etwas umfangreicher waren, wurde es immer schwieriger.

Zunächst bestand die Herausforderung nur darin, überhaupt etwas zum Funktionieren zu bekommen. Dann musste ich mir überlegen, wie ich Programme schreiben konnte, die aus mehr Zeilen bestanden, als ich mir gleichzeitig merken konnte. Anstatt Bücher wie »Programmierung in C« von Kernighan und Ritchie zu lesen, versuchte ich Fachliteratur zu finden, die sich mit dem Organisieren von Programmen befasste.

Zeitsprung. Mehrere Jahre später drückte mir ein Bekannter das Buch Design Patterns: Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software in die Hand. Endlich! Das war genau das Nachschlagewerk, nach dem ich seit meiner Teenagerzeit gesucht hatte. Ich las es in einem Rutsch von vorne bis hinten durch. Zwar hatte ich noch immer mit meinen eigenen Programmen zu kämpfen, aber mir fiel ein Stein vom Herzen, als ich begriff, dass andere Leute ähnliche Schwierigkeiten hatten und Lösungen dafür erarbeiteten. Ich hatte das Gefühl, dass ich statt »nur« meiner bloßen Hände nun endlich richtige Werkzeuge einsetzen konnte.

2001 trat ich meinen Traumjob an: Programmierer bei Electronic Arts. Ich konnte es kaum erwarten, mir die richtigen Spiele anzusehen und herauszufinden, wie die Profis sie entwickeln. Wie sieht wohl die Architektur eines so gigantischen Spiels wie Madden Football aus? Wie arbeiten die verschiedenen Systemkomponenten zusammen? Wie schaffen sie es, eine einzige Codebasis auf mehreren Plattformen zum Laufen zu bringen?

Als ich den Quellcode sah, war das eine demutsvolle und überraschende Erfahrung. Der Code zur Grafikerzeugung, die künstliche Intelligenz (KI), die Animationen und visuellen Effekte – all das war einfach brillant. Hier gab es Leute, die das letzte bisschen Leistung aus der CPU herauskitzeln und nutzen konnten. Sie erledigten Dinge, von denen ich gar nicht wusste, dass sie überhaupt möglich sind, schon vor der Mittagspause.

Aber der Architektur, in der sich dieser brillante Code befand, wurde kaum Beachtung geschenkt. Die Programmierer waren so sehr auf Features konzentriert, dass sie dabei die Organisation übersahen. Es wimmelte nur so von eng gekoppelten Modulen. Neue Features wurden der Codebasis da aufgepfropft, wo es gerade passte. Ernüchtert musste ich feststellen, dass es viele der Programmierer offenbar nicht weiter als bis zum Singleton-Pattern geschafft hatten – wenn sie das Buch Design Patterns denn überhaupt mal aufgeschlagen haben sollten.

Na ja, ganz so schlimm war es natürlich auch wieder nicht. Ich hatte mir allerdings ausgemalt, dass Spieleprogrammierer mithilfe von Wandtafelen wochenlang in aller Seelenruhe in einem Elfenbeinturm die architektonischen Einzelheiten ausdiskutierten – tatsächlich war der Code, den ich mir ansah, jedoch von Leuten geschrieben worden, die sich mit engen Abgabefristen konfrontiert sahen. Sie gaben wirklich ihr Bestes und das war, so dämmerte mir allmählich, oft sehr gut. Je länger ich mich mit der Arbeit am Gamecode beschäftigte, desto mehr brillante Codeschnipsel entdeckte ich, die sich unter der Oberfläche versteckten.

Leider war »versteckt« häufig eine allzu treffende Beschreibung. Es waren echte Juwelen im Code verborgen, die viele völlig übersahen. Ich habe mehr als nur einmal erlebt, dass andere Programmierer sich damit abmühten, Dinge neu zu erfinden, obwohl in der Codebasis, mit der sie arbeiteten, bereits gute Lösungen für genau die betreffende Fragestellung vorhanden waren.

Dieses Problem möchte das vorliegende Buch lösen. Ich habe die besten in der Spieleprogrammierung vorkommenden Patterns ausgewählt, geordnet und zusammengestellt, damit wir unsere Zeit damit verbringen können, Dinge tatsächlich neu zu erfinden, anstatt sie wieder zu erfinden.

Es gibt bereits Dutzende Bücher über Spieleprogrammierung – warum also ein weiteres schreiben? Die meisten mir bekannten Bücher zum Thema Spieleprogrammierung gehören einer der beiden folgenden Kategorien an:

Themenspezifische Bücher Diese Bücher sind weitestgehend auf einen bestimmten Aspekt der Spieleprogrammierung fokussiert, wie etwa 3D-Grafik, Rendern in Echtzeit, Physiksimulation, künstliche Intelligenz oder Audio. Das sind die Gebiete, auf die sich viele Spieleprogrammierer im Lauf ihrer Karriere spezialisieren.

Bücher über komplette Spiel-Engines Im Gegensatz zu der vorgenannten Kategorie versuchen diese Bücher, alle Bestandteile einer Engine abzuhandeln. Sie sind auf die Entwicklung einer kompletten Engine für ein bestimmtes Spielgenre ausgerichtet, meist 3D-Ego-Shooter.

Mir sagen die beiden Kategorien durchaus zu, aber ich denke, dass sie einige Lücken lassen. Themenspezifische Bücher erklären selten, wie der Code mit dem Rest des Spiels zusammenwirkt. Sie mögen vielleicht beim Rendern und der Physiksimulation ein alter Hase sein, aber wissen Sie auch, wie man beides vernünftig miteinander verbindet?

Dieser Bereich wird von der zweiten Kategorie zwar abgedeckt, ich finde die Bücher über komplette Spiel-Engines allerdings oft zu einseitig und genrebezogen. Mit dem Aufkommen von Smartphones und der damit einhergehenden Verbreitung mobiler Spiele und sogenannter Casual Games (einfache Spiele, die man bei Gelegenheit spielt) sind wir in einem Zeitalter angelangt, in dem viele verschiedene Spielegenres bedient werden. Wir klonen nicht mehr nur Quake. Bücher über Spiel-Engines helfen Ihnen nicht weiter, wenn Ihr Spiel nicht zur Engine passt.

Ich bemühe mich hier darum, die Themen eher wie auf einer Speisekarte zu präsentieren. Die einzelnen Kapitel im Buch beruhen auf jeweils unabhängigen Konzepten, die auf Ihren Code anwendbar sind. Auf diese Weise können Sie sie so zusammenstellen, wie es am besten zu dem Spiel passt, das Sie entwickeln möchten.

Jedes Buch über Programmierung, dessen Titel das Wort »Patterns« enthält, steht in einer gewissen Beziehung zu dem Klassiker Design Patterns: Entwurfsmuster als Elemente wiederverwendbarer objektorientierter Software von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides (die merkwürdigerweise als die »Gang of Four« bezeichnet werden).

Mit dem Titel Design Patterns für die Spieleprogrammierung will ich keineswegs sagen, dass die Design Patterns der Gang of Four nicht auf Spiele anwendbar sind. Im Gegenteil: Das Kapitel Design Patterns neu überdacht stellt viele der klassischen Design Patterns vor, legt den Schwerpunkt dabei aber gezielt auf deren Anwendung in der Spieleprogrammierung.

Umgekehrt denke ich, dass dieses Buch auch auf Software anwendbar ist, bei der es sich nicht um Spiele handelt. Ich hätte ebenso gut einen Titel wie Weitere Design Patterns wählen können, ich finde aber, dass Spiele oft besonders ansprechende Beispiele ermöglichen. Sie wollen doch nicht wirklich schon wieder ein Buch über Angestelltendatensätze und Bankkonten lesen, oder?

Die hier vorgestellten Patterns sind nicht nur für andere Software nützlich, sie sind meiner Ansicht nach auch besonders gut für Probleme geeignet, die bei der Spieleprogrammierung häufig auftreten:

Zeit und Abläufe sind oftmals das Kernstück einer Spielarchitektur. Vorgänge müssen in der richtigen Reihenfolge und zum richtigen Zeitpunkt stattfinden.

Die Entwicklungszyklen folgen oft eng aufeinander und die Programmierer müssen in der Lage sein, schnell neue Versionen mit vielen verschiedenen neuen Verhaltensweisen zu entwickeln, ohne sich dabei gegenseitig im Weg zu stehen oder überall in der Codebasis Spuren zu hinterlassen.

Wenn die Verhaltensweisen festgelegt sind, folgen die Interaktionen. Monster beißen den Helden, Zaubertränke werden angerührt und Bomben sprengen Freund und Feind in die Luft. Solche Interaktionen müssen stattfinden können, ohne dass die Codebasis zu einem verworrenen Knäuel wird.

Und zu guter Letzt kommt der Performance bei Spielen eine maßgebliche Bedeutung zu. Spieleentwickler befinden sich in einem dauerhaften Wettstreit, um herauszufinden, wer das meiste aus einer Plattform herausholen kann. Tricks und Kniffe, mit denen sich einige CPU-Takte einsparen lassen, können den Unterschied zwischen einem hervorragend bewerteten, millionenfach verkauften und einem von Bildaussetzern geprägten sowie genervten Spieletestern verrissenen Spiel bedeuten.

Das vorliegende Buch ist in drei größere Teile gegliedert. Der erste (I) besteht aus der Einführung, die Sie gerade lesen, und dem folgenden Kapitel 1.

Der zweite Teil (II), Design Patterns neu überdacht, stellt einige der Entwurfsmuster aus dem Buch der Gang of Four vor. Ich lege in den einzelnen Kapiteln meine Ansichten zu den einzelnen Patterns dar und beschreibe, wie sie sich auf die Spieleprogrammierung anwenden lassen.

Danach folgt der Hauptteil des Buches (III bis VI), in dem 13 Design Patterns präsentiert werden, die sich als nützlich erwiesen haben. Sie sind in vier Kategorien unterteilt: Sequenzierungsmuster (III, Sequencing Patterns), Verhaltensmuster (IV, Behavioral Patterns), Entkopplungsmuster (V, Decoupling Patterns) und Optimierungsmuster (VI, Optimization Patterns). Die dazugehörigen Patterns werden jeweils auf einheitliche Art und Weise beschrieben, damit Sie das Buch als Referenz verwenden können und schnell finden, was Sie suchen:

Der einleitende Abschnitt erläutert kurz und knapp die Zielsetzung des Design Patterns und beschreibt, für welche Problemstellungen es gedacht ist. Diese Informationen sollen es Ihnen ermöglichen, das Buch bei der Suche nach einem Pattern, das bei der Lösung eines Problems hilfreich wäre, schnell durchforsten zu können.

Der Abschnitt Motivation beschreibt ein Anwendungsbeispiel des Patterns. Im Gegensatz zu konkreten Algorithmen ist ein Pattern mehr oder weniger formlos, solange es nicht auf ein bestimmtes Problem angewendet wird. Ein Pattern ohne ein Beispiel zu erklären, käme einem Backkurs gleich, in dem der Teig keine Erwähnung findet. Dieser Abschnitt liefert sozusagen den Teig, der in den nachfolgenden Abschnitten gebacken wird.

Der Abschnitt Das Pattern fasst die wesentlichen Charakteristiken und Eigenschaften des im vorausgegangenen Beispiel dargestellten Entwurfsmusters zusammen. Wenn Sie eine trockene, lehrbuchhafte Beschreibung des Patterns suchen, werden Sie hier fündig. Dieser Abschnitt kann auch zur Wissensauffrischung dienen, wenn Ihnen der Gebrauch eines Patterns schon geläufig ist und Sie sich vergewissern möchten, dass Sie nichts vergessen haben.

Bisher wurde das Pattern nur anhand eines einzigen Beispiels erläutert. Wie aber können Sie feststellen, ob es für Ihr Problem geeignet ist? Der Abschnitt Anwendbarkeit enthält einige Richtlinien dazu, wann die Verwendung des Patterns sinnvoll ist und wann man besser darauf verzichten sollte.

Der Abschnitt Konsequenzen weist auf mögliche Risiken bei der Anwendung des Patterns hin.

Wenn es Ihnen wie mir geht und Sie ein konkretes Beispiel brauchen, um etwas wirklich zu begreifen, sind Sie im Abschnitt Beispielcode richtig. Hier finden Sie eine schrittweise Implementierung des Patterns, damit Sie genau nachvollziehen können, wie es funktioniert.

Patterns unterscheiden sich von Algorithmen dadurch, dass sie ergebnisoffen sind. Wenn Sie ein Pattern mehrmals verwenden, werden Sie es vermutlich jedes Mal anders implementieren. Der Abschnitt Designentscheidungen geht dem auf den Grund und zeigt verschiedene Möglichkeiten bei der Anwendung des Patterns auf.

Und zum Abschluss wird in einem kurzen Abschnitt Siehe auch ... erklärt, in welcher Beziehung das Pattern zu anderen Patterns steht. Außerdem finden Sie hier Hinweise auf Open-Source-Code, der das Pattern in der Praxis einsetzt.

Die Codebeispiele in diesem Buch sind in C++ geschrieben, das heißt jedoch nicht, dass die Design Patterns nur in dieser Programmiersprache nützlich sind oder dass C++ besonders gut dafür geeignet wäre. Fast alle Programmiersprachen sind geeignet, allerdings setzen einige Patterns das Vorhandensein von Objekten und Klassen voraus.

Ich habe aus verschiedenen Gründen C++ gewählt. Zunächst einmal handelt es sich hierbei um die bei kommerziell vertriebenen Spielen verbreitetste Programmiersprache. C++ ist sozusagen die Lingua franca der Spielebranche. Außerdem bildet die C-Syntax,​ auf der C++ beruht, auch die Grundlage für Java, C#, JavaScript und viele andere Programmiersprachen. Selbst wenn Sie sich nicht mit C++ auskennen, stehen die Chancen daher nicht schlecht, dass Sie den Beispielcode mit ein klein wenig Mühe verstehen können.

Es ist nicht das Ziel dieses Buches, Sie C++ zu lehren. Die Beispiele sind so einfach wie möglich gehalten und sollen weder guten Programmierstil noch eine besondere Verwendungsart darstellen. Denken Sie beim Betrachten des Codes an das dahinterstehende Konzept, nicht an den Code, der es formuliert.

Der Code wurde insbesondere nicht im »modernen« Stil (C++11 oder neuer) verfasst. Die Standardbibliothek wird nicht verwendet und Templates nur selten. Der C++-Code ist zwar nicht besonders elegant, aber er ist kompakt und ich hoffe, dass er auf diese Weise für Leute, die Erfahrung mit C, Objective-C, Java oder anderen Sprachen haben, leichter verständlich ist.

Um Platz zu sparen, werde ich in den Beispielen hin und wieder Code weglassen, wenn Sie ihn schon kennen oder er für ein Pattern nicht relevant ist. Diese Stellen sind durch Auslassungspunkte gekennzeichnet.

Betrachten Sie beispielsweise eine Funktion, die bestimmte Aufgaben erledigt und dann einen Rückgabewert liefert. Für das Pattern ist nur der Rückgabewert von Bedeutung, nicht die Erledigung der Aufgaben. Der Beispielcode sieht dann folgendermaßen aus:

bool update()
{
  // Aufgaben erledigen ...
  return isDone();
}

Patterns sind ein Bestandteil der Softwareentwicklung, der einem ständigen Wandel und kontinuierlichen Erweiterungen unterliegt. Dieses Buch möchte den von der Gang of Four angestoßenen Prozess fortsetzen, die bislang entdeckten Patterns zu dokumentieren und mit anderen zu teilen. Und natürlich ist dieses Vorhaben mit dem vorliegenden Buch noch lange nicht abgeschlossen!

Sie selbst sind ebenfalls Teil dieses Prozesses. Wenn Sie Ihre eigenen Patterns entwickeln und die im Buch vorgestellten optimieren (oder sie ablehnen!), erweisen Sie der Community der Softwareentwickler ebenfalls einen Dienst. Sollten Sie Vorschläge haben, Fehler entdecken oder anderweitiges Feedback geben wollen, melden Sie sich bitte!