No. It is a fairly static language, with whole program compilation and optimization. The dynamic loading the parent refers to is like a new VM instance, very different from class/function (re)loading.
Even though this just showed up on HN (for the 10th time?) the Lobster project started in ~2010. No LLMs on the horizon back then.
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.
While Voxile has off-grid blocks of voxels for monsters etc, it is much more serious about being on-grid for everything else. The entire world is entirely on-grid, single size voxels, you can only place aligned objects, and rotate in 4 directions. These voxels only every exist as voxels, never as polygons.
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.
Lobster is meant to be a more high level language than Rust, so encoding what you want 99% of the time in the type made sense. It also makes it easier for people to read, knowing that common types like int2 are always by value.
That said, it be easy to have annotations to force the other use case, just so far that has not been needed :)
It's not intended to be a Minecraft clone.. if you look a bit closer than the initial visual impression, you'll see there are many differences in gameplay.
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.
Any ideas how to increase the render distance way further?
Because that's where I always get stuck. There are so many cool algorithms and ideas that I have like combining ray tracing with meshing and even like imposters for the distant chunks.
But this is getting very complicated with contrees and raytracing/marching etc.
With raytracing having a far render distance is actually fairly cheap and simple compared to polygonal worlds (good looking LOD is hard).
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.
That is tricky with raytracing, since rays would need to be curved, and at least in this raytracer, ray steps are not all equal in size so doing that correctly could be very expensive.
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.
Is there any way to have something like a distance blur? e.g. as rays travel further you reduce the number, subsample then apply a gaussian(or algo of choice) blur across those that return, increasing in intensity as the rays angle gets coarser?
It'd be really neat to have some way of enabling really long-distance raytraced voxels so you can make planet-scale worlds look good, but as far as I'm aware noone's really nailed the technical implementation yet. A few companies and engines seem to have come up with pieces of what might end up being a final puzzle, but not seen anything close to a complete solution yet.
Yup you could blur, but it is not cheap, and it doesn't feel very satisfying to look at blurry stuff in the distance.
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.
Having just played it, you seem to have worked around the destruction problem by removing voxels one chunk at a time. But I’m still baffled by the sheer number on screen at the same time :)
reply