[ItsFirefly]

It's ridiculously hard to come up with an answer to this seemingly simple question. I've tracked my time usage pretty meticulously by version number, but for most features I had to develop the server-side, client-side, website and network simulator code simultaneously. Developing this (or any) game I think isn't a process where you build the server first, then build the simulator and then build the client. It's building v0.0 for all parts, then v0.1 for all parts and onwards where all parts gain features in lockstep.

For Angeldust I've done dozens of updates, each and every single one building upon the existing base. Looking back it's amazing to see that the product evolved in an almost linear fashion from v0.0 all the way to the current version without ever having to drop or redo features. But because the product evolved as a whole I can not really distill a time estimate for only the "client side engine".

I mean: would you consider testing the client side engine part of client side engine development? For testing you need a working server. For which you "need" a working network simulator. It's dependencies all the way down.

And how about translation work for in-engine strings, updating shared libraries and frameworks, issue tracking, writing the asset conversion toolchain (which needs assets, which need integration). It's very hard to come up with any solid number. Maybe if you can severely limit your question's scope I can come up with an educated guess.

[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!