• Keine Ergebnisse gefunden

Architektur von Videospielen

N/A
N/A
Protected

Academic year: 2022

Aktie "Architektur von Videospielen"

Copied!
62
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

November 8, 2021

(2)

Organisation

Beginnen Sie jetzt mit dem Programmieren

z.B.: /<spielname>/<spielname>.sln

▶ Jenkins und Sonar sind nun online

▶ Arbeiten Sie an einem Projekt, integrieren Sie kontinuierlich

▶ MS01: N ¨achste Woche (Spielobjekt in der Welt bewegbar, bewegliche Ansichten, Level laden/speichern, Soundausgabe)

▶ Nehmen Sie die w ¨ochentlichen Aufgaben als Chance sich zu verbessern

Ideenpr ¨asentation (Do. N ¨achste Woche)

▶ Ab 14 Uhr ct. in Zoom

▶ Ab 14 Uhr st. Technik testen

▶ Gesamte Gruppe mit Kamera

▶ max 10min (+ 5min Fragen)

▶ Bereiten Sie sich vor:

▶ Worum geht es?

▶ Zentrale Spielmechanik?

▶ Spielablauf? (gewinnen, verlieren)

▶ Warum macht es Spaß?

(3)
(4)

Architektur

Engine

Eingabe

▶ Men ¨us und Popups

▶ Persistente Einstellungen

▶ Speichern/Laden

▶ Rendern und Kamera

▶ Pathfinding

▶ Kollisionserkennung

Netzwerk

▶ Objektverwaltung Spielmechanik

Tools

▶ Modelle integrieren

▶ Texturen integrieren

▶ Sounds integrieren

▶ Level erstellen

▶ Debugging output Content

▶ Sound und Musik

Modelle

▶ Sprites

▶ Levels

A Man Ran (WS17/18)

(5)

▶ Men ¨us und Popups

▶ Persistente Einstellungen

▶ Speichern/Laden

▶ Rendern und Kamera

▶ Pathfinding

▶ Kollisionserkennung

Netzwerk

▶ Objektverwaltung Spielmechanik

▶ Texturen integrieren

▶ Sounds integrieren

▶ Level erstellen

▶ Debugging output Content

▶ Sound und Musik

Modelle

▶ Sprites

▶ Levels

(6)

Architektur

(7)

Am Besten Top-Down anfangen:

▶ Zuerst Struktur aufbauen

▶ Funktionalit ¨at aufteilen

▶ Separation of Concerns

Content

Game Logic

Engine

MonoGame

(8)

MonoGame und .NET

(9)

▶ Mathematik

▶ Zufallszahlen

▶ (De-)Serialisierung in XML/Bin ¨ar

▶ Datenstrukturen (Liste, Menge, ...)

▶ Debugging

Profiling

▶ Abstraktion

▶ Grafik

▶ Sound

▶ Input

▶ Content Pipeline

▶ Einfache Anzeigemethoden (BasicEffect, SpriteBatch)

▶ Datentypen

▶ Vector2, Vector3

▶ Matrix

▶ ...

(10)

MonoGame Lifecycle

Initialize() LoadContent()

BeginRun() Update(GameTime t)

BeginDraw(): bool

Draw(GameTime t)

EndDraw() EndRun()

(Un-)Load Content

Game Loop

(11)
(12)

Screen Management

Entkoppeln der Verwaltung von Spielzust ¨anden und deren Inhalt:

Screens implementieren ihre jeweilige Funktionalit ¨at

▶ Hauptmen ¨u

▶ Optionsmen ¨u

▶ Spielansicht

▶ HUD

▶ Ladebildschirm

▶ ...

▶ ScreenManager verwaltet alle Screens

(13)

MainMenuScreen

- mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

Draw()

Update()

(14)

Screen Management

MainMenuScreen

ScreenManager - mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

AddScreen(OptionsScreen)

(15)

MainMenuScreen

- mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

OptionScreen

Draw()

Update()

(16)

Screen Management

MainMenuScreen

ScreenManager - mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

OptionScreen

RemoveScreen()

(17)

MainMenuScreen

- mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

Draw()

Update()

(18)

Screen Management

GameScreen HudScreen

ScreenManager - mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

UpdateLower?

DrawLower?

(19)

GameScreen HudScreen

- mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

Yes

Yes

(20)

Screen Management

GameScreen HudScreen

ScreenManager - mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

PauseMenuScreen

(21)

GameScreen HudScreen

- mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

PauseMenuScreen UpdateLower?

DrawLower?

(22)

Screen Management

GameScreen HudScreen

ScreenManager - mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...) + Update(...)

PauseMenuScreen

No

Yes

(23)

Screen Management

ScreenManager

- mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...)

+ Update(...)

<<Interface>>

IScreen

+ UpdateLower: bool + DrawLower: bool + Update(...) + Draw(...)

MenuScreen

HudScreen

PauseMenuScreen

<<component>> Menu

(24)

Screen Management

Engine.ScreenManagement

GameLogic.Menu

ScreenManager

- mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...)

+ Update(...)

<<Interface>>

IScreen

+ UpdateLower: bool + DrawLower: bool + Update(...) + Draw(...)

HudScreen

PauseMenuScreen

<<component>> ScreenManagement

<<component>> Menu

IScreen

(25)

GameLogic.Menu

ScreenManager

- mScreenStack:List<IScreen>

+ AddScreen(screen:IScreen) + RemoveScreen(...) + Draw(...)

+ Update(...)

<<Interface>>

IScreen

+ UpdateLower: bool + DrawLower: bool + Update(...) + Draw(...)

HudScreen

PauseMenuScreen

<<component>>

ScreenManagement

IScreen

(26)

Input Management

▶ Tastatur, Maus, Gamepad, ...

▶ MonoGame Namespace Microsoft.Xna.Framework.Input

▶ KeyboardState mKeyboardState = Keyboard.GetState();

▶ Statusinformation per Frame: Zustand der Tasten, Mausposition

keine

Historie

▶ Wir brauchen

▶ Statusinformation in Abh ¨angigkeit von Zeit (z.B.:

A

wurde diese Frame losgelassen)

Abstraktion

von Tasten zu Aktionen

(27)

Input Management

Xna...Mouse

Xna...MouseState

Xna...Keyboard

Xna...KeyboardState

<<enumeration>>

Xna...Keys

KeyEvent

<<enumeration>> KeyEventType OnButtonDown OnButtonPressed OnButtonUp

0...*

InputState + MousePosition:Vector2

1

<<enumeration>> ActionType

(28)

Input Management

Engine.Input

Xna...Mouse

Xna...MouseState

Xna...Keyboard

Xna...KeyboardState

InputManager

+ GetKeyMappings():Dictionary<ActionType, List<KeyEvent>>

+ SetKeyMapping(keyEvents: List<KeyEvent>, action: ActionType) + DeleteKeyMapping(...)

+ Update (...)

KeyEvent

<<enumeration>>

KeyEventType 0...*

InputState + MousePosition:Vector2

1

(29)

▶ Viele Elemente die sich sehr ¨ahnlich verhalten

▶ Panels

▶ Buttons

▶ Labels

▶ Textboxen

▶ Checkboxen

▶ Auch im Hud verwendbar

(30)

Men ¨us

MenuElement + Position:Vector2 + Size:Rectangle + Visible: bool MenuEventHandler

<<Interface>>

IKeyboardSelectable + Enabled: bool

<<Interface>>

IDrawable2D + CurrentRatio: float + Draw(...)

Pane Label Textbox Button

1

PaneElements 0..*

1 ButtonParts 0..*

(31)

Spielobjekte

Spielobjekte

Spielobjekte sind alle Dinge, die eine Repr ¨asentation in der Spielwelt haben.

▶ Charaktere, Fahrzeuge, B ¨aume, Raketen, Gras, Steine, Trigger, Lichter, Sounds, ...

▶ Spielobjekte m ¨ussen manchmal

▶ gezeichnet werden

▶ sich bewegen

▶ zerst ¨orbar sein

▶ miteinander kollidieren

▶ etc.

▶ Wie verwaltet man so viele (verschiedene) Objekte effizient?

(32)

Spielobjekte

Spielobjekte

Spielobjekte sind alle Dinge, die eine Repr ¨asentation in der Spielwelt haben.

▶ Charaktere, Fahrzeuge, B ¨aume, Raketen, Gras, Steine, Trigger, Lichter, Sounds, ...

▶ Spielobjekte m ¨ussen manchmal

▶ gezeichnet werden

▶ sich bewegen

▶ zerst ¨orbar sein

▶ miteinander kollidieren

▶ etc.

▶ Wie verwaltet man so viele (verschiedene) Objekte effizient?

▶ Zur

Laufzeit?

(33)

Ein Szenengraph ist eine zentrale Datenstruktur, die der logischen und r ¨aumlichen Verwaltung der Spielobjekte dient.

▶ Antwort auf r ¨aumliche Fragen

▶ Update- und Drawaufrufe an Spielobjekte weitergeben

▶ Beispiele: Liste, Heap, Quad-/ Octree, KD-Tree, R-Tree, ...

(34)

Spielobjekte

Objektzentriert

▶ Spielobjekte sind Klassen mit

▶ Eigenschaften des Spielobjekts

▶ Verhalten des Spielobjekts

▶ Spielwelt ist eine Menge von Instanzen der Spielobjekte

Eigenschaftszentriert

▶ Jedes Spielobjekt ist nur eine ID

▶ Eigenschaften werden in Tabellen gespeichert

▶ Verhalten sind Operationen auf Tabellen

▶ Anhnlich zu Datenbanken ¨

(35)

Spielobjekte und Vererbung

(36)

Spielobjekte und Vererbung

Enemy

Was ist mit der Kamera?

(37)

Spielobjekte und Vererbung

PlayerCharacter Enemy

(38)

Spielobjekte und Vererbung

PlayerCharacter

PhysicsObject

Enemy

Was ist mit der Kamera?

(39)

Spielobjekte und Vererbung

MovableObject

PlayerCharacter

PhysicsObject

Enemy

(40)

Spielobjekte und Vererbung

MovableObject Platform

PlayerCharacter

PhysicsObject

Enemy

Was ist mit der Kamera?

(41)

Spielobjekte und Vererbung

ColldiableObject

MovableObject Platform

PlayerCharacter

PhysicsObject

Enemy

(42)

Spielobjekte und Vererbung

ColldiableObject AmbientTree

MovableObject Platform

PlayerCharacter

PhysicsObject

Enemy

Was ist mit der Kamera?

(43)

Spielobjekte und Vererbung

GameObject

ColldiableObject AmbientTree

MovableObject Platform

PlayerCharacter

PhysicsObject

Enemy

(44)

Spielobjekte und Vererbung

GameObject

ColldiableObject AmbientTree

MovableObject Platform

PlayerCharacter

PhysicsObject

Enemy

Was ist mit der Kamera?

(45)

Spielobjekte

Eine einfache Kamera

▶ Speichert z.B.:

▶ View Matrix

▶ Projection Matrix

▶ Grundlage f ¨ur Picking

▶ Definiert View Frustrum

(46)

Spielobjekte

Eine einfache Kamera

▶ Speichert z.B.:

▶ View Matrix

▶ Projection Matrix

▶ Grundlage f ¨ur Picking

▶ Definiert View Frustrum

- Teil der Spielwelt

- Nicht kollidierend

(47)

Tree Platform PlayerCharacter Mob BossMob Camera

GameObject ✓ ✓ ✓ ✓ ✓ ✓

Collidable ✓ ✓ ✓ ✓

Movable ✓ ✓ ✓ ✓

Physics ✓ ✓ ✓

EnemyBehaviour ✓ ✓

(48)

Spielobjekte und Vererbung

GameObject

ColldiableObject AmbientTree

MovableObject Platform

PlayerCharacter

PhysicsObject

Enemy

Camera

(49)

Spielobjekte und Komposition

Enemy IMovement ICollidable IEnemyBeaviour

<<interface>>

IGameObject

<<interface>>

IEnemy

NonCollidableObject

EnemyBehaviour

BossEnemyBeaviour

FlyingEnemyBehaviour ICollidable

<<interface>> IEnemyBeaviour 1

Behaviour 1 1

(50)

Spielobjekte und Komposition

Enemy IMovement ICollidable IEnemyBeaviour

<<interface>>

IGameObject

<<interface>>

IEnemy

FlyingMovement

UnitMovement

CollidableObject

NonCollidableObject

EnemyBehaviour

BossEnemyBeaviour

FlyingEnemyBehaviour

<<interface>>

IMovement

<<interface>>

ICollidable

<<interface>>

IEnemyBeaviour Movement

1 1

Physics 1 1

Behaviour 1 1

(51)

Enemy IMovement ICollidable IEnemyBeaviour

<<interface>>

IGameObject

<<interface>>

IEnemy

UnitMovement

CollidableObject

NonCollidableObject

EnemyBehaviour

BossEnemyBeaviour

<<interface>>

IMovement

<<interface>>

ICollidable

<<interface>>

IEnemyBeaviour Movement

1 1

Physics 1 1

Behaviour 1 1

(52)

Pathfinding

Offline

▶ Ber ¨ucksichtigt Welt und unbewegliche Objekte

▶ Meistens A*

▶ Viele m ¨ogliche Weltrepr ¨asentationen:

Grid, Hierarchical Grid, Waypoint Graph, Navigation Mesh,...

Online

▶ Beweglichen Objekten ausweichen

▶ Verschiedene Verfahren:

Steering, Flocking, Flow Fields, ...

(53)

+ GetPath(Location src, Location dest): Path

UnitMovement

Path AStarPathfinder

<<interface>>

IMapRepresentation

(54)

Library Falle

(55)

Die Libraryfalle

Die Libraryfalle

▶ Es existieren viele Libraries

▶ Pro:

▶ Rad nicht neu erfinden

▶ Optimierte L ¨osungen f ¨ur bekannte Probleme

▶ Aber:

▶ Problem muss verstanden sein

▶ Library muss verstanden werden

Versteckte Kosten

wenn Library fehlerhaft/schlecht/unpassend/...

Vorher das Risiko absch ¨atzen:

▶ Wie zentral ist die Library?

▶ Wie reif ist die Library?

▶ K ¨onnen wir das einfacher selbst machen?

Part3 Lib

- Weniger m ¨oglicher Schaden:

Part1 Part2

Part3 Lib

Part4

(56)

Die Libraryfalle

Die Libraryfalle

▶ Es existieren viele Libraries

▶ Pro:

▶ Rad nicht neu erfinden

▶ Optimierte L ¨osungen f ¨ur bekannte Probleme

▶ Aber:

▶ Problem muss verstanden sein

▶ Library muss verstanden werden

Versteckte Kosten

wenn Library fehlerhaft/schlecht/unpassend/...

Vorher das Risiko absch ¨atzen:

▶ Wie zentral ist die Library?

Wie zentral ist die Library? -Viel m ¨oglicher Schaden:

Part1 Part2

Part3 Part4

Lib

- Weniger m ¨oglicher Schaden:

Part1 Part2

Part3 Lib

Part4

(57)

▶ Es existieren viele Libraries

▶ Pro:

▶ Rad nicht neu erfinden

▶ Optimierte L ¨osungen f ¨ur bekannte Probleme

▶ Aber:

▶ Problem muss verstanden sein

▶ Library muss verstanden werden

Versteckte Kosten

wenn Library fehlerhaft/schlecht/unpassend/...

Vorher das Risiko absch ¨atzen:

▶ Wie zentral ist die Library?

Part1 Part2

Part3 Part4

Lib

- Weniger m ¨oglicher Schaden:

Part1 Part2

Lib

(58)

Organisation

(59)

Ziel

Architektur anhand von Designprinzipien verbessern, Probleme fr ¨uhzeitig aufdecken.

Ablauf:

▶ Kurze Zusammenfassung des Spiels

▶ Ubersicht ¨uber die Architektur ¨

▶ Was machen die einzelnen Komponenten

▶ Vorstellen der Architektur anhand der Szenarien

▶ Fragen und zus ¨atzliche Szenarien

Quelle: Dozent Ausl ¨ oser: Spieler

Umgebung: Ich befinde mich im Hauptmen ¨u.

Ich dr ¨ucke auf Spiel Starten, es werden Spielob-

jekte erzeugt.

(60)

Was nun?

▶ Fangen Sie jetzt an zu programmieren

▶ In

einem

Projekt

▶ Arbeiten Sie gemeinsam

▶ GDD-Reviews lesen und Probleme beheben

▶ Inhaltliche Probleme fr ¨uh l ¨osen

▶ Nicht vergessen:

▶ Architekturbesprechung

▶ Ideenpr ¨asentation

F ¨ur Fragen gibt es die Sprech-

stunde: Donnerstags 14-18 Uhr,

dauerhafter Zoomlink ab heute auf

dem Wiki.

(61)

▶ Fangen Sie jetzt an zu programmieren

▶ In

einem

Projekt

▶ Arbeiten Sie gemeinsam

▶ GDD-Reviews lesen und Probleme beheben

▶ Inhaltliche Probleme fr ¨uh l ¨osen

▶ Nicht vergessen:

▶ Architekturbesprechung

▶ Ideenpr ¨asentation

F ¨ur Fragen gibt es die Sprech-

stunde: Donnerstags 14-18 Uhr,

dauerhafter Zoomlink ab heute auf

dem Wiki.

(62)

Referenzen

ÄHNLICHE DOKUMENTE

(Berechnungs-)Verfahren nach Al Chwarismi (Bagdad, um 800), latinisiert zu Algoritmi. FGdI I Sommer 2010 M

Ein Graph G heißt zusammenh¨ angend, falls es zu jedem Knotenpaar s, t ∈ V einen [s, t]-Weg in G gibt. Die Komponenten von G sind die bez¨uglich Kante- ninklusion

Objekts anzufertigen, die ¨ Anderungen darauf anzuwenden und dann die Instanz auf dieses Schema umzubiegen. Von Nachteil ist, dass damit die urspr¨ungliche Prozesstyp–Zugeh¨o-

Rand des Baumes Liste der Blattmarkierungen eines geordneten Baumes bin¨ arer Baum Jeder Knoten ist Blatt oder hat genau zwei T¨ ochter. H¨ ohe (Tiefe) maximale L¨ ange eines Weges

▸ Alle Knoten (außer der Wurzel) besitzen einen Elternknoten (oder Vaterknoten) und sind ihrerseits Kinder dieses Knotens.. ▸ Wir unterscheiden zwischen Bl¨ attern und

I Jeder Pfad von der Wurzel zu einem Blatt hat die gleiche Anzahl von schwarzen Referenzen. I (Gleiche Tiefe im

Implementiert werden rot- schwarze B¨ aume mit bin¨ aren B¨ aumen, in denen die Knoten gef¨ arbt sind (n¨ amlich rot oder schwarz)1. Jeweils zwei oder drei solche gef¨ arbter

Affine Unterr¨aume sind genau die L¨osungsmen- gen von linearen Gleichungssystemen (siehe Lineare