March 6, 2026

DevLog: Circumventing the constraints of real-time audio capture

In the old days of rhythm games, people still had all their music as files on their PC. But today it's mostly streaming, so I really need to support capturing streamed music in real time, from any source.

Unfortunately it's clearly not possible for two big reasons:

• On a road, you can see what's coming up. If you can't pre-calculate the road from an mp3, or at least buffer a few seconds of it, you can't know what should be coming up.
• Rhythm games rely on the player moving at a constant speed. You might want to have something like streetlights going past the player on beat, but if your driving is physics-based and their speed is always changing, you can't place them appropriately.

Having said that, check this out:

It's still early days. The car interior is placeholder. The world is pretty bland. But hopefully it's heading somewhere interesting. I'm doing the music under the artist name Balatran.

I'm capturing the direct audio output from the system. I can't do it in a browser as it's heavily sandboxed, but I can do it as a standalone game. So that way, every audio source is supported. You can play music through Spotify, YouTube, local files, etc. The game picks it up and processes it in real time.

But it does mean that I can't ever see what's coming up in the music. So how can I, for example, have the road slope more downwards as the music increases in intensity? Well, I pivot the entire world around the player's car:

What about scenery like streetlights needing to go past on beat, when the car's changing speed all the time? Well, much like with the terrain, if I can't bring the car to the world at the right time, I can bring the world to the car:

Hoping to continue sharing more of Driving At Night as I work on it.