Hi everybody!
This devlog, I thought it would be interesting to talk about the band song sequences. If you don't care about the technical aspect of that or don't want to be spoiled, I suggest you skip this and don't watch the video!
As mentioned in the previous devlog, I'm having to slowly start getting rid of unlicensed material. That includes a handful of songs I'm using. I've received the song uniquely composed for the EP04 sequence last week, made by a wonderful chap that offered his services. I spent that week and a bit trying to figure out how I was going to set that up more useful and efficently than before.
The idea was first introduced in EP03, but the way that was set up, I wasn't entirely happy about. A lot of these headaches could be avoided if I simply was using a recorded video and animation, but I'm not an animator and I wouldn't be happy about the lower quality that would come because of compression and the likes. I like doing it the way I've chosen, because it's a 100% the exact same quality as the rest of renders.
It takes forever trying to guess and get the timing right, when I want to switch between the different characters and instruments, while trying to somewhat keep on beat. The start of the song in EP03 worked very well, but it didn't take long for that to fall apart, go out of synch, and switch into more generic repeating sections. That was the part that annoyed me, and I wanted to do it differently and more accurately this time around. On top of that, the longer the song is, the harder it becomes to test. As you get to about 3 minutes in, and want to make a small fix or tweak, I had to listen to the bloody thing over and over.
I knew what I ideally needed, but had no clue how to utilize Renpy script to my advantage and write a proper bit of modular code for that. So, I ventured forth into the depths of the Renpy Discord, and started asking around if anyone had an idea. There's some clever bastards around that place, who know Python and Renpy script inside out.
Eventually, after chatting a bit back & forth, someone came up with a clever function that was ideal for my use-case. The way it functions, allows me to sample the song that is currently playing, and pick and choose a timestamp for when to switch to a different part of the flipbook animation.
This is what that code looks like:

In short, each of those green lines, are image definitions that call the right part at an exact timestamp in the song. I'm now able to keep exactly on beat, without having to guess.
Although defined as single image, each of those green lines are a container of images. Those images play at a certain interval and repeat, until a section is finished and it goes to the next. A single image definition looks like this, though some are more complicated than others:

I only figured out recently, that you can use "block" to repeat many smaller elements. This prevents you from having to copy and paste the same thing manually. Those blocks are then put inside "parallel" sections, which allows you to play each parallel section in synch with other functionality and effects together at the same time.
As you know, you either join the band as a guitarist or drummer, so that's another thing to take into account. This is fairly easy, as something as simple as a "conditionswitch" command can be used. This needs to be defined for each render used, so it picks the correct one, according to what you've chosen to be. The entire sequence is exactly 70 renders, so each need to be defined. A single definition with a condition switch, looks like this:

Once all of that is in place, the sequence is very simply called within the story script. It starts playing the song first, then loads the scene, then pauses the story script execution until you press the button to skip.

I don't like calling out render counts or lines of 'code', because it means absolutely nothing to anybody. I can say that I've done 2000, but what does it actually mean? Well, now you have some context of what that actually means, and it's not 2000 lines of dialogue or simple scene calls either, which is what most usually mean when they say that.
Thanks for reading this mumbo jumbo, may it aid in your future development endevours or simply provide interesting insight into my development process! The next dev-log, I'll prepare a diagram of where we're at, so you can see how much work I've got left to do, until we're ready for a beta release.
Until the next dev-log, take care!
Ezy
Ezy
2024-06-23 15:34:49 +0000 UTCMerlin
2024-06-23 15:31:37 +0000 UTC