Skip to content

starweaver

March 28, 2022 by David Su and Megan Carnes
Placeholder

Hi there! We are Haversine Collective, a team composed of David Su, Megan Carnes, Colorfiction, and Dominique Star. Our game _starweaver_ is about capturing the last songs of dying gods, who also take form as planets. Eight planets orbit around the player, each playing a different melody on a different instrument. The player controls the game by moving and rotating their device around in physical space, much like a camera, and the gods' songs are spatialized using Dolby Atmos in order to immerse the player in a chorus of harmonies.

Starweaver Saturn and Mars.png

The game starts in a "pregame" state, in which the player is presented with a single button. Once they press the button, the game enters an "ensemble" state, in which all the planets play different melodic fragments, each using a different instrument. If the player locks onto a planet with the camera, that planet then enters a "focus" state, in which it begins playing a special solo melody while the other planets fade out (this is accompanied by some really neat visual flourishes). Once the melody plays to completion, the planet's song has been captured; the planet now begins playing a new melodic loop, and also shows a visual symbol (inspired by the Roman mythology of the particular god) to indicate its "completed" state. When all the songs have been captured, _starweaver_ enters the "endgame" state, in which all the planets play new triumphant music together, perhaps to celebrate the player's success!

Space is the Place

Starweaver 3_WwiseSchematic.png

This is David here, going over some of the spatial audio setup we did for the game. In particular, working with Dolby Atmos was pretty much as smooth a process as we could ask for. All we had to do was set up a 7.1.4 output bus, attach the Dolby Atmos Renderer effect, and we were good to go! (We also had a stereo bus with the Dolby Stereo Renderer, but the spatialized sounds are where the fun happens. :) )

Each planet object was set to spatialize its 3D position and orientation, and all eight planets were routed to the Atmos bus, while a single synth pad was routed to the stereo bus. We actually used minimal distance-based volume attenuation, as we found that with more noticeable attenuation, certain planets would end up sounding too quiet by virtue of being farther away, which caused the overall mix to sound uneven. It turned out that the position-based spatialization contributed more to the overall aural immersion than the distance-based attenuation did for our game anyways.

In order to help the player determine whether a planet is in front or behind them, each planet was also assigned a low-pass filter based on its angle to the player (incorporating both altitude and azimuth). The low-pass filter's frequency would decrease (thus letting fewer high frequencies through) as the planet moved more behind the player. This mimicked the psychoacoustic effect of sounds behind you being slightly muffled in real life.

I'll pass it over to Megan to talk about the awesome music she created:

Music of the Spheres

Starweaver 4_WwiseLayoutCropped.png

Spatial space music, what a concept! There’s so much I could talk about with regard to _starweaver_’s music, but I’ll focus mostly on the elements having to do with spatial audio, since that’s the part of making this game that was new and exciting for me. 

One of the coolest things about using spatialization with music is that it really allows you to hear each individual music layer more than you can in a normal stereo track. So in addition to the obvious goal of all working together as one piece of music, I really wanted each planet’s part to be unique and interesting on its own. When choosing the planets’ instruments, I tried to choose ones with all different sorts of timbres and ranges. I also wanted each planet’s musical voice to fit the god it represents. That’s how we ended up with the unusual ensemble of violin (Mercury), flute (Venus), French horn (Mars), cello (Jupiter), harp (Saturn), celesta (Uranus), piano (Neptune), and plucked piano strings (Pluto).

Since the planets would be orbiting around you, each one playing one instrument’s part, you’d be hearing music coming from all different angles. Which is very cool! But we also decided to add a simple synth pad in stereo, centered on the player. This way there would be a constant, something to keep the player grounded. We also chose to have the stingers in stereo, both to make implementation simpler and to have another centering element.

Another thing I discovered was that in this context, I could write music that might have sounded a bit too crowded or busy in stereo, because the parts literally have more room to spread out and because we put that low pass filter on the planets behind you. I especially had fun with this during the endgame track, which is the triumphant music you hear once you’ve collected all the gods’ melodies. Writing a track with 8 different big, energetic parts, none of them playing anything similar to any of the others, was a blast!

Overall, I loved being able to create music in such a new, exciting way, and I love that we’re able to let people experience interactive music in such a uniquely immersive way. 

Back to David to discuss some of the challenges we faced throughout development:

Shoot for the Moon

Starweaver 5_GameDebuggingCropped.png

One of our biggest challenges was getting things to feel good for the player once we had the initial groundwork setup. For example, the low-pass filter's lowest frequency was originally set at 200Hz, which resulted in planets being practically inaudible when they were directly behind you. This definitely made the planet's position apparent, but also detracted from the ensemble soundscape we wanted to create, as you wouldn't be able to hear all the planets all the time. As a result, I revised the filter settings and increased the lowest frequency to 2000Hz -- there was still a clear "muffling" effect, but it no longer came at the cost of the soundscape's clarity.

We had decided early on that we wanted to use gyroscope input to allow the player to look around by rotating their device, much like a real camera. This mechanic excited us in its ability to blur the lines between game space and physical space (especially given the additional immersion that Atmos would be able to provide), and fit well with the ethereal, dream-like nature of the game itself. Upon watching video captures of playthroughs during testing, we were happy to see a very clear "handheld camera movement" effect -- we felt that this gave the game an extra layer of immersion.

That being said, using gyroscope input did have its drawbacks. The main issue was drift -- due to the way typical gyroscopes work, over time their zero reading will drift, causing readings to become inaccurate. This was a problem for us, as sometimes it would cause certain planets to become out of reach. One way we tried to mitigate this was by making the planet heights more consistent with one another (on iOS, drift tended to be worse when looking up and down vs. left and right). We also added a "recenter" button, in the shape of a compass rose -- whenever the player presses it, their rotation along the x-axis would be reset to 0.

The last challenge I'll mention is a bug that had been, well, bugging us for a good chunk of development. The issue was that whenever we played the game, Wwise would undergo voice starvation the first time all the planets began playing their melodies (i.e. when transitioning from the "pregame" to "ensemble" state), which resulted in a not-so-nice audible pop, as well as the engine ignoring a crossfade that we had set up (presumably because it had too much on its plate already -- hence the voice starvation). I tried a bunch of different fixes, from changing the sample rate to adjusting voice limiting settings to implementing a whole "staggered entrance" system to lessen the initial memory load (apologies to Megan, who had to change all of the melody entry points to accommodate the new beat offsets), none of which had any effect. Finally, I tried adding dummy music segments that played during the "pregame" state, but turned down -72dB so that they were essentially inaudible. This fixed the issue! Because the planets were already playing (inaudible) music by the time the "pregame"-to-"ensemble" transition came around, voice starvation would no longer happen when playing the planets' "ensemble" melodies. In fact, the voice starvation occurrence had been pushed to the beginning of the "pregame" section (when all the dummy segments began playing), but this was fine for our purposes -- since it pertained to segments that were already silent, there was no pop to be heard! We'll keep digging to see if we can stop the voice starvation from happening altogether, but I'm definitely happy with this workaround for now.

All in all, we're really proud of the work we did on _starweaver_. We feel that we were able to create an experience with a distinct mood and atmosphere, with the audio, visuals, and gameplay coming together to form something greater than the sum of its parts. We'd like to thank Playcrafting and Dolby for this incredible opportunity, and for their support all throughout the jam!

----

To hear more from Haversine Collective about _starweaver_ check out their video.

Decorative image