Design patterns für die spieleprogrammierung

Die bekannten Design Patterns der Gang of Four im konkreten Einsatz für die Entwicklung von Games Zahlreiche weitere vom Autor entwickelte Patterns Sequenzierungs-, Verhaltens-, Entkopplungs- und Optimierungsmuster Für viele Spieleprogrammierer stellt die Finalisierung ihres Spiels die größte Heraus...

Descripción completa

Detalles Bibliográficos
Otros Autores:	Nystrom, Robert, author (author), Lorenzen, Knut, translator (translator)
Formato:	Libro electrónico
Idioma:	Alemán
Publicado:	[Wachtendonk, Germany] : MITP Verlag 2015.
Edición:	1. Auflage
Colección:	mitp Professional
Materias:	Computer games > Programming.
Ver en Biblioteca Universitat Ramon Llull:	https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009630308706719

Tabla de Contenidos:

Cover
Titel
Impressum
Inhaltsverzeichnis
Danksagungen
Teil I: Einführung
Kapitel 1: Architektur, Performance und Spiele
1.1 Was ist Softwarearchitektur?
1.1.1 Was zeichnet eine gute Softwarearchitektur aus?
1.1.2 Wie nimmt man Änderungen vor?
1.1.3 Inwiefern hilft eine Entkopplung?
1.2 Zu welchem Preis?
1.3 Performance und Geschwindigkeit
1.4 Das Gute an schlechtem Code
1.5 Ein ausgewogenes Verhältnis finden
1.6 Einfachheit
1.7 Fang endlich an!
Teil II: Design Patternsneu überdacht
Kapitel 2: Command (Befehl)
2.1 Eingabekonfiguration
2.2 Regieanweisungen
2.3 Rückgängig und Wiederholen
2.4 Klassen ohne Funktionen?
2.5 Siehe auch ...
Kapitel 3: Flyweight (Fliegengewicht)
3.1 Den Wald vor lauter Bäumen nicht sehen
3.2 Tausend Instanzen
3.3 Das Flyweight-Pattern
3.4 Ein Ort, um Wurzeln zu schlagen
3.5 Und die Performance?
3.6 Siehe auch ...
Kapitel 4: Observer (Beobachter)
4.1 Erzielte Leistungen
4.2 Funktionsweise
4.2.1 Der Observer
4.2.2 Das Subjekt
4.2.3 Beobachtung der Physik-Engine
4.3 »Das ist zu langsam!«
4.3.1 Oder ist es doch zu schnell?
4.4 »Zu viele dynamische Allokationen«
4.4.1 Verkettete Observer
4.4.2 Ein Pool von Listenknoten
4.5 Verbleibende Schwierigkeiten
4.5.1 Subjekte und Observer löschen
4.5.2 Keine Sorge, der Garbage Collector erledigt das schon
4.5.3 Was geht hier vor?
4.6 Heutige Observer
4.7 Zukünftige Observer
Kapitel 5: Prototype (Prototyp)
5.1 Das Design Pattern Prototype
5.1.1 Wie gut funktioniert es?
5.1.2 Spawn-Funktionen
5.1.3 Templates
5.1.4 First-Class-Typen
5.2 Eine auf Prototypen beruhende Sprache
5.2.1 Self
5.2.2 Wie ist es gelaufen?
5.2.3 Was ist mit JavaScript?
5.3 Prototypen zur Datenmodellierung
Kapitel 6: Singleton.
6.1 Das Singleton-Pattern
6.1.1 Beschränkung einer Klasse auf eine Instanz
6.1.2 Bereitstellung eines globalen Zugriffspunkts
6.2 Gründe für die Verwendung
6.3 Gründe, die Verwendung zu bereuen
6.3.1 Singletons sind globale Variablen
6.3.2 Das Pattern löst zwei Probleme, selbst wenn es nur eins gibt
6.3.3 Die späte Initialisierung entzieht Ihnen die Kontrolle
6.4 Verzicht auf Singletons
6.4.1 Wird die Klasse überhaupt benötigt?
6.4.2 Nur eine Instanz einer Klasse
6.4.3 Bequemer Zugriff auf eine Instanz
6.5 Was bleibt dem Singleton?
Kapitel 7: State (Zustand)
7.1 Altbekanntes
7.2 Zustandsautomaten erledigen das
7.3 Enumerationen und Switch-Anweisungen
7.4 Das State-Pattern
7.4.1 Das Interface für den Zustand
7.4.2 Klassen für alle Zustände
7.4.3 An den Zustand delegieren
7.5 Wo sind die Zustandsobjekte?
7.5.1 Statische Zustände
7.5.2 Instanziierte Zustandsobjekte
7.6 Eintritts- und Austrittsaktionen
7.7 Wo ist der Haken?
7.8 Nebenläufige Zustandsautomaten
7.9 Hierarchische Zustandsautomaten
7.10 Kellerautomaten
7.11 Wie nützlich sind sie?
Teil III: Sequenzierungsmuster (Sequencing Patterns)
Kapitel 8: Double Buffer (Doppelter Buffer)
8.1 Motivation
8.1.1 Computergrafik kurz und bündig
8.1.2 Erster Akt, erste Szene
8.1.3 Zurück zur Grafik
8.2 Das Pattern
8.3 Anwendbarkeit
8.4 Konsequenzen
8.4.1 Der Austausch selbst kostet Zeit
8.4.2 Zwei Framebuffer belegen mehr Arbeitsspeicher
8.5 Beispielcode
8.5.1 Nicht nur Grafik
8.5.2 Künstliche Unintelligenz
8.5.3 Gebufferte Ohrfeigen
8.6 Designentscheidungen
8.6.1 Wie werden die Buffer ausgetauscht?
8.6.2 Wie fein ist der Buffer untergliedert?
8.7 Siehe auch ...
Kapitel 9: Game Loop (Hauptschleife)
9.1 Motivation
9.1.1 Interview mit einer CPU.
9.1.2 Ereignisschleifen
9.1.3 Eine aus dem Takt geratene Welt
9.1.4 Sekunden pro Sekunde
9.2 Das Pattern
9.3 Anwendbarkeit
9.4 Konsequenzen
9.4.1 Abstimmung mit der Ereignisschleife des Betriebssystems
9.5 Beispielcode
9.5.1 Die Beine in die Hand nehmen
9.5.2 Ein kleines Nickerchen
9.5.3 Ein kleiner und ein großer Schritt
9.5.4 Aufholjagd
9.5.5 In der Mitte hängen geblieben
9.6 Designentscheidungen
9.6.1 Stammt die Game Loop aus Ihrer Feder oder benutzen Sie die der Plattform?
9.6.2 Wie handhaben Sie die Leistungsaufnahme?
9.6.3 Wie steuern Sie die Spielgeschwindigkeit?
9.7 Siehe auch ...
Kapitel 10: Update Method (Aktualisierungsmethode)
10.1 Motivation
10.2 Das Pattern
10.3 Anwendbarkeit
10.4 Konsequenzen
10.4.1 Verkomplizierung durch Aufteilen des Codes in einzelne Frames
10.4.2 Der Zustand muss gespeichert werden, um im nächsten Frame fortfahren zu können
10.4.3 Alle Objekte simulieren jeden Frame, aber nicht wirklich exakt gleichzeitig
10.4.4 Obacht bei der Modifizierung der Objektliste während der Aktualisierung
10.5 Beispielcode
10.5.1 Entity-Unterklassen?
10.5.2 Entities definieren
10.5.3 Zeitablauf
10.6 Designentscheidungen
10.6.1 Zu welcher Klasse gehört die update()-Methode?
10.6.2 Wie werden inaktive Objekte gehandhabt?
10.7 Siehe auch ...
Teil IV: Verhaltensmuster (Behavioral Patterns)
Kapitel 11: Bytecode
11.1 Motivation
11.1.1 Wettkampf der Zaubersprüche
11.1.2 Daten &gt
Code
11.1.3 Das Interpreter-Pattern
11.1.4 Faktisch Maschinencode
11.2 Das Pattern
11.3 Anwendbarkeit
11.4 Konsequenzen
11.4.1 Befehlsformat
11.4.2 Fehlender Debugger
11.5 Beispielcode
11.5.1 Eine zauberhafte API
11.5.2 Ein bezaubernder Befehlssatz
11.5.3 Eine Stackmaschine
11.5.4 Verhalten = Komposition.
11.5.5 Eine virtuelle Maschine
11.5.6 Hexerwerkzeuge
11.6 Designentscheidungen
11.6.1 Wie greifen Befehle auf den Stack zu?
11.6.2 Welche Befehle gibt es?
11.6.3 Wie werden Werte repräsentiert?
11.6.4 Wie wird der Bytecode erzeugt?
11.7 Siehe auch ...
Kapitel 12: Subclass Sandbox (Unterklassen-Sandbox)
12.1 Motivation
12.2 Das Pattern
12.3 Anwendbarkeit
12.4 Konsequenzen
12.5 Beispielcode
12.6 Designentscheidungen
12.6.1 Welche Operationen sollen bereitgestellt werden?
12.6.2 Sollen Methoden direkt oder durch Objekte, die sie enthalten, bereitgestellt werden?
12.6.3 Wie gelangt die Basisklasse an die benötigten Zustände?
12.7 Siehe auch ...
Kapitel 13: Type Object (Typ-Objekt)
13.1 Motivation
13.1.1 Die typische OOP-Lösung
13.1.2 Eine Klasse für eine Klasse
13.2 Das Pattern
13.3 Anwendbarkeit
13.4 Konsequenzen
13.4.1 Typ-Objekte müssen manuell gehandhabt werden
13.4.2 Die Definition des Verhaltens der verschiedenen Typen ist schwieriger
13.5 Beispielcode
13.5.1 Typartiges Verhalten von Typ-Objekten: Konstruktoren
13.5.2 Gemeinsame Nutzung von Daten durch Vererbung
13.6 Designentscheidungen
13.6.1 Ist das Typ-Objekt gekapselt oder zugänglich?
13.6.2 Wie werden Typ-Objekte erzeugt?
13.6.3 Kann sich der Typ ändern?
13.6.4 Welche Formen der Vererbung werden unterstützt?
13.7 Siehe auch ...
Teil V: Entkopplungsmuster (Decoupling Patterns)
Kapitel 14: Component (Komponente)
14.1 Motivation
14.1.1 Der Gordische Knoten
14.1.2 Den Knoten durchschlagen
14.1.3 Unerledigtes
14.1.4 Wiederverwendung
14.2 Das Pattern
14.3 Anwendbarkeit
14.4 Konsequenzen
14.5 Beispielcode
14.5.1 Eine monolithische Klasse
14.5.2 Abspalten eines Bereichs
14.5.3 Abspalten der übrigen Bereiche
14.5.4 Robo-Bjørn.
14.5.5 Ganz ohne Bjørn?
14.6 Designentscheidungen
14.6.1 Wie gelangt ein Objekt an seine Komponenten?
14.6.2 Wie kommunizieren die Komponenten untereinander?
14.7 Siehe auch ...
Kapitel 15: Event Queue (Ereigniswarteschlange)
15.1 Motivation
15.1.1 Ereignisschleife der grafischen Benutzeroberfläche
15.1.2 Zentrale Ereignissammlung
15.1.3 Wie bitte?
15.2 Das Pattern
15.3 Anwendbarkeit
15.4 Konsequenzen
15.4.1 Eine zentrale Ereigniswarteschlange ist eine globale Variable
15.4.2 Den Boden unter den Füßen verlieren
15.4.3 Steckenbleiben in Rückkopplungsschleifen
15.5 Beispielcode
15.5.1 Ein Ring-Buffer
15.5.2 Anfragen zusammenfassen
15.5.3 Threads
15.6 Designentscheidungen
15.6.1 Was soll in die Warteschlange aufgenommen werden?
15.6.2 Wer darf lesend auf die Warteschlange zugreifen?
15.6.3 Wer darf schreibend auf die Warteschlange zugreifen?
15.6.4 Wie lang ist die Lebensdauer der Objekte in der Warteschlange?
15.7 Siehe auch ...
Kapitel 16: Service Locator (Dienstlokalisierung)
16.1 Motivation
16.2 Das Pattern
16.3 Anwendbarkeit
16.4 Konsequenzen
16.4.1 Der Dienst muss auch tatsächlich lokalisiert werden können
16.4.2 Dem Dienst ist nicht bekannt, wer ihn nutzt
16.5 Beispielcode
16.5.1 Der Dienst
16.5.2 Der Dienstanbieter
16.5.3 Ein einfacher Service Locator
16.5.4 Ein leerer Dienst
16.5.5 Protokollierender Dekorierer
16.6 Designentscheidungen
16.6.1 Wie wird der Dienst lokalisiert?
16.6.2 Was geschieht, wenn die Lokalisierung des Dienstes scheitert?
16.6.3 Wer darf auf den Dienst zugreifen?
16.7 Siehe auch ...
Teil VI: Optimierungsmuster (Optimization Patterns)
Kapitel 17: Data Locality (Datenlokalität)
17.1 Motivation
17.1.1 Ein Datenlager
17.1.2 Eine Palette für die CPU
17.1.3 Daten = Performance?.
17.2 Das Pattern.

Design patterns für die spieleprogrammierung

Ejemplares similares