"Beat Street is a VR, first-person rhythm game where you drive a car using drums to get to the end of a highway while playing to the beat of a song."
With a drumsitck in each hand, swing yours arms and smack the holo-drums infront of you to the rhythm of one of 3 in-game songs to dodge oncoming obstacles and earn points. This game is about rhythm, the closer you hit on beat to the song, the more points you earn! Mastery of each song is difficult and will take considerable effort.
Beat Street was created as a part of a 4 week, game-jam-style project in conjunction with my second year studies at the AIE, and was developed specifically for the Meta Quest 2.
Beat Street can be downloaded here from the team's Itch.io page, I'd love to hear what you think!
For the majority of Beat Street's production I involved myself in producing many of the important gameplay systems using Unity's C# scripting, namely the Rhythm System, which spawns obstacles at the correct spacing and ensures they arrive at the player on beat to whatever song is playing, as well as the tutorial and difficulty systems in the game. I also took on a general role of producer in which I created and maintained the team's Trello board, and took an active role in ensuring that our short milestones and sprints were being allocated and met effectively by the team.
My first point of focus was in making a Rhythm System for the game. Because the basis of our pitch was a game in which you dodged obstacles to a beat, I knew we'd need to create some type of system that managed the spacing and speed of said obstacles, such that they accurately arrive on beat. My inital approach was to create a system that would spawn obstacles in multiple of a set time signature and tempo, and then we could simply match the time signature and tempo of whatever song was being played in the level. I knew this wouldn't feel like true rhythm, but it would be a start and would likely feel close enough considering the amount of time we had for the project. However, early on a fellow programmer in the team, Nghia Do, was able to produce a really creative system that could read the peaks in an audio clip, and store their timestamps accurately in an array. This meant that we could find a song, isolate the drum track from the song, put that drum track through Nghia's Beat Reader, and generate a list of the exact timestamps of every single drum hit in that song. Once we had this system, I immediately began to adapt my initial implementation of the Rhythm System to work with his generated array of timestamps.
During gameplay, the Rhythm System tracks which "beat" the song is currently up to based on the current play-time of the song, and the timestamps of entries in the array. The Rhythm System then figures out at what time it needs to spawn the next obstacle set such that they arrive as their corresponding beat occurs in the song, based on the set spawn distance and set travel speed of obstacles in the game (this is just using simple linear speed, S = D / T). Because both Nghia's Beat Reader and my Rhythm System are general solutions that in theory work for any song with a distinct enough drum track, it allowed us to put three different songs (effectively levels) in the game, even though we only had a relatively short production period. The pipeline for putting new songs in the game is very simple, and so we could pheasibly add many more songs to the game, and also talked about implementing the ability for users to upload their own drum tracks and songs that they could then play along to in our game.
After sufficiently completing the Rhythm System, I figured I should work on producing a Tutorial System that would teach players both the controls and aim of the game. Being a VR game these things are not always as intuitive to players as standard PC or console games, and the game itself is pretty difficult and fast paced, so I thought it was a necessary addition. In a short amount of time (about a few days), I was able to implement a Tutorial System that took in a set number of Tutorial Prompts, and would spawn obstacles in arrangements according to those prompts. The player's control during the tutorial is constrained, and they are only able to hit the correct drum at each point in the tutorial (shown by the glowing drum in the GIF below). The tutorial itself is pretty short, and simply shows the player how to move left and right with the left and right drums, how to move two spaces left and right with the left and right cymbals, and expresses to the player that being closer to the beat will give you more score and increase your combo counter.
Approaching the end of production, once more people in the team had begun playtesting what we had, it became apparent that the game was quite difficult. Not only are obstacles in the game hurtling towards you at quite fast speeds, but the songs we have in the game are all quite upbeat and fast as well. Because of this, one of the last systems I produced for Beat Street was the Difficulty System. The way it works is fairly simple, firstly, there is a list of Spawn Double Frequencies that the designers had access to tweaking. These three values relate to the percentage of obstacle spawns that will result in two obstacles being spawned for a certain beat, with each value relating to one of the three difficulties (so in the image below, beats will double spawn obstacles 50% of the time on easy difficulty etc). The second list of values, Adjacent To Apart Ratios, relates to the frequency that double spawns will spawn in two lanes adjacent to each other, or whether they'll spawn on opposite edges of the road, again with each value relating to a difficulty. So in the example below, 80% of beats will double spawn obstacles on hard mode, and 70% of those double spawns will be adjacent to one another.
The reason I decided to implement the difficulty system in this way was because much of the difficulty in the game came from the fact that double adjacent spawns required you to use the cymbal to clear both obstructed lanes, and this added complexity to the gameplay, so being able to control the frequency of these occurences meant we could better control the most difficult parts of our game. On top of this, I ended up making it so that the Easy difficulty wouldn't spawn obstacles for every second beat in the song, this was because some playtesters found there wasn't a great enough difference between Easy and Medium difficulties.
Once all the major systems had been implemented, I spend the final days of production working on the visual effects in the game to add juice and enhance the users feeling during songs. I did this predominantly using post processing effects, namely adding a pulsing bloom to the game that would trigger on time with the beats of a song, as well as adding a subtle vignette that would creep into the screen when the player entered combo mode, and disappear once their combo was lost.
If you're interested in reading more specifically about my week by week workflow, you can find my devlogs here on my website.