spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

In dem TombRaider Jam gibt es keine Preise zugewinnen und die Regeln sind auch nicht sehr Streng, und sogar Abgabe Termin war nicht fest. Diese wurde diese Woche weiter nachvorne verlegt, den ich denke weil sich grob gesagt 100 Teams angemeldet haben, wird es toll wenn alle möglichst weit kommen!

Heute konnte ich mit meiner Lara duch ein Erstes Level Laufen und auch wenn ich Shader Mässig nichts reissen werde, fand ich's schon retro-atmosphärisch, es wird

Och, die Ärmste hat ja 'n Unterschenkel verloren...
Frau hats eben nicht leicht als Grabjägerin.

vielleicht macht es Ihnen trotztem einfach Spaß, auch die Herausforderung und vielleicht bekommt meine Lara auch noch ein Kin

Ich habe mein Highscoresystem endlich am Laufen. jetzt auch mit Indikator für den Wert der letzten Runde.

Hi,

zur Zeit arbeite ich an einem etwas größeren Projekt, der qEngine. Dabei handelt es sich um eine 3D-Engine, die ich in C++ 14 schreibe. Ich hatte vorher schon einiges in dem Bereich gemacht, aber lege bei diesem Versuch vernünftigen Wert auf Architektur und Entkoppelung.




Die Engine besitzt derzeit einen Render-Layer, der von der eigentlichen Implementierung (aktuell OpenGL 4) abstrahiert. Die Implementierung ist also austauschbar und basiert auf einer Render-Queue, die die Drawcalls sammelt und sortiert. Das Ganze ist ein klassischer Forward-Renderer, der mit Materials arbeitet und später auf Forward+ erweitert werden soll. Mittlerweile bin ich so weit, dass ich vernünftig weitere Render-Features implementieren kann. Als nächstes kommt etwa ein layer-basiertes Rendering, um bspw. 2D-Overlays erzeugen zu können. Danach möchte ich mich gerne an ein Event-System wagen, das an alle Subsysteme Events verbreiten kann, auf die dann reagiert werden kann.

Die Engine selbst hat als Grundlage ein Entity-Component-System, wobei ich hier ebenfalls noch einiges zu tun habe. Weiterhin gibt es noch einen Input-Layer, der aktuell Keyboard und Maus unterstützt. Fensterkram- und Kontexterzeugung mache ich derzeit mit GLFW, wobei ich eben die Events (z. B. Eingabe) an die Engine selber propagiere, die diese dann weiter verarbeitet.

Weiterhin habe ich in einem anderen Projekt noch einen effizienten 2D-Spritebatch geschrieben, den ich als Grundlage für das Vertex Batching nehmen werden. Partikel-Engine habe ich ebenfalls in einem separaten Projekt geschrieben und werde ich integrieren. Gibt noch sehr viel zu tun und das Ganze ist derzeit ein Solo-Freizeitprojekt, da ich aber seit Jahren in der Entwicklung und im Projektmanagement arbeite, kann ich die Implementierungsumfänge glücklicherweise recht gut abschätzen und komme ganz gut klar. ToDo-Liste ist ewig, bspw. Frustum Culling, Occlusion Culling, ... - mir fehlt nur leider gerade ein wenig die Zeit, weswegen ich ganz froh war, dass ich über Weihnachten ein bisschen Energie reinstecken konnte. Ziel: soll mal ein vollumfängliches Spielesystem werden, in das LUA als Skriptsprache integriert wird und das auf einer Switch läuft.
Der Name kommt nämlich daher, dass ich mich bei dem damit zu realisierenden Projekt an dem Rollenspiel Quest 64 / Holy Magic Century auf dem N64, ein Spiel, das für mich damals nen ganz eigenen Charme hatte, orientiere.

Eine grobe Übersicht der bisherigen Features:

- Mesh-Loader mit TinyOBJ (wird gerade durch Assimp ersetzt)
- Statistiken sammeln (z. B. Vertices aufm Bildschirm)
- Cubemaps, Skyboxes
- Zentraler Asset-Manager
- Austauschbare Grafik-API
- Cubemap Reflections, Refraction
- Shadow Mapping, PCF, Slope-Scaled Depth Bias, Konfigurierbarkeit von Shadow Castern- und Shadow Receivern
- Directional Lights, Point Lights, Spot Lights
- Render-Queue als Basis mit Drawcall-Sortierung
- Shader-Preprocessor (define, include, ...)
- Kamerasteuerung
- Input-Layer
- Entity Component-System mit hierarchischem Transformationssystem
- Heightmapping
- Normal Mapping, Specular Mapping, Emissive Maps
- Nebel
- Alles aus der Anwendung heraus parametrisierbar
- Serialisierbares bzw. deserialisierbares Szenenformat
- Funktioniert auf Win, Linux und OSX
...

Natürlich fehlt noch ein Haufen Zeug, damit daraus wirklich eine Engine wird. Bis jetzt habe ich aber trotz mangelnder Zeit ein Ergebnis geliefert, das doch zumindest ganz gut funktioniert, keinen Speicher leakt und eine Architektur besitzt, in der es wenig Koppelung und viel Kohäsion gibt.

Parallel integriere ich die Engine in einen Welteneditor, den ich ebenfalls in C++ und Qt schreibe.

Mein Hintergrund: habe neben dem Beruf als Entwickler und IT-Projektleiter 4 Jahre parallel Informatik mit Nebenfach Mathematik an der Fernuni studiert und schreibe gerade meine Bachelorarbeit im Bereich Computergrafik und schreibe seit jeher private Projekte nur mit C++, weil mir die Sprache am Meisten liegt. Mache privat viel Low Level-Kram (bspw. FPGAs, Embedded C) und bin daher kein Freund automatischer Speicherverwaltung und "Magic".

Schick. Hab ich damals alles genauso gemacht. Engine-Entwicklung macht halt Spaß :-)

Wie sieht's aus mit Animationen? Welche Arten werden unterstützt?

Noch keine. Da ich derzeit noch Assimp implementiere, werde ich danach einfaches Skinning einbaue.
Ich erinnere mich übrigens noch an Mellowz und A Singing Mushroom. Ist ja doch schon einige Zeit her. War sogar auf mellowz.de.vu mit Performance-Bericht von meiner Kiste damals vertreten. War doch von dir. Richtig?

Ach du Schande. Ja, das war von mir. Gott, das ist etwa 18-20 Jahre her! Lass mal weiter News von dir hören, wenn's mit Animationen voran geht. Der Rest klingt ja schon recht ordentlich.

15 Jahre sind es mindestens, ja. :-)
Aktuell schreibe ich am Log-Subsystem weiter. Das funktioniert aber nun auch schon ganz ordentlich.