Things are progressing at a steady pace, in a bit every direction, as usual. The aim is to have the Steam Page in May at worst and a public Demo in June at worst (for the Next Fest).

Resolving performance issues

During playtests, it has come to my attention that the game performed poorly with bad computers or graphic cards that don’t mix well with Vulkan, Godot’s forward rendering engine.

After investigation, I would discover shadows from my lights would take a lot of draw calls. Despite playing with the distance fade, it would not affect performance. I introduced a setting to disable shadows and we went to test it on a low laptop.

But this didn’t help and the game was still going at 20 fps or less. Someone suggested using RenderDoc, a software that captures the steps in which a frame is rendered. To be honest, it’s black magic for me and I’m out of my field. But thanks to the software and guidance of friends, we managed to discover that most of the frame time, was used to render an image above, below, and on the side of the player. Like a sort of cube map. One of my friends immediately thought of reflection and here it was, on the player camera, I had a Reflection Probe set to refresh each frame. This was taking a LOT of time. I was using it to have reflections in water, but I chose a more wind-waker style of water, so it’s not as important anymore.

RenderDoc shows clearly how much time is spent on a certain rendering step.

Similarly, thanks to render doc, we witnessed the shadows from the directional light being drawn in each frame. I lowered the quality of the shadow as well by setting it to Orthogonal. With those changes, the game could run at 50/60 fps on the poor laptop which was much better. I might add an option to run at 30 fps so it’s stable, we will see!

You can visualize all the intermediary steps to build each frame.

Big Mesh vs Instancing many

I’ve also discovered that you could export any scene in Godot to gltf, to be modified in Blender, which is great because it means I can generate my levels in Godot, and then make it a single mesh later. However, after testing, loading a lot of instances of my walls and loading a unique big mesh would improve loading times and memory, only very marginally, so I dropped this for now.

I wish I would do more playtesting, but I keep going on technical stuff.

New assets

I replaced the placeholder for the skeleton and the zombie.

New challengers appears!

Moon Level

I’m blocking the moon level. I’m not satisfied yet with how it looks, but it’s ongoing. I have several plans for this area. I want it to be lightly Japanese-themed, with a pale blue area and a pale pink area. It will be inhabited by Onis (blue and red) and one of them will be your companion. I already have a sketch of this character that I’m happy with.

A sketch I made during my trip in Japan.

Looking down

On the gameplay side, I do a little step while looking down and I really love how smooth it is. Sometimes instead of playtesting, I play with the looking down.

Victory screen

I also made a new shader that takes a picture, tile it, and moves it across the screen which I really love. I’m gonna reuse this everywhere.


I made a discord server about the game, mostly for ease of speaking with playtesters. I did not communicate about it publically, so if you find it here, and join, it’s still a bit of a secret club.

Next week I’ll take it easy. I’m fighting with a slight infection, and a dungeon crawler game jam is coming so I want to play some more games to be inspired for it.



  • Added a new monster, Skeleton with a Rapier.
  • Debuffed Monsters
  • Then buffed them they were too weak
  • Looking down is easier


  • Add Goblin expression to the dialogue scripts
  • Blocking the mood for the moon level, I made several floors, walls, and pillars.
  • Make monsters wobble
  • Rework the victory screen with a cool shader.


  • Added some missing Stairs Down event
  • Campfire clipping fixup
  • Added little animated stars to represent energy
  • Improved performance by 60% on bad computers!