spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi,

ich poste morgen Abend Dir mal was, bin momentan bei Freundin und hab keinen Code zur Hand ;D

-Patrick

Hatten wir so einen Thread nicht neulich schon mal?

1) API-unabhängig oder nicht? Falls ja, am besten eigene Mathe-Klassen (ohnehin empfehlenswert, damit anzufangen) wie Vector, Matrix, Quaternion, Plane, Ray, etc.

2) DLL oder statische lib (Igitt)? Objektorientiertes Modell (hoffentlich!)? Am besten eine Grafik-Hauptklasse, ohne Extras, danach Manager (Texture/Material/Effekt (was ja bei TB das "Material" bildet)), danach Buffer, danach Kapselungen für Objekte.
Dann Hilfskomponenten wie Sound, Input, etc.

Grundsätzlich sieht es so aus: Bei einer schönen OOP-Engine gibt's immer eine "Hauptverwaltungsklasse", die die Engine hoch- und runterfährt (u. evtl auch Manager initialisiert). Der Benutzer sollte dann Objekte anlegen können, die über die Hauptklasse gerendert werden, sonst aber unabhängig davon erstellt und verwaltet werden können. Dabei können Manager verwendet werden (intern für die Engine, aber auch extern für den Benutzer, wie ein Speichermanager).

Wenn du deine Engine Professioneller aufziehen willst, bleibt dir nichts anderes übrig als dich hinzusetzen, dir ein Stift Papier zu nehmen und alles aufzuschreiben. Erst einmal was grober dann immer weiter ins Detail gehen. Dazu hatte ich auch schon mal jede Menge zu gesagt. Ich glaub sogar in dem einen Thread den du schon erwähntest.

Einen Generellen Aufbau gibt es wircklich nicht. Es fängt aber damit an dir ein paar Standards zu setzen. Welche Variablen Typen verwende ich z.B. oder wie genau sehen die Variablen aus. Vom Namen her. Alles klein mit oder ohne Notation. Muss ja nicht die Ungarische sein.

Das Stichwort heißt Plannung

Der Rest ergibt sich dann von selbst. Es hängt auch viel davon ab, willst du einen Support für PlugIn's, soll die Engine in einer DLL vorliegen oder mit dem Projekt zusammen kompiliert werden oder soll alles auf reinem C++ Aufbauen.
Ein Konzept kann dir hier keiner geben. Schreib doch einfach mal was dir so vorschwebt. Du must doch schon die ein oder andere Idee haben. Dann können wir dir auch genaueres sagen.

Auch ein(für mich) wichtiger Punkt ist: Wieviel Automatismus ist gesund? Ich habe da zum Glück bei vielen Sachen ne Lösung gefunden.

Zitat von »"Nox"«

Auch ein(für mich) wichtiger Punkt ist: Wieviel Automatismus ist gesund? Ich habe da zum Glück bei vielen Sachen ne Lösung gefunden.

Der Automatismus ist auch eine wichtige Frage. Ich denke wenn die Engine speziell für ein Projekt geschrieben wird, kann der Grad des Automatismus sehr viel höher sein als wenn man eher eine Allgemeine 3D Graphic Engine schreibt.


Input, Sound, etc. gehören nicht zu einer 3D Graphic Engine. Oft werden diese Komponenten zwar nur als Hilfmoduule degradiert, Fakt ist aber auch eine gute Input Engine oder eine gute Sound Engine ist sehr wichtig. Dann aber verläst man den bereich einer "3D Engine" oder besser gesagt einer Graphic Engine mit 3D Support

Es kommt sehr darauf an, was Du mit der Engine machen willst.

Bei PLIB (kenn ich eben am besten) gibt's folgende Module:

- GUI. Wenn Deine Engine nur für Windows ist kannst Du auch sagen, der benutzer muss halt die DUI Funktionmen von Windows nehmen. Da PLIB mit ner GUI kommt ist die einzige Abhängigkeit von PLIB OpenGL.

- Joystick bzw Input.

- "Grafik Mathe", also Matrix, vektor, Quaternion etc

- Ein Szenen Graph. Dies sehe ich als den Kernpunkt einer Engine an.

- Netzwerk.

- Ne Scripting Sparache. Kam als eines der lezten Dinge hinzu und ist m.E. nicht nötig.

- Eine kleine Fenster Bibliotheck. Natürlich nicht nötig, wenn Du nicht portabel sein willst.

- Util, z.B. Fehler logging

- Sound

Die Abhängigkeiten zwischen den Modulen sind sehr gering, aus dem Kopf:
Alles benötigt Util.
Der Szenen Graph benötigt die Grafik Mathe.

Es ist absolut normal, dass ein Spiel nur ein Teil der Module benuzt.

Zitat

Einfach ne virtuelle Basisklasse, die mir ein Interface bietet zum Rendern und von der leit ich dann die Klassen um, die das dann in DX oder OGL umsetzen.

Ja, würde ich so machen. Die Hauptdesign-entscheidung ist, auf welcher Ebene das sein wird, also ist ein Befehl "rendere ein Dreieck" oder "Lade Objekt aus Datei Flugzeug.x" "rednere Objekt". Ich würde vermuten, die richtige Antwort ist "beides".

Zitat

- Input / Output
( Extra GUI dafür entwickeln ? )

Ist möglich, PLIB hat es gemacht. Soll die Engine Betriebssystem-unabhängig sein?

Zitat

- Physik
( Kollision, Schwerkraft, aber was noch ?
- Portals, Octree, Frustrum Culling, etc ..
( Werlche Algorithmen einbauen ? )

Für welche Art von Spielen soll die Engine laufen?
Ich würde NICHT alle rendering Algorithmen einbauen, das kostet riesig Zeit und wer weiss für wieviel Spiele Du die Engine wirklich einsetzen wirst.

Zitat

- Modell Loader
( Sollen mehrere Modells ladbar sein ? Welches Modell Format für welche
Art von Gegenstand - Spieler, Bäume / Büsche, Steine etc .. )

"mehrere Modells " = "verschiedene Dateiformate"?
Dann wäre meine Antwort "nein".

Ich hab da mal eine eigene Frage dazu:

Ist es besser alle Komponenten in eine DLL zu packen, sowie es die TriBase Engine macht.
Oder ist es besser für jede Koponente eine eigene DLL zu schreiben, sowie es die ZFX Engine macht?

Ich denke da an DLLs für Grafik, Input, Sound usw.

Aber was ist der bessere Weg?

Ich glaub das ist im Grunde egal. Wenn man allerdings verschiedene DLL's hat, hat man den Vorteil das Patches kleiner sind.
Ich habe für jede Komponente der Engine einzelne DLL's. Das hab ich aber auch deswegen weil alles in PlugIn's verstaut ist.
Performancevorteile ergeben sich da nicht.


@Engine:
API Unabhängig ist schon sehr gut. Ich denke eine höhere Ebene ist dabei aber besser, da Dinge wie RenderEinPrimitiv doch recht unterschiedlich sein können und ergo bei OGL und D3D auch sind. Wird es schwieriger hier einen passenden Schnitt zu finden, als wenn man sagt RenderObjektXY.

Zitat

Einfach ne virtuelle Basisklasse, die mir ein Interface bietet zum Rendern und von der leit ich dann die Klassen um, die das dann in DX oder OGL umsetzen.

JA

Eine ordentliche Mathe Bibi kann nie schaden. Ich empfehle diese in eine separate DLL zu verstauen. Dann kannst du sie auch in anderen Projekten verwenden. Falls du in erwägung ziehst auch Optimierungen mittels SSE oder 3DNow!, etc. durchzuführen, dann bau alles auf Funktionszeigern auf.

Für jeden Objekttyp ein eigenes Dateiformat zu erstellen ist sinnlos. Eigentlich würd ich sagen das man sich ein eigenes Format erstellt mit dem die gesamte Engine dann arbeitet. Die Engine kann dann auch nur mit diesem Format Arbeiten. Das ermöglich Optimierungen hinsichtlich der Performance. Man kann natürlich auch ein fertiges Format nutzen, wie z.B. DDS für Texturen (PlugIn gibbet für Abode PhotoShop) in kombination mit obj oder 3ds. Wenn ein eigenes sollte es auf jeden Fall auf Chunks aufbauen. Damit es flexibel bleibt.

Zitat

- Physik
( Kollision, Schwerkraft, aber was noch ?
- Portals, Octree, Frustrum Culling, etc ..
( Werlche Algorithmen einbauen ? )

Physik ist sehr allgemein. Soll es ein Rennspiel werden ist eine gute Fahphysik zwingend, bei einem Shooter nur noch ein nettes Feature.
Wie Osram schon fragte. Für welche Art von Spielen willst du denn das ganze machen?
Wenn die Engine sehr Allgemein gehalten werden soll, dann bleibt dir nichts anderes Übrig als die Algos (Frustum Culling, etc.) aus der Engine heraus zu ziehen und in ein separates Interface zu packen. Das dann für jedes Spiel neu Implementiert wird. Das selbe gilt dann aber auch für den Szenengraphen, der doch sehr eng mit den Algos zusammen hängt. Ein passendes Interface dafür zu finden ist aber keine leichte Aufgabe. Zudem bedeutet das dann, das deine Render Unit nicht mehr im direktem Zusammenhang zum Szenengraphen steht. Die Render Unit muss also entsprechend Allgemein bleiben.

Zitat

- Ne Scripting Sparache. Kam als eines der lezten Dinge hinzu und ist m.E. nicht nötig.

Nötig ist sie wircklich nicht. Aber ganz nett wenn man eine hat Man hat auch hier die Wahl sich selber eine zu basteln, das sehr viel Aufwand ist, oder eine fertige zu nutzen. Z.B. Lua (so hieß die glaub ich) ist ganz gut.

Zitat

Vorerst soll die Engine immer mitkompiliert werden. Später werd ich dann wohl auf DLLs umsteigen.

Sei dir aber darüber im klaren, das es Unterschiede zwischen Nicht-DLL und DLL gibt. Dieser liegt vor allem in der Speicherverwaltung des OS. Ganz besonders Template BIbi's wie die STL machen hier immer wieder Schwierigkeiten. Ich empfehle dir dich für eines zu entscheiden und es dann dabei zu belassen.
Beide Varianten haben hier Vor- und Nachteile. Hier irgendwo im Forum wurden die schon mal besprochen.

Zitat

Na ich werd halt wie in jedem sonstigen Programm auch coden.
Warum sollte ich meinen Stil für ne Engine ändern :f

Ich weis nicht wie dein Code Style ist. Aber setzen gewisser Standards ehöht die einfachheit der Wartung und Erweiterung der Engine. Da eine Engine ein größeres Projekt ist, sollte man auch das nicht vernachlässigen. Du wirst es dir sehr Danken wenn du nach einer längeren Zeit mal wieder deine Engine betrachtest