How Sonar Beat was born
By Miguel Vallés Susín. Creative Director
There’s something about musical games that has been applied on them for already more than a decade: their workflow pattern is based on linearity. This means that the gameplay structure of traditional musical games is built parallel to the musical theme playing in the background. In the case of Sonar Beat, we aimed to transform a musical game into a more arcade kind of game, in which linearity would make way to recursiveness. This brings us to the main idea of our proposal: you play a radar that scans the scenery in pursuit of finding enemies that match the music’s rhythm. If you don’t destroy these enemies, they will come back on the successive laps, accumulating and increasing the difficulty.
Besides this, we didn’t want Sonar Beat to be a casual game in which you just kill enemies without knowing why. We wanted to exploit the concept of the radar and give the game a certain depth and a meaning objective: secure your submarine to a safe and secure surface.
Developing a musical game with an arcade spirit reminded us of the design essence that the games of amusement arcades had, now disused. We thought that we could enhance this idea by benefiting from our current means. In order to do this, we built a shared Leaderboard for all platforms, allowing users to compete between them at a worldwide level. We also included ingame a way to share their scores through Twitter, providing us a way to gain virality on social media and boosting marketing.
As a plus, users receive a special identity key that they can use on any device to recover their account information. For example, if someone purchases both the PC and the mobile version, this person will be able to continue playing on any device on the go, without losing their progress.
Visual context and style evolution
By Elena Herrero Jaén. Art Director
At the beginning of the visual development of Sonar Beat, we worked on the idea of representing the subject matter of the game. We didn’t want the user’s visual experience to be anecdotal or unimportant. Our main goal was to create artistic features that would come along with the player’s game experience. Because of this, every screen on Sonar Beat includes content that scrupulously recalls the underwater thematic area.
In the first phases of development, as usual, many tests and art concepts were done in order to define what style we wanted for the project. After a few weeks, we found the artistic profile that tipped the balance. We finally chose 2D aesthetics with a minimalistic touch and the use of plain ink. Effects such as enemy explosions were made frame by frame, with the objective of creating a relaxing environment during the user’s experience.
But soon came the musical themes to the equation, and with them a level design that had little to do with calmness and serenity. Almost without realizing it, we stepped towards a different artistic line that would come along better with the music. This way, Sonar Beat’s aesthetics evolved to a different mood: vivid colors and a lot of light, brighter and seamless explosions, still made frame by frame.
Neon effects had a minimalist touch, but they had the plus of being vibrating and electrical.
We adapted this new style to the already existing elements, like the radar or some of the UI interfaces. Soon we realized that, in Sonar Beat, the submarine wasn’t the only main character, the music was the real queen of the game. It was unquestionable that we had to support the musical experience graphically, so in order to achieve this, we developed concepts of the background effects disposed on the main game screen. These effects were specially designed for each song to make every element, the movement, the animations and the color palettes transmit visually the feeling of every theme.
Enemy generation based on music
By Roxanne López van Dooren. Main Programmer
When the project of Sonar Beat started, the main goal on the programming side was to achieve enemy generation based on the musical notes of a song.
Looking around forums and blog posts for more information about how rhythm games addressed this matter, we concluded that, in order to receive relevant information from an audio clip, we had to work with MIDI files. These files carry event messages that specify a note’s notation, pitch, velocity, vibrato, panning and clock signals, enough information to translate it later to game parameters.
Fortunately, we found a very useful tool from the Asset Store that simplifies this process of synchronizing gameplay to music in a few steps: Koreographer.
Koreographer allows you to translate the MIDI events to game parameters in your game. Thanks to this, we simply needed to export the MIDI files from the themes of Sonar Beat and later import them back to Unity through a MIDI converter that Koreographer provides.
As you can see on the image above, after importing the MIDI file of a Piano track, we are able to select the entire note count with its velocity or with the note itself. Once we have selected the wanted notes, we append them to a so called “Track”, which contains every note we have imported and assigned.
On the Koreographer Editor, we have all our imported notes placed on the timeline of our song. This interface allows us to map the rhythms, beats and notes of Sonar Beat’s themes through an Event System. The events (our imported notes) are reported to any component on our game that is registered to listen and they contain the exact timing of the beat. This means that on runtime, while the song is playing and we reach the point in which the piano plays its first note, we will receive an event notifying this.
These events can optionally contain something called a “Payload”. Payloads allow us to specify extra information on an event.
This can be used in many ways. For example, we can use the Payload “expl” to specify that, in the moment we reach that event, we want an explosion to happen on our game view. This way, each time our Explosion Manager receives an event labeled as “expl”, we will call the function that contains the behavior behind it.
In Sonar Beat, working with procedural generation, we have used Payloads in order to indicate the probability of each note to spawn as an enemy. Taking benefit of this, if a beat has a payload of 100 it means that it has a 100% chance of spawning on the radar; if it has a payload with a 50 on it, the beat will have a 50% chance to spawn an enemy, and so on.
Now that we know the foundations of our workflow, how are enemies generated and placed on Sonar Beat’s radar? Firstly, to explain this we must know that in Sonar Beat we have a viewer that rotates 360 degrees around the center of the radar, nonstop.
As you can see, the radar is formed by four quadrants, as in any circle. Each quadrant expresses a musical concept: a compass. This means that a full turn (360 º) is equivalent to four compasses of a song. The composers of Sonar Beat’s themes arranged with us to design their songs according to these rules: there will never be more than 16 notes per compass. This rule is due to enemies generating too close; we wanted space between notes to make it more playable. If the radar represents four compasses at the time, up to 64 enemies will spawn (or not) on it during a same spin.
Also, the viewer will rotate according to the tempo of each song. Depending on the BPMs of a theme, this element will go faster or slower, becoming in essence a pointer that indicates in real-time the scope of the song.
Having these concepts in mind, placing an enemy on a radar is rather simple. As said before, a Koreography Event contains information such as its timing. If a radar represents four compasses, this means that the full duration of a spin will be 4 * the duration of a compass. The duration of a compass is calculated through the tempo of the song. For example, in a song of 90 BPMs, a compass lasts 2.65 seconds, which means that the entire radar lasts a total of 10.6 seconds. Each time we receive the event of a possible enemy (a beat as explained before), we will obtain its timing and place it correctly on the radar based on this.
The first thing to do is to calculate the section on the radar based on its timing, having 64 possible spaces to spawn on. Once we know the enemies section, we proceed to calculate the angle on the radar’s circle on which it will spawn. Finally, knowing its angle we will be able to calculate the exact position in which an object “enemy” will be placed.
Certainly this has been an interesting learning experience, in many ways. This has just been the basics on how Sonar Beat works on an enemy generation level. After developing this, the project has continued expanding until having multiple features regarding this topic.
We hope that this has been interesting and even useful to someone developing musical rhythm games with Unity, thanks a lot for reading!
