I recently built a C++ meta-programming monster for a side project. I want to make an article about that in the near future, and I am somewhat afraid that some people might think of reusing it in a real project.
I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.
That seems like a great side project. The one that let's you understand things NOT to do. At the same time, it helps engender basic traits like curiosity, try-until-you-fail-and-try-again, engineering skills etc.
There are two types of side-projects though: one such as yours, where you try and understand a concept or engineer something just for the fun of it.
And there is second one: a game that will mature into something; a hobby project that will actually develop into a company. I think it's good to disambiguate these two as the OP was more about the latter where you may never get to a point to see it run or build let alone flourish into something meaningful - as overengineering kills the fail fast fail often mentality and the project itself.
Maybe the real lesson here is that the last open task on your project is something that can present human-readable digests from parsing the compiler errors...
My constant on-again/off-again side project is something similar but in C#. Spending a week building a preprocessor and then discarding it because I didn't need it was both infuriating and strangely pleasing at once. :)
I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.