Devlog 80 - Calibration Rework

Published: October 16, 2025

Progress continues on doing the easy/hard charts for the remaining levels that I've made so far, but I took a detour for a bit to work on something more important that I've been putting off for a while -- redoing the audio latency calibration flow.

The Story So Far

Rhythm Quest is a music game that does its best to Do Things Right when it comes to audio synchronization, even doing things like prescheduling jump/hit sounds by default instead of playing them in response to player actions. Of course, some sort of audio latency calibration system is needed to measure the difference in the delay of input/video display versus the audio output that is being used by any given player.

The calibration has gone through a number of different forms over time. Here's a really early version that was needlessly confusing and had the player set the audio offset manually for no good reason:


I realized at some point that =that= wasn't really going to work well, so I fell back to something simpler:


And then there's this "rotating circle path" visual that has been in the demo for a while:


I've known for a while that this needed a rework (honestly, the earlier/simpler version was probably better). I had various issues that I needed to solve...for example, I had the "beeps" create a melody to go along with the background music, but players were getting confused at which beeps they were supposed to be following. The whole circle path thing was "cool" but visually confusing and I don't think it actually helped many people understand what they were supposed to do. When I watched some people go through the flow, they were off-beat to the point that it would have been better if they =hadn't= gone through any sort of calibration process.

This was something that I had been mulling over for a while (user experience design is hard!) thinking about how to do it effectively. I also did some research into how this is handled in other rhythm games -- unfortunately, a lot of it ranges from bad to worse. The flows I saw were either really bad (even for experienced users), or at the very least not easy to understand for the average layperson. I was beginning to wonder whether I should just not even prompt people for calibration at all and let only advanced users do it by drilling into the settings menus? That didn't feel right, though...

Opt-in Calibration

Thinking about this, the first thing I wanted was to give people a good and intuitive litmus test for whether they =should= recalibrate their audio latency or not. Before I was using flashing squares for this, but I wanted something less abstract and easier for people to see, so I built out this screen using an animation of a drum being hit:


Hopefully this is much more clear, as it provides a snappy visual and also illustrates what the player should be looking/listening for to see if they care to change things.

Drum Animation

Drawing the drum animation was a fun little project. I obviously wanted something that clearly looked like a drum being hit, but it was also important to make sure that the exact moment of impact was highlighted. There's a brief flash that happens with the outline and other colors to demarcate this:


I used a big motion smear, because there can't really be anticipation frames for this animation (I'm using it for the auto calibration flow as well) -- the drum stick needs to hit immediately on the first frame. And then the squash + stretch of the drum itself not only makes the animation more "lively", but also serves to create a visual "moment" that your eyes can distinguish for the moment that the drum is getting hit.

Next, I needed to build the automatic calibration flow for if you say that the sound seems too early/late. This one is relatively straightforward -- this time the drum reacts to your input. There's a little progress meter on the bottom to solve a problem with the old calibration flow (it wasn't clear when it was going to be finished), and I even try to give you a rough indication of how consistent you were at the end.


One little interesting quip you might have about this screen is that every system has not only some amount of audio output delay, but also a delay inherent in receiving and processing input, and having the result of that input become visible on the display. If you watch the animation of the drum as you tap, you might actually time your taps slightly earlier, so that the drum animation matches the audio, instead of tapping exactly when you =hear= the audio.

I think this is okay, though. If players unconsciously (or consciously?) time their taps a little early in this way, that will probably be a tendency that they carry over into the game as well. And experienced rhythm game players who want to rely primarily on the exact audio timings may already know that the most accurate way to do this sort of test to achieve that outcome is to close your eyes or not look at any visuals at all...

After calibrating, you get this screen where you can check your work, and the option to adjust it manually:


I like this "choose the drum animation that looks best" approach as it provides a simultaneous side by side view of what different calibration settings look like, as opposed to most other flows I've seen (including my own) where you kind of just have to adjust a number while looking at one thing.


That's it for this update! There was a little more work involved in getting this all fleshed out, and getting the drum audio (it's just a pre-mixed separate version of the music loop, I don't schedule each drum hit on the fly) to play correctly; for example there's a completely different set of audio that plays in-game when you're in the pause menu and I needed to add the drum-sounded versions of that, too. But it's all working properly and this should be going out with my next patch release! I'm excited to finally be checking this one off (for now...) because first-time user experience is always important and this was definitely something I needed to address and iterate on at some point.

<< Back: Devlog 79 - Hard Charts, Settings Tweaks, and More
>> Next: Devlog 81 - Clematis