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!
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.
[1]: https://veloren.net/
Gonna try it as soon as... I have time
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.
Instead of the usual BS "AI will kill us all" or "AI wrote Linux in 5 secs!" style articles.
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.
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.
Ref: https://aardappel.github.io/lobster/language_reference.html
Edit: I was mistaken about what Lobster is (potentially compiled instead of jit), but the main point stands.
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.
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.
Right now the editor has a UI driven minimalistic language for specifying quests and other gameplay actions.
https://x.com/ProgrammerLin/status/1342786223811698688 https://voxely.net/blog/
But I think the project was abandoned in 2021.
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.
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.
> 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...
As if you can't program C# functional style.
That said, it be easy to have annotations to force the other use case, just so far that has not been needed :)
IMO the effect is less compelling than you might think.
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.
Also, does it have a single world grid? (I saw you say octree somewhere) or many separate elements?
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.
I find Kotlin way easier to read back than C#, and for the cases where I would have reached for GDScript for its simplicity, I can use Kotlin and have still a lot of simplicity, while also having type-safety.
C# is already more verbose because it lacks things like union types (and so you need to have a fallback branch in every switch) and for example everything needs to be nested in a class.
Then you also have the fact that there is no "val" keyword (which makes things clearer imo) and the fact that it's generics type inferencing is only based on method arguments, which really adds a lot of noise to almost all generic functions.
I was using LanguageExt [0] in C# and I am now using Arrow [1] in Kotlin, and while LanguageExt is really nice for addressing some C# shortcomings, for me this is night and day.
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.
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.
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.
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.
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.
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.
Voxile, the co-op, ray traced, micro-voxel, survival-crafting game from VoxRay Games, has just released its largest update yet: THE BUILDER’S UPDATE (release notes here). You can check out the Steam demo here and Voxile is now 40% off on Steam until March 9th.
Keep up with all the latest updates in VoxRay Games Discord Channel.
[

I first met Wouter van Oortmerssen for lunch in downtown San Francisco in July of 2023. Friends had put his studio on my radar (shout out to Dan Levine and Jeffrey Rosen) so when we connected on LinkedIn, I was excited to arrange an in-person meeting.
[

I expected to spend the afternoon chatting casually about high-level gamedev and design. I had seen video of Voxile’s high-fidelity, ray traced, global illumination with reflections. So my plan was to ask for a Steam key and then boot it up on my gaming rig when I got home. Instead, Wouter brandished a slender laptop from his backpack (with no wall power outlets in sight) and in seconds, the Voxile demo loaded up and was sustaining high frame rates without jitter in all its high-definition glory.
I climbed up from the tranquil beach to forage in the forest but was violently interrupted by an angry skeleton. After losing substantial health, I smashed him into pieces. As I caught my breath… I realized that the sun was arcing through the sky while all the shadows (even the shadows on the little voxel blades of voxel grass) were dynamically updating in real-time. Soon the sun had set and now the glow of flickering torchlight and phosphorescent mushrooms made the engine even more beautiful.
“Is this Unity or Unreal?” I asked even though I knew I had never seen anything like it before.
[

“Neither,” Wouter replied. “VoxRay Games uses our own custom engine written in our own custom programming language, Lobster.”
Wouter’s accomplished career had driven him to this moment (just check out his github). There are very few game developers who have the talent, intelligence and fortitude to tackle game development at both the engine and language level. Let’s be clear, before Jai was a twinkle in Jon Blow’s eye: Wouter had invented and helped design nine languages: Amiga E, FALSE, Bla (created during his Masters in Computer Science), Aardappel (invented during his PHD research), WadC, SHEEP, CubesScript, CryScript and Restructor.
Lobster is Wouter’s tenth language and was built from the ground up to enable prototyping games like Voxile. It amalgamates everything Wouter has learned at companies like: Amiga Inc., Crytek (building the original Cryengine for Far Cry), Maxis (SimCity), Gearbox (Borderlands 2) and Google (where he helped design Web Assembly and invented FlatBuffers while working on LLVM and Android VR/gaming tech). If you’re technical, I recommend you watch some of Wouter’s lecture videos (linked above and below) to understand just how much Wouter knows about game engine coding and languages.
Wouter also believes in giving back to the greater gamedev ecosystem (something that is really important to EGG and its community). He wants to share his knowledge and his joy for games with others. Beyond all his open source contributions to major projects, he was also one of the creators of SMU Guildhall, teaching students how to build engine components (such as shader systems, skeletal character animation, scripting compilers) while supervising their Master’s projects. At DICE this year, I watched as a former student, upon seeing his former professor, ran across the room to thank Wouter for teaching him game development and inspiring him to start his successful gamedev career (he is now an executive at a prominent company).
In his spare time, Wouter made the 3D Cube Engines including Cube 2/Sauerbraten with Lee Salzman for Mac, Windows and Linux (now open-sourced with over 1,000,000 downloads). It’s a performant multiplayer, deathmatch engine (like the Quake engine) but also enables real-time, multiplayer, map editing (and this was in the year 2000 almost a decade before Minecraft would make this a core mechanic).
After years of experience, Wouter decided it was time to form VoxRay Games and up-res, voxel-based world crafting. He successfully raised venture capital led by the well-known VC firm Accel. When he offered EGG a chance to join his round, it was a no-brainer for us to participate as well.
Most game engines interact with programming languages similar to the image below.
[

However, a game engine written in Lobster can be built like following diagram. Unlike Jai, which aims to replace 100% of C++, Wouter’s design paradigm only replaces 90% of it. C++ is still used with Lobster but it’s relegated to the leaf nodes of the call graph.
[

The result is record-speed compile times even after substantial changes to the code base. Cold start times are generally well under 2 seconds for Voxile. Nine out of ten changes in the VoxRay codebase don’t need to touch the C++ code at all. Most languages have either good static typing and performance or fast startup times but it’s very rare for them to have both. Lobster has both.
[

Lobster is therefore ideal for fast, iterative prototyping without rigidly confining the user to a particular engine architecture. Wouter himself has been able to quickly craft wildly different game ideas (each with bespoke engines instanced in Lobster) to “find the fun”. You can check out his many prototype ideas here.
Voxile emerged from this prototyping crucible as the project with the most compelling gameplay and prettiest graphics.
Wouter has explained that his design goals for Voxile involve a growing list of foundational engine features that yield emergent properties:
3D Volumetric Worlds: Polygonal meshes are like a hollow shell without substance. Building and destroying are integral parts of Voxile and they are seamless, molecular properties of the entire micro-voxel world. I fondly remember Red Faction from my childhood but even that was essentially a veneer of polygons used to simulate the destruction of pre-scripted set pieces whereas EVERYTHING in the Voxile world is buildable and destructible.
Performant Ray Tracing: Dynamic shadows, global illumination, ambient occlusion and reflections are all built in to Voxile’s graphics pipeline and create a wonderful visual style. Art and design workloads are reduced because the engine automatically makes all the voxels look and feel right.
Co-op Multiplayer: Both world crafting and destruction happen seamlessly and persistently in real-time. This opens the door for group gameplay and modding experiences like you find in Valheim, Minecraft, Helldivers, Peak, and more... For example: a level where you build a fortress with your friends by day before you have to defend it from zombie raiders at night can be trivially constructed in Voxile.
Quest and Inventory Systems: Wouter has mentioned being heavily inspired by Fallout. Each Voxile world map can offer the player RPG-style quests, progression and upgrades.
Tactile Combat: Weapons are juicy and responsive. Melee weapons have weight and impact to them while customizable range weapons, guns and explosives (why would Wouter add grenades to a “Builder’s Update”!?) cause procedural voxel damage. Just like the world, enemies exhibit voxel-based damage modeling. The result is like Soldier of Fortune’s visceral damage system.
UGC: The modding potential for Voxile is obvious and expansive. Making custom assets is like playing with Legos.
[

Just look at the way the look and feel of the game changes dramatically across worlds.
[

Dead Water Slums
[

The Police Station
[

The Floating Snow Biome
[

The Crystal Cathedral World
[

The Isle of the Dragon
As new worlds get created, the prefabbed assets they contain become recyclable modules for future level design and modding (à la LittleBIGPlanet).
While Wouter has never publicly stated any plans whatsoever to use AI, it’s clear that with his skill and control over the language, the engine and the game, he could add any number of procedural world generation features to Voxile in the future… stuff that most other gamedevs could only dream of (or at the very least they’d have to submit a feature request ticket to their game engine provider).
In an industry that is hungry for growth and innovation, Wouter has created a full-stack, farm-to-table game technology that is truly one-of-a-kind. Everyone should take a moment to check out the free Voxile Demo and if you like the content or want a rich sandbox to mod your own worlds in… you should consider supporting his studio by buying the game on Steam now for 40% off. You can join the public VoxRay Games Discord channel to keep tabs on their latest news. Wouter, congrats again on The Builder’s Update! EGG is excited by what you have built and to go on this journey with you.
No posts