More Rhythm Quest progress, cooking, gendered dance

Despite this being our busy week at work (deadline!), life is going surprisingly well.  This also despite a pretty myemie day on Monday my attempt to fix the washer didn't work and, even worse, I cooked a pretty poor meal for dinner.  It doesn't happen too often, but sometimes dinner really just doesn't go right...this time I had some miso black cod which I cooked in the toaster oven, but it really didn't sit well with me.  The fish was relatively fresh, so not sure if it was just something that didn't jive with my stomach that time, or because I hadn't marinated it very long, or what.  I ate it with some pickled radishes (those at least, were fine), rice, and some premade rolled egg/tamagoyaki thing which was...meh.  But yeah mostly something about the fish.  I feel like I cooked it well enough so I don't really know.  But I'll pass on black cod for a bit before trying it again.

I haven't had that much success with unagi at home actually -- they have been "ok" but not really super great (using the pre-packaged vaccum-sealed ones, of course).  I have been wanting to try umaki though (unagi rolled in tamagoyaki), so I'll give it a go the next time I stop by Nijiya for food.

Anyways despite all that, as I said, life is going pretty well.  I've returned back to working on my side indie game Rhythm Quest in full force, which has been great fun and extremely motivating -- I've basically been doing that for my train rides to and from the city, which is especially great because I don't really have any games to play on the train at the moment.  Haven't decided what I'm going to play next, but it could be Mother 3 (!), or maybe something I'll buy on Steam like Flinthook.  Or maybe I'll go through Undertale's "Hard mode" segment, since I never ended up doing that?

In any case, Rhythm Quest has gotten a bunch of work done.  Last time I worked on it I added both flying and double-hit enemies, and now I've added a lot of extra visual feedback for elements reacting to the beat as well as working on better particle effects, and cool visual effects for when you successfully hit a note/obstacle.

Most recently I rearchitected the whole audio syncing system and I'm now using Unity's AudioSettings.dspTime absolute timeline and scheduling all of my music segments precisely.  My previous solution relied on taking the current music playback time and having all of the elements of the game be based on that...except, if you do that naively, it's really jerky because the music playback time isn't updated smoothly at all.  So you end up having to track your own time, and do your best to sync your timeline to the music playback time.  That actually worked reasonably well, to be honest, but it wasn't perfect.

I was adding a feature similar to bit.trip runner on death such that when you die, a background loop plays such that there's still a persistent beat going through your respawn -- and when you finally reach your respawn point, it's downbeat-aligned, so it all snaps into place.  Very nice, very bit.trip runner, no breaking of flow or anything.  I had that all working with the old system actually, and it wasn't too bad, but I wanted to see if I could go the extra mile and use the audio scheduling functions to get sample-perfect playback.

It definitely took some work, but it's all working well now!  I've split my track into multiple segments, which are queued up and scheduled according to an absolute time.  I still detect drift between the "game time" and the audio dsp time, to ensure that the two sync up within some error margin.  When you die, the background track is already looping, so I just have to set its volume to 1 and stop the playback of the current music segment.  Then I do a bunch of magical calculations in order to figure out how long to let the background track play (for the respawn) -- and I schedule the new music segment to kick in exactly on time at the beat at which you respawn.  I also schedule the background track to stop playing at that same time.  So the music transitions are totally aligned, totally synced, and it's wonderful.  At some point I'll do a test with some sine waves or something just to make sure that it's actually sample-perfect.

Now there are some limitations though.  I did lose one of my features, which was playing and pausing the song willy-nilly and even changing playback speed for slowmo and rewind during debug play.  None of that works if I want to use the absolute audio timeline, so I dumped those features for now.  Sad because going through the song in slowmo and being able to rewind it was super cool, but ultimately those aren't really that necessary, and if I end up needing them I can do some sort of workaround.

The only remaining issue is that because audio latency and buffering is still a thing, *game*-related sounds that are supposed to be beat-aligned won't actually be played on beat.  This is simply a problem by nature and there's not that much you can do about it -- if your player presses attack perfectly on beat, you'll end up queuing your sound to play on that frame, but it won't be until some milliseconds later that you end up hearing the song because of audio buffering and latency.  In some cases you can try to be predictive and queue up the sound beforehand -- I will probably end up doing something like that for my checkpoint sounds, for instance -- but for sounds that depend on player input you can't really predict if/when the player is going to press the button.

So there's still some work to do there in terms of having coin sounds / checkpoint sounds be scheduled using the same audioDsp mechanism.  I also could be a =little= smarter about catching drift between game time and audio dsp time -- use some sort of adaptive heuristic or at least some smoothing in an attempt to find the best relation between game time and audio dsp time, but that doesn't appear to be a huge issue at the moment.  I also would like to try and clean up the code now that I've finished the refactor for the most part -- see if I can split off the new audio scheduling/timing logic away from the rest of the main gamestate logic.

So that's all cool!  One thing that is NOT cool is how disproportionately gender affects our social dance community and experience, though (as it does with the rest of our lives too).  I know this might be coming out of left field, but yeah.  I'm over it today, but I remember yesterday while walking back home from the station I had some thoughts about it and I ended up just feeling upset.  Ugh...it's just really sad.  I don't think we are doing nearly enough about it either.  I should try and be more proactive about setting a better example, if I find it in myself.