Ich habe vor in nächster zeit eine Engine für mein neues Projekt zu programieren. Sie soll ungefähr die Leistung haben wie "Command&Conquer3 oder 4". Kann man das alles mit OpenGL und Delphi machen? Gibt es dazu entsprechende Tutorials, bzw. was muss ich alles beachten, was brauch ich dazu? Wie lange dauert es eigentlich durchschnittlich so eine Engine zu schreiben?

Es soll so aussehen, dass ich dann erst das Grundgerüst, die Engine baue und danach erst die entsprechenden "Maps" dazu.


Vielen Dank schon mal im vorraus

Wenn du sowas wie C&C 3/4 (also Tiberian Sun, bzw. der Nachfolger) machen willst, dann hast du erstmal zwei Möglichkeiten, da die Ansicht ja isometrisch (aka Generalsperspektive) ist. Entweder du programmierst eine reine 2D-Engine (siehe dazu Ortho-Modus) und renderst (oder zeichnest) die Grafiken bereits isometrisch vor (so wird es in den C&C-Teilen zumindest für die Umgebung gemacht). Dann brauchst du nur die vorgerenderten Tiles im 2D-Modus auf den Schirm zu bringen. Oder du machst alles komplett in 3D (also wie z.B. C&C-Generals). Das ist im Endeffekt dann wie jede 3D-Anwendung und du musst nur eine isometrische Kameraperspektive setzen, bist aber im Endeffekt sehr viel flexibler falls du z.B. mal die Kameraposition wechseln willst (z.B. Zoom, Rotation).
In Sachen Tutorials solltest du dir halt alles was mit OpenGL und entsprechend in deinem RTS vorkommenden Techniken zu tun durchlesen. Was das genau ist entscheidest im Endeffekt ja du selbst, bzw. deine Anforderungen an die RTS-Engine.

Aber um dich vorzuwarnen : Wenn das dein erstes OpenGL-Projekt sein soll, dann lass es. Eine Engine ist nämlich ein wirklick komplexes Konstrukt, dessen Ausarbeitung und Entwicklung locker mehrere Jahre verschlingen kann. Da gehört ja nämlich nicht nur Grafik dazu, sondern auch AI (u.a. Pathfinding, was bei RTS-Spielen ja sehr wichtig ist), Skriptsysteme (für Ereignisse), eine gute Datenverwaltung usw. Auch solltest du einen sehr guten Programmierstil mitbringen und dich mit Delphi auch gut auskennen, besonders Vererbung und Überladen von Prozeduren/Funktion) sind bei der Entwicklung einer Engine unverzichtbar.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich kann da auch nur empfehlen Schritt für Schritt dranzugehen und sich darauf einzustellen daß es sehr viele Versionen der Engine geben wird und du vermutlich oft neuanfangen mußt bis sie den gewünschten Stand hat. Denn ein so großes Projekt kann man von Anfang an nicht überblicken und so lernt man neue Dinge hinzu die nicht mehr ins alte Konzept passen. Vieles ist vorher ja auch nicht unbedingt immer klar. Daher vielleicht erstmal Modelle anzeigen, dann das Spielfeld darstellen usw.. und irgendwann hast du alles ausprobiert und kannst das Spiel zusammenbauen. Wenn du mit einer anderen Sprache OOP Erfahrung hast, dann dürfte es nicht schwer sein, sie auch auf Delphi zu übertragen. Wenn nicht, dann wirst du es zwangsläufig bei der Entwicklung lernen, weil bestimmte Dinge eben nicht beliebig auf jede Weise elegant funktionieren. Darum kann ich nur Raten: Bei Problemen nicht aufgeben und sich vor Allem auch nicht scheuen auch sehr viel Quelltext wegzuwerfen, wenn er nicht mehr deinem Kenntnisstand entspricht, da er sonst das ganze Projekt runterzieht.

Ihr solltet mal nen "Ich will ne Engine Schreiben FAQ" bauen. Bevor jemand dann hier im Forum Fragt muss er sich den durchlesen. Weil er ja nun nich der erste is... Aber vorallem bei echten OpenGL oder sogar Delphi Neulingen schreibt man jedesmal das selbe um die Tonnenschweren Schuppen von den Augen zu klopfen.

@SteffenG: Ich weis ja net wies bei dir im konkreten aussieht aber solche anfragen gabs schon einige male. Durchsuch mal das Forum nach "Engine" und du kannst dir das mal alles gaaaaanz genau durch den Kopf gehen lassen.

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

ich denke mal dass der, der es versuchen will versuchen sollte und 99% werden dann doch erstmal einen Pong-Klon schreiben, da es einfach besser ist um in die Materie einzusteigen...
das ist dann halt eine Erfahrung, die man gemacht hat...
nur besteht halt die Gefahr, dass man dadurch demotiviert wird und deshalb soltle man eben direkt kleine Brötchen Backen, v.a. wenn man gerade erst einsteigt...
man hat ja noch genug Zeit eine Engine zu programmieren, wenn man gesehen hat, dass man mit kleineren Dingen klarkommt...
außer man will das dann garnicht mehr

_________________
. . .

Andererseits denke ich daß es auch schwer ist dann mit etwas Einfachem anzufangen, zu dem man gar keine richtige Lust hat. Dann lieber doch eine Engine machen, nur eben man muß wissen, daß es nicht sofort was wird.
Zumal man nicht unbedingt bei jedem kleinen Projekt auch etwas für sein großes Projekt lernen kann.

das kann sein, aber wenn man mit OpenGL grade bei NULL anfängt, dann wird man auf alle Fälle was für das große durch das kleine Projekt lernen

_________________
. . .

Also ich hab dann nochmal ein paar Grundlegende Fragen zu Engines.

Ist es richtig ,dass eine Engine ein Programm ist, welches beim start einer "Map" gestartet wird und dann folgende Funktionen hat:

-es "malt" mithilfe der Map das Bild auf den Bildschirm
-es reagiert auf Tasten, und bewegt die Welt dadurch
-es berechnet Licht und Schatten, spiegelt Wasser
-....mehr fällt mir jetzt nicht ein, aber ist das soweit erstmal richtig?


Hat eigentlich schon mal jemand von euch eine Engine programiert? Wenn ja, wie habt ihr angefangen?

Ich hab als Abschlussarbeit auf der HBFS eine 3D-Engine auf OpenGL-Basis für einen kleinen FPS geschrieben, inklusive Netzwerkunterstützung, Soundsystem und eigenem Mapeditor. Da das aber damals so ziemlich mein erstes OpenGL-Projekt war, würde ich heute sehr viele Sachen anders machen.
Du musst halt bei deiner Engine erstmal in Betracht ziehen was diese überhaupt leisten bzw. bereitstellen soll. Eine Engine für einen FPS unterscheidet sich z.B. recht stark von einer Engine für ein RTS. Also am besten nicht direkt loslegen, sondern überlegen was deine Engine alles enthalten soll (unverzichtbar sind natürlich Grafikteil, Soundteil, Netzwerkteil, AI). Dann kannst du anfangen dir das grundlegende Layout zu überlegen und es danach in Code umsetzen.

Aber um eins zu sagen (das verstehen viele nicht) : Eine Engine ist nur dann nötig, wenn die Technik in mehreren Projekten Verwendung finden soll. Wenn du das alles für nur ein Spiel machst, ist eine allgemeine Engine wohl zu übertrieben, und es wird viel zu lange dauern bis du dich dem eigentlichen Spiel widmen kannst. Ich hab auch seit meiner Engine bereits mehrere Spieleprojekte realisiert, aber keines davon hat eine komplette Engine gebraucht. Für kleinere Projekte, oder einmalige ist sowas wie ein grundlegendes Framework, oder ein Basecode mit allen gebrauchten Units weitaus besser geeignet.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Sagen wir ich möchte jetzt ein Spiel programieren (wie Command&Conquer), wo es keine viele verschiedene Maps gibt, sondern nur eine große Map, in der das ganze Spiel abläuft.
Braucht man dann dafür keine Engine? Aber wie soll man das dann machen?

Und geht das auch ohne Engine bei einem Ego Shooter? (bin mir noch nicht ganz sicher ob ich es nun auf der C&C Art mache oder ein Ego Shooter. Kommt darauf an was einfacher geht)

Dabei ist auch noch zu bedenken was man als Engine bezeichnet. Auch die Quake Engine ist nicht total flexible. Wenn man da eigene Maps und Gegner hinzufügen kann ist das eigentlich schon flexibel genug um es Engine zu nennen. Was man sicherlich nicht machen sollte ist zu versuchen eine Engine für alle Arten von Spielen zu schreiben. Das geht in den meisten Fällen schief weil die Anforderungen einfach zu unterschiedlich sind. Daher würd ich das Spiel möglichst flexibel programmieren, also möglichst viel unabhängig vom Programm definierbar lassen. Vielleicht durch Skripte für Missionen und Gegner usw.. Bei Quake gibt man für Mods einfach ein anderes Verzeichnis an. Das bringt schonmal eine Menge an Flexibilität. Und das was nacher veränderbar ist, kann man dann Engine nennen.
Der Begriff "Engine" wird sowieso fließend und für alle möglichen Dinge sicherlich nicht immer gerechtfertigt verwendet.

Also Gegner, Missionsskripte, etc. ist ja nicht das Problem. Das was mir eigentlich Sorgen macht ist die Grafische Oberfläche.

Ich glaube die flexibelste Lösung ist da so ein ScriptSprache zu nehmen und damit dann so eine Art von OpenGL VCL zu skripten. Hier im Forum wurde schon so ein ähnliches Projekt vorgestellt, bei dem die OpenGL Befehle in die Scriptsprache eingebunden wurden.

Was genau macht dir denn Probleme bei der GUI? Ich finde grade diesen Teil eigentlich recht leicht zu implementieren, und besonders in der Anfangsphase reicht doch eine simple GUI die man über XML-Laden bzw. verändern kann. Hab selbst mal ne ziemlich komplexe OpenGL-GUI geschrieben, die eigentlich alle benötigten Komponenten enthalten hat und ihre Daten aus XML geladen hat, aber das war im Vergleich zum Rest des Projektes ziemlich einfach, wenn auch recht viel Tipparbeit.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Also wenn ich ein Spiel schreibe dann hat Engine beim mir wirklich die Bedeutung "MOTOR". Und mein Motor hat mit Grafik rein gar nix zu tun...

Ich bin ja eher auf der Strategiespielschiene unterwegs und bei mir ist der aufbau so:

Grafikteil: Ließt Karteninformationen und zeichnet nach Sichtbarkeitsregeln
KI: Bearbeitet Karteninformationen (Einheiten, Gebäude)
Steuerung: Wertet Nutzereingaben aus und gibts an Engine Weiter
Engine: Bearbeitet Karteninformationen nach Steuerungsinfos, Erstellt Ereignisse, Führt Berechnungen aller art nach den Spielregeln aus, etc.

Wobei die Steuerung meist in die Engine Eingebettet ist.
Eine Engine in der Form eines "Framework" (um mal Microsoft kompatibel zu beliben 8) ) ist föllig überflüssig, denn meine Grafik wird immer direkt an den Daten ausgerichtet die dargestellt werden sollen. Damit bin ich von Projekt zu Projekt viel Flexibler wenn es darum geht andere Daten darzustellen. (Man muss es halt frisch schreiben...)

Engine bedeutet bei mir: Das Ding was das gesamte Spiel steuert und dafür sorgt, dass alle Teile tun was sie tun sollen und die Spielregeln einhalten. Eine Art zentrale Kontrolle und Verteiler.

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