There are some arguments to stick with C instead of a very C-like subset of C++. Off the top of my head:<p>- Recompiling and reloading parts of your game at run-time is quite easy in C. In C++ you have to make sure (at least) that nobody has pointers to vtables of the dll at the time of reload. This can be a bit tricky if you&#x27;re using things like std::function in your dll code. Yes, you could be using a scripting language, but thinking how to match the semantics of a scripting language with your engine, where to draw the line, and then write the glue code is a lot more work than just reloading some plain C functions. And if you later decide this was a bad&#x2F;worthless idea, reverting from dynamic C code to static is almost a no-op, whereas reverting back from scripts is dreadful.<p>- A quick &amp; dirty reflection is easy when you don&#x27;t have to deal with name mangling, templates, and overloading. Just some script scanning through your code and outputting elementary type info to .c file may be enough for things like real-time memory browser-editor for your whole engine. This can be very valuable when developing new engine features, as you can view and edit, and maybe draw even graphs of members you just added to some struct. Also useful for modifying game object data on the fly when debugging&#x2F;creating levels.<p>(I too do my game programming in C)