Rhythm Quest News

Welcome to 2025! Hopefully this year brings a bunch of more exciting progress on Rhythm Quest...we're going to kick things off with a new bonus level -- this one is called "Bottled Up"! This is actually a song I made all the way back in 2019 for an as-of-yet-unreleased album...unfortunately some of my other music projects have had to take a backseat to Rhythm Quest development, but hey, it's cool that I unexpectedly get to bring this song out in a different way. Here's the playthrough video:

[previewyoutube][/previewyoutube]

[h2]Bottled Up[/h2]

This song was really fun to chart -- I'm glad I ended up choosing it to bring into the game! I'm really enjoying furthering my exploration of charting as I grow alongside the game and work with different types of patterns. I'm also trying to make sure that I add in more songs like this that differ from my usual "9-bit" tracks, to showcase a variety of music styles within the game.

Having multiple difficulties planned also lets me feel more free when I'm charting -- I no longer have to worry about whether I'm having a good spread of easy, medium, and hard levels since I'll have three different charts for each one! For the hard chart here, I'm leaning into 16th note rhythms to provide some nice bursts of action, but since the song is relatively quick, I'm being careful to avoid too many repeated presses, as personally I don't think constant jackhammers of the same key at high speed are very fun:



The slow "breakdown" section of the song features a long underwater section. Here you can see another little tweak I made while I was working on this song -- Princess's spiky balls now move slower underwater (just like your jumps!):



The contrast between the slow, drawn out underwater phrase and the next section works really well, you get slammed into the action with some yellow ghost combo rhythms:



The last section of the song is completely in triplet meter! This was my first test to see whether I could make that work using the existing speed zones mechanic. The speed zones are a little bit limited in that I have to keep patterns simple for the aid of readability (more jumps than enemies, as they're easier to read at high speeds), but it manages to work out:



You can see another addition here that I made while working on this song: because the beat markers are a little confusing within speed zones, I tried to add little vertical lines that pulse with the beat and delineate both full beats as well as the triplet markers. Hopefully I can land on the right balance where these add a little bit of liveliness and information to the speed zones without making it look overly noisy.

[h2]Level Browser Work[/h2]

The other thing I was focusing on for most of this past month (besides recovering from Covid...) was continuing to work on the level browser (formerly "song select") menu, which is now much more fully fleshed out. This is the main way to browse all of the bonus and custom levels that you have available, but you can use it to select and play the main levels, too. Here's a full video of that in action:

[previewyoutube][/previewyoutube]

You'll notice to the left that in addition to the stats display that I built a while back for custom levels, and the new difficulty selector button, I've also ditched the old 1-99 numeric difficulty display for a new fancy density chart:



Hopefully this is both a more representative and more interesting-looking representation of the difficulty level of songs, as well as being clear that it's only charting out note density and not making any claims about how hard the rhythms are to decipher or read. (As before, simultaneous attack+jump presses count as 1.5 actions for this chart) The calculations are a little bit more complicated than before as I have a rolling window that I use to track the density of the actions over time, but I've tweaked it to a point where I'm relatively happy with the results.

The chart itself is rendered dynamically (using parallelization!) to a texture, in much the same way as the waveform display UI that I implemented a while ago for the custom level editor. Besides the colored line itself, there's min and max labels on the chart, which serve as a more quantitative measure of how sparse or dense the chart gets. The color-coding I think really ties everything together (currently it goes from green at 100 notes/minute, to yellow at 200 notes/minute, to red at 300 notes/minute), as it provides an at-a-glance rough indication of overall difficulty without having to rely on parsing raw numbers.

I also now have a fully-working purchase flow for bonus songs, which replaces the old level shop (which was hopelessly outdated). I also support short descriptions of each song, which I'll try to backfill for all of the existing bonus levels.



I still have to get the custom levels working in this view again, but I also want to include this UI (along with all of the song previews) in the demo! I still have a bit more work to do before that will be fully functional (need to hook it up to the "not available in demo" overlay screen), but this will hopefully be a nice way of showing off all of the content that's going to be in the full game in a way that will get people hyped up for what they can expect when they make the full purchase. (I mean, it was already pretty satisfying for me to browse the levels and listen to all the music previews!)

The Rhythm Quest Demo has been updated to version 0.35.0! This patch includes two new difficulty levels for you to try out -- play on Easy mode for a more relaxing experience, or try out Hard mode to challenge your skills with more difficult charts!

Full changelog:

Version 0.35.0
- Added Easy / Normal / Hard difficulties and corresponding charts
- Added spacebar as a default binding for jump (in-game only)
- Recharted / tweaked some Normal difficulty charts and songs
- Added temporary display of difficulty on level start and end
- Reworked water effect for level 1-3
- Fixed bugs with screen filter shaders
- Change end-of-demo popup to only show automatically on first level 3-4 completion
- Prevent binding the same input to multiple action slots
- Attempt to fix pixel clamping rendering issue
- Fixed minor rendering bug for certain menu backdrops
- Reworked level loading implementation (may lead to faster load times)
- Fixed potential load crash when loading old save data (< 0.29.0)
- Fixed practice mode menu navigation
- Update coin sfx pitch to match current music speed
- Fixed VSync setting button not updating correctly
- Fixed incorrect jump/scroll logic when fast-forwarding through level end

Version 0.35.1
- Fixed respawn bug for certain levels (1-3, 2-1) when using timing window mods
- Fixed pixel font underline offset

Version 0.35.2
- Fixed wrong music playing when returning to level select
- Minor UI tweaks and fixes

We're into the start of the holiday season now! I could either take this opportunity to dive head-first into Rhythm Quest work, or I could instead take it as a chance to rest and recover before the start of the new year...knowing myself, I suspect it's going to be neither of those and I'm just going to continue onward at a slow and steady pace!

[h2]Multiple Difficulties[/h2]

Unfortunately I don't have any sort of "Rhythm Quest is feature complete!" or even "I finished working on all of the main levels!" announcement for the end of the year. However! As a consolation prize, I do have a little upcoming holiday present for all of you, and that is the unveiling of the new difficulty selection feature:



This isn't live in the demo (yet!), but you can now select from Easy, Normal, and Hard difficulties when starting the game, right before the world select menu. While I have reservations about adding yet another screen that you need to get through before you're actually in-game, in this case I ultimately decided that the benefits seem to justify the cost in this case. I unfortunately didn't have enough screen real estate to show any fancy previews or graphics here, but I also didn't want to have a menu that was =just= text, so I added the little enemy icons some some cute little visual iconography (with beat-synced animations!).

The hope is that adding multiple difficulty options will let experienced rhythm game players feel less bored through the earlier part of the campaign, as well as offer a more lightweight version for people who want to experience all of the levels but without them getting too hard near the end. It also adds some amount of replay value for people who want to go back and replay the levels with some harder charts.

Picking a difficulty level isn't a commitment and doesn't "lock you in" -- you're free to change your mind at any time and each level will track your scores (and coin counts!) separately, so if you decide that the levels are getting a little too hard for you, you can always turn the difficulty down moving forward. This does mean that there are essentially triple the amount of available coins in the game, so you'll probably just end up with a bunch of extra ones after unlocking everything (or maybe I'll just make some expensive "stretch" purchases for show).

There have been some UI changes in various screens to accomodate the new feature. Here's the level select screen, for example, which has a new button for changing your selected difficulty without having to go back to the initial menu. Again, I dislike how this screen feels more cluttered than before, but it was the best solution I could come up with given the constraints, and committing to it also allowed me to fit an extra "Bonus Levels" button on the upper-left to make things all nice and symmetrical.



I've been thinking about this feature for a while and initially had some trepidation because one of the main strengths of Rhythm Quest is the tight and intentional mirroring between the charting and the music cues -- I was worried that recharting the same tracks would lead to a loss in that coherence. With a previous game, "Melody Muncher", I solved this by simply adding new melodies into the existing songs and exporting multiple mixes of them, but I wanted to avoid doing that this time around as that would triple the amount of audio content that needs to be authored and served with the game, which is undesirable (particularly on mobile devices).

After thinking about the tracks, however, I think I can manage to make it work, even reusing the same audio. Normal mode will still be presented as "Rhythm Quest as it was originally intended", so it will most likely have the best matching between charting and music, but I think there are plenty of good opportunities where I can take liberties in charting the same piece differently.

This does add quite a lot of additional charting work for me, as I've now got to re-chart all of the existing 29 songs for both Easy and Hard mode (some of the later Normal mode charts might even get toned down a bit), not to mention the bonus songs as well. But charting is not particularly "hard" work to do, as it's a very known quantity. It's just going to take time.

I do, however, intend to release the re-charted versions of the demo levels before the end of the year, so you can look forward to playing those soon! Consider them to be my holiday present to all of you who are patiently waiting for more progress to be made on the game...

[h2]Charting Differences[/h2]

Because the beginning of the game needs to ramp players up from essentially zero, the first few levels (the only ones I've worked on so far) won't have very significant charting differences between the three difficulties, but there will still be some.

The mechanics are still going to be introduced in the same levels throughout all difficulties, because I want players to be able to switch between difficulties at any time during their playthrough. However, the level of "rhythmic pattern" difficulty will increase at different rates. Here's an example of a snippet of level 1-2 to illustrate some of the minor differences:



Separating the easy and normal charts is actually fairly difficult early on and as a result they end up looking mostly the same (which is alright, for now, until we get to the later levels). I could just remove even more obstacles from the easy chart, but at a certain point that ceases to meaningfully make the chart easier, and can even make things =harder= as it's potentially more difficult to keep a steady beat in your head when the notes are too sparse. I briefly thought about increasing the number of checkpoints in the easy charts, but I decided against it as that would throw off a number of things (color palettes, too many screen flashes, etc).

The hard charting is a little more interesting to look at. Early on I need to strike a balance where I don't want to ramp up the difficulty too quickly, but I want to also make sure that players who "get" rhythm games are still always being engaged. I decided to allow for eighth-note basic enemy patterns in hard mode from the get-go, which really helps set apart the hard chart, but I'm still mostly holding off on more advanced rhythms involving off-beats and syncopation, except where it really flows in tune with the music in an obvious way.

[h2]Level Loading[/h2]

Small (boring) technical note here on a change that's being made to the way levels are stored and loaded. Previously I had a "level baking" process where I ran the level generator code for each level ahead of time and then wrote the results out to disk as part of the build. The idea here was to (in theory) speed up the process of loading levels by precomputing all of that logic and just reading the fully-baked level from disk instead of instantiating all of the objects on the fly dynamically.

This is now more or less gone as part of the difficulty refactor. I didn't want to bake 3 different versions of every single level, and it's not actually even clear that this reduced loading times at all, as reading a million serialized objects from disk can potentially be slower than just instantiating them dynamically (this is the sort of thing that's hard to test outside of an actual build, and probably varies device to device). I still have a "level analysis" pass that needs to be run offline where the logic runs through every level to collect stats on it (notably, how many coins are in the level), but now I only save those numbers and not any of the actual level geometry.

I've mentioned before that I have an "object pooling" solution that's used in the level editor in order to reuse object instances every time the level is re-generated. I'm leaving this as a task for future me to talk about, but if I wanted to speed up level load times, I could actually persist the object pooling across different level loads -- that way, when you load a new level, it can just reuse the enemy/obstacle objects from the previous one you played instead of creating new ones from scratch (which is slower). So there's more optimizations that can be done if I put in the work to make it possible.

[h2]Song Select Menu[/h2]

Besides supporting multiple difficulties, another work item on my by-end-of-year wishlist was building out a holistic "song select" menu that features all of the levels available in the game -- including the main campaign, the bonus levels, and custom levels, all in one big browser. I spent a good portion of this month working on that, and it's coming along pretty alright:



This looks pretty similar to the custom level browser that I implemented a while back, and a lot of the implementation is copied over, but in general things are more encapsulated / architected out a bit more robustly because I need to handle different types of content (i.e. many different button formats, instead of just one).

One new thing I coded up was a way to scroll the list via touch swipes, with scroll momentum and all that. This is only allowed on mobile devices, as on desktop / web / switch builds you have other better methods of navigating the list. It's a bit weird that this is the only UI in the game that uses this UI navigation paradigm, but I couldn't think of an elegant alternative for touchscreens that I was happy with and this is the only place in the game where the buttons need to be laid out in a really long dynamic list like this.



I had two options for implementing this -- use Unity's built-in scrollview logic, or just code and manage the scrolling inertia and clamping/snapping logic myself. Fortunately, I'm wiser than I once was, so I chose to just roll my own custom solution instead of even attempting to deal with Unity's this time. =P

Overall, it works pretty well! I had to iterate a little on exactly how much momentum to accumulate based on the movement of your intial touch/swipe, but fortunately it seems like my instincts were mostly on point and it feels natural for the most part.

[h2]New Water Shader[/h2]

Someone reported a bug where the water effect in level 1-3 wasn't stretching across the entire screen for certain resolution/zoom levels, so I took the opportunity to just revamp the entire effect altogether. Here's what it used to look like, just a flat rectangle with a render texture that's used to capture the "reflected" graphics and then apply some sine wave modulation to them:



And here's the new version:



Looking a lot nicer, I think! This is going to be one of (hopefully) many many improvements to help bring the visual quality of the earlier levels more in line with the later ones.

The different "wave" layers are actually all drawn in a single pass by the fragment shader here. There's no complicated water simulation going on (the movement doesn't need to react to anything dynamic anyways), it's just a bunch of sine waves blended together to make an undulating pattern. Combined with the parallax scrolling and layering (and the fact that it's now partially translucent), it all comes together to make a nice effect.

One interesting aspect of the implementation here was to clamp/filter the pixel rendering correctly. Without that, you get waves that are rendered smoothly at whatever your device's native resolution is, which doesn't match the pixel aesthetic of the rest of the level:



With the clamping, the water waves are "stepped" with the same pixel sizing as the rest of the level graphics.




That's it for this update! There's still a lot more work to be done on the song select menu (bringing back the left-hand panel, letting you change your selected difficulty, etc) as well as recharting all of the demo levels (which will be my priority for the remainder of the year!) as well as trying to think about what I want to do with the backdrop visuals for worlds 1-3. Hopefully you all have a nice end of year and here's hoping (once again) that the coming year is "the year" for Rhythm Quest!

No fancy new level to show you all this time, but I've been doing good work regardless this month. I have a silly little -- ok, maybe it's really not little anymore, actually quite the opposite -- Trello board where I track tasks and work items that I accomplish for the game, divided into weeks, so you sorta track the number of things that I end up tackling per week. This past month had some columns that are longer than can fit in my screen...



[h2]Weblate Site[/h2]

I mentioned in a previous devlog that I had been working on migrating off of Crowdin for managing community translation efforts due to exceeding their free plan limits. I'm happy to report that my self-hosted Weblate site has been up and running and seems to be fully functional with no issues!



Currently (subject to change) this runs on an Amazon t3a.small EC2 instance, which costs me $0.0188 an hour on-demand (was easiest to go with AWS since I already have other stuff running there), which is pennies compared to the non-selfhosted options out there. More importantly, it all seems to work, and it's even synchronizing everything to a github repository in XLIFF format, so I can breathe much easier knowing that rollbacks or tracking down issues are going to be that much easier.

[h2]No More Unity Branding[/h2]

I finally bit the bullet and did a major engine upgrade to Unity 6 (aka Unity 2023). This involved fixing a couple of bugs that cropped up (the upgrade exposed some issues that were mostly my fault that had never surfaced before). Upgrading isn't really painless right now because I have all of these custom changes to Unity packages (hacks to make things actually work like they should...), but I managed to handle it well enough. Probably the biggest relevant change (hah) in Unity 6 is the removal of the Unity splash screen requirement for free Unity licenses (huzzah!). I also took a few minutes to update the WebGL template for the web version of the game, so now we get a nice loading graphic and we're totally devoid of any Unity branding!



I can probably stand to make this even nicer later on, but this is already a welcome change, and nobody has to wait those extra 5 seconds sitting through the Unity logo before the game starts, woo~

[h2]Loading Icons[/h2]

Speaking of loading graphics...I also took another few minutes to implement a simple change that's been on my list for a while: the loading indicator in the corner of the game now changes to reflect which character you have selected!



[h2](More) Backdrop Optimizations[/h2]

I was tired of seeing framerate drops when testing on lower-end devices (like the Switch...), so I went in and did another pass at performance optimizations. Besides random trivial "cache this lookup" or "use a binary search here" improvements, the main change that happened was with regards to how the backdrops are rendered (again).



A long time ago I did some nifty optimizations around backdrops that had large opaque areas (obscuring big chunks of what was behind them). Essentially, if we know that the entire screen below a certain point is covered up, we don't need to bother rendering any of the backdrops below that point.



...eeexcept if the backdrop in question is transparent, in which case we =do= have to go ahead and still render everything. Now of course, I have a lot of backdrops that are opaque, so this is still a good improvement.



...eeexcept when I'm crossfading between two sets of backdrops in the menu. This special case has caused me a lot of headaches in the past and it was never performant on the Switch despite my best efforts. There's multiple problems at play here:

- We're simply drawing twice as much stuff (twice as many texture lookups, twice as many "pixel paint" operations).
- If you want something that's a halfway fade between set A and set B, you can't just render set A at 50% opacity and then render set B at 50% opacity on top of that. That's not how blending works. So instead you need to reorder everything -- you can render set A at 100% opacity, and then set B at 50% opacity on top of all that. That requires a lot of bookkeeping logic around the sort order of all of the different backdrop layers.
- Rendering backdrop layers at less than 100% opacity throws all the nice optimization described above out the window.

Really what I wanted to do was just treat backdrop set A and backdrop set B as pre-rendered (moving) images and then fade between those two, instead of having to deal with the complexity of each one being made up of 20-30 different layers. So, I did just that!



In the new setup, each set of backdrop layers is rendered at full opacity to two separate temporary render textures -- one for foreground layers, and one for background layers (for those of you who are familiar with how rendering works, we need to use premultiplied alpha here to handle transparency correctly). We can then easily crossfade between our temporary textures without having to worry about weird transparency blending artifacts. This took a bunch of work to set up, but actually massively simplified the menu backdrop handling code as I don't have to worry about doing weird juggling of the sort order of a bajillion different individual layers.

There's still more rendering optimizations I can potentially look at in the future (some of the world 6 backdrop sets are particularly heavyweight and could benefit from some additional techniques around intermediary textures), but this is already great progress and we successfully eliminated the framerate drops on Switch that were caused by menu transitions.

[h2]Editor Improvements[/h2]

I also made some optimizations for the level editor! Previously I described how each time you make a change to a level, the editor currently needs to regenerate the level in its entirety. To make this faster, I have object pools for all of the level objects, so that I can reuse the instances instead of destroying all of them and recreating them from scratch (which would be much slower).

...except, somewhere along the way I ended up breaking that entirely, lol. When I started supporting different level tilesets, I had to swap out the "level generator" object that contained all of the tileset data, and the easiest way to do that was to just replace it every time you recreated a new level. Except, that object also contained the object pool...which therefore was getting destroyed every time...[facepalm]

Anyhow, that's all fixed now. I actually found this bug because I was testing out the new fine-grained editor grid, which lets you place obstacles using a 16th-note grid. This is mostly so that you can create interesting syncopated rhythms, but yes, if you wanted to, you could just go wild and make "random note-spam" type charts:



[h2]Virtual Cursor[/h2]

I also added a virtual mouse cursor implementation for the level editor that you can control using either the keyboard or a gamepad. Technically this isn't really required for any platform (even for something like Nintendo Switch you can still use the touchscreen, unless of course you have it docked), but navigating the editor UI via keyboard doesn't really make any sense anyways so I figured I'd try this out.



As usual, Unity gets you kinda halfway there but then you have to pick up the pieces, leaving you wondering whether you should have just implemented the entire feature yourself in the first place. Unity provides a virtual mouse cursor implementation that (fortunately) will hook into their UI input system, except:

- It doesn't properly handle UI canvases that are scaled (like mine)
- Disabling and re-enabling the cursor causes a HUGE lag spike as it re-registers a new virtual input device and does god-knows-what-else
- For whatever reason it seems to not interact with UI (yet still move around fine) if you're using specific parts of the new input system (device-based control schemes)

But after some cursing and debugging, and some added hacks, it seems to all be working fine! The system is smart enough to enable the cursor when you use keyboard or gamepad input, and turn it back off if you start using a mouse, plus you can even scroll the camera by putting the virtual camera at the screen edges (or via right analog stick).

[h2]Gamepad Fixes[/h2]

As is common, gamepad support is yet another piece of functionality that has landed firmly in the bucket of "I should have just reimplemented this myself manually from the beginning instead of using the Unity-provided solution". So far I've been using Unity's newer "Input System" solution, which actually has a number of advantages over older implementations -- including automatically switching between control schemes based on player input, as well as supporting input rebinding. After (sigh) some hacks here and there, including one to deal with the fact that Steam forcibly takes controller input and translates it to keystrokes (thanks, no thanks...), I actually had that all mostly working.

...eeexcept for the fact that on some systems (??), certain controllers would simply not register input under Unity's new input system whatsoever. Not just a "my implementation" problem either, as I downloaded some sample projects and the issue shows up there, too. But...clearly the device has connectivity, and Unity even throws up a helpful message reporting when the controller connects.



Gamepad input is understandably something really hard to deal with (given the number of hoops you have to go through sometimes to get a given console controller working with your system), but I'm going to blame Unity for this one given that their old input manager implementation still picks up the gamepad's input in this case.

I hope I'm not going to be regretting this later on, but for now I'm leaving the old (new?) input system implementation in place (with my hacks, it does end up switching more-or-less gracefully between input schemes, which I like), but I implemented a legacy gamepad fallback implementation for when the new input system claims to not have gamepads attached but the old one does.

Of course, with the legacy input system, there's no standardization for how the buttons and sticks on various controllers present themselves, which is probably part of why Unity had that old input configuration dialog that used to pop up every time you started up a poorly-made game jam game:



Ah yes, the telltale sign that you were about to play somebody's first Unity game. Anyways, fortunately for me, Incontrol's old open-source package contains device profiles for many known controllers. Granted, this hasn't been updated in the past 3 years (since Incontrol became a commercial closed-source asset), but I found that it was good enough for my purposes, at least for now. I integrated Incontrol's input handling and mapping, updated it to work with Unity 6, turned on XInput support, and "just like that", I have gamepad input testing and working for my XBox360 controller on Windows and on my PS3 controller across Windows and Mac.

I mean, forget the fact that I needed two separate programs to even get the PS3 controller to hookup to those systems successfully, and the fact that the XBox360 controller support is just plain borked on Mac...

[h2]Font Rendering Fixes[/h2]

Updating to Unity 6 meant some small shifts in how Unity packages its text-rendering system, which exposed a few issues with pixel snapping and sorting order that I ended up ironing out. While I was at it, I noticed that the unicode pixel font that I use (unifont) rendered OK when the game was at small resolutions, but at higher resolutions it got all blurry and the sampling didn't seem right.



This one is kind of on me. Unifont is designed to render minimally at size 16 (or 12, depending on what you're plugging it into), but because my game pixels are often already upscaled, I was having it sample at that size and then setting it to display at 50%. The UI canvas would for example be scaled up by 2x, so it ends up balancing out to present at 1x scale and render crisp pixels (which are 50% the size of the rest of the game's "pixels").

Unfortunately that just doesn't extend to other canvas scaling situations. In the end I just decided to get rid of that 50% factor, so now unifont displays one to one with the rest of the pixels in the game UI:



Of course, now the font is just bigger, so I run into issues where the glyphs can't really fit properly into the areas they're supposed to. But if you're using a language where the unicode font is used, you reallllyyy ought to not use the pixel-based font anyways (and the game is smart enough to default you to smooth font rendering in this case). Unless of course, you're playing at like 500x300 resolution for who-knows-what reason. In that case, this is actually an excellent change because the unicode pixel font now reads really well at that size, and you probably don't mind that the lettering is bigger!

[h2]What's Next?[/h2]

Phew. There's still an endless list of things to take care of, and we're already two months out from the end of the year, but I'm happy with the amount of time I've been putting into things, at least. Moving forward, there are some remaining big-ticket items that'll make me feel much better if I can knock them out, including but not limited to:

- Unifying the selection menu for both bonus songs and custom levels (and main campaign levels, why not) into one big "song select/free play" menu
- Doing some thinking about whether I want to support multiple game difficulties (and more importantly, how I'd like them to work)
- It's awkward that the game settings are half split between "settings" and "game mods", I'd like to reorganize things if possible
- I still need a proper export flow for the level editor...

With any luck I will be able to at least get a few of these done by the end of the year. Thanks for reading, as always!

The Rhythm Quest Demo has been updated to version 0.34.0! This patch includes some major internal improvements, including a major Unity update, better gamepad support, performance optimizations, and more!

Full changelog:

Version 0.34.0
​- Updated to Unity 6 (removed Unity splash screen...)
​- Reworked rendering for menu backdrops to improve performance, especially during transitions
​- Other performance improvements
​- Add alternative gamepad support to improve gamepad compatibility
​- Decreased coin sfx volume
​- Loading indicator now matches selected character
​- Attempt to handle audio device changes/resets in menu scene
​- Fix softlock on changing audio device/improve audio reset behavior
​- Fixed spike enemies not responding to skin changes immediately
​- Fixed transitions for non-tiling backdrops in low-quality graphics mode
​- Localization/text updates and fixes
​- Added menu option to skip 1-1 tutorial
​- Disabled assist menu during 1-1 tutorial
​- Fixed track freezing causing softlock in 1-1 tutorial
​- Reset menu backdrop scrolling on transition
​- Potential rendering fixes
​- Fixed unintended menu description label changes during transitions
​- Fix rendering on unicode pixel font by making it much larger