Thread by @Nothke

For people thinking of writing their own engine in C/C++ after the Unity fiasco, here's a few things I learned in my own journey making #ShakedownGame in C++: 🧵👇 #gamedev #cpp

1. Making your engine is not "hard", individual steps are easy, but there's just many of them! Every magical checkbox in Unity is now a feature you have to implement. So you're better off chosing specific features for your game, if you want generalist use another engine..

2. C++ is a mess, it's almost 40 years old, and built upon C, which is 50, so it inherited a lot of issues, like terrible defaults and manual header file management. It has evolved and grew drastically over the years, and all this makes it a rocky road for any beginner to learn..

3. The way I would sum up using C++ is: if you want to use a feature in it, you need to know EVERYTHING about it. Example: Lists in C#, it's enough to just know that it can grow, you can Add things into it, you can Remove, Clear.. That's it, go use it! Just works!

Meanwhile, C++ has std::vector which is the same as a C# List! Go use it! You've added a few items in it and took a reference to a member and boom 💥 segfault.. You do some stuff in the con/destructor boom 💥 They were run 5x in a row, your brain: boom 💥😨

You see, you just can't go and use it! You have to understand that under the hood when a vector is resized, it gets reallocated, and your ref/pointers now point to gibberish, meanwhile, for each item you added and got moved, there was a copy which triggered a con/destructor...

So before using a vector, you need to know what happens under the hood. And this is just an example, every feature in C++ is like this, you try to use it, you shoot yourself in the foot and then you go like "oh I see!!".

Aaand this exact thing causes many people to yell "never use a vector!", or an entire std library. But the truth is that there's nothing wrong with vectors, and many things in std are extremely useful, but you just have to really really know how it works to use it.

That said, there's a lot of "modern" features that make c++ safer, but not necessarily "better". You shouldn't trust people who yell "never use FEATURE!" and likewise you shouldn't trust people who say "always use FEATURE!". The truth is in between, C++ gives you powerful tools.

5. People are mostly afraid of pointers and manual memory management, but believe me, it's the easiest part!
6. The most difficult part of C/C++ for me was definitely just understanding the compilation process, the way header files stack, and compilation units build and link

Why is this important? Well, let's say you want to add some code that someone else has made. Coming from Unity you're thinking oh, you just drag and drop "scripts" into your project and that's it! Well no no no, this is C, nothing happens automagically.

In best case, this is a header-only library, which means it has a bunch of .h files. But even that doesn't makes it easy. First, you need to include your files into a project so that your IDE is aware of their existence. Second, you need to #include into your .h or .cpp, aaand..

Because headers combine into a single sequential file, the order matters and their definitions and declarations can mingle. Depending on which libraries you use, eventually you will find out about magical defines like WIN32_LEAN_AND_MEAN, one definition rule..

..(to which the solution is usually "make everything inline" (at which point you go WTF (at which point you go down the rabbit hole of why that is because of 50 years of legacy of the compilation process))), and liking errors to which you can't find any meaningful error message..

.. And I said this was in case of a header-only library. In case it is a bigger library like a physics engine, you'll need to "build it yourself" as a static or dynamic library and include it in your project. Which is.. Another wonderful great wall to cross!!

Soon you'll find out about cmake and plethora of new linking errors which will lead you to realize you didn't put correct bool into the cmake configuration after checking each one.. And this is again why you need to have a deep understanding of the compilation process first..

..Modern languages have abstracted this process while C/C++ still require you to manually manage all this stuff and get in the way of actually working on the game and you live in constant fear of ruining order of includes. (One of the reasons why I'm trying out #ziglang now)..

..I wish I could say "but once you know all this, you're a ninja!!" Because there's actually a lot of things that are too weird in C/C++scape that I think more "well, I'm not sure I needed to know that"

8. Ok ok, let's not just be so negative about it, the old age of C/C++ is also a good thing! Actually, TODAY is the best time to make you own engine in it because there are so many good and stable open source libraries and plenty of learning resources!

There's really good libraries like @ocornut's dear imgui, glfw, glm, spdlog, @jrouwe's jolt, soloud, just to name a few. And you can also mix and match! You don't have to go full low level, could use a renderer abstraction like @bkaradzic bgfx or Google's filament..

@ocornut @jrouwe @bkaradzic ..@raysan5's raylib (which is a mix and match modular library itself), to entire engines that include an editor like Urho3D..

@ocornut @jrouwe @bkaradzic @raysan5 Besides that, todays 3d formats like gltf or USD are not just model files, but can be used as scene files! That means you can use blender as an "editor", as I do with #ShakedownGame. This wasn't available before, you would always need to write your own scene format and an editor.

@ocornut @jrouwe @bkaradzic @raysan5 ...this all means that writing your own engine today is easier than ever. So, what are you waiting for? 😉

There's plenty of things I could say and rant about, but I think it's enough for now 😅 will think of making a series of blog posts or videos some other day.