Enginepfad: Unterschied zwischen den Versionen

Aus DGL Wiki
Wechseln zu: Navigation, Suche
 
(Der Trampelpfad)
Zeile 12: Zeile 12:
  
 
Weiterhin ist die Wahl der Sprache zu treffen.
 
Weiterhin ist die Wahl der Sprache zu treffen.
Wenn ihr mit Object Pascal in seinen vielen Varianten arbeiten wollt, dann ist der [[DGLOpenGL.pas]]-Header genau das richtige für euch. Wenn es eine andere Sprache sein soll, müsst ihr euch dann nach einen aktuellen Header in Google umschauen. Es ist im vorhinein schon zu erwähnen das dieses Wiki Object Pascal in seiner Vielfalt verwendet.
+
Wenn ihr mit Object Pascal in seinen vielen Varianten (z.B. '''Delphi''') arbeiten wollt, dann ist der [[DGLOpenGL.pas]]-Header genau das richtige für euch. Wenn es eine andere Sprache sein soll, müsst ihr euch dann nach einen aktuellen Header in Google umschauen. Es ist im vorhinein schon zu erwähnen das dieses Wiki Object Pascal in seiner Vielfalt verwendet.
  
 
==Vorbereitung==
 
==Vorbereitung==

Version vom 30. Mai 2005, 22:01 Uhr

Der Enginepfad

Einführung

Willkommen auf dem Enginepfad des DelphiGL-Wikis. Dieser Pfad soll euch zeigen wie man eine Engine von grund auf konzipiert und realisieren kann.

Wie funktioniert der Trampelpfad? Im nachfolgenden Abschnitt findet ihr einen Text der euch etwas über Engines erzählen soll. Dieser Text ist durchsetzt mit Schlagwörtern welche Links auf andere Artikel im Wiki sind. Wenn ihr diesen Links folgt, erfahrt ihr mehr zu den entsprechenden Themen.

Sinn des Trampelpfades ist es euch die Artikel aufzuzeigen, welche ihr gelesen haben solltet und welche nützlich für den Einstieg in OpenGL sind. Am Ende dieses Trampelpfades findet ihr noch Links, die euch die Materie genauer erklären werden.

Der Trampelpfad

Am Beginn steht bei den meisten Anfängern zum Thema Engine die Frage "Was brauch ich um eine Engine zu entwickeln?". Je nach dem welches Betriebsystem ihr als Plattform gewählt habt, können sich die Hilfsmittel unterscheiden.

Weiterhin ist die Wahl der Sprache zu treffen. Wenn ihr mit Object Pascal in seinen vielen Varianten (z.B. Delphi) arbeiten wollt, dann ist der DGLOpenGL.pas-Header genau das richtige für euch. Wenn es eine andere Sprache sein soll, müsst ihr euch dann nach einen aktuellen Header in Google umschauen. Es ist im vorhinein schon zu erwähnen das dieses Wiki Object Pascal in seiner Vielfalt verwendet.

Vorbereitung

Als erstes muss uns klar werden welches Ausmaß die Engine erreichen soll und davon abhängig unsere Planung zu gestalten.

1. Es ist ratsam mit der Platformunterstützung anzufangen, da diese unsere unterste Schicht bilden wird.

Windows
Linux
MacOS X

2. Abhängig davon wählen wir nun unseren Compiler.

Delphi (Windows)
FreePascal (Windows, Linux, MacOS X)
gcc (Windows, Linux, MacOS X)
Kylix (Linux)
Visual C++ (Windows)

3. Nun sollten wir entscheiden welche Libary wir für das ansprechen der Grafikkarte verwenden.

DirectX (Windows)
GDI (Windows)
Mesa (Windows, Linux)
OpenGL (Windows, Linux, MacOS X)

Im diesen Fall gehen wir von OpenGL aus, da dies ein OpenGL Wiki ist.

4. Nun kommen wir zur allgemeinen Libaries für das ansprechen unsere Hardware.
Sound:

ALSA (Linux)
BASS (Windows, Linux)
Direct Sound (Windows)
FMOD (Windows, Linux)
OpenAL (Windows, Linux, MacOS X)
OSS (Linux)
SDL_Sound (Windows, Linux, MacOS X)

Netzwerk:

Direct Net (Windows)
SDL_Net (Windows, Linux, MacOS X)

5. Jetzt sollte man entscheiden ob und welche Libaries man zur erleichterung der nicht Hardwarebezogenen Aufgaben wählt. Um den Rahmen nicht zu sprengen nur ein paar Beispiele. Physik:

Havoc (Windows)
Newton (Windows, MacOS X)
NovodeX (Windows)
ODE (Windows, Linux, MacOS X)

Fenster:

GTK (Windows, Linux)
SDL (Windows, Linux, MacOS X)
TK (Linux)
Win API (Windows)

6. Nun beachten wir unser eventuell eingeplantes Budge (normalerweise 0€ ^_^) und gehen die Liste oben nochmal durch.

Planung

Wir gehen mal von ein "allinone wonder" aus und nutzen FreePascal aufgrund der Platformunabhängigkeit, SDL und sämtliche zusatzpakete zur Platformunabhängigen Fenserinitialisierung sowie Laden von etlichen Bildformaten. Für Sound werden wir aufgrund von kostengründen auf OpenAL setzen und für Physik ist eine vorhandene Libary wie ODE zu favorisieren, da diese schon ausgereifter als selbst entwickelte sind. Doch kann eine eigene Physik Libary eventuell schneller und viel schlanker sein, da man nur eine Handvoll dinge braucht.

Gehts nun Los?
Naja nun kommt der warscheinlich unangenehmste Satz für alle.
Die Entwicklung einer Engine bedarf einer ausführlichen Planung, was kurz und knapp ein Softwarecycle bedeutet. Nun sollte man die einzelnen Schritte eines Softwarecycles abarbeiten und ganz am ende, wenn viel zeit rum ist, kann man dann endlich anfangen den Compiler flott zu machen. Kleiner Tip macht euch die Mühe da diese sich auszahlt des so grösser das Projekt ist.

Die ersten Schritte in eine nicht reelle Welt.

Nun ist es so weit, wir wissen was wir wollen und haben uns alles Dokumentiert. Nun gilt es die einzelnen Module in die Tat um zu setzen. Hierzu sollen folgende Links weiter helfen.

Grundlagen:

  1. Template
  2. Kamera
  3. Schrift
  4. Input (Maus/Tastatur)


Fortgeschrittene Grundlagen:

  1. Sound
  2. Phyik
  3. Texturen
  4. Levelformat
  5. Modelformat
  6. Console (Laufzeit Schnittstelle zur Engine)
  7. GUI (Game User Interface)
  8. Netzwerk


Fortgeschritten:

  1. Shader
  2. Materials
  3. Packformate
  4. VFS (Virtual File System)
  5. Soundformat erweitrungen
  6. KI


Sieht doch eigentlich nach nicht so viel aus oder ? Hehe der Schein drügt, in grossen Firmen sitzen meist mehere Programmierer die in diesen Gebiet erfahren sind an nur ein maximal 2 Modulen.
Wie ist es dann möglich das es trotzdem so viele Spiele/Engines gibt die nicht von Firmen sind ?

  1. die Planung wird bei weitem nicht so gross ausfallen wie in Grossfirmen
  2. die koordination von vielen Person ist sehr schwer und es kann zu grossen Zeitlücken kommen
  3. meistens wird die Planung sowieso nicht in die Tat um zusetzen sein, es gibt immer ein Problem
  4. ein kleines Team kann in besten Fall sich gegenseitig hoch putschen und zu mehr anspornen
  5. Grossfirmen haben selten die Möglichkeit mal ein Codefetzen in Foren zu setzen und verbessern zu lassen
  6. das nutzen von Libaries ist sehr Zeitsparend

Die Engine ist fertig oder doch nicht ?

Fertig ist eine Engine nie, man kann sie immer wieder opimieren und erweitern. Doch kommt der Punkt wo die Qualität den Ansprüchen völlig ausreichend ist. Man sollte nun noch überlegen ob man eventuell Tool zur leichteren Handhabung der Engine entwickelt. So kann ein GUI-Editor oder Material-Editor die Arbeit um vieles erleichtern, wenn es dann heisst die Engine auch zu nutzen.

Nun bleibt es nur noch zu sagen, viel Glück und erfolg mit der Entwicklung einer eigenen Engine und mögen die bereitgestellten Links zur erleuchtung führen.

Links