As usual, I decided to learn something new for Ludum Dare. Last time I learned Go, really liked it and wanted to use it a second time. Learning Vulkan had been on my bucket list for a while, so this was the perfect opportunity to do it. Why use Go + Vulkan? Go is garbage collected after all. Well, what could go wrong?

Some weeks before LD44 I started writing a Vulkan renderer in Go (vulkan-go). I knew I would have to get this done beforehand as Vulkan is very verbose. You essentially start by selecting your physical GPU and then specify everything you want to do explicitly. There are swap chains, render passes, graphics pipelines and lots of different buffers. You have to allocate memory for your buffers and copy the data onto your GPU. All of your draw commands have to be recorded to a buffer beforehand. Doing all of this is both liberating and restricting. I actually settled on using the same command buffer for the entire game, with a separate draw buffer so that I wouldn’t have to re-record anything of the fly. By Friday I had the core renderer done that could render colored triangles in only 1600 lines of code. I decided to use my LD40 WebGL engine as a base for this one.

After the theme was announced, I got to work on depth buffers, texture loading and obj parsing. Now I could finally render textured triangle meshes! The rest of the engine was much easier to do as I could essentially copy stuff over from my previous engine. I ended up adjusting a lot of the physics code as physics simulation is something I’ve always struggled with. I definitely wouldn’t recommend doing your own 3D physics as this is generally a difficult problem to solve. I use convex hull intersection for collision detection. You can calculate convex hull intersection simply by taking a dot product of all the faces and figuring out whether a vertex is inside or outside. This can be used for concave stuff as well if we assume that all geometry is convex locally. Only do intersection on the closest triangles and you should be good. The physics simulation itself just calculates the velocities directly, does a position correction and adds some damping. I wouldn’t get involved with iterative methods or LCP. You just hope everything doesn’t explode.

I settled on a game idea fairly quickly as I thought this would inform my technical decisions. The game would be about a grim reaper’s job collecting souls and trying to make ends meet financially. I didn’t want to make levels manually so I had the crazy idea of generating the levels procedurally. First I started by generating random 16x16 triangular meshes, but pure randomness just doesn’t look very nice. So I created an implementation of the venerable diamond-square algorithm. Chunks of size 16x16 would be generated and then stitched together at the sides to make a continous level. Continous generation of chunks would make for an infinite world. I struggled with this a lot and you can still clearly see the edges of the chunks. I had never created infinite 3D terrain, so I’m still pretty happy with it.

The actual gameplay was very rushed as I had little time left. Balancing was a guessing game and I ended up leaving lots of bugs behind. I had no working Windows machine, so cross-compiling took a bit to figure out. In the end it all worked out and I’m pretty happy I did it. The Ludum Dares that leave me learning something are the best.

https://ldjam.com/events/ludum-dare/44/worked-to-death