I planned on making an update to the Rhythm Quest demo to release the new level browser menu, but I got caught up in more work and ended up embarking on a different big refactor that'll be rolling into the same update. It'll be a big one! Nothing too visibly exciting, but cleans things up a lot implementation-wise, and enables some new functionality as an added bonus (which y'all will probably be more excited about than the actual refactor)...


In a previous devlog I mentioned that I had done away with "baking" all of the different levels in the game (pre-generating all of the object instances) and have switched to just always generating the levels dynamically. I had also mentioned that it would be possible for me to make a further optimization where instead of destroying the instances between levels I keep them around so that I can reuse them -- the common ones that are the same between each level, at least (enemies, wings, anything else that doesn't change with the tileset).

What about everything that =does= change with the tileset, though? Things like the floor, ramps, jumps, etc. all change their appearance from world to world, which is why each world has a different "level generator" object that contains references to all of the tileset objects that are used for that level.

I =could= try to keep these around, but they'd only be useful if you play another level with the same tileset. Otherwise, I'd just accumulate a bunch of unused objects in memory, which is probably a bad idea...


The solution was to make "universal" versions of these tileset objects which are capable of displaying the graphics for any world. So instead of having floor_1, floor_2, floor_3, ... I now have floor_universal which has 6 different sprites inside of it, and then I dynamically enable/disable the correct one depending on what tileset you're using.

Unfortunately it wasn't =quite= that simple. Different tilesets actually have slightly different properties at level-generation time, most notably for the little "ledges" that jut out (or not!) for jumps. As you can see here, because the "overhang" amount varies per tileset, the ground below is also a little wider or thinner to accommodate:

I was up to the task, however, and managed to bake these offsets into the universal tileset objects, so everything "Just Works" the way that it should (hooray!). Not only does this allow me to do the object pooling across scenes that I mentioned above, it also allows me to potentially specify a different tileset per-checkpoint and fade them (mostly) nicely across each other:

Of course the "gameplay trailer" level already had multiple tilesets, but that was done in a very hacky (and non-performant) way; it feels much nicer that this is now a first-class feature and it shouldn't be too hard to expose this in the level editor in the future. More importantly, I'll be able to use this in level 6-5, which as the final level of the game will potentially (?) be some sort of recap medley that takes you through all 6 different worlds. That's something I'm definitely feeling intimidated about writing, but knowing me I'll just eventually sit down one day and just sort of knock it out in one go...


Kind of along the same lines, I've re-coded the backdrop scripts and shaders to support having a different backdrop per checkpoint. Fortunately, the work I mentioned in a previous devlog that I did for the menu scene meant that I already had an optimized setup for taking an arbitrary number of backdrops and being able to fade between them without losing too much performance. So now you can do this, too:

The level loading code now iterates through all of the checkpoints in the level and loads in all of the backdrops that are used for the level at load time. Of course, the more backdrops you have loaded, the more memory gets used, but luckily I already know this isn't really an issue, as the menu scene already needs to have every backdrop in the game loaded!

As a final bonus, I no longer need a manual listing of which levels use which backdrops for displaying the preview image in the level browser -- I now just pull the appropriate image based on whatever backdrop set the first checkpoint uses. Yay!


With all of the above work done there was only one remaining element that was still specific to each individual level scene -- the particle effects for each level. I had already done some work toward creating a set of common particle effects that you can use in your custom levels, but...none of the levels I authored were actually using them, they still just had hardcoded particle system instances.

Loading those dynamically (just like the backdrops) was not very difficult, but while I was at it I ended up digging into the particle systems and trying to clean up some longstanding issues.

First off, you know how the particles cover the whole screen nicely, regardless of your screen resolution? Yeah...it's actually not so nice. This is done simply by generating a ton of particles (many of which you never see) in a really big area that hopefully accounts for whatever is in view:

I decided to finally go ahead and tackle this in a more elegant way. Now I have scripting that inspects each individual particle and detects when it goes offscreen. When it does, I either despawn the particle and instantly spawn in a new one (I can make sure the spawns happen offscreen), or I just warp the particle's position so that it screenwraps. Here's what it looks like when you just have the same set of particles wrapping around:

I know, I know, in-game it usually doesn't look much different, so it's not really a noticeable change. But one nice thing about this is that since I'm managing the particle lifetimes myself I can specify the number of particles as a density relative to the screen size, so something like "1 particle per 2000 square pixels", which feels much more elegant than just spawning a whole crapload of particles offscreen and adjusting the numbers until it "looks right". My code automatically takes care of spawning in new particles (or destroying older ones) if the camera size is changed at runtime, and this also handles camera movement in a much nicer way.

You might think that going in and modifying the particles individually is computationally expensive, but I'm using Unity's "burst" compilation feature to make sure that is all done in parallel in an optimized way -- plus, there are less particles to handle since the system doesn't have to process all of those previously "wasted" off-screen ones. As an actual added functional bonus, this also let me implement parallax scrolling for particles, which wasn't possible before. So now I can have different layers of particle effects that scroll at different rates if I want:

Of course, before this was also possible to sort of "fake" by just having the particles scroll to the left at different rates, but now it's actually keying off of the camera movement, so it'll behave correctly for things like respawns, as well as being able to handle vertical camera movement.

With all of these refactors in place I can finally delete all ~50 of the individual level scenes that I previously had in the project and simply replace them all with a single universal game scene (woo!). Of course, there's still some cleanup to do -- level 1-1 is broken because I haven't handled the tutorial backdrops yet, and the level editor/custom level setup needs to be redone to reflect all of these changes...but progress is progress!


I've been working on other stuff here and there as well...for example, the "test UI" that lets you jump between checkpoints (previously only available in the level editor) is now shown in the in-game "practice mode", letting you jump between checkpoints freely to practice whatever section you want, or quickly change the speed of the music (you can now raise the speed past 100% in practice mode as well).

Through this all, the game will remember what checkpoint you were at before starting practice mode -- and will now also handle resetting coins correctly (this was previously bugged)! There's a new "Section Lock" setting that controls whether practice mode will lock you to only practicing a single section or whether it'll let you proceed through the level normally until reaching the end (at which point it'll bring you back to the beginning).

For the demo version of the game, the "Unavailable" lock logic is fully hooked up in the level browser:

And last but not least, I've been experimenting with "diamond" shaped markers on winged air jumps to denote off-beats vs on-beats. This comes in response to an issue I've seen crop up with players going through level 2-1 where you have to distinguish between the following two airjump patterns:

There's multiple solutions to this -- change the music + chart, increase the scrolling speed, add visual markers of some sort, change the default noteskin for air jumps to reflect the beat they're on. I've mostly seen this be a problem in level 2-1, unlike level 2-3 which is at a slower tempo despite having more complicated airjump strings.

By far the =cleanest= solution would be to simply redesign the chart here, so that I can intentionally segment the level into introducing whole-beat airjump patterns and then half-beat airjump patterns separately. But that's easier said than done, because the main melodies in the song weren't designed with this in mind at all. I'd probably have to just make a brand new level 2-1 track if I want that to happen, and that isn't something I'm ready to bite off at this moment.

As a stopgap solution, I've slightly increased the scrolling speed (which marginally increases the difference in horizontal spacing between the two patterns), as well as started experimenting with a new "diamond" marker for obstacles that are put on off-beats, which could end up being useful for other obstacles as well (basic enemies on offbeats, for example). I'll probably be adding some different settings/toggles for this behavior later.

I have no idea whether this helps or not because to me it's trivial to read the rhythmic differences based on the relative height of the airjumps, so I'll have to revisit this change later after I publish it in the new demo to see if it actually does anything for new players or not!