Live data from Hacker News

Voxile: A ray-traced game made in its own engine and programming language

elbowgreasegames.substack.com

71–80 of 83 posts

Re: Voxile: A ray-traced game made in its own engine and programming language

#71
post #68
post #58

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 det…

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 ` on instantiation. It also does reference counting by default, and tries to optimise it out at compile time by assigning…

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

Re: Voxile: A ray-traced game made in its own engine and programming language

#72

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 f…

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

Re: Voxile: A ray-traced game made in its own engine and programming language

#73

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 i…

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.

Re: Voxile: A ray-traced game made in its own engine and programming language

#74
Building your own language to build your own engine to build your own game is what most orgs would flag as scope creep. But that's exactly what lets Wouter push things nobody else can lol he controls every constraint all the way down. Genuinely wild stuff.

Re: Voxile: A ray-traced game made in its own engine and programming language

#75
post #40

Earlier quoted context omitted.

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.

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

Re: Voxile: A ray-traced game made in its own engine and programming language

#76
post #36

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

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.

[deleted]

Re: Voxile: A ray-traced game made in its own engine and programming language

#77

Earlier quoted context omitted.

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

Sorry, I mean that writing functional code in C# is way more verbose than in Kotlin.

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.

[0] https://github.com/louthy/language-ext

[1] https://arrow-kt.io/

Re: Voxile: A ray-traced game made in its own engine and programming language

#78

Earlier quoted context omitted.

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.

For me, it does.

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.

Re: Voxile: A ray-traced game made in its own engine and programming language

#80

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 f…

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

Teardown calculates collision meshes and does physics on those. Not on voxels directly, and definitely on in voxel space.
Post reply on HN