spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »SpieleMorpheus«

Für ein "3D" Spiel benötige ich eine GameEngine.

Du MUSST keine Engine verwenden - kannst du aber.

Am Anfang sollte dir eine Graphik / Audio Bibliothek reichen (ggf. Inputbibliothek).

Bei DirectX ist mehr oder weniger alles schon dabei. (C++)

Selbstzusammenstellung:

Bei Open GL (Open Graphics Language) nur Graphik (C / C++ / bindings in andere Sprachen z.B.: Java oder Python)
Bei Open AL (Open Audio Language) nur Sound und 3d Musik (C / C++ / bindings in andere Sprachen z.B.: Java oder Python)

Input weiß ich leider nicht da ich unter Java auf jinput zurückgreife...

So falls das falsch ist kann mich ja jemd. netterweise korrigieren.

Das L bei OpenAL und OpenGL steht nicht für Language, denn das wäre Quatsch. Es steht für Library.

Die Unreal und Cry Ungines sind keine "Grafik Engines", sondern "Game Engines". Game Engines kombinieren alle notwendigen technischen Bestandteile, damit darauf aufbauend ein Spiel entwickelt werden kann.
Mir ist bisher noch keine Sound oder Netzwerk Engine aufgefallen, da dafür i. d. R. Bibliotheken bzw. Frameworks (oder Bestandteile dieser) verwendet werden.

Es ist möglich, dass man seine eigene Engine zusammenstellt, nur sollte man immer an das Motto "write games, not engines" denken! Auch wenn es möglich ist, wird es dennoch diverse Jahre dauern, bis die Engine an und für sich einen ausreichenden Stand hat und selbst dann kann es sein, dass sie zu viele Unschönheiten besitzt, wodurch sich auch dann immernoch das Verwenden einer anderen Engine lohnen würde.
Viele, die eine Engine haben, haben i. d. R. auch das Problem, dass sie sich zu wenig mit der Entwicklung von Spielen und den Anforderungen an Engines auskennen, abgesehen von der Entwicklung von Engines an und für sich.
Hält man sich an das Motte, versucht man wahrscheinlich gar nicht erst eine allgemeingültige Engine zu schreiben. Man wird am Ende zwar sehr viel "Hardcoded" (bspw. die Spiellogik bzw. Teile davon) haben, was für eine Engine wahrscheinlich sehr ungünstig wäre, solange sie nicht extrem spezialisiert ist, für ein Spiel ist es aber nicht weiter relevant.

Vor kurzem bin ich auch über einen sehr ausführlichen Artikel bzgl. der Wahl der richtigen Engine gestoßen: The Game Engine Dating Guide: How to Pick up an Engine for Single Developers
Interessant anzumerken ist dabei, dass dir bereits die Sprache wichtig ist, mit der du arbeiten wirst (während viele andere lieber das nehmen, was auch die Profis nehmen).

Du solltest dir evtl. auch mal Unity ansehen. Das Scripting ist mit C# möglich, der Einstieg ist relativ einfach (finde ich), man muss aber auch diverse Dinge noch selbst implementieren (wobei es für viele Dinge bereits vorgefertigte Komponenten und Skripte gibt, wie bspw. den CharacterController für die Steuerung eines Charakters).

Und die Engines geben meist auch bekannt, welche Engines im Hintergrund verwendet werden, man muss nur an der richtigen Stelle gucken.

Zitat von »BlueCobold«

Das L bei OpenAL und OpenGL steht nicht für Language, denn das wäre Quatsch. Es steht für Library.

Ok thx. So lernt man dazu.

Nur mal nebenbei die Unreal Engine 4 hat keinerlei Bindung an UnrealScript, man kann problemlos sämtlichen Code in c++ schreiben

Also die Kernfrage war ja ob man diese Bestandteile einfach verbinden könnte.

Nein, kann man nicht, da nicht alle dieser Engines OpenSource sind und die Code Basis außerdem wahrscheinlich völlig unterschiedlich aussieht.
Häufig greifen diese Einzelsysteme auch auf grundlegenden Elemente der Engine zu (Dateien laden, Speicherverwaltung, ...), daher müsstest du viele viele Schnittstellen anpassen oder mitliefern. Nur dann hättest du wieder jede Engine an sich...
Sie sind natürlich absichtlich (vor allem die großen) so konzepiert dass sie Standalone Spiele erzeugen können.

Die Lösung:

Wenn du viel Zeit hast und erst noch ordentlich Programmieren lernst kannst du OpenSource Teile nehmen und daraus etwas eigenes basteln.
Ein gutes Beispiel wäre eine Engine wie Ogre oder Horde zu nehmen und diese zu erweitern.
Du würdest dann eigene Teile schreiben und andere erweitern/austauschen. Der Zeitaufwand wäre allerdings enorm (länger als das Spiel das du schreiben möchtest).

Man sollte vielleicht auch noch darauf hinweisen dass bei einer halbwegs modernen Engine auch nicht alles in Stein gemeißelt ist.
Du kannst fast immer Teile überschreiben oder auch erweitern (für die Unreal Engine bekommt man sogar Zugriff auf den Code). Kerbal Space Program (Unity) hat z.B. viele Teile der Physik selbst ergänzt.

Unterm Strich würde ich dir also dazu raten ein Komplettpaket zu wählen, oder, wenn du viel viel Zeit oder ganz komische Ansprüche hast alles selbst zu schreiben.

Der Meinung vom Kugelschreiber kann ich mich nur anschließen. Es ist sicherlich möglich, dass du Teile von größeren Game(!)-Engines nutzt, allerdings findest du diese häufig auch standalone.

• Für die Videowiedergabe wird häufig Bink Video o.ä. verwendet
  
• für Rendering wird oft nur ein Wrapper für die APIs geschrieben, der dann Engine-Spezifische Techniken implementiert (Deferred, LI, SSAO / SSDO und andere GI-Techniken, Geometry Instancing, Vertex Deformation, Shadercache, Ubershader, ...)
  
• die Physik wird häufig auf solche Boliden wie Havok ausgelegt
  
• Scripting machen auch extra Libraries (Lua by CryEngine, oder bei Unreal eben eine eigene)
  
• Serialisierung wird dann doch häufig noch selber geschrieben (da es sehr intentionsbezogen ist und sich nicht so leicht zu verallgemeinern ist)
  
• auch der Sound wird häufig durch extra libraries gestreamt
  
• Input ist dann häufig relativ minimal im Gegensatz zu den anderen Komponenten, wird daher häufig selber geschrieben (gerade besonders, um multiplatform zu unterstützen)
  

Du siehst also, dass du viele Komponenten schon beziehen kannst, WENN du denn vorhast eine Game-Engine nach CryEngine, UnrealEngine, Snowdrop, frostbite und wie sie alle heißen zu erstellen. D.h. du musst nicht zwingen eine große Game Engine zerschneiden, um an ihre Komponenten zu kommen (zumal das häufig entweder ziemlich lange dauert oder garnicht erst möglich ist)

Natürlich ist es auch ein berechtigter Grund, dass du dir Erfahrungen über so ein Konstrukt im Detail aneignen willst.
Nun musst du aber entscheiden, ob du detaillierte Informationen über diese Komponenten haben möchtest, oder lieber vertieft in eine einzelne (Rendering ist ein extrem großer Part) hineinschauen möchtest, oder vllt. doch nur einen Überblick über die Gestaltung eines solchen Frameworks Gedanken machen möchtest.


Willst du hingegen in die Spieleprogrammierung erst einsteigen (was ich so jetzt heraushöre), höre auf bitte auf, dir über solche Dinge Gedanken zu machen und fange klein an. Lerne lieber von Grund auf die Graphik APIs sehr gut kennen (und auf eine zu spezialisieren), sehr gut zu programmieren und im laufe der Zeit immer Größer zu werden. Wenn du ein paar komplexere Programme z.B. mit reinem D3D geschrieben hast, kannst du dir zum Beispiel eine größere Engine her nehmen und versuchen, ein Mod zu schreiben, oder die Engine zu erweitern. Du lernst dabei auch die Komponenten einer solchen Engine kennen und kannst danach dann versuchen, ein eigenes größeres Spiel zu schreiben. Bei letzterem wirst du dann auch schnell merken, dass du einiges an Code separieren möchtest. Dabei entsteht dann ganz automatisch deine Game-Engine.