(Wieder-)Einstieg in die Spieleentwicklung

[MDE]

Hallo Community,

nach knapp 10 Jahren Unterbrechung möchte ich mich gerne wieder dem 3D Game Development widmen. Ich habe seiner Zeit alle drei Bücher von Stefan durchgearbeitet und war damals zudem stets auf dem laufenden was die aktuellen Technologien betrifft. Nun ist natürlich sehr viel Zeit vergangen und ich habe mittlerweile so gut wie alles gelernte wieder vergessen (3D Mathematik, DX, OpenGL, SDL ... ) oder die damaligen Technologien sind nicht mehr zeitgemäß. Beim letzten Umzug bin ich im Keller auf zig ältere Fachbücher, u. a. auch Stefans, gestoßen und war gleich Motiviert mich wieder mit dem Thema zu beschäftigen. Ich habe mir zum ziel gesetzt eine kleine 3D Engine zu entwickeln. Dabei geht es nicht darum später ein tolles Produkt auf den Markt zu werfen sondern eher Erfahrung zu sammeln. Der Weg ist das Ziel!

Ich dachte mir dass es vielleicht gar nicht so verkehrt wäre zum Wiedereinstieg noch einmal die Bücher von Stefan durchzuarbeiten, um mir die wesentlichen Grundlagen, insbesondere die 3D Mathematik, wieder in Erinnerung zu rufen. Nun ist es so dass die Bücher etwas veraltet sind und ich daher statt DX lieber gleich auf OpenGL setzen möchte. Die entstehende Engine sollte auch gleich Plattformunabhängig (Win, OSX, Linux) sein. Und genau dafür fehlen mir die notwendigen Informationen und hoffe dass ihr mir vielleicht ein paar Tips geben könnt die mir den Wiedereinstieg erleichtern können.

Ich vergaß im übrigen zu erwähnen dass ich die Engine in C/C++ schreiben möchte. Die wesentlichen C++ Grundlagen habe ich noch im Kopf doch in den letzten Jahren fehlte es einfach an Praxis. Ich selbst bin auf die Entwicklung von skalier- und hochverfügbaren Webapplikation spezialisiert und beruflich als Technical Architect unterwegs. Die Softwareentwicklung und der Entwurf komplexer Systeme ist mein täglich Brot und ich denke dass dies eine gute Grundlagen sein sollte.

LG

[Schrompf]

Viel Spaß. Ich glaube nicht, dass ich Dir da irgendwas Konkretes raten kann. Fang an, und der Rest ergibt sich auf dem Weg. Und rechne damit, dass die erste Engine auf jeden Fall Grütze wird :-) Die nächsten werden dann besser.

Was sich meiner Meinung nach in den letzten 10 Jahren geändert hat:
- Grafikkarten sind Rechenzeit-Monster geworden. Mach soviel wie möglich auf der Grafikkarte.
- Damit zusammenghängend: Mach jeden Arbeitsschritt auf soviel Daten wie möglich gleichzeitig. Culling per Dreieck z.B. war vor 10 Jahren grad noch so vertretbar, heutzutage ist es tödlich.
- Shader! Nur Shader. Es gibt einfach nix anderes mehr, das wird alles emuliert.
- Eigentlich hätte ich Dir zu DirectX geraten, weil OpenGL auf all den Plattformen in Kombination mit Treibern und Distris eine kleine Hölle für sich darstellt. Aber wenn Du Dich da schon entschieden hast...
- Unbedingt: Entwickel die Engine zusammen mit einem Spiel. Sonst schreibst Du ne Menge Features und Strukturen, die Du nicht brauchst und die Dir dann nur im Weg sind. Den "ganzheitlichen" Ansatz mancher Software-Architekten halte ich für gefährlich, vor allem im Hobby-Bereich.

[pUnkOuter]

Kannst ja mal damit beginnen: http://www.opengl-tutorial.org/

[MDE]

Hi Schrompf,

vielen Dank für dein schelles Feedback. :)

Das Thema Shader ist wirklich totales Neuland für mich. Zwar ist mir die Theorie einigermaßen bekannt aber in der Praxis habe ich damit noch etwas gemacht. Ich lese immer von CUDA, GLSL, HLSL etc. Auch Multithreading hat ist ein wichtiges Thema geworden. Ich denke da werde ich mal ein paar Howtos im Netz suchen müssen. Für OpenGL habe ich mich lediglich zwecks der Portierbarkeit (und weil ich vorzugsweise Linux und OSX nutze) entschieden. Die erste Engine muss auch nicht sonderlich viel können und dient lediglich dazu die Grundlagen aufzufrischen. Mir würde es schon reichen wenn unterm Strich ein kleiner Level-Editor bei raus kommt und meine Engine die darin erstellten Level als Wireframe oder billig texturiert rendern kann. Dazu natürlich noch die Verarbeitung des Input und Ausgabe von Sound.

Sind das Culling mittels Octreee und BSP eigentlich noch zeitgemäß oder gibt es da mittlerweile schon bessere Verfahren? Zudem frage ich mich ob sich die Verwendung der STL und Boost negativ auf die Performance auswirkt. Wie gehe ich am besten an die Sache ran wenn ich die Engine plattformunabhängig entwickeln möchte? Gibt es da Besonderheiten auf die ich achten muss? Die erste Hürde die ich nehmen muss wäre der "Launcher" für die verschiedenen Plattformen. Ich überlege ob ich dazu wieder SDL nutze, oder aber ein eigenes Interface definiere und anschließend jeweils konkrete Adapter für OSX, Linux und Win32 implementiere.

Naja, als Software-Architekt neige ich dazu einfache Systeme stark zu strukturieren bzw. alles möglichst abstrakt zu entwerfen. Das ist an sich auch nicht verkehrt da unterm Strich eine flexible und wartbare Software entsteht. Ich denke aber auch dass dieses Vorgehen bei der Umsetzung der geplanten Engine eher ein Hindernis werden könnte. Ein eventuelles Refactoring kann dann später immer noch erfolgen. :)

BTW.: Kann man hier auch Mitglieder anhand des Wohnorts suchen? Entweder hab ich die Funktion übersehen oder es ist tatsächlich nicht möglich. Wäre nämlich icht schlecht wenn man ein paar Kontakte in der selben Region finden würde. So könnte man sich bei einem "fachlichen" Bierchen und Know-how austauschen.

[dot]

Wäre es nicht vielleicht sinnvoll, erstmal ein paar Demos oder kleine Spiele zu schreiben, um all die Dinge zu lernen und dein C++ Wissen aufzufrischen? Bei C++ hat sich außerdem auch viel getan...

Und rein prinzipiell: http://scientificninja.com/blog/write-games-not-engines ;)

[Schrompf]

BSPs sind tot. Man kann sie zwar immernoch einsetzen, aber die Leaf Nodes sollten dann doch ein paar Tausend Dreiecke enthalten, damit das für's Rendern was bringt. Physik und Konsorten arbeiten evtl. auch noch mit BSPs, aber auch da gibt es inzwischen bessere Strukturen, glaube ich. Spontan fallen mir da kd-trees ein. Octrees sind ne einfache Sache, die kann man hier und da noch gebrauchen.

Shader: wenn Du OpenGL benutzt, dann nutze GLSL. CUDA ist NVidia-Eigen, davon würde ich abraten. OpenCL ist zwar offiziell für alle, aber nur ATI hat dafür sinnvollen Support. Und beides sind eigentlich keine Grafik-APIs, sondern Programmiersprachen bzw. Umgebungen für allgemeine GPU-Programmierung. Wenn Du was Sichtbares auf den Bildschirm kriegen willst, ist GLSL Dein Weg.

STL und Boost wirken sich auf die Performance aus... sie sind deutlich besser und schneller als alles, was Du mit Deinen aktuellen C++-Fähigkeiten schreiben könntest. Du solltest nur eine Vorstellung davon haben, was für Strukturen sich dahinter verbergen, damit Du deren Performance-Eigenschaften einschätzen kannst und die richtigen Werkzeuge für die richtigen Aufgaben auswählst.

Und zum Thema Plattform-Unabhängigkeit: SDL oder SFML sind ein guter Ansatz. Du kannst das natürlich auch selbst schreiben, aber dann bist Du auch ne Weile beschäftigt und würdest eine Menge Lernprozesse durchmachen, die andere auch schon getan haben. Setze Deine Zeit weise ein, sie ist der limitierende Faktor.

[MDE]

@Schrompf

Das sind doch schon mal brauchbare Informationen. Besonders den KD-Tree werde ich mir bei Gelegenheit mal anschauen. Nun gut, bis ich bei dem Punkt angelangt bin dass meine Applikation dazu in der Lage ist Grafik zu rendern wird es ohnehin noch eine Weile dauern da ich beruflich sehr eingespannt bin und privat nur wenig Freizeit habe. Das Leben ist leider zu kurz um sich mit all den Dingen zu beschäftigen die man sich schon immer vorgenommen hat. =/

Bezüglich STL und Boost meine ich mal gelesen zu haben dass sich der Einsatz zwecks dem Overhead eher negativ auf die Performance auswirkt. Ist aber auch schon wieder ein paar Jährchen her und das kann sich geändert haben.

Die Verwendung von SDL oder SFML für den "Launcher" / WindowManager scheue ich ein wenig. Ich möchte ja versuchen etwas über die Entwicklung von plattformunabhängigen Anwendungen lernen. Eine Library kann ja jeder benutzten wenn man sich durch die Doku wühlt. Wie ich oben schon schrieb geht es mir in erster Linie darum mein Wissen zu vertiefen. Was unterm Strich bei raus kommt ist mir eigentlich egal. Dass ich mich für eine einfache 3D Engine entschied lag daran, dass meine Motivation auf Grund des Interesses stärker ist. Als Entwickler macht man ja oft den Fehler und fängt vieles an und bringt es nicht ganz zu Ende bzw. zieht die restlichen 20% des Projekts nur halbherzig durch.

Ich habe mir nun ein paar Open Source Engines geladen um mir zur Inspiration den Source anzuschauen. Ich denke dort werde ich auch das ein oder andere nützliche finden. Im Augenblick schlage ich mich mit den plattformunabhängigen Datentypen rum. Soweit ich es bis jetzt beurteilen kann gibt es diesbezüglich ja nur Unterschiede mit integer. Kannst du mir zu dem Thema ein paar gute Links / Artikel empfehlen?

[Jonathan]

Bezüglich STL und Boost meine ich mal gelesen zu haben dass sich der Einsatz zwecks dem Overhead eher negativ auf die Performance auswirkt. Ist aber auch schon wieder ein paar Jährchen her und das kann sich geändert haben.

Naja, da wäre das hier:
http://www.tomprogs.at/tutorials/progra ... tive.xhtml

Die STL ist nicht ohne Grund die Standardbibliothek. Klar gibt es einen gewissen Overhead, in Effektiv C++ steht zum Beispiel zu lesen, dass die ganzen Stream-Klassen durch die vielen beteiligten Objekte in bestimmten Situationen langsamer als die alten C-Routinen sind. Nur: Man arbeitet halt wesentlich effizienter damit. Die Programme sind kürzer und viel robuster, Fehler sind um ein Vielfaches unwahrscheinlicher. Und intern wird natürlich eine Menge optimiert. Ein unachtsam geschriebenes C Programm wird trotzdem langsamer sein.

Letztendlich wird deine Performance aber eh durch die Programmstruktur und die gewählten Algorithmen bestimmt sein. Es ist natürlich immer möglich, auf einer niedrigen Ebene etwas zu optimieren, aber Anfangen sollte man ganz oben. Und auch gerade boost bietet dir so unglaublich viele nützliche Funktionen, die man ständig mal gebrauchen kann. Bei boost ist halt Flexibilität und elegantes Design die oberste Grundlage, nicht unbedingt Performance. Aber wenn du es dir genau überlegst, sind sehr viele Teile deines Programms überhaupt nicht so kritisch, wie man denkt.

Ich benutze STL und boost wo es nur geht. Man kann sich da Sicher sein, eine robuste und funktionierende Lösung zu haben, spricht irgendetwas dann doch dagegen, kann man immernoch eine Alternative suchen. Aber die beiden sind die erste Anlaufstelle für Probleme jeglicher Art.

[MDE]

Hallo Jonathan,

im Nachhinein wurde mir auch klar dass ich während der Entwicklung der Engine / des Frameworks auf STL und ggf. auch Boost setzen sollte. Zum einen nehmen einem die Libraries sehr viel Arbeit ab und man muss das Rad ja auch nicht gleich neu erfinden. Wenn man hochperformanten Code schreiben will darf man im Grunde auch keine OOP einsetzen. Prozeduraler Code ist immer schneller als komplexe Klassenkonstrukte, doch die Wartbarkeit sollte man nicht aus dem Auge verlieren. Optimierungen kann man später immer noch vornehmen wenn es umbedingt sein muss. Bis ich aber diesen Zeitpunkt erreichen werde (wenn überhaupt) wird noch eine ganz Weile vergehen da ich mich ohnehin zunächst wieder mit all den anderen Grundlagen vertraut machen muss. Die letzten drei Tage habe ich mich mal umgeschaut was alles auf mich zukommen wird. Besonders was die 3D Mathematik angeht muss ich mir alle Grundlagen wieder ins Gedächtnis rufen. Derzeit bin ich auf der Suche nach einem guten Buch das die Themen möglichst einfach und nicht zu akademisch behandelt.

[pUnkOuter]

Das ist der richtige Ansatz. Erst Optimieren, wenn etwas als Flaschenhals erkannt wurde.