Nystrom Design Patterns für die Spieleprogrammierung

1. Auflage 2015
ISBN: 978-3-95845-091-2
Verlag: mitp Verlags GmbH & Co.KG
Format: PDF
Kopierschutz: 0 - No protection

E-Book, Deutsch, 400 Seiten

Reihe: mitp Professional

Die größte Herausforderung bei der Entwicklung von Spielen ist die Komplexität der Software. Der Autor stellt in diesem Buch bewährte Patterns zusammen, die er über Jahre bei der Spieleprogrammierung zusammengestellt und eingesetzt hat. Die Patterns sind in Form unabhängiger Rezepte organisiert. Dabei werden die wichtigsten Probleme berücksichtigt wie z.B. das Schreiben einer stabilen Game Loop oder wie man den CPU-Chae nutzt, umd die Performance zu steigern. Außerdem erfahren Sie, wie man die klassischen Deisgn Patterns in Spielen einsetzen lassen.

Zielgruppe

Alle Spieleprogrammierer

Autoren/Hrsg.

Nystrom, Robert

Inhaltsverzeichnis

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

Über Autor(innen)

Robert Nystrom arbeitet seit acht Jahren bei Electronic Arts, der weltweit führenden Firma auf dem Gebiet der digitalen interaktiven Unterhaltung. Das Unternehmen ist bekannt für Blockbuster-Marken wie Die Sims, Madden NFL, Battlefield und Dragon Age.