The founder, Wouter, has created or helped design 10 programming languages. Voxile is built in his newest language: Lobster. Wouter has been a major contributor to WASM and LLVM while also inventing flatbuffers. He’s worked at Crytek, Gearbox and Google among many other places. I’ve never seen anything like Voxile.

Cube 2: Sauerbraten too! Definitely spent some evenings playing that with my roomies back in the day before we invariably went back to Q3. What an insane resume.

I have fond memories of porting Cube, Sauerbraten and AssaultCube to the Mac back in the day. Given what i've seen from Wouter back in the day i am not surprised he is still on it full steam…

Indeed! Thanks for also linking my discussion with Wouter His early work on Cube engine and Amiga-E are still awesome to look at.

I remember learning about Bla, a functional programming language for Amiga wrote for his master's thesis.

About the Lobster language used: The first thing I do when encountering a new language is look at the memory management, since what I want to do with a piece of code is usually build and manipulate data in a safe and efficient manner, so this is central. I am happy to see Lobster seems to be trying to take a new(ish) and pragmatical approach to memory management and that there is a whole document describing it in detail (https://aardappel.github.io/lobster/memory_management.html) which means the language creator agrees that this is important. Also happy to see the language seems to support fast memory management in a multi threaded environment, which is absolutely not self evident in many languages.

Thanks for sharing, it's indeed a great way to quickly see what a language has to offer.

From what I understand, the main innovation of Lobster here is that `class Foo` is a boxed type, while `struct Bar` will be inlined. I'm not sure I see how that's an improvement over using either `Foo` or `Box<Foo>` on instantiation. It also does reference counting by default, and tries to optimise it out at compile time by assigning a single owner and borrow.

We often see complains that Rust's ownership puts a lot of burden on the programmer, but there is really a point at which it clicks and we stop having to fight the borrow checker almost entirely.

I'm a long time Unity developer that in the past year picked up Godot. The speed at which Godot loads compared to Unity is staggering, it's just so much faster. When I returned to Unity I raised that my flow state was constantly being broken in a way that it wasn't when using Godot.

Entering flow is one of the beautiful things I love about programming. And being knocked out of it often feels like a physical jolt.

Lobster seems to take the idea of optimisation and speed to new levels. Entering and remaining in flow must be even easier. First though, I'll need to put the time into learning enough to be able to do it!

Thanks for mentioning Lobster. This guy seems to have learned many lessons of language simplification and design. Looks like a promising language and I wish it success.

Ref: https://aardappel.github.io/lobster/language_reference.html

Lobster doesn’t seem that different from Lua in that regard? I won’t say it isn’t impressive, but I’m having a hard time believing the hard part of this thing was calling from an interpreted to a static language.

Edit: I was mistaken about what Lobster is (potentially compiled instead of jit), but the main point stands.

Yeah,

I'm working on an indie game project and just got frustrated with Unity, I'm porting everything over to Godot.

I even learned about using Kotlin with Godot today [0] and I am really hopeful this is stable (it seems so), because I favor a more functional style of programming and C# ends up making everything 5 times more verbose than Kotlin.

[0] https://godot-kotl.in/en/stable/

I do wonder whether Kotlin is sufficiently different from C# to make it worth developing in Godot in a non-standard way.

> I favor a more functional style of programming and C# ends up making everything 5 times more verbose than Kotlin.

As if you can't program C# functional style.

> As if you can't program C# functional style.

This, I was really impressed recently when I met a C# dev who was also a programmer (as opposed to your standard C# SaaS dev who just copy pasted from the framework docs and stack overflow and was fully automated by Claude in 2025) and he showed me how nice the language has gotten since I last used it over a decade ago when it was just Microslop Java. They've really put in work and it has a lot of great functional constructs now.

So true.

Recent changes to Xcode have meant that on device debugging now launches WAY slower for me every time.

Once it’s going it’s fine. But an extra 20 seconds every time you start the app just kills things for me. It was never instant but now it’s trash.

Not every conversation is about AI. This one isn't.

Are we just assuming nobody is programming commando anymore?

If the flow is just typing prompt after prompt into AI, I guess just ignore that it's running and keep typing? Or open a new tab and keep typing. Why does Claude even break the typewriter flow thing that's going for you?

You can try not using Claude

Very cool - the post made me want to play the game, and check out lobster, but didn't link to it - lobster is open source: https://github.com/aardappel/lobster. It doesn't look like the voxel engine is, though, which is a bummer. On reflection, I'm guessing that game is built for mods, so that would be a path to getting to play with the engine side.

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.

What is the voxel resolution Voxile works at?

Also, does it have a single world grid? (I saw you say octree somewhere) or many separate elements?

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.

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.

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.

Heh. I thought I remembered the name. I used to use Wouter's E programming language on the Amiga. It was pretty good, as I recall.

Gorgeous. These are the graphics I wish Veloren[1] had. Maybe my machine is lacking the specs to dial up the graphics all the way…

[1]: https://veloren.net/

I appreciate when games load fast (this one does). Its one of the signs I use to see if a game is worth my time. Most of the games I play, I am playing the game within 20-30 seconds of opening the game from my desktop. I'm naively assuming that in order for a game to load fast you have to have a good plan of what order to load things in. It feels like an attention to detail thing to me.

One issue with Voxel-based physics destruction games is that the physics happens in continuous space (as opposed to voxel space). This means that the moment you break off a chunk of geometry, it has to be converted into a mesh and simulated like any other mesh-based model will. This makes voxels seem like more complicated Voronoi-noise based fractures. If you want the modelling workflow or the looks of voxels, it's fine. But assuming that voxels will somehow help with the destruction physics seems not to be a valid assumption.

Ideally, we would be able to do physics in voxel space itself (sort of like a cellular automata based classical mechanics), but that doesn't seem to be possible.

This isn’t actually true if you use GPU raytracing, as everyone involved with voxel destruction seems to realize at one point or another. Meshing in a performant way after every destruction event is simply not possible.

So how would you do destruction physics on voxels without meshing? This is how even Teardown does it, and it uses raymarching.

Kind of looks like like Minecraft if it was built out of Voxatron. (millions of Little destructible cubes) seems like a very very difficult thing to do at that scale. On top of that making a engine and a language. This guy must have interesting things to say.

Cool, finally something from Aardappel again (maybe I missed many other things). I like the programming languages since E and I am happy something we can buy comes from it. Well done.

Love Voxile! It's a beautiful little game. Actually didn't known it was still receiving updates.

Now this is the kind of thing I expect people to bring to show and tell when they post about how they are 100x as productive thanks to AI.

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

If you use Google in any capacity, you already have.

and this is why i, personally, use searxng these days instead of google or duckduckgo

Ah, the Lobster guy!

I have been running across that repo for years and wondered if anything was happening with it - great to see an impressive game project built on it now.

I wasn't prepared to see how good the game looks visually. It's super cool.

Congrats on your release, Aardappel! Bought a copy to support the dream!

Much appreciated :)

Does anyone know if this uses Microvoxels or an Octree? As someone who has built an Octree engine I am curious. I will say it is gorgeous!

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

This looks so cool! Love the build to fight angle.

Gonna try it as soon as... I have time

Really looking forward to playing Voxile with my friends! I feel like merging real quests with a Minecraft-like will be compelling.

naming something tech related without referencing crabs or lobsters challenge [impossible difficulty]

It always mildly annoys me when a game says that it is all voxels, but clearly isn't, since the little cubes easily move off the voxel grid. Its just geometry moving around, like normal games, but modelled in little cubes, instead of being fully restricted to voxels. I would really like to see a fully voxel game, where all geometry is "rendered" to voxel space before being rendered to the screen, so that everything is just cubes that don't move, just change colour

Lexaloffle's Voxatron is what you're describing: https://www.lexaloffle.com/voxatron.php

IMO the effect is less compelling than you might think.

John Lin used to work on such an engine where all voxels stay axis and grid aligned, even in animations:

https://x.com/ProgrammerLin/status/1342786223811698688 https://voxely.net/blog/

But I think the project was abandoned in 2021.

Are you suggesting the voxel grid is attached to the camera, or that the camera moves through the grid?

Either could work, but world space voxels would probably be easier to understand than camera space

The game currently has a Mixed (65%) rating on Steam. Granted, some negative reviews are shallow, but some mention important issues. Regardless, a Minecraft clone is not exactly groundbreaking in terms of gameplay.

This is to say that technical merits are rarely good indicators of a good game. As a gamer, I don't really care about the game engine, and even less about the language it's written in. Good programmers often obsess about these details, but it's easy to miss the forest for the trees, which is what I think happened here. Game design is a separate skill from game development, and not many people excel at both.

Still, it's great seeing this here, as the technical achievements are quite remarkable.

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.

65% positive reviews doesn’t tell you much about whether the game is good or not. At most it tells you that the game wasn’t great at communicating what people should expect.

This is just being intentionally obtuse. Everyone knows that 65% generally means the game doesn't even run on most devices, crashes constantly, or has some other serious flaw. Ridiculous.

Explain how a game that doesn’t run on most devices or crashes constantly is recommended by 65% of reviewers.

But also if that is true, that just solidifies my point which is that a 65% doesn’t necessarily have anything to do with game design.

Steam review marked as most helpful states:

> I played this game for 3 hours and i can confirm it is not in a playable state, there were several bugs within the first few maps that deleted needed items causing us to reset the entire world. several times. Don't waste your time...

That review is a year old. Just maybe it’s improved since then?

lobster: Like rust, python and ruby all mixed together

I guess if I'd done all that work on lobster and then bipolar built a ray traced voxel engine on top of that, end game would be to licence the engine. You have something here that the other game engines don't have, and something Minecraft is not likely to have (they are pretty stagnant development wise). This is easily 100 times better than Roblox. If you focus on making the world building tools easy to use and modding/game design you could easily be the next big thing. Don't get too bogged down in game design other than to use it as a proof of concept to help you understand what game designers will need.

Very cool