Show HN: Crown – A flexible game engine written from scratch in C++

Interesting! I'd be interested in better understanding the motivation behind Orthodox C++. In particular, you seem to dump most of the C++ standard library:

"Don't use anything from STL that allocates memory, unless you don't care about memory management."

I now mostly avoid templatization in my own code unless there's a really good reason. But the standard library often lets me avoid explicit memory allocation. Would love to hear more about the motivation for this (and other aspects of your C++ usage).

Also, if you have a demo of the engine in use that would be fun to see!

New hobbyist engines pop up from time to time and then they fade into memory. Why is this going to be different?

Not to be too grumpy but game engines are a weird thing cause they are such complex beasts and usually the people using them have invested a lot of time in learning them. It's fun to make a new engine, but it probably doesn't have the community nor interest to cover the hard 10 to 20% that inevitably come up. Seems like the time is better invested in one of the super big AAA engines or in writing your own.

What's the plan for 2 to 3 years from now?

https://news.ycombinator.com/item?id=5442366

Polycode had some interest around here 4 years ago, with lots of the same goals, but haven't really heard from it since. Similarly, how does this compare to Godot or even something like Torque?

I partially agree with "Orthodox C++". Templates should be used only when needed and for turn the code simpler(not like the abomination used in most of Boost libraries).

But also, i don,t see any sane reason to reinvent the wheel and reimplement basic stuff like thread/mutex classes when the C++ version works well. Or using "NULL" instead "nullptr", or using that pre-processor macro garbage instead templates/constexpr, etc

I think some modern C++ features, that if well used, turn the code much clear and expressive.

It's a lost cause: there's no such thing as "sane" or "orthodox" C++. Instead, use something actually sane like Go. Or Rust, if you really must (first bad pun is free, then it's 50 cents each).

Generally speaking many C++ game engines avoid the STL stuff and reimplement their own more predictable containers, often with custom allocation schemes. The engine at the last game company i worked at, for example, had its own containers and memory allocator and allowed you to define the allocation category and pool per allocator and per object class (so, e.g., dynamic strings would be isolated to their own pool to avoid fragmenting the heap).

Related, Andrei Alexandrescu had a great talk about allocators in C++ a couple of years ago: https://www.youtube.com/watch?v=LIb3L4vKZ7U

Also related to the Orthodox C++, the same engine also ousted exceptions and RTTI. I'm not sure about the reason for exceptions, but C++'s RTTI was simply inadequate and instead it was replaced with a custom one made using macros (similarly to wxWidgets and MFC) that allowed automatic object serialization and reflection which was used for all saving and loading, exposing objects to the editor automatically with a common UI and exposing classes and objects to the (custom) scripting language with very little setup.

Interestingly most of the stuff the engine had to reinvent seem to be first class citizens in the D language. Also Andrei's allocators also seem to be available (experimentally) there too.

Personally i prefer plain old C (C89 even, although with a few commonly available or easily reproducible extras like stdint) because i see C++ as too complex for what it is worth. However D seems to provide more power with less complexity and more and more makes me want to try it, especially the new "better C" mode that DMD has got (which i think is somewhat the D equivalent to Orthodox C++ that is linked from the page).