Design Patterns für die Spieleprogrammierung

1 - Cover [Seite 1]
2 - Titel [Seite 3]
3 - Impressum [Seite 4]
4 - Inhaltsverzeichnis [Seite 7]
5 - Danksagungen [Seite 17]
6 - Teil I: Einführung [Seite 19]
6.1 - Kapitel 1: Architektur, Performance und Spiele [Seite 27]
6.1.1 - 1.1 Was ist Softwarearchitektur? [Seite 27]
6.1.1.1 - 1.1.1 Was zeichnet eine gute Softwarearchitektur aus? [Seite 28]
6.1.1.2 - 1.1.2 Wie nimmt man Änderungen vor? [Seite 28]
6.1.1.3 - 1.1.3 Inwiefern hilft eine Entkopplung? [Seite 30]
6.1.2 - 1.2 Zu welchem Preis? [Seite 30]
6.1.3 - 1.3 Performance und Geschwindigkeit [Seite 32]
6.1.4 - 1.4 Das Gute an schlechtem Code [Seite 33]
6.1.5 - 1.5 Ein ausgewogenes Verhältnis finden [Seite 34]
6.1.6 - 1.6 Einfachheit [Seite 35]
6.1.7 - 1.7 Fang endlich an! [Seite 37]
7 - Teil II: Design Patternsneu überdacht [Seite 39]
7.1 - Kapitel 2: Command (Befehl) [Seite 41]
7.1.1 - 2.1 Eingabekonfiguration [Seite 42]
7.1.2 - 2.2 Regieanweisungen [Seite 45]
7.1.3 - 2.3 Rückgängig und Wiederholen [Seite 47]
7.1.4 - 2.4 Klassen ohne Funktionen? [Seite 51]
7.1.5 - 2.5 Siehe auch ... [Seite 53]
7.2 - Kapitel 3: Flyweight (Fliegengewicht) [Seite 55]
7.2.1 - 3.1 Den Wald vor lauter Bäumen nicht sehen [Seite 55]
7.2.2 - 3.2 Tausend Instanzen [Seite 58]
7.2.3 - 3.3 Das Flyweight-Pattern [Seite 58]
7.2.4 - 3.4 Ein Ort, um Wurzeln zu schlagen [Seite 59]
7.2.5 - 3.5 Und die Performance? [Seite 64]
7.2.6 - 3.6 Siehe auch ... [Seite 65]
7.3 - Kapitel 4: Observer (Beobachter) [Seite 67]
7.3.1 - 4.1 Erzielte Leistungen [Seite 67]
7.3.2 - 4.2 Funktionsweise [Seite 69]
7.3.2.1 - 4.2.1 Der Observer [Seite 69]
7.3.2.2 - 4.2.2 Das Subjekt [Seite 70]
7.3.2.3 - 4.2.3 Beobachtung der Physik-Engine [Seite 72]
7.3.3 - 4.3 »Das ist zu langsam!« [Seite 73]
7.3.3.1 - 4.3.1 Oder ist es doch zu schnell? [Seite 74]
7.3.4 - 4.4 »Zu viele dynamische Allokationen« [Seite 74]
7.3.4.1 - 4.4.1 Verkettete Observer [Seite 75]
7.3.4.2 - 4.4.2 Ein Pool von Listenknoten [Seite 79]
7.3.5 - 4.5 Verbleibende Schwierigkeiten [Seite 79]
7.3.5.1 - 4.5.1 Subjekte und Observer löschen [Seite 80]
7.3.5.2 - 4.5.2 Keine Sorge, der Garbage Collector erledigt das schon [Seite 81]
7.3.5.3 - 4.5.3 Was geht hier vor? [Seite 82]
7.3.6 - 4.6 Heutige Observer [Seite 83]
7.3.7 - 4.7 Zukünftige Observer [Seite 84]
7.4 - Kapitel 5: Prototype (Prototyp) [Seite 87]
7.4.1 - 5.1 Das Design Pattern Prototype [Seite 87]
7.4.1.1 - 5.1.1 Wie gut funktioniert es? [Seite 91]
7.4.1.2 - 5.1.2 Spawn-Funktionen [Seite 91]
7.4.1.3 - 5.1.3 Templates [Seite 92]
7.4.1.4 - 5.1.4 First-Class-Typen [Seite 93]
7.4.2 - 5.2 Eine auf Prototypen beruhende Sprache [Seite 93]
7.4.2.1 - 5.2.1 Self [Seite 93]
7.4.2.2 - 5.2.2 Wie ist es gelaufen? [Seite 96]
7.4.2.3 - 5.2.3 Was ist mit JavaScript? [Seite 97]
7.4.3 - 5.3 Prototypen zur Datenmodellierung [Seite 99]
7.5 - Kapitel 6: Singleton [Seite 103]
7.5.1 - 6.1 Das Singleton-Pattern [Seite 103]
7.5.1.1 - 6.1.1 Beschränkung einer Klasse auf eine Instanz [Seite 103]
7.5.1.2 - 6.1.2 Bereitstellung eines globalen Zugriffspunkts [Seite 104]
7.5.2 - 6.2 Gründe für die Verwendung [Seite 105]
7.5.3 - 6.3 Gründe, die Verwendung zu bereuen [Seite 107]
7.5.3.1 - 6.3.1 Singletons sind globale Variablen [Seite 108]
7.5.3.2 - 6.3.2 Das Pattern löst zwei Probleme, selbst wenn es nur eins gibt [Seite 109]
7.5.3.3 - 6.3.3 Die späte Initialisierung entzieht Ihnen die Kontrolle [Seite 110]
7.5.4 - 6.4 Verzicht auf Singletons [Seite 112]
7.5.4.1 - 6.4.1 Wird die Klasse überhaupt benötigt? [Seite 112]
7.5.4.2 - 6.4.2 Nur eine Instanz einer Klasse [Seite 114]
7.5.4.3 - 6.4.3 Bequemer Zugriff auf eine Instanz [Seite 115]
7.5.5 - 6.5 Was bleibt dem Singleton? [Seite 118]
7.6 - Kapitel 7: State (Zustand) [Seite 119]
7.6.1 - 7.1 Altbekanntes [Seite 119]
7.6.2 - 7.2 Zustandsautomaten erledigen das [Seite 123]
7.6.3 - 7.3 Enumerationen und Switch-Anweisungen [Seite 124]
7.6.4 - 7.4 Das State-Pattern [Seite 127]
7.6.4.1 - 7.4.1 Das Interface für den Zustand [Seite 128]
7.6.4.2 - 7.4.2 Klassen für alle Zustände [Seite 128]
7.6.4.3 - 7.4.3 An den Zustand delegieren [Seite 129]
7.6.5 - 7.5 Wo sind die Zustandsobjekte? [Seite 130]
7.6.5.1 - 7.5.1 Statische Zustände [Seite 130]
7.6.5.2 - 7.5.2 Instanziierte Zustandsobjekte [Seite 131]
7.6.6 - 7.6 Eintritts- und Austrittsaktionen [Seite 132]
7.6.7 - 7.7 Wo ist der Haken? [Seite 134]
7.6.8 - 7.8 Nebenläufige Zustandsautomaten [Seite 134]
7.6.9 - 7.9 Hierarchische Zustandsautomaten [Seite 136]
7.6.10 - 7.10 Kellerautomaten [Seite 138]
7.6.11 - 7.11 Wie nützlich sind sie? [Seite 139]
8 - Teil III: Sequenzierungsmuster (Sequencing Patterns) [Seite 141]
8.1 - Kapitel 8: Double Buffer (Doppelter Buffer) [Seite 143]
8.1.1 - 8.1 Motivation [Seite 143]
8.1.1.1 - 8.1.1 Computergrafik kurz und bündig [Seite 143]
8.1.1.2 - 8.1.2 Erster Akt, erste Szene [Seite 145]
8.1.1.3 - 8.1.3 Zurück zur Grafik [Seite 146]
8.1.2 - 8.2 Das Pattern [Seite 146]
8.1.3 - 8.3 Anwendbarkeit [Seite 147]
8.1.4 - 8.4 Konsequenzen [Seite 147]
8.1.4.1 - 8.4.1 Der Austausch selbst kostet Zeit [Seite 147]
8.1.4.2 - 8.4.2 Zwei Framebuffer belegen mehr Arbeitsspeicher [Seite 147]
8.1.5 - 8.5 Beispielcode [Seite 148]
8.1.5.1 - 8.5.1 Nicht nur Grafik [Seite 151]
8.1.5.2 - 8.5.2 Künstliche Unintelligenz [Seite 151]
8.1.5.3 - 8.5.3 Gebufferte Ohrfeigen [Seite 155]
8.1.6 - 8.6 Designentscheidungen [Seite 156]
8.1.6.1 - 8.6.1 Wie werden die Buffer ausgetauscht? [Seite 157]
8.1.6.2 - 8.6.2 Wie fein ist der Buffer untergliedert? [Seite 158]
8.1.7 - 8.7 Siehe auch ... [Seite 159]
8.2 - Kapitel 9: Game Loop (Hauptschleife) [Seite 161]
8.2.1 - 9.1 Motivation [Seite 161]
8.2.1.1 - 9.1.1 Interview mit einer CPU [Seite 161]
8.2.1.2 - 9.1.2 Ereignisschleifen [Seite 162]
8.2.1.3 - 9.1.3 Eine aus dem Takt geratene Welt [Seite 163]
8.2.1.4 - 9.1.4 Sekunden pro Sekunde [Seite 164]
8.2.2 - 9.2 Das Pattern [Seite 164]
8.2.3 - 9.3 Anwendbarkeit [Seite 164]
8.2.4 - 9.4 Konsequenzen [Seite 165]
8.2.4.1 - 9.4.1 Abstimmung mit der Ereignisschleife des Betriebssystems [Seite 165]
8.2.5 - 9.5 Beispielcode [Seite 166]
8.2.5.1 - 9.5.1 Die Beine in die Hand nehmen [Seite 166]
8.2.5.2 - 9.5.2 Ein kleines Nickerchen [Seite 166]
8.2.5.3 - 9.5.3 Ein kleiner und ein großer Schritt [Seite 167]
8.2.5.4 - 9.5.4 Aufholjagd [Seite 169]
8.2.5.5 - 9.5.5 In der Mitte hängen geblieben [Seite 171]
8.2.6 - 9.6 Designentscheidungen [Seite 173]
8.2.6.1 - 9.6.1 Stammt die Game Loop aus Ihrer Feder oder benutzen Sie die der Plattform? [Seite 173]
8.2.6.2 - 9.6.2 Wie handhaben Sie die Leistungsaufnahme? [Seite 174]
8.2.6.3 - 9.6.3 Wie steuern Sie die Spielgeschwindigkeit? [Seite 175]
8.2.7 - 9.7 Siehe auch ... [Seite 176]
8.3 - Kapitel 10: Update Method (Aktualisierungsmethode) [Seite 177]
8.3.1 - 10.1 Motivation [Seite 177]
8.3.2 - 10.2 Das Pattern [Seite 180]
8.3.3 - 10.3 Anwendbarkeit [Seite 180]
8.3.4 - 10.4 Konsequenzen [Seite 181]
8.3.4.1 - 10.4.1 Verkomplizierung durch Aufteilen des Codes in einzelne Frames [Seite 181]
8.3.4.2 - 10.4.2 Der Zustand muss gespeichert werden, um im nächsten Frame fortfahren zu können [Seite 181]
8.3.4.3 - 10.4.3 Alle Objekte simulieren jeden Frame, aber nicht wirklich exakt gleichzeitig [Seite 182]
8.3.4.4 - 10.4.4 Obacht bei der Modifizierung der Objektliste während der Aktualisierung [Seite 182]
8.3.5 - 10.5 Beispielcode [Seite 184]
8.3.5.1 - 10.5.1 Entity-Unterklassen? [Seite 186]
8.3.5.2 - 10.5.2 Entities definieren [Seite 186]
8.3.5.3 - 10.5.3 Zeitablauf [Seite 189]
8.3.6 - 10.6 Designentscheidungen [Seite 190]
8.3.6.1 - 10.6.1 Zu welcher Klasse gehört die update()-Methode? [Seite 190]
8.3.6.2 - 10.6.2 Wie werden inaktive Objekte gehandhabt? [Seite 191]
8.3.7 - 10.7 Siehe auch ... [Seite 192]
9 - Teil IV: Verhaltensmuster (Behavioral Patterns) [Seite 193]
9.1 - Kapitel 11: Bytecode [Seite 195]
9.1.1 - 11.1 Motivation [Seite 195]
9.1.1.1 - 11.1.1 Wettkampf der Zaubersprüche [Seite 196]
9.1.1.2 - 11.1.2 Daten > Code [Seite 196]
9.1.1.3 - 11.1.3 Das Interpreter-Pattern [Seite 196]
9.1.1.4 - 11.1.4 Faktisch Maschinencode [Seite 200]
9.1.2 - 11.2 Das Pattern [Seite 201]
9.1.3 - 11.3 Anwendbarkeit [Seite 201]
9.1.4 - 11.4 Konsequenzen [Seite 201]
9.1.4.1 - 11.4.1 Befehlsformat [Seite 202]
9.1.4.2 - 11.4.2 Fehlender Debugger [Seite 203]
9.1.5 - 11.5 Beispielcode [Seite 203]
9.1.5.1 - 11.5.1 Eine zauberhafte API [Seite 203]
9.1.5.2 - 11.5.2 Ein bezaubernder Befehlssatz [Seite 204]
9.1.5.3 - 11.5.3 Eine Stackmaschine [Seite 206]
9.1.5.4 - 11.5.4 Verhalten = Komposition [Seite 209]
9.1.5.5 - 11.5.5 Eine virtuelle Maschine [Seite 212]
9.1.5.6 - 11.5.6 Hexerwerkzeuge [Seite 213]
9.1.6 - 11.6 Designentscheidungen [Seite 215]
9.1.6.1 - 11.6.1 Wie greifen Befehle auf den Stack zu? [Seite 215]
9.1.6.2 - 11.6.2 Welche Befehle gibt es? [Seite 216]
9.1.6.3 - 11.6.3 Wie werden Werte repräsentiert? [Seite 217]
9.1.6.4 - 11.6.4 Wie wird der Bytecode erzeugt? [Seite 220]
9.1.7 - 11.7 Siehe auch ... [Seite 222]
9.2 - Kapitel 12: Subclass Sandbox (Unterklassen-Sandbox) [Seite 223]
9.2.1 - 12.1 Motivation [Seite 223]
9.2.2 - 12.2 Das Pattern [Seite 225]
9.2.3 - 12.3 Anwendbarkeit [Seite 226]
9.2.4 - 12.4 Konsequenzen [Seite 226]
9.2.5 - 12.5 Beispielcode [Seite 226]
9.2.6 - 12.6 Designentscheidungen [Seite 229]
9.2.6.1 - 12.6.1 Welche Operationen sollen bereitgestellt werden? [Seite 229]
9.2.6.2 - 12.6.2 Sollen Methoden direkt oder durch Objekte, die sie enthalten, bereitgestellt werden? [Seite 231]
9.2.6.3 - 12.6.3 Wie gelangt die Basisklasse an die benötigten Zustände? [Seite 232]
9.2.7 - 12.7 Siehe auch ... [Seite 236]
9.3 - Kapitel 13: Type Object (Typ-Objekt) [Seite 237]
9.3.1 - 13.1 Motivation [Seite 237]
9.3.1.1 - 13.1.1 Die typische OOP-Lösung [Seite 237]
9.3.1.2 - 13.1.2 Eine Klasse für eine Klasse [Seite 239]
9.3.2 - 13.2 Das Pattern [Seite 241]
9.3.3 - 13.3 Anwendbarkeit [Seite 241]
9.3.4 - 13.4 Konsequenzen [Seite 242]
9.3.4.1 - 13.4.1 Typ-Objekte müssen manuell gehandhabt werden [Seite 242]
9.3.4.2 - 13.4.2 Die Definition des Verhaltens der verschiedenen Typen ist schwieriger [Seite 242]
9.3.5 - 13.5 Beispielcode [Seite 243]
9.3.5.1 - 13.5.1 Typartiges Verhalten von Typ-Objekten: Konstruktoren [Seite 245]
9.3.5.2 - 13.5.2 Gemeinsame Nutzung von Daten durch Vererbung [Seite 246]
9.3.6 - 13.6 Designentscheidungen [Seite 250]
9.3.6.1 - 13.6.1 Ist das Typ-Objekt gekapselt oder zugänglich? [Seite 250]
9.3.6.2 - 13.6.2 Wie werden Typ-Objekte erzeugt? [Seite 251]
9.3.6.3 - 13.6.3 Kann sich der Typ ändern? [Seite 252]
9.3.6.4 - 13.6.4 Welche Formen der Vererbung werden unterstützt? [Seite 253]
9.3.7 - 13.7 Siehe auch ... [Seite 254]
10 - Teil V: Entkopplungsmuster (Decoupling Patterns) [Seite 255]
10.1 - Kapitel 14: Component (Komponente) [Seite 257]
10.1.1 - 14.1 Motivation [Seite 257]
10.1.1.1 - 14.1.1 Der Gordische Knoten [Seite 258]
10.1.1.2 - 14.1.2 Den Knoten durchschlagen [Seite 258]
10.1.1.3 - 14.1.3 Unerledigtes [Seite 259]
10.1.1.4 - 14.1.4 Wiederverwendung [Seite 259]
10.1.2 - 14.2 Das Pattern [Seite 261]
10.1.3 - 14.3 Anwendbarkeit [Seite 261]
10.1.4 - 14.4 Konsequenzen [Seite 262]
10.1.5 - 14.5 Beispielcode [Seite 262]
10.1.5.1 - 14.5.1 Eine monolithische Klasse [Seite 263]
10.1.5.2 - 14.5.2 Abspalten eines Bereichs [Seite 264]
10.1.5.3 - 14.5.3 Abspalten der übrigen Bereiche [Seite 266]
10.1.5.4 - 14.5.4 Robo-Bjørn [Seite 268]
10.1.5.5 - 14.5.5 Ganz ohne Bjørn? [Seite 270]
10.1.6 - 14.6 Designentscheidungen [Seite 272]
10.1.6.1 - 14.6.1 Wie gelangt ein Objekt an seine Komponenten? [Seite 273]
10.1.6.2 - 14.6.2 Wie kommunizieren die Komponenten untereinander? [Seite 273]
10.1.7 - 14.7 Siehe auch ... [Seite 277]
10.2 - Kapitel 15: Event Queue (Ereigniswarteschlange) [Seite 279]
10.2.1 - 15.1 Motivation [Seite 279]
10.2.1.1 - 15.1.1 Ereignisschleife der grafischen Benutzeroberfläche [Seite 279]
10.2.1.2 - 15.1.2 Zentrale Ereignissammlung [Seite 280]
10.2.1.3 - 15.1.3 Wie bitte? [Seite 281]
10.2.2 - 15.2 Das Pattern [Seite 284]
10.2.3 - 15.3 Anwendbarkeit [Seite 284]
10.2.4 - 15.4 Konsequenzen [Seite 285]
10.2.4.1 - 15.4.1 Eine zentrale Ereigniswarteschlange ist eine globale Variable [Seite 285]
10.2.4.2 - 15.4.2 Den Boden unter den Füßen verlieren [Seite 285]
10.2.4.3 - 15.4.3 Steckenbleiben in Rückkopplungsschleifen [Seite 286]
10.2.5 - 15.5 Beispielcode [Seite 286]
10.2.5.1 - 15.5.1 Ein Ring-Buffer [Seite 289]
10.2.5.2 - 15.5.2 Anfragen zusammenfassen [Seite 293]
10.2.5.3 - 15.5.3 Threads [Seite 294]
10.2.6 - 15.6 Designentscheidungen [Seite 295]
10.2.6.1 - 15.6.1 Was soll in die Warteschlange aufgenommen werden? [Seite 295]
10.2.6.2 - 15.6.2 Wer darf lesend auf die Warteschlange zugreifen? [Seite 296]
10.2.6.3 - 15.6.3 Wer darf schreibend auf die Warteschlange zugreifen? [Seite 298]
10.2.6.4 - 15.6.4 Wie lang ist die Lebensdauer der Objekte in der Warteschlange? [Seite 299]
10.2.7 - 15.7 Siehe auch ... [Seite 300]
10.3 - Kapitel 16: Service Locator (Dienstlokalisierung) [Seite 301]
10.3.1 - 16.1 Motivation [Seite 301]
10.3.2 - 16.2 Das Pattern [Seite 302]
10.3.3 - 16.3 Anwendbarkeit [Seite 302]
10.3.4 - 16.4 Konsequenzen [Seite 303]
10.3.4.1 - 16.4.1 Der Dienst muss auch tatsächlich lokalisiert werden können [Seite 303]
10.3.4.2 - 16.4.2 Dem Dienst ist nicht bekannt, wer ihn nutzt [Seite 303]
10.3.5 - 16.5 Beispielcode [Seite 304]
10.3.5.1 - 16.5.1 Der Dienst [Seite 304]
10.3.5.2 - 16.5.2 Der Dienstanbieter [Seite 304]
10.3.5.3 - 16.5.3 Ein einfacher Service Locator [Seite 305]
10.3.5.4 - 16.5.4 Ein leerer Dienst [Seite 306]
10.3.5.5 - 16.5.5 Protokollierender Dekorierer [Seite 308]
10.3.6 - 16.6 Designentscheidungen [Seite 310]
10.3.6.1 - 16.6.1 Wie wird der Dienst lokalisiert? [Seite 310]
10.3.6.2 - 16.6.2 Was geschieht, wenn die Lokalisierung des Dienstes scheitert? [Seite 312]
10.3.6.3 - 16.6.3 Wer darf auf den Dienst zugreifen? [Seite 315]
10.3.7 - 16.7 Siehe auch ... [Seite 316]
11 - Teil VI: Optimierungsmuster (Optimization Patterns) [Seite 317]
11.1 - Kapitel 17: Data Locality (Datenlokalität) [Seite 319]
11.1.1 - 17.1 Motivation [Seite 319]
11.1.1.1 - 17.1.1 Ein Datenlager [Seite 320]
11.1.1.2 - 17.1.2 Eine Palette für die CPU [Seite 322]
11.1.1.3 - 17.1.3 Daten = Performance? [Seite 323]
11.1.2 - 17.2 Das Pattern [Seite 324]
11.1.3 - 17.3 Anwendbarkeit [Seite 325]
11.1.4 - 17.4 Konsequenzen [Seite 325]
11.1.5 - 17.5 Beispielcode [Seite 326]
11.1.5.1 - 17.5.1 Aneinandergereihte Arrays [Seite 326]
11.1.5.2 - 17.5.2 Gebündelte Daten [Seite 331]
11.1.5.3 - 17.5.3 Hot/Cold Splitting [Seite 335]
11.1.6 - 17.6 Designentscheidungen [Seite 337]
11.1.6.1 - 17.6.1 Wie wird Polymorphismus gehandhabt? [Seite 338]
11.1.6.2 - 17.6.2 Wie werden Spielobjekte definiert? [Seite 339]
11.1.7 - 17.7 Siehe auch ... [Seite 342]
11.2 - Kapitel 18: Dirty Flag (Veraltet-Flag) [Seite 345]
11.2.1 - 18.1 Motivation [Seite 345]
11.2.1.1 - 18.1.1 Lokale Koordinaten und Weltkoordinaten [Seite 346]
11.2.1.2 - 18.1.2 Gecachete Weltkoordinaten [Seite 347]
11.2.1.3 - 18.1.3 Verzögerte Berechnung [Seite 348]
11.2.2 - 18.2 Das Pattern [Seite 350]
11.2.3 - 18.3 Anwendbarkeit [Seite 350]
11.2.4 - 18.4 Konsequenzen [Seite 351]
11.2.4.1 - 18.4.1 Nicht zu lange verzögern [Seite 351]
11.2.4.2 - 18.4.2 Das Flag bei jedem Zustandswechsel ändern [Seite 352]
11.2.4.3 - 18.4.3 Vorherige abgeleitete Daten verbleiben im Speicher [Seite 352]
11.2.5 - 18.5 Beispielcode [Seite 353]
11.2.5.1 - 18.5.1 Nicht-optimierte Traversierung [Seite 354]
11.2.5.2 - 18.5.2 Let's Get Dirty [Seite 355]
11.2.6 - 18.6 Designentscheidungen [Seite 358]
11.2.6.1 - 18.6.1 Wann wird das Dirty Flag gelöscht? [Seite 358]
11.2.6.2 - 18.6.2 Wie feingranular ist Ihr »Dirty-Tracking«? [Seite 359]
11.2.7 - 18.7 Siehe auch ... [Seite 360]
11.3 - Kapitel 19: Object Pool (Objektpool) [Seite 361]
11.3.1 - 19.1 Motivation [Seite 361]
11.3.1.1 - 19.1.1 Der Fluch der Fragmentierung [Seite 361]
11.3.1.2 - 19.1.2 Das Beste beider Welten [Seite 362]
11.3.2 - 19.2 Das Pattern [Seite 363]
11.3.3 - 19.3 Anwendbarkeit [Seite 363]
11.3.4 - 19.4 Konsequenzen [Seite 363]
11.3.4.1 - 19.4.1 Der Pool verschwendet möglicherweise Speicherplatz für ungenutzte Objekte [Seite 363]
11.3.4.2 - 19.4.2 Es steht nur eine feste Anzahl von Objekten zur Verfügung [Seite 364]
11.3.4.3 - 19.4.3 Die Objekte sind von fester Größe [Seite 365]
11.3.4.4 - 19.4.4 Wiederverwendete Objekte werden nicht automatisch zurückgesetzt [Seite 365]
11.3.4.5 - 19.4.5 Unbenutzte Objekte verbleiben im Arbeitsspeicher [Seite 366]
11.3.5 - 19.5 Beispielcode [Seite 366]
11.3.5.1 - 19.5.1 Eine kostenlose Liste [Seite 369]
11.3.6 - 19.6 Designentscheidungen [Seite 372]
11.3.6.1 - 19.6.1 Sind Objekte an den Pool gekoppelt? [Seite 372]
11.3.6.2 - 19.6.2 Wer ist für die Initialisierung der wiederverwendeten Objekte verantwortlich? [Seite 374]
11.3.7 - 19.7 Siehe auch ... [Seite 376]
11.4 - Kapitel 20: Spatial Partition (Räumliche Aufteilung) [Seite 377]
11.4.1 - 20.1 Motivation [Seite 377]
11.4.1.1 - 20.1.1 Kampfeinheiten auf dem Schlachtfeld [Seite 377]
11.4.1.2 - 20.1.2 Schlachtreihen zeichnen [Seite 378]
11.4.2 - 20.2 Das Pattern [Seite 379]
11.4.3 - 20.3 Anwendbarkeit [Seite 379]
11.4.4 - 20.4 Konsequenzen [Seite 379]
11.4.5 - 20.5 Beispielcode [Seite 380]
11.4.5.1 - 20.5.1 Ein Bogen Millimeterpapier [Seite 380]
11.4.5.2 - 20.5.2 Ein Gitternetz verketteter Einheiten [Seite 381]
11.4.5.3 - 20.5.3 Betreten des Schlachtfeldes [Seite 383]
11.4.5.4 - 20.5.4 Klirrende Schwerter [Seite 384]
11.4.5.5 - 20.5.5 Vormarschieren [Seite 385]
11.4.5.6 - 20.5.6 Um Armeslänge [Seite 386]
11.4.6 - 20.6 Designentscheidungen [Seite 390]
11.4.6.1 - 20.6.1 Ist die Aufteilung hierarchisch oder gleichmäßig? [Seite 390]
11.4.6.2 - 20.6.2 Hängt die Zellengröße von der Verteilung der Objekte ab? [Seite 391]
11.4.6.3 - 20.6.3 Werden die Objekte nur in den Zellen gespeichert? [Seite 393]
11.4.7 - 20.7 Siehe auch ... [Seite 394]
12 - Stichwortverzeichnis [Seite 395]