The advantage of writing your own "game engine" is that it would only have the exact set of features you need for your game, and it would make the things you need to achieve as fast and as easy as possible.

This means traditional advice for "the basics of a good game engine" doesn't really apply, because if you're just making a bog standard game engine you're wasting your time and making a crappier version of Unity or Unreal.

https://geometrian.com/programming/tutorials/write-games-not...

Agreed, but I guess I'm saying basic architecture stuff like:

- "How do I render things?"

- "How do I integrate sound?"

- "How should I handle events?"

THREE.js[0] is high enough level that it solves some basic problems (hierarchies of objects, basic materials, basic lighting, rendering pipeline) and low enough level that you still have high granularity control (you can roll your own shaders, lighting, render order, etc).

I don't know if anything like THREE exists for OpenGL, though.

The upshot of THREE is its super easy to develop with (alls you need is a browser). The downside is that it slows down very quickly for even simple things.

[0] https://threejs.org/

I've been looking for something like THREE.js for C++ for years now, to the point where I actually started developing my own. But due to my inexperience with large codebases I have a hard time doing something like it that looks good and works well.

(I am a security analyst, not an engineer, but I'm transitioning to engineering roles now, so this might change in future, who knows :) )

For a general reference I would look at Jason Gregory "Game Engine Architecture".

For a deep dive into all game engine topics I would recommend the Handmade Hero dev streams: https://handmadehero.org

(Note that Handmade is not a useful model for an actual game production, it's more like a platform for investigating cutting-edge engine topics, so you can pick and choose parts to get what you need. It's been going for years and remains mostly a tech demo.)