Eine Engine ist schon etwas komplizierter. Üblicherweise besteht sie aus Modulen die jeweils eine spezielle Aufgabe übernehmen.

Aus dem Bauch raus fallen mir diese ein:


Objekt-Manager (Speichert die ganzen veränderlichen Objekte in einer Szene. z.B. Spieler)
Input-Manager (nimmt Maus und Tastaturevents entgegen und leitet sie an die Objekte weiter)
Physik-Modul (Berechnet Kollisionen und Bewegungen)
Partikel-Engine (z.B. für Feuer und Rauch)
Grafik-Modul (Mit Textur-Manager, Raum-Unterteilung, Schattenwurf etc)
KI-Modul (steuert z.B. Bots wenn vorhanden)

Und sicher noch das ein oder andere mehr. Ich selber hab noch nie ne Engine geschrieben. Es gibt einige hier die das getan haben. Das ist eure Chance! Nebenbei könnte gleich mal das hier aufgepeppt/überarbeitet werden.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Es kommt sehr auf die Zeit an, die man reinstecken will/kann.
Je mehr Zeit man reinsteckt, des so mehr kann am Ende rauskommen.
Ich hab die Erfahrung gemacht, konzipiere was kleines und bau es später aus.
Mitlerweile bin ich z.B. beim Projekt Karmarama++, also von kleinen templates, zu frameworks, einer kleinen engine, einer größeren engine, eine große engine und als letzes ein Umstieg von freepascal auf c++.
Man sollte auch erstmal entscheiden, will ich ein Spiel machen oder eine Engine schreiben.
Beides geht nicht wirklich, entweder ich schreibe eine Engine und versuche damit dann ein Spiel zu schreiben(eher nicht so toll) oder ich schreibe direkt ein Spiel.
Engine entwicklung hat kein Endpunkt(es kommen immer neue module,erweiterungen,änderungen), ein Spiel schon(steht der content, dann gibt es nur noch bugfixes).
Wenn es doch eine Engine werden soll, dann plan dir ne kleine übersicht, was willst du so als erstes drin haben(z.B. Fenstersystem,3D Renderer,2D Renderer, Sound).
Entwickel dies, wärend der Planung fallen dir eh immer wieder bessere Möglichkeiten ein und wie das ganze flexibler zu gestalten ist.
Später kann man sich dann gedanken machen, wie schauts mit SceneGraph, Physik, Graifkformaten, Scriptanbindung aus.
Wenn du so weit bist, dass du dir gedanken über SG,Model/Levelformate machst, dann wird es auch ziemlich wichtig ein Editor zu haben.
Eine Toolchain wird also auch ein Teil sein, wie diese ausfällt ist sehr unterschiedlich.
Ich z.B. benutzte Blender mit einen eigenen python exporter für meine Models und wenn mein neuer SG fertig ist, kommt der erste Welt Editor.
Später könnten vieleicht auch tolls für VFS, ScriptTools, Konvertierungstools und andere Helfer mit einfliessen.
Ich arbeite aktuell an einer eigenen miniScriptsprache, die nur für das Materialsystem genutzt wird und dafür gibt es dann auch ein tool, welches den optimierten bytecode erstellt.
Im Bereich Texturen hat sich bei mir auch extrem viel über die einzelnen Etappen getan.
Für meinen Karmarama c++ Version lasse ich nur noch DXT1,DXT5,rgba und ein 256 grauwert format zu, alle in einen eigenen DDS Loader supportet.
Früher hatte ich wesentlich mehr Formate im Angebot, jpeg,png,bmp,... sogar ein eigenes haarwavelet basiertes Format aber dies macht nur Probleme und bringt mit keine Vorteile(mir liegt Performance und nicht eine lange Format Supportliste am Herzen).

Also einfach am Anfang überlegen welche Richtung(z.B. cross platform, 3D, 2D, gengre spezifisch, schwerpunkte auf bestimmte Hardware oder Software Technik) du einschlagen willst und dann immer Etappenweise weiter Planen und realisieren.
Dann loslegen und versuchen soviel Selbstmotivation wie möglich zu erzeugen(z.B. schafbare Tasklisten/Milestones, kleine Features vorziehen, die vieleicht eher unwichtig sind aber dir eine Freude bereiten).
Mut zur Lücke und scheu nicht davor, fremden Code zu verwenden.
Wenn jemand schon ein Lua,MySQL,PostgreSQL,OpenAL,Ode,Newton,VFS Interface oder was auch immer programmiert hat, nimmer es erstmal.
Später kannst du es wieder rauswerfen und durch eine eigene Lösung ersetzen oder du hast festgestellt, dass dies genau das tut, was du wolltest und hast ne menge Zeit gespart.

Hier noch ein paar Links zu meinem Zeuch.
mein altes Projekt X-Dream(viele links tot, da wiki abgeschalten hab)
X-Dream svn
Karmarama
Karmarama(Delphi/Freepascal)
Karmarama(gcc/vc++)

Grob erklärter grundaufbau von Karmarama++.
Eine handvoll von abstrakten Klassen/Interface für Fenster,Zeichengerät,Programm,Bildschirm.
Von diesen wird je nach Betriebssystem(und damit auch interne compilerflags) die uses/inlcudes gelenkt.
Also wenn Windows dann compilier und link mygdi sonnst, wenn Linux dann myXLib mit.
Ich benutzte in der Basis erstmal eine Klasse Application, welche meine Fenster verwaltet und die messageloop für das jeweilige OS enthält.
Dann gibt es noch Window, welche den jeweiligen OS Fenstercode wrappt und Instanzen von z.B. ZeichnContext und GUI binden kann.
ZeichenContext ist eigentlich wie canvas bei der Delphi VCL, es ist das mädchen für alles sichtbare.
Ich biete generell 2 Arten von Context an(theoretisch, denn Agg ist nicht wirklich eingebunden),3D(OpenGL) und 2D(AGG) Context.
Wenn man also ein Fenster erstellt, dann kann man auch ein Kontext erstellen und diesem zuweisen.
So bleibt das Konstrukt flexibel, denn man kann später auch D3D,D3D für xbox,Wii API,PS3 API,Mesa,... in einen eigenen Context Kapseln und diesen zuweisen.
Damit alles seine richtigkeit behält, gibt es ja eine Abstrakte Klasse/Interface, wovon abeleitet werden muss.
Wenn ich also eine Textur brauche, dann lasse ich mir von Fenster.Context.GenerateTexture(...); eine erstellen und arbeite mit dieser.
Jeder Context kann seine eigene Implementierung von Texturen haben aber durch die abstrakte Klasse/Interface sind auch hier die minimalimplementierung vorgeben.
Dies gilte für alle Ressource, die 2D/3D bezogen sind, die Texturen,Meshes,Shader und so weiter.
Also Application hält alle registrierten Fenster und verarbeitet und leitet die OS Messages weiter.
Fenster bietet ne menge Callbacks(OnPaint,OnIdle,OnMouseDown...) an, wo man eigene methoden/funktionen einstöpseln kann.
An einem Fenster können jeweils ein Context und eine GUI Instanz gehangen werden.
Die GUI Instanz nutzt automatisch die Contextinstanz zum zeichnen und ist nur für 2D darstellung zuständig.
Der Context bietet alle zeichenfunktionen, die der Engine zur verfügung stehen und kapselt intern mehere Ressourcenmanager(Texture,Material,Shader,...).
Der gesammte restliche Code arbeitet entweder auf diesem Core oder ist unabhängig einsetzbar(Sound,Physik brauchen keine Core Klassen).


edit:

Ich hab mir schon vielemale vorgenommen, den Pfad weiter zu bestücken aber finde nie wirklich zeit dafür ^^.
Mein Paper über SceneGraph gammelt auch seit ner weile auf meinem Linux Desktop.
Ich hab mein Notebook wieder flott gemacht und kann nun in den langweiligen Unistunden mal was schreiben(hab allerdings Fr,Sa,So,Mo und eigentlich auch Do frei, also nur Di und Mi möglichkeit dazu).
Vieleicht einfach mal boardsuche nehmen, Author TAK2004 und mal die interessanten Threads raussuchen. Ich hab eigentlich meine Kentnisse versucht im Forum zu veröffentlichen und Diskursionen zu den Thematik anzuregen. Aktuell z.B. dieser hier . Allerdings gbt es ja auch Threads zu SceneGraph,GUI,dglgui,FPC,... .

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ein nicht zu verachtender Punkt wenn man andere seine Produkte Nutzen lassen will sind Plugins. Es ist erstaunlich wie sich die Entwicklungs und Adaptionsgeschwindigkeit erhöt, sobald andere Menschen ihre eigenen Ideen in ein Projekt einbauen können.

Bei einer Engine könnte dies bedeuten Shader hinzufügen zu können, oder neue Texturloader, neue Modellloader etc. Und zwar so, dass niemand in der Engine selbst rumprogrammieren muss(!).

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Dies ist nicht nur ein "nicht zu verachtender Punkt" sondern ein elementarer Pfeiler bei der Engine entwicklung.
Im gegensatz zur Spieleentwicklung hat man bei der Engineentwicklung keine exakte Vorgabe, was zu realisieren ist und bietet einfach mal die vom Engineentwickler emfpohlenen Möglichkeiten. Den rest liefer dann die Community, in Form von Addons.

Ein kleines Beispiel.
Du möchtest ein Video darstellen aber in der Engine ist kein Videoformat im support(nur ein DDS Format ^^).
Dann muss dieses leicht nachrüstbar sein und hier kommt es dann auf das API Konzept der Engine drauf an.
Stecker->Adapter->Buchse Prinzip((divx,xvid,mpeg,... Loader)->Video2Texture Modul->Engine.Texture).
Also nicht deine Textur die arbeit machen lassen sondern der Texturklasse Daten und Datenbeschreibung geben.
Deine Engine.Textur beherscht z.B. RGBA,RGB,Grauwerte Allgemein und je Nach RenderContext noch vieleicht andere FarbFormate wie DXT.
Nun kannst du eine Klasse schreiben, die anhand von Zeit und eines Buffers, Videframes anfordern kann und diese entsprechend in das Engine Format konvertiert(wenn mpeg z.B. YUV Bilder liefern würde, dann müsste dein Adapter diese in RGB umwandeln).
Das Bild kann nun der Engine.Textur Klasse übergeben werden.
Gleiches Prinzip gilt auch für Models.
3DS Loader->Adapter->Engine.Mesh
Der Adapter muss wissen, das die Meshklasse(von Engine) z.B. einen Vertex,Normal,Color,TexCoord,Face Liste anbietet und per Flag an oder abgestellt werden kann.
Nun kann der Adapter die routine vom 3DS Loader aufrufen und die Daten in das Meshformat umarbeiten und in die Instanz von Engine.Mesh übergeben werden.
Also das anbinden von neuen Formaten stellt ein geringes Problem dar aber wie aufrufen ?
Die Frage sollte nun sein, wie kann ich diesen Adapter überhaupt einstöpseln und hierfür bietet es sich an, Adapterlisten in den jeweiligen Managern zu packen.
Da ich mit meiner Portierung von meiner Engine noch nicht so weit bin, dass solch ein Manager schon wieder existiert, biete ich mal nur ein Pseudocode.



Wenn nun dein Materialsystem eine Textur laden will, dann guckt es bei TTextureManager vorbei und sucht nen Adapter.
Ist keiner da dann kann das File ned geladen werden und hier fängt dann ein anderes Problem an xD(Fehlerbehandlung).

Muster/Pattern sind was feines, ich kann hierzu nur mal das Buch "Entwurfsmuster von Kopf bis Fuß" emfehlen.
Das Buch ist von O'Reilly und ist ein wahrer Schatz für Programmierer.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Weil ich gerade das Buch empfohlen habe, fällt mir folgender Artikel ein.
Ich hatte das Buch in Rahmen eines Wettbewerbs gewonnen.
Für den Wettbewerb hatte ich ein Artikel geschrieben, der hier zu finden ist.
Es ist ein sehr Allgemeiner und Sprachenunabhängiger Artikel für die Entwicklung auf Windows und Linux(dinge die für Linux gelten sind fast ohne probleme auf Consolenentwicklung abbildbar).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Gibt es meherer Renderprozeduren oder nur eine wo dann nach dem Motto for i := ... dann jedes Objekt einzeln gerendert wird oder wie muss man sich das ganze vorstellen?
wie speichert man ein Level am besten? einfach alle XYZ koordinaten usw in eine Datei speichern oder wie ?

Hallo,

du kannst ganz einfach ein Objekt nach dem anderen rendern. Vorher musst du noch die Kamera bewegen, dann kannst du die Objekte in einer for-Schleife abklappern und jedes einzeln rendern lassen. Am besten erstellst du dir Klassen für die Objekte, die das Rendering selber übernehmen.

Beim Speichern kommt es ganz darauf an, was du machen willst. Ich habe zwei Formate - ein unkompiliertes, das man mit dem Editor bearbeiten kann, und ein kompiliertes, das dann von der Engine gelesen werden kann. Das hat den Vorteil, dass du im Editor auch Namen etc. vergeben kannst, die später eher hinderlich sind.

Du kannst entweder die Daten "roh" in die Datei speichern, also alle Vertices abklappern und schreiben, oder du schreibst nur rein "Würfel - Position - Drehung - Größe".

Grüße,
Yogu

Ja es gibt mehere möglichkeiten der Renderloop.
Die einfachste ist das einfache durchgehen aller Objekte, mit einer Schleife.
Man kann alle Objekte durchgehen und die überspringen, die nicht sichtbar sind.
Spatial Systeme, wie Octree/Quadtree verwenden und alle Objekte immer auf die zugehörigkeit hin prüfen
oder das Spatial System und die Objekte mit einem Event/Abo/Observer/... ausstatten.
Hinter den Schlagwörtern vesteckt sich die gleiche Technik, also man hat seine Objektliste L und hat noch eine Liste mit aktuell sichtbaren Objekten Lout.
Durch das Observer Modell wird der Lout automatisch bescheit gegeben, wenn sich ein Objekt verändert hat(auch zerstört oder ein neues erzeugt wurde).
Das Observer Modell ist das schnellere, da dieses sich nur ändert, wenn sich das Objekt verändert hat(es gibt LevelObjekte(statisch und fallen bei Observer nur beim Init einmal auf),physik Objekte(werden in einer Loop(teiliste mit allen aktiven objekten) aktualisiert und melden sich dann bei änderung),scriptgesteuerte Objekte(sind nur beim init aufruf einmal in last, sonnst wird auf zu ändernde Objekte direkt zugegriffen und keine loop über alle)).

Ein Beispiel:
Wir haben eine Szene mit einem Octree und vielen Objekten, sowie einer Kamera.
Wenn ein Objekt erzeugt wird, dann registriert es sich in der Liste des passenden Nodes im Octree.
Verändert sich das Objekt in seiner Position, dann gibt es dem Node bescheit und eventuell wird es bei einen anderen Node angemeldet. Wenn das Objekt zerstört wird, dann meldet es sich bei dem Node wieder ab.
Das Octree muss also nicht jedes Objekt durchgehen und prüfen ob noch alles beim alten ist, sondern die Objekte melden sich beim Octree, wenn sie sich verändert haben(das Octree muss auch das Objekt nicht kenne, nur wissen das es von einer Observerartigen Klasse abgeleitet wurde).
Die Kamera ist auch ein Objekt(braucht kein Observer), dieses hat zum Beispiel eine FrustumViewList, wo alle Nodes rein kommen, die Sichtbar sind.
Ändert sich die Kamera, dann fragt sie die neuen Nodes beim Octree ab und löscht die nicht mehr im Frustum liegenden Nodes aus der Liste. Ruft dann die Liste zum zeichnen auf und die Nodes leiten den aufruf dann an deren Liste.

Wo liegt der Vorteil von diesem System ?
Es wird klar, wenn sich Daten mal nicht ändern, denn dann passiert garnichts, man kann sofort die letzte Liste rendern.
Da die Kamera sich eigentlich immer bewegt, hab ich extra das Octree mit ins Beispiel gebracht, da das Frustum nur auf das Octree prüft und damit die vielen tausend Objekte im Octree nicht betrachtet.
Die Kamera ist der Direktor,das Octree ist hier Quasi der Klassenlehrer, die Nodes die Klassensprecher und die Objekte die Schüler. Der Direktor(Kamera) hat eine änderung zu melden und redet mit dem Klassenlehrern(Octree), der es den beiden Klassensprechern(Nodes) weiter gibt, die es wiederrum den Mitschülern(zeichenbare Obj) erzählen.
Da die Objekte sich nur bei änderungen an das fixe Octree wenden, entsteht von der Seite nur selten Arbeit.
Die Kamera hat weniger Arbeit zu verrichten, da das Spatial System die zu kontaktierenden Objekte stark reduziert hat.

Also hat man eigentlich immer eine Loop aber diese kann durch verschiedene Techniken verkürzt werden.

edit:
Zum Thema Szenenspeicherung empfehle ich folgenden Aufbau.
Szenenformat->Modelformat
Das Szenenformat enthält Positionen, Größe, Ausrichtung, ModelFileName und vieleicht noch ein paar Metainfos(kann man zum anfang sehr gut mit ner XML file machen).
Wenn was größeres mit reinkommt, wie ein Haus, Landschaft, dann sollte diese dann vom Modelformat in das Szeneformat importiert und überarbeitet werden(zerlegen, damit das Spatial System noch was draus machen kann).
Dafür sollte dann ein Flag im Szenenformat geben.
Man kann auch das große Model(Landschaft,Haus) schon im Modeleditor in meheren Teilen exportieren.
Für ein performantes Modelformat schreibe ich im moment ein Artikel im Wiki aber dies kennt zur Zeit keine Bones.
Alternativ kannst du auch mit 3DS als Einstieg verwenden.

Ich empfehle ein Szeneformat, welches nur Metainfos enthält und ein Modelformat.
Ein eigenes Tool, mit dem man die Szenen zusammenklicken kann, bietet auch dann eine Funktion zum zerlegen der größeren Models.
Das Tool wäre auch nur ein Platzierungstool(zur erzeugung der Szenenformat Datei), also damit kann man nicht modeln und spart damit viel Zeit bei der Entwicklung. Als Modelwerkzeug nutze ich Blender, wofür ich ein exporter geschrieben hab, der mir die Modelformat Files schreibt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Falls einige Wörter dir wahlweise chinesischoder spanisch vorkommen, kannst du sie im Wiki nachschlagen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Hehee ja ich bin jetzt ne weile dabei mich da durch zu beißen.
Danke erstmal.

Ich hab heute mal ein bischen Uni- und Freizeit genutzt und ein bischen was ins Wiki geschrieben.
Zwar hat der Engine Trampelpfad nur nen kleines Lifting bekommen aber ich hab mal 2 kleine Artikel eingefügt.
http://wiki.delphigl.com/index.php/Enginepfad
http://wiki.delphigl.com/index.php/Modelformat
http://wiki.delphigl.com/index.php/Adapter_Muster
Sind so Sachen, die in dein Interessengebiet gehen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Was bei mir derzeit der Aufhänger ist, ist wie mann denn Sachen wie ein einzelnes Objekt oder Level am besten "Zeichnet".
Ich denke es wird nicht direkt in einer Procedure stehen sondern eher als "Bauanleitung" in eine Datei ausgelagert oder?

Da gibt es einige Wege ... .
Man kann z.B. solche "Bauanleitungen" in form von Skripten oder Konfigurationsdatein mitliefern(flexibel aber langsamer).
Alternativ schreibt man im Code die verarbeitung der Daten.
Man benutzt ein selber festgelegte abfolge zum zeichnen und passt externe Daten diesen an.

Mein letzer Renderer bestand aus einen SzenenGraph,Szenenformat,Materialsystem und Texturloader.
Der Szenengraph hat die Datei geladen und Nodes in den Graphen hinzugefügt.
Wenn Nodes gezeichnet werden mussten, dann wurden sie geladen(wenn noch nicht im Speicher) und zum zeichnen geschickt.
Mein SG hat anhand des Datenhashes, jeden zu zeichnenden Nodes, die Liste sortiert und zusammengefasst.
Der Renderer hat dann 2 Passes gehabt, ein ZPass(zeichnet nur in den Tiefenpuffer) und ein Normalen Renderpass(zeichnet die echte Szene).
Er hat also das Model genommen und das Material gebunden, Model gezeichnet, Material zurück gesetzt.
Mein Material sind LUA scripte, in denen dann drin steht, was zu für Shader gebunden werden sollen, welche Daten übergen werden müssen.
Meine Scripte bestehen aus 3 Funktionen Bind(),Unbind() und Init(), wobei Init beim laden des Materialfiles ausgeführt wird.
Dort steht drin, welche Shaderdatein und Texturen noch benötigt werden und stösst ein Ladeprozess an.

Mein neuer Renderer wird in kürze noch 2 weitere Funktionen bieten SkipDraw() und Draw(...).
SkipDraw bricht das gesammte Batch ab, also alle Nodes, die den gleichen Datenhashwert haben und Draw(..) ist halt die Drawfunktion die ich vorher ausserhalb des Scriptes hatte.
Dazu kommt, dass ich die Bind/Unbind Funktionen nun ein Parameter RenderPass haben, welcher aktuell ZPass oder DrawPass enthält.
Allerdings bin ich noch nicht sicher, ob ich da nicht noch ein bischen umstrukturieren muss.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004