Game Engine Architecture and Development. Einführung

Größe: px

Ab Seite anzeigen:

Download "Game Engine Architecture and Development. Einführung"

Theresa Vogt
vor 6 Jahren
Abrufe

1 Game Engine Architecture and Development Einführung

2 Wer sollte hier sein? Ihr interessiert euch für die technischen Hintergründe von Spielen Ihr wisst wie die Grafikpipeline aussieht 3D Mathematik ist euch kein Fremdwort Die Grundlagen aus AUD sind noch bekannt :)

3 Und wer nicht? Ihr braucht Credit Points Dies ist eine fakultative Veranstaltung Ihr wollt ein Spiel machen Dafür bietet Acagamics andere klasse Veranstaltungen an

4 Wer bin ich? Marc Appelsmeier Studiere Computervisualistik Arbeite neben dem Studium bei Trinigy (Game Engine Middleware Hersteller)

5 Wer seid ihr?

6 Literatur Game Engine Architecture von Jason Gregory Game Engine Gems, Volume One Real-Time Rendering, Third Edition GPU Pro: Advanced Rendering Techniques AI for Game Developers von David M. Bourg Das Web..

7 Der Plan Heute: Einführung / Auffrischung Die nächsten Termine: Spezifische Engine Subsysteme und auch Tools

8 Was ist eigentlich eine Game Engine?

9 Was ist eigentlich eine Game Engine? Die wiederwendbaren Teile eines Spiels die als Basis für neue Spiele genutzt werden können.

10 Game Engine Komponenten Gameplay Code / Script Binding / AI Sound System Szenen Verwaltung Serialisierung Rendering GUI Animations System Task System Partikel System Basis Bibliotheken (File I/O, Timer, Threads..) Low Level Renderer OS / Treiber Level

11 Grundlagen

12 Grundlagen Datenstrukturen

13 Datenstrukturen Datenstrukturen die uns über den Weg laufen werden: Listen (LinkedList, DoubleLinkedList) Arrays / Vector Stacks Hash-Maps Bäume

14 Listen (LinkedList, DoubleLinkedList) Einfach oder doppelt verkettete Listen Element einfügen: O(1) Zugriff auf das n-te Element: O(n) Element entfernen: O(1) Bedeutet normalerweise viele kleine Allokationen

15 Arrays / Vector Dynamisch wachsendes Array (C++: std::vector) Element anhängen: üblicherweise O(1) Zugriff auf das n-te Element: O(1) Element entfernen: O(n) Deutlich weniger Allokationen als eine Liste Nett: Elemente liegen garantiert kontinuierlich im Speicher!

16 Bäume Übliche Bäume im Bereich Game Development: BSP trees Quadtrees Octrees kd-trees BVH (Bounding volume hierarchy)

17 BSP Trees Die Szene wird rekursiv an Split-Planes in Zwei geteilt Lange Zeit Standard (vor allem im FPS Bereich) Einige Engines nutzen sie noch heute (zum Beispiel die Source Engine)

18 Quadtrees Jeder Knoten hat vier Kinder Wird öfters für Verwaltung von zwei dimensionalen Datensätzen verwendet (Texturen, Terrain,..)

19 Octree Jeder Knoten hat acht Kinder Geeignet für 3D Daten Bilder:

20 kd-trees kd-trees erlauben eine Organisation von Punkten in einem k-dimensionalen Raum Erlauben durch ihre Struktur ein schnelles finden von Nachbarn zu Baumknoten

21 BVH Bounding Volume Hierarchies sind einfache Bäume die die Bounding Volumes um Objekte hierarchisch anordnen Gut für 3D Daten (zum Beispiel Szenen) Aber auch 2D geht ohne Probleme (GUI)

22 Grundlagen Design Patterns

23 Design Patterns Singletons Iteratoren Observer Dependency Injection Plugins

24 Singletons Verhindert das Erstellen von mehr als einer Instanz eines Objektes Diese Instanz ist auch üblicherweise global verfügbar Singletons are evil (?) Na ja, ein wenig.. Wie immer gilt: Du solltest wissen was du tust!

25 Iteratoren (Cursor) Iteratoren stellen einen bequemen sequenziellen Zugriff auf die Inhalte einer Struktur bereit (Ohne das man die zugrundeliegende Struktur kennen muss) Praktisch zum Beispiel in der Szenenverwaltung Man kann einfach über alle Objekte iterieren ohne wissen zu müssen ob die Objekte jetzt in einem Octree oder in einer Liste liegen.

26 Observer Pattern Auch bekannt als Signal-Slot Prinzip Erlaubt über Änderungen in einem Objekt informiert zu werden Input Handling, Objekte wurden zerstört, Spieler läuft in einen Trigger...

27 Dependency Injection Verschiedene Varianten Constructor Injection, Setter Injection,.. Für uns meistens am interessantesten: Constructor Injection Wir geben einem Objekt bei der Erstellung andere benötigte Objekte mit Beispiel: Unser GUI System muss sich darstellen können, dazu braucht es den Renderer Mit CI übergeben wir den Renderer und brauchen ihn somit nicht als globale Variable herumliegen haben

28 Plugins Wie der Name sagt - dieses Design Pattern steht für eine Plugin basierte Architektur (zum Beispiel Interface basiert) Beliebt in Game Engines da man so die Funktionalität erweitern kann ohne große Teile des Codes neukompilieren zu müssen etc.

29 Grundlagen Reference Counting / Smart Pointer

30 Reference Counting Kann verwendet werden um zu tracken wieviele Objekte auf ein anderes angewiesen sind Einfaches Prinzip: Jedes Objekt hat einen sogenannten Reference Counter Dieser kann mittels AddRef() erhöht und mittels Release() verringert werden.

31 Smart Pointer Ein Smart Pointer ist im einfachsten Fall eine Kapselung um ein Objekt mit Reference Counting Beim Anlegen eines Smart Pointers wird der Reference Counter automatisch erhöht Sobald der Smart Pointer zerstört wird wird der Reference Count verringert Ist der Reference Count des Objektes 0 kann es gelöscht werden

32 Grundlagen CPUs

33 CPUs sind schnell! Leider ist das Arbeitsspeicher Tempo nicht im gleichem Umfang gewachsen.. Was bedeutet das für uns?

34 CPU Caches Die Grundlage für eine schnelle Verarbeitung von Daten besteht darin die CPU zu kennen und wie die Caches funktionieren Wenn Daten verarbeitet werden fetcht die CPU die zu bearbeitenden Daten in die Cache Lines. Sind diese wild über den Speicher verteilt verringert sich die Wahrscheinlichkeit das nachfolgende Elemente bereits im Cache sind

CPU Caches: Partikel Array of Structures (AOS) Structure of Arrays (SOA) http://research.

35 CPU Caches: Partikel Array of Structures (AOS) Structure of Arrays (SOA)

36 Warum unterhalten wir uns darüber?

37 Warum unterhalten wir uns darüber? In einer Game Engine muss alles schnell gehen Bei 60 FPS haben wir 16,67ms Zeit (!) Die richtige Wahl der Algorithmen und Datenstrukturen bedeutet oftmals den größten Unterschied zwischen einer Engine die nur OK ist und einer Engine die sehr gut ist und auch gut skaliert. Die besten CPUs und GPUs nutzen nichts wenn die Engine sie nicht richtig füttert

38 Eine kurze Verschnaufpause Gibt es soweit Fragen?

39 Resource Management

40 Resource Management Eine der essentiellsten Komponenten einer Game Engine Ohne Resourcen Verwaltung gibt es keine Texturen, Shader, Sounds, Geometrie,.. Fehler auf der Ebene des Resource Managments wirken sich stark auf den Rest der Engine aus (Sowohl konzeptionell als auch Laufzeitfehler)

41 Resource Management Mögliche Resourcen in einem Spiel Texturen Models / Meshes Animationen Skripte Sounds Partikelsysteme...

42 Resource Managment: Anforderungen Einfach Sprich: LoadResource( Pfad ) und fertig Fehlertolerant Eine fehlende Resource sollte nicht zum Absturz führen Sollte Speicher Limits beachten Sollte nicht mehr benötigte Resourcen aufräumen können Resourcen Tracking ist auch eine feine Sache

43 Resourcen Laden Zwei Ansätze primär verbreitet Für jeden Resourcen Typ einen Manager TextureManager::LoadResource( MyTexture ) Diese Manager leiten von einer Basis Klasse ResourceManager ab

44 Resourcen Laden Für alle Resourcen ein geteilter Manager Dieser hat dann entweder den Code für alle Resourcen Typen oder spezielle Resourcen Lader ResourceManager::LoadResource( MyTexture ) (nach ResourceManager::RegisterLoader(new TextureLoader(); )

45 Fehlertoleranz Es passiert häufig das eine Resource nicht vorhanden ist Vergessen etwas zu kopieren, Nutzer hat Dateien gelöscht,.. Um Probleme wie Abstürze zu vermeiden kann es hilfreich sein sogenannte Fallback Resourcen bereit zu halten Zum Beispiel eine (penetrante) Textur die verwendet wird wenn die eigentlich angeforderte nicht gefunden wird

46 Resourcen Tracking Resourcen sollten nach dem Laden (oder wenn möglich vorher) dem System mitteilen können wieviel Speicher sie verbrauchen (Host / GPU) Damit kann zum Beispiel bei einem Speicherlimit das Aufräumen der ältesten Resourcen angestoßen werden um Platz zu schaffen Andererseits hilft es auch beim Profiling ungemein zu wissen wohin der Speicher verschwindet

47 Resourcen Freigabe Egal welches Konzept: RM sollte eine Liste der verwalteten Resourcen mitführen Am besten sind die Resourcen RefCounted um unbenutzte Resourcen zu finden Diese können dann entladen werden um Speicher freizugeben

48 Programmier Aufgabe Die (freiwillige) Aufgabe für nächstes mal: (Pseudo-) Code für eine Resourcen Verwaltung in einer Engine Es muss nicht das komplette Textur laden etc. eingebaut sein Bringt eure Ansätze mit damit wir kurz darüber reden können

49 Das war es für heute! Nächster Termin: Dienstag, Thema: Platform Unabhängiger Code, Multi Threading

50 PS: Für die Grafikinteressierten - am Donnerstag ist das Echtzeitgrafiktreffen (17 Uhr im 335)

Ähnliche Dokumente

Game Engine Architecture and Development. Platform Unabhängiger Code Multi Threading in Game Engines Profiling

Game Engine Architecture and Development Platform Unabhängiger Code Multi Threading in Game Engines Profiling Folien Die Folien werden auf acagamics.de hochgeladen Das Passwort ist 60fps (ohne ) Rückblick: