I admit this was mostly out of simplicity/convenience/familiarity.

If you're a Rust person, you'll appreciate that Lobster lets you use similar exhaustive switches to Rust's enum instead: https://github.com/aardappel/lobster/blob/master/tests/types...

And while Lobster is a niche language LLMs don't know as well, they do surprisingly well coding in it, especially in the context of a larger codebase as context. It occasionally slips in Python-isms but nothing that can't be fixed easily.

Not suitable for larger autonomous coding projects, though.

But is generally a cool idea.

Fog is good too, though. It helps with a sense of scale, and it helps colors and distance noise not be too busy.

In contrast with most voxel-looking games, which are actually meshes converted from voxel inputs, placed at arbitrary locations with arbitrary scale.

When I started this project, I actually prototyped what it would take to have moving objects in-world as aligned voxels, but the animation was too jerky and it was too limited. Would have been an interesting "style" suitable for some games (strategy games?) but none with fast paced realtime combat.

That said, it be easy to have annotations to force the other use case, just so far that has not been needed :)

We have a "depth of field" implementation for when you're in dialog with an NPC. There it looks nice, because you're focused on one thing. But when looking around its not that great.

Ideally you want it close to native res in the distance, but without any wobble produced by noise as you move. This is really hard.

Yes there is a single world grid, so all world objects are axis aligned and same size.

On top of that it can have floating "sprites" which are used for monsters, particles and such.

As for the rating, yes we had a rough initial launch, but we're fixing all these things. Note that it is 65% out of only 63 user reviews, so statistically not set in stone yet.

Some reasons why we don't have a super far render distance, in order of importance:

The biggest is GPU memory. The octree that holds the world gets gigantic at large sizes. We'd have to swap parts out as the camera moves. We can do that but haven't gotten there.

Noise: raytracing looks incredibly noisy if you simply cast rays far into small geometry. Hence we even have LOD for blocks, even though they're not needed for efficiency, they're needed for visual stability.

If you're unlucky and a ray has a lot of near misses with geometry, it does more work than other rays and it causes GPU performance degradation. It's rare but to raytrace far you have to optimize for a certain amount of ray steps, we actually put a bound on this.

We find having fog gives some visual unity and sense of scale. With far away fog, the world looks VERY busy visually.

Right now the editor has a UI driven minimalistic language for specifying quests and other gameplay actions.

There's already bindings for Box2D in the "ph" namespace.

The syntax comes from the observation that even in C-like languages, 99% of the time I want to iterate over the range (0..m-1), so that's what it is optimized for.

I don't enjoy writing the same boilerplate over and over. Moreover, because it is so verbose, it is hard to spot `for (int i = 0; i <= m; i++): print(i);` being a special kind of loop since it looks so similar to the common `<` case. I'd rather that looks entirely different to alert me we're also iterating over the bound.

I am not sure what you mean by "Initiating `i` right before every loop"