[jammygit]

I think all that counts. I guess I’m just tempted to make a game engine as a hobby project. I made an OpenGL renderer in uni once (it was fun), but I don’t really know what the scope would be to extend it substantially - obviously, not to “unreal” levels or anything even close

[ItsFirefly]

Go for it! If you already have OpenGL experience—doesn't matter what level—you "only" have to add a bit of basic 3D world math and input handling. I found SDL (http://libsdl.org) to be a very good core framework to build upon regarding input handling.

For the 3D world, start with a checkerboard pattern or so. In fact, this is almost exactly what I did to start Angeldust. I once showed off some early game prototypes on my stream, take a look at this one for example: https://www.youtube.com/watch?v=qMs8YpkSrg0&t=3289

If you keep watching that stream you'll see other in-progress versions so you can see how my product evolved.

[jammygit]

Any other resources you would recommend? I read that physics is particularly time consuming for example. Thanks for the replies so far; it’s very fun to see your work

[ItsFirefly]

I didn't really use many external resources during development, most of the time I'm just "winging it" and acting towards a goal that I have in my mind. Coming up with a naive solution first, then trying to optimize it a bit in my head, then writing the code for it.

Angeldust's physics are relatively straightforward since it's based on a voxel grid. All game world intersections are approximated using axis-aligned bounding boxes (AABBs). I wrote the physics engine myself from scratch to reduce the number of game world data lookups, because that's pretty much the hot path in the code.

In the YouTube video from my earlier comment you can see that initially I started out with just game world boundary clipping and simple plane physics on the checkerboard. As I expanded my game world model, the physics engine grew along. So my advice would be (again) to start simple and grow from there. You'll do fine!