This game was made in 2 days at the end of April 2015 as part of the Dublin One Game A Month (1GAM)’s challenge. The theme was “Depth“. I decided that I wanted to take it as not water-based depth, but bringing depth to a game mechanic. I decided to toy with an idea I had for bringing procedural elements to game music.
First off, it’s not a game. There’s nothing to do other than just listen. The environment was just me toying around with having something to look at. The only other function is that the further you get from the ball, the lower the volume and low pass filter are set on the Master audio channel.
The idea was to take a number of 4-bar music stems and let a script decide which ones to play. Rather than base the changes on player location or enemies appearing, I wanted to simply keep time and make changes as a real band jamming would decide to. So keeping time musically was essential. I made all stems 4 bars at 120 bmp, meaning 4 bars was exactly 8 seconds.
It’s something of a failed experiment so far, however, but there’s potential here if I could solve a few problems. The failure can be heard the longer you listen. Time is being kept in the Unity Update function by measuring Time.deltaTime and knowing that 2 seconds is exactly 1 bar. The problem is that the time the computer is keeping (as seen in the upper left) starts to fall further and further out of time with the music. As a stop-gap in this demo I have it do a (jarring) hard-reset every 64 bars. The problem could be a slight imperfection in the track length that Ableton exported for me, or a problem with the processor running the program. The problem seems worse on my laptop than PC for instance. Any insights would be greatly appreciated.
There’s a lot of potential here, particularly for music-based games, if time could be kept a bit better. If anyone knows a better way to keep time or wants to see the project file, please get in touch.
Credits:
Kevin Murphy – Programming, Sound, Environment