Comment by ItsFirefly | Hacker News Reader

Comment by ItsFirefly | Hacker News Reader

Parent Full thread

My vision was to make an "all-inclusive" product where people with ancient hardware would be able to enjoy a modern-day product. All existing engines focus on modern specs like OpenGL 3.x, 64-bit processors and operating system versions that I am not even able to run on some of my own devices.

In addition I have complex, dynamic geometry to render. And I wrote a custom, fixed-precision integer math library to prevent rounding errors for the almost infinite game world. Other products have weird rounding errors near the start, the middle or end of their worlds because of inconsistent floating-point accuracy. Moving to doubles only mitigates the problem instead of solving it.

And then it's just efficiency too. I have no idea how or why Unity or Unreal will treat my assets. As demonstrated on the stream: the game instantly switches between visual styles and texture quality. It lazily loads all resources so the main thread is only stalled when doing bulk uploads to the GPU. This makes the game start up in less than a second, something I couldn't pull off with a COTS engine.

Let me know if this answer didn't address your question fully.

How long did the client side engine take to build, if you had been able to do it full time?

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.

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

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.

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

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!

Reply on news.ycombinator.com