[buba]

Absolutely, i stick to C89 in this serie for clarity as you said, knowing what a game engine does under the hood is the only point here and C is a self explanatory language by design (even if it can be "tricky" sometimes), Im also doing tricky things with it (not that tricky anyways) like the method-like function pointers in the structures that can be "obscure" for those who only work with high level languages but i'm trying to explain everything with detail.

As i said previously, i'd never do a profesional game proyect (or even a hobby one to be sold) with C89, it takes lots of boilerplate and it feels like reinventing the wheel over and over. I'll have to code a hash map approach, a growing array (already did), a "garbage collector" in C89, things that you either don't need or have in the C++ Stdlib, so yep, you are absolutely right.

Also, i enjoy C :D

Maybe after this i could do the same with C++ macroprogramming

[Supersaiyan_IV]

I like your approach, mostly because it's bottom-up, and because this is an excellent opportunity to illustrate common pitfalls. Those pitfalls can be identified using sanitizers (-fsanitize=undefined,leak,address,thread etc). With the correct CI setup you'll have a safety net, where sanitizers provide precise motivations why one approach works, and another also works, but at risk of undefined behaviour.

I have no opinion on use of C89 instead of C++, since that's just an implementation detail. Also, for your purposes, it works to your advantage, since C is basically the white-box of C++.