Happy new year! I'm finally back on this project. The last three months have been really busy for me (relocation, Christmas, hosting my own jam…), but now that we enter 2020, I have finally more time for this project, and writing those devlogs!

That doesn't mean that I haven't made progress since the last time! Let me update you on the state of the game. We finally have some visuals! But first, I'd like to talk about a technical matter…

How to pitch a sound

If you remember, back in the previous decade, I had some issues with the quality of the pitch shift. Depending on the note, the attack felt weaker, a bit distorted… This is related to the way pitch shift works in Godot. There are two ways you can do a pitch shift:

• The first one is by editing the property pitch_scale of the AudioStreamSampler (the node that plays the sound), which is a positive number that is set to 1 by default. Its value multiplies the pitch of the sound, but also affects its speed. The lower it is, the slower the sound becomes, and conversely.
• The second one is to use a PitchShift effect on an Audio Bus. Buses are powerful tools provided by Godot to manage sound in the entire game. The pitch shift effect changes the pitch without altering the speed, thus allowing to obtain lower or higher sounds without deforming them.

So, the second option sounds better, no? Well, wrong! This was so far the solution I used: I created a bus for each of my samplers, with a pitch shift effect, and I edited the value of that pitch shift. Resulting in… A deformed sound!? Actually, the length of the sound was intact. But shifting its pitch meant also changing its attack a bit. “But this is not an issue I have in Audacity, which does the exact same thing!”, I thought. Well, turns out the algorithm used by Godot in this case is less efficient. This doesn't mean that it is complete trash: for long sounds, it is very efficient! So if you have a music, a sfx or a voice that you want to pitch, the PitchShift effect is definitely the tool you want to use! But for a very short sample? Better use directly pitch_scale. Even if the sounds speed is changed, it's too short to be noticeable. And as I explained before, I always take the closest note to have the lowest deformation.

Thus I changed my algorithm a bit. No more multiple buses, just a simple change on the variable pitch_scale! It's actually… much more simple. Although I was proud of my bus manipulation, this provides much greater results. Listen for yourself.

pitch_scale = pow(2, (note_val - sample.value) / 12.0)

There is still a little "click" unfortunately that can be heard, but it is small enough to be hidden by manipulating volumes. The proper way to fix it would be to implement a small decay when stopping a note to play a new one, but it's not certain I will work on that right now.

But enough about the fixes! Let's get to the interesting bits!

The visuals

My idea for how the game should look is very simple: floating instruments, bouncing in a room. At the start of the game they will be naturally placed, as if they were in a repetition or recording booth, but as soon as the player hits a key, the corresponding instrument will fly.

This is technically not too hard to do! A 3D scene with some assets, collision mesh, zero gravity, and at each input I just apply a random force on the body. More specifically, I stop them in mid-air before pushing them, as it makes the movement more perceptible and goofy. I also decreases slightly the velocity with time so that the instrument is "boosted" once played. Every walls and instruments are, of course, bouncy.

Looking for free instrument models was the first thing I've done for the project (I'm terrible at 3D modelling). It wasn't as easy as I hoped, but I eventually found what I needed. Then I had to convert them into .dae using Blender in order to export them in Godot, scale them (some models being just really huge), and giving them approximate collision shapes (some models are too detailed to use their mesh as a collision shape). The trickiest part was maybe to edit their material. I want them to be colorful, and have a toy aspect. Not reflect, no shadow. A bit like a N64 game! Although it doesn't work really well with some shapes, so I had to find compromises.

The result is not too disappointing.

Oh, here is the game logo by the way. Thought it would be nice to have it for this demo.

Anyway, I was quite happy with this result. But then I played a little bit with the camera, and I realized that the orthogonal projection gives a really great result too!

We have more emphasis on the logo, it's less claustrophobic, instrument are shown equally, and in a more abstract and silly set. The main drawback is that we loose the aspect "a normal scene that turns into chaos". And the lack of depth make the instruments less like flying in the air, and more like floating in an aquarium.

I'm really tempted to switch to the second view, but the first one is also interesting. Which one do you prefer?

Anyway, my next goal is now to implement the music! So far all of the instruments make the same sound. It is time I hunt some other samples. Then, I'll finally compose an original song for this game! See you next time.