Aardappel

You'd prefer something more like Rust traits or Haskell Type Classes?

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...

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.

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.

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.

Have you tried Teardown? Has incredibly good voxel physics. Definitely possible.

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 :)

Much appreciated :)

Both! It uses an octree, and at the leaves are bricks of small voxels.

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.

A voxel is about 2 inches / 5cm in size.

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.

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.

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.

Haha.. yeah entirely coded without AI so far, lets see how long we keep that up :P

Yes, only the lower layers are open source right now. We will eventually expose more, when modding will more stable, etc.

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

Yes, that is a downside, but when you write very generic code being limited in what code you can write because it has to typecheck even for types that it doesn't apply to is one of the more frustrating things of doing this in C++ and other languages.

Would love to add Jolt at some point, yes.

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

if you find in files for "phong" you should be able to find samples that use it.. the actual shader is in data/shaders/default.materials

In Lobster, this is `for(m) i: print(i)` Or simply `for(m): print(_)`

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"

In Lobster you must initialize a variable declaration. Now you can produce your bad case with `var x = nil`, but that is undesirable because nil types must be explicitly checked at compile time, so typically you want to use as few nils as possible. More likely thus is `var x = ""` if you must initialize later.

Yes the author :) I make both programming languages and games / engines / maps..

Yes, its somewhat similar, monomorphic specialization.

I am sure it has some limitations, but it is pretty powerful, it can even do things C++ can't, like have a type error in a branch that in the current specialization is never executed doesn't count as a type error :)

There's no FPL style pattern matching. It can do a switch case on types (the various subclasses of a base class) but only 1 level, i.e. can't match against type of members. That could still be added, just personally rarely have use for it.

Seen by creator :)

It comes with a tiny minecraft clone in < 100 lines of Lobster.

Agreed it could use more actual game examples. I've written a ton of game prototypes in it, and some could do with open sourcing, just haven't gotten around to it.

the "gl" namespace is really a bit of misnomer since it is much higher level API than OpenGL, and does not really depend on OpenGL. It could pretty easily run on another API underneath.

The repo comes with a LOT of graphical samples (in the "samples" dir).

The lights are more of standard way of passing them to the shader (see the phong shader implementation).

Matrices are a bit of a weak spot since its all implicit (which is convenient, but not powerful). There are also classes for direct use of matrices though.

Yup, it generally inlines lambdas passed to custom control flow functions, so it ends up pretty similar to hand-written.

The name does not refer to anything in particular :)

All the VM runtime functions are written in C++, as are all of the built-in functionality and the engine it uses. To use C, either all of that needs to be rewritten in C, or there needs to be a clear layer between the two, but the API surface is fairly big.

It actually uses C for the JIT (libtcc), but the fact it has to go thru a layer is a source of slowness and complication.

No, this analysis is fairly linear.. the whole compiler is pretty fast.

The actual game itself, yes. Based on this open source project though which provides the language its written in and core engine tech: https://github.com/aardappel/lobster

Yes, for both gameplay and most of the engine.

Thanks for the support :) More here: https://twitter.com/voxraygames