spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

ich bin gerade mit dem gleichen Projekt beschäftigt

Du kannst auf abstrakte Klassen setzen und deine Klassen ableitbar machen. Wenn du eine Basisklase für Objekte hast, die z.B. deren Shader und Constantbuffer etc. verwaltet, wird diese Klasse eine virtuelle Rendermethode haben. Eine weitere Klasse, die als Szene fungiert und mit Objekten bestückt wird, kann zum Rendern auf jedem Objekt die Rendermethode aufrufen. So kann es letztendlich der Szenenklasse egal sein, um was für ein Objekt es sich handelt. Auf diesse Weise erzeugst du eine Architektur, deren Inhalt beliebig erweiterbar ist. Du kannst in deinem Framework Klassen für beispielsweise 2D- und 3D-Objekte von der Basisklasse ableiten und zur Verfügung stellen. Möchte der Benutzer später weitere Objekttypen erzeugen, muss er nur von der Basisklasse ableiten.

Klar, beim Erstellen der grundlegenden DirectX-Schnittstellen, muss man Abstriche machen, was die Flexibilität betrifft, um die Komplexität zu senken. Vielleicht hilft es hier schon, Parameter deiner Funktionen mit Standardwerten zu versehen.

Wenn du ein Framework für dein Spiel schreiben willst, dann sollte auch das Interface an dein Spiel angepasst sein. Die Anzahl der Buffer der SwapChain interessiert dein Spiel sicherlich herzlich wenig. Dein Spiel muss lediglich ein Fenster aufmachen und was reinrendern können. Dein Spiel interessiert sich auch nicht für Shader oder Constant Buffer. Dein Spiel interessiert sich dafür, dass eine Spielfigur an einer bestimmten Position gezeichnet wird. Das Interface zwischen deinem Spiel und dem Renderer sollte also wohl auch eher von einem Playermodel an einer bestimmten Position sprechen, als von Projection Matritzen, Shadern, Texturen und Rasterizer States. Wie all diese Dinge kombiniert werden, um am Ende ein Playermodel an eine bestimmte Position zu malen, genau das ist doch eigentlich die Aufgabe des Renderers...

Ich weiß, wie verlockend es ist, ein "Framework" oder eine "Engine" zu schreiben, die de facto einfach nur Direct3D Wrapper ist. Imo fundamentale Erkenntnis: Ein Wrapper bringt keine echte Abstraktion und ist damit am Ende praktisch wertlos.

XNA als DirectX-Wrapper macht aber durchaus Sinn, weil es sonst keinen nativen Zugriff aus .Net heraus zu DirectX gäbe.
Andernfalls sind Wrapper wirklich nicht sonderlich sinnvoll. Sie sollen eben wrappen, was man wrappen *muss*, weil es anders nicht geht. Ich denke dot hat schon sehr gut beschrieben, was für Dein Spiel relevant ist. Und dem ist die Anzahl der Buffer oder die Swapchain wirklich total egal, genau genommen ist ihm sogar egal mit welcher Engine das Zeug gerendert wird, solange es überhaupt gerendert wird. Folglich sind viele der intern notwendigen Parameter total egal. Falls nicht, dann lass die Engine ein Konfig-File einlesen, wo diese Parameter spezifiziert werden können. Aber sie als Parameter in der API wie in einem Wrapper durchschleifen, das ist wirklich nicht sinnvoll.

Zitat von »Sortoc«

Zitat von »dot«

Wenn du ein Framework für dein Spiel schreiben...

So wie du die Sache beschreibst hört sich das nach dem Model-View-Controller Design Pattern an. Das Problem das ich mit dem Pattern habe ist das ich zwar schon unmengen dazu gelesen habe aber noch keine vernüftige Beispiel-Implementation gefunden habe die etwas mit Spielen zu tun had und über ein einfaches Pong hinaus geht.

Ich hab jetzt eigentlich nicht unbedingt an MVC gedacht, auch wenn das am Ende tatsächlich wohl etwas in die Richtung geht.

Zitat von »Sortoc«

Zitat von »dot«

Ich weiß, wie verlockend es ist, ein "Framework" oder eine "Engine" zu schreiben, die de facto einfach nur Direct3D Wrapper ist. Imo fundamentale Erkenntnis: Ein Wrapper bringt keine echte Abstraktion und ist damit am Ende praktisch wertlos.

So schlecht sind Wrapper doch nicht? Wenn ich mich nicht irre ist das XNA-Framework für C# doch auch nur ein DirectX Wrapper oder nicht?

Ich hab nie mit XNA gearbeitet, afaik ist es jedoch wesentlich mehr als einfach nur ein DirectX Wrapper. Und selbst wenn, würde das im Fall von XNA Sinn machen, wie BlueCobold schon gesagt hat. Aber überleg mal, was ein Wrapper dir bringt. Was bringt dir ein "Renderer", der am Ende das selbe Interface bietet wie die darunterliegende API selbst!? Wenn du mich fragst, hast du dadurch nichts gewonnen, du könntest stattdessen gleich auch einfach wieder Direct3D direkt benutzen. Ein Renderer für dein Spiel sollte eben das Rendern deines Spiels kapseln...

Ich finde eine Klassenhierarchie alles andere als Kontraproduktiv. Was mich persönlich immer ärgert ist, wenn ich in einer Klasse genau denselben größeren Codeausschnitt oder sogar mehrere Funktionen verwenden muss, die ich schon in einer anderen Klasse verwendet habe. Dann nämlich haben diese Klassen eine Beziehung zueinander (sie benötigen teilweise die selbe Funktionalität). In diesem Fall hätte man das besser modellieren können, indem beide Klassen von einer Klasse erben, die genau diese Funktionen zur Verfügung stellt. Natürlich kann man das übertreiben. Vererbung muss auch einer gewissen Logik folgen. Nur weil zufällig 2 Klassen Daten sortieren (was nicht ihre Hauptaufgabe ist) und dazu den gleichen Algorithmus verwenden, heißt das noch lange nicht, dass sie diese Funktionalität von einer Basisklasse erben sollten. Bei den von mir geschilderten Objekttypen halte ich das im Gegensatz für sehr sinnvoll. Ein Renderer kann jedes Objekt gleich behandeln, wenn jedes ein Basisinterface implementiert und muss sich nicht darum kümmern, wie das jeweilige Objekt aufgebaut ist. Das steigert in jedem Fall die Erweiterbarkeit deines Frameworks.

Anbei ein Ausschnitt aus einem Klassendiagramm, das ich aus meinem Framework erstellt habe. Die dort angewandte Vererbungshierarchie halte ich persönlich für sinnvoll.

Ich würde eher sagen, GUI gehört zum View und zum Controller, bin aber kein MVC Experte...

Ein "IDrawableGameObject" oder "ICharacterSprite" oder "IPlayerSprite" verstößt schon vom Namen her vermutlich gegen MVC. Player und GameObject sind Models, Drawables und Sprites sind Views.
Ich finde in Games MVC oft aber sehr kontraproduktiv.