Dec 24 2021 - Engine Complete
I finally did it. I completed the rewrite from version 3 to version 4 of my game engine. It took me a couple of years. Yikes. But, it's done.
I can start sharing more about my progress. Here's a proof of life video that shows placeholder art, some lighting, room, and collision system working. Later in the video I turn on some of the debug shapes. There's not much in the way of gameplay here. At this stage, other than the world and room system, I have not worked on gameplay or player skills. It's a blank canvas.
Was it worth it? Not sure. The entire process from zero skills to now took me almost 7 years on and off. I wrote 4 game engines, a custom scripting language (unused) and a set of tools in 7 years... I certainly am very competent now in all sorts of C++ programming styles and gamedev. But it turned out to be a gigantic undertaking and burden for someone who's only slightly perfectionist such as myself. Hard to say if I would have been able to make good games in the same time had I chosen an off the shelf engine but this engine quest has certainly prevented me from actually producing my clumsily announced demo 3 years ago... Version 3 and its custom scripting language was a promising engine 2 years ago but there's no contest with version 4. My future life as a programmer/designer is greatly enhanced by the sheer power and flexibility of version 4. So, from that perspective, I have no regrets. I can tell there will not be a need for a version 5. Let's look at it.
About the engine. It follows the live-coding paradigm I described in previous posts. The game and renderer are separate DLLs. The game is launched by a platform specific executable. All memory is managed from the platform launcher. Reloading DLLs does not modify that memory unless I choose to and that allows me to near live code the game without shutting it down. The C++ style I use is very bare bones, procedural, does not rely on compiler heavy C++ features. All code is brought under single compilation units and the resulting compilation times are near 1s for each module. This architecture makes programming systems or gameplay a breeze. I would often be surprised how I could to write complete systems in a day instead of a few days as I used to. The near instant compilation keeps me in the flow and productive.
About the tools. I have two kinds, standalone and in-engine. The standalone tools run inside their own process and monitor my creative apps. When I edit registered files, the tools package them into an engine ready binaries. The engine monitors those and live-reloads them as the game runs. This allows me to draw art or modify levels from dedicated apps and see instant changes in game. The in-engine tools range from C++ compiler replacement facilities such as meta programming, introspection, custom preprocessor based code generation to visual debug tools, input replay for QA, etc. These turned out to be more interesting to me. Due to the coding style and nature of version 4, I can very easily write stuff and see results live. For instance, just yesterday I was reluctantly looking into fixing a bug in my static light system and I had been dragging my feet there because it looked like it would take a while to nail down. Rather than starting up gdb and do some old school code investigation (very impractical there because that room had 100s of lights), I wrote an immediate mode style bounding box sprites selected by mouse hovering system to help me identify what light exactly was playing up. Setting those up took me less than half hour. I could retrieve several troublesome light ids very quickly just by exploring the world with the game camera and my mouse. Those ids set me down the right track, and I nailed down the bug quickly. I had more fun writing the quick tool than using the traditional debugger. This system would be reusable for other game objects in the future for which I'll want quick introspection.
On performance. This simpler style of C++ coding makes it easier to run -O3 type compiler based optimizations. Just by switching that on I gain a 4x CPU speed advantage in most scenarios. I have also pushed my renderer to do much more sampling and color work than version 3 used to. I am knowingly using way too many FBOs, essentially having a mini-photoshop like layer system. The idea being that as I design the game, the facilities will be there should I need them with the intention of bundling things tighter once I am set on the look I'll be going for. This kind of unduly complicated pipeline made me aware of OpenGL driver overheads and I am now very curious about AZDO style interfaces such as Vulkan but that's a rabbit hole I am not prepared to go down for some time.
Where to go next. I would contemplate splitting logic from rendering into separate threads to speed up the QA replay facility. Also, there's more work needed on my audio system, as I would like to have more mixing facility and logic to accomplish some dynamic music effects.
That was a long, technical post. I am about to open a new chapter on my gamedev journey. One where I'll be mostly focused on art, design and storytelling, the stuff that brought me here in the first place. I actually spent the last 2 weeks just doodling until I worked up enough motivation to fix those pesky static lights ;) I am very happy to be largely done with the engine, even though those things have a life of their own and there'll be no doubt new systems or tools I'll just feel like writing down the track. I am very excited to be finally turning to those design and art notebooks and try to make Two for Dinner come to light.
I really appreciate your support and interest. Here, you can have a quick look at the tip of a 7 year iceberg with this placeholder art video. Enjoy!
Merry Christmas everyone and all the best to you all!
Claude