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

Yet another game engine written in an imperative language, seemingly with the focus on writing something in Orthodox C++ and not necessarily writing something to solve a problem. Just as the discussion on this post shows, the more interesting thing here is Orthodox C++, not yet another game engine which doesn't offer any featues that modern game engines offer.

If you're expecting people to see this as a useful product, please explain why it should be used instead of the existing game engines. Consider listing its features and comparing them, maybe in a table, to popular game engines. Deferred rendering? Multi-threaded rendering? Entity-component system? etc.

Right now, I can see it has a (nice looking) editor, "physics" (nothing's moving, so it's hard to tell), and "animation" (again, nothing's animating in the image). Alas, one needs to learn to use its entirely fresh standard library reimplementation, and likely its strict C++ subset, if one actually wants to be productive with it. Given apparently no active community, no sample (or actual) games written in it, and no paid support, I don't see how that would be feasible.

If you have no interest in actually making a competitive, novel, or useful (to others, compared to existing solutions) game engine, please just say that. In that case, I'd just say this is a neat side project: well done, but try to focus on building something with it to help sell/prove its features.

Debatably, this exists. With GCC or Clang there are several command line flags that can help.

If you use the flag -Werror all warnings will be errors.

Then add -Wall which enables all unambiguously good warnings, which will stop a whole lot of things that skirt the type system, it will prevent silly rounding bugs and in general reduce the bug surface of your code.

Then if you enable "-pedantic" more errors are found, but not all are clearly improvements. I think most of them are good and I think most would agree that mandating the "override" keyword is good, but not all would agree with every signed to unsigned comparison warning.

Put together this add "-Werror -Wall -pedantic" or a "/w4" MSVC) to the command line, or more likely makefile/CMakeLists.

I personally advocate enabling all these and a similar set from msvc then adding a set of robust warning suppression macros to you code and suppress the warning that really make no sense to fix. This has prevented a ton of bugs in my code, it minimizes the amount of premature optimizations I see in code that tried to cast from one type to another by relying on some unspecified binary compatibility and in general makes writing C++ really enjoyable.

RAII is necessary for exceptions. Why the hell would you do that to yourself?

While in general you are right about the boring stuff (although some people find writing tools far from boring - e.g. me, i should actually write less tools if ever want to finish some of my own stuff:-P) the shiny visual bits aren't usually "just" imported. In the (commercial, not personal) engines i worked at, the artists used their 3D mesh editor of choice (max and maya) to make the meshes but only bothered with the basic texturing in that 3D mesh editor. The materials were created inside the engine's own editor since 3dsmax/maya's materials both do not make much sense to fully replicate and they lack functionality that the engine's own renderer (and material system) can provide.

In the last (commercial) engine i worked at, the pipeline was to export the mesh from the 3D mesh editor (3dsmax or maya) to a custom easy to parse format and then import it from the editor to a more compact faster and easier to work with format. Then the artists would create the materials and other resources that the engine needed to work with from inside the engine's own tools. The imported resource remembered the original file so that artists could simply export again and ask the editor to reimport stuff (at a later point we made the editor to automatically monitor the directories for changes - both Windows and Linux provide functionality for this - so the artists would simply export from their 3D mesh editor and the engine's editor would reimport the meshes automatically).

In the previous (commercial) engine i worked at, things were simpler in that we only supported 3ds max (although the 3dsmax SDK was far from simple, if it wasn't for SymbianOS it would be one of the worst SDKs i've worked with... but that is another story) and we exported animations and meshes directly to a custom format the engine expected. The exporter also had a "preview" feature to allow the artists preview the exported files in a standalone viewer that used the engine's renderer to make sure that things looked fine (in that case we actually did try to use 3ds max's materials, although in hindsight that was a mistake since even with the viewer the artists often assigned textures incorrectly - we should have relied only as little as necessary on 3ds max instead of making it the primary content editor).

I love the article! It makes sense that after developing AR application on a game engine, I will identify the common functionality that would fit better for an "engine" that would fit the ideas I want to develop.

I am interested in developing AR applications that are not as much of a game, so I was worried that a game engine would not fit.

With both learning more about graphics and making my own games, it would make future engine development more clear.