Here is the announcement of my new project: Sound Horizons! It's a procedural rhythm game, based on one of my previous creation, One Colorful Grid. I've recently finished the alpha version of the game, so it seems a good time to start sharing my progress. First, let me introduce you the game.

Why remaking One Colorful Grid

One Colorful Grid is one of the creation I'm the most proud of. Although it was entirely made in a jam in 2020, it's a solid rhythm game that perfectly reflects my game-design philosophy for the genre: minimalist, precise, but never too punishing. It also has a dynamic soundtrack that uses most of what I've learned to do, and combines what I enjoy in interactive music: rewarding feed-backs, and playful expressiveness. If you want to know what Sound Horizon will be, you can One Coloful Grid. It will basically play the same!

One Colorful Grid received some positive feedback. Not many, mind you (I'm still terrible to promote my games), but they were pretty enthusiast. Some players even claimed they would like to see  a commercial release with more levels. At first, I wasn't really sure about it. I feel that One Colorful Grid is self sufficient, and more levels would just seem redundant. However, two years later, I actually would  like to improve it in order to to make it more visible, and maybe expand on it.

There are indeed some issues I have with Colorful Grid. Here are some of its problems I would like to solve:

• It's ugly as hell. Originally, its minimalist visuals were made in reference to the other game it takers inspiration from, One Colorful Line. While it was okay for a game jam, it's definitely not appealing today. Which is a shame for what I consider to be "one of my best game"! I'd like more people to discover it, and this ugly aesthetic certainly don't help it. It's also linked to point 2:
• It lacks identity. By looking just like a prototype, with a 4 chords chiptune loop, it fails to be recognizable. If I ever want to make a larger game, I need solid ground. A monochrome scree<br>n is not enough.
• It lacks a proper tutorial. The game was made intuitive enough so that you can figure it out, and it has a difficulty curve that lets you learn different pattern one by one. But it's quite basic, and the first seconds of the game are a bit confusing for most players.
• It's slightly too hard. Not excessively too hard though: its difficulty balance and non-punitive difficulty is also an aspect I'm proud of! But it asks very precise input, and has a steep curve near the end. One comment I saw a lot is “Phew, I finally saw the end!”. I suspect others to simply not have finished. The challenge can be improved in order to be smoother, and letting more players experience the whole game.
• It doesn't have a sound calibration setting. This is mandatory for any good rhythm game. If I want this game to be playable by everyone, it needs to have one.
• Nobody played the Free Mode. Yeah there is this special mode, that allows you to just play music as you want! I find it really fun. But you have to unlock it with a perfect score! No-one have patience for that. I want to come back on that design decision, and make this mode not a super secret bonus you have to earn, but just the default reward. Because I assure you it's a really great mode!

One goal of Sound Horizons is to make a new version of One Colorful Grid with those aspects fixed. It will be a re-vamping of the game with improved visuals (or should Ito say "actual visuals" tbh), new music, more balanced difficulty, and better settings.

On top of that, Sound Horizons will serve as a test to see if this game is worth of a commercial release, with more features. And for those, I have a couple of ideas:

• Several levels with different visual identities. The version of the game I'm currently working on will only have one level. But I'm preparing it to be fully customizable! One level could be a bossa nova in a jungle, another one synthwave in space, another one fusion jazz in an abstract landscape... All levels should share the same common UI and systems, that can be placed in any environments.
• More difficulty modes. If I make the game easier, I also need to provide a good challenge for daring players! I will talk about those later. But yes, I have several ideas for extra challenges that should not be hard to implement, and that would fit great in the main game.
• Accessibility options. I already experienced with those in my previous game, Line Momentum. It's a good option to provide for players who have trouble with rythmic challenges, but still want to enjoy the music. I can make the game slower, have it less punitive, display more indicators, or even add an option to directly unlock the Free Mode. Yes I want everyone to play that Free Mode! Oh, which reminds me...
• Better Free Mode. Playing notes in One Colorful Grid is great, but how about having full DJ control of the music system? Hell yeah.

And some other details I should reveal in time.

With that in mind, I began this year to work on a first version of Sound Horizons that would just reproduce the core of One Colorful Grid with Unity and Wwise. One Colorful Grid was made in Godot, and I still love this framework. However if I ever want to make a more ambitious version of this project, I might need other developpers and artists to help me (... well especially artists). And let's be honest: I will find more people already familiar with Unity. Plus Unity is a bigger and older tool, so it should be even more powerful and allow to do greater things with ease, right? Right?

As for Wwise, well, it seems obvious now looking at my games that I enjoy working on sound-design. So instead of coding everything myself, I should also now how to use some of the most popular sound-design tools in the industry. I spent most of last year learning Wwise, and actually made a game with it during a jam! Again, it's a tool made for sound-design and dynamic music, so I presumed it should allow me to create even more complex sound systems... At least in theory.

The finite possibilities of Wwise

The music system of One Colorful Grid was made all by hands (using my own Godot plugin Simple Sampler). For Sound Horizons, I aim to recreate it entirely in Wwise. This way it should be reusable, and I will have tools to make it even richer. As stated above, I already used Wwise for a rhythm game. I documented how I implemented it in two articles: one focused on Wwise, the other on the integration with Unity. The music system in Sound Horizons is a bit different, but I knew at least some bricks I could reuse.

Let me describe the music system. The dynamic music of Sound Horizon has two dimensions: adaptive layers, and interactive notes. The adaptive layers are the background music in a level. It consists in a loop with several instruments, that evolves with the player progression. This divides the level several segments. For example, on the first one, we can assume only the a basic kick and a bass play. Then on the second, a guitar and a snare are added, on the third one the guitar is removed an organ plays chords, and so on until the very last segment which should sound the most epic. The fading transitions between segments are immediate. This gives the player a great sensation of progress as they move forward in the level. Then the interactive notes are notes played both by a "lead" instrument and the player. At any time the lead plays a random note (on a quarter beat), then the player has to repeat them. There are 4 possible notes for each player, corresponding to 4 directions : up, down, left, right. However, these notes change depending on the chord that is played! For example, if in the first bar the chord is a C major, the lead notes will be C4, E4, G4, C5. But when in the third bar we're on a F minor 7, then it playsC4,  E4, F4, and G#4. On top of that, the instruments used are different on each layer. It's the combination of these two dimensions that makes the music in Sound Horizons feel like it follows the player actions.

My first objective was to create this system in Wwise. No coding: only the Wwise logic should manage this dynamic sound-design. The less dependency there will be with Unity, the more modular it should be. Unity should only send events to Wwise, like the segment number or the direction pressed, without knowing which instrument layer or which notes should be played. While this system has complexity, it seemed feasible with Wwise. I had a vague idea of what tools I should use, and how. Turns out I had more difficulties than anticipated, and that Wwise is not that versatile when it comes to dynamic music.

The adaptive layers were the most straight-forward part to implement. Just like I did with Line Momentum, I could separate the song tracks into several Music Segments, and activate or deactivate them with a State. The main difference is that this time, the transition (fade in and fade out) should be immediate, and not at the end of the loop or bar. And this is how I found the first limitation of Wwise: it handles poorly immediate transition when it overlaps two loops. Fade-out would abruptly ends on the end of the loop, and fade-in would simply not be triggered and instead starts the next loop full volume. I can see the technical difficulties for this, but it makes the immediate transition pretty useless. Which sucks because transistion are a great tool of Wwise! So instead, after trying for a long time to find a solution, I eventually opted to implement the fade in and out "manually". Instead of activating or deactivating tracks with the State, I have them all play by default, and adjust their volume depending on the current level segment. This solution requires more settings, and also has some limitations for the fading duration, but it's the only one that allows fully immediate transition. Maybe I could cheat and activate a track on the "N-1" segment, but I fear it would make things just more complicated. At least I can obtain the result I want, and even add or remove effects like reverb or filter.

Next, the interactive notes. Certainly a tricky one, for a long time I thought I would have to code it. But good news: Wwise can play MIDI with sample instruments! Exactly what I need! It is even possible to configure an instrument to play a different sound depending on a State. So after some trial and errors, I was eventually able to have only two instruments (Lead and Player) that would adapt to the layers. And this still only using one or two sound files to be able to play any note! But how do I tell these instruments to play dynamically a note? There is no "Play E4" action we could associate to an event. And while it's possible to send MIDI event to Wwise, that would be too low-level for my taste, especially since, as explained, I don't want Unity to deal with the music logic. So instead, I had to play MIDI tracks containing one single note, and contained in a Switch Track to select the note corresponding to the bar. One Switch track per direction, containing one MIDI track per bars.  So, when a directional event is sent (like "up"), the corresponding Switch track is played, and it chooses the sub-track based on a State tha tautomatically changes on the main loop (thanks to Wwise custom Cue Event).

However if this doesn't sound tedious enough to configure, here is the catch: Wwise doesn't provide a MIDI editor! Which means that if I want an instrument to play a E4... I have to create a MIDI file "E4" containing just this note! A MIDI file is not a sound file, it doesn't contain any audio, just the "instructions" to play an audio. So the content of a E4.mid file is almost a file with just  the word "E4" written in it. Not heavy, but kinda pointless. Unfortunately there was no alternative, so I had to create a bunch of midi file for every notes I needed, and drag'n drop them manually in the editor. Yes that's very silly. But hey, at least we have working instruments now!

So, in the end, was Wwise useful? Yes, indubitably. But I'm kind of disappointed. It showed quickly some limits when it comes to music, and a lot of configuration ended up being laborious. I don't feel like I can do significantly more than what I was already achieving with scripting, and it isn't even faster to implement. Adding this to the fact that Wwise only works on Windows, and cannot export web games, I'm eager to compare it to Fmod (or even Godot 4 new features relative to sound). I will still keep it for Sound Horizons, now that I have a functional system! It's time make a game out of it.

Gamedev is too hard

Recreating One Colorful Grid in Unity came with some satisfactions… and some frustrations.

The good part was that most of the work was just to re-write code from Gdscipt to C#! Sure, I needed to clean it a bit and make it more modular. But the logic in One Colorful Grid was already separated into several components, mostly using Godot signals to handle communication between them. Seriously this is one of the aspect I like about Godot: its nodes logic encourage to use clean patterns, even in small jam games. Almost all of the logic for Sound Horizon was already in place! And even though I hadn't read that code for 2 years, well, it wasn't that hard to put together again.

One of the main change however was that I had to prepare the code to allow several levels. I don't only have to create the One Colorful Grid level, I must build it in a way that will later allow me to configure it for a new level,  with another song, segments, difficulty levels, environment animations, etc. For this, I wrote a "Store"  in a ScriptableObject that would handle all the game events and contain the level configuration. Any component can be plugged to it to subscribe to its events. It has barely any logic: it is up to the components in the game to manage what's within their scope. Thhere is still a "Game Manager", but all it does is reading the player input and updating the score (I might explode it into an InputManager and a ScoreManager). There is no dependencies between any component, and no hierarchy. You could say it's an holacracy! In the last parts I was even able to use semi-generic Scriptable Object to configure difficulty levels and environment animations. I'm quite happy to have managed to set that in place with Unity, using mostly Unity Actions (although I admit a home made events system would be even more efficient, maybe later). I might write a bit more about it one day, or even describe it in a video, why not. It's an architecture I'm proud of, and that I feel could help others. It's not that complicated to write, and is very useful even in small projects!

However not everything were as fun and pleasant. The more I use Unity... the more I get frustrated with it! It's a powerful framework, but it still has so many strange parts. And most tragically, a terrible documentation, combined with a large internet history of unhelpful threads. On good days, I want to do something that seems complex with Unity, and discovers that it has a native solution for it, with a ton of cool possibilities. But sometimes, I want to make something very basic, like making a mesh clickable or drawing a circle, and... It's just impossible? I find no solution in the official documentation, and when you search it in forums or blog, I find dozens of answers from outdated versions, it's never trivial to do despite that it should be, and way too many time it is solved with a random hack that needs you to "Calculate the X, Y and Z position of the cursor, then copy paste this shader, and checks in the Update if one of the vertex crosses the cosinus of the camera angle. I don't know what it does, but it works. for me!". Yeah, I'm salty. I dunno, I feel like global solutions or generic tools are not written anywhere on the internet. The most examples shared are very specific use cases, that people found by accident and are seen like some kind of secret spells. Were are the resources!? I'm sure there are great video tutorials somewhere, or unofficial guides, but it's just not as efficient as a good documentation. Learning and discovering new techniques is what makes an engine (or any tool) efficient. It's something I can do with confidence with Godot or even Phaser! But with Unity, it's always painful. I dread the times I need to search for something.

Fortunately, I found out a nice solution for this issue: Chat GPT. After hours of desperately searching Google for an answer, I decided to give it a try. In a way, it was just doing the same search I did, only way more efficiently. It quickly gave me one satisfying solution to my problem, but that's not what was the most interesting. Discussing with ChatGPT about its proposal, how it worked, why it worked, and where I could read more about it, proved to be really helpful! It did the job I was expecting from the doc, with more focus on the part I was interested in. Furthermore, it also provided me a list of relevant plugins when I asked for. Some were poorly documented, but once again ChatGPT was able to help. Was it always right? No, there was some dead links and deprecated methods. But those were minor, and easy to check against. Sometime I just needed to point them to obtain a second answer that would rectify those. Overall, ChatGPT set me in the right direction, and allowed me to learn what I needed to know in order to to progress. So if you're working with Unity, my recommendation is: don't search with Google, search with ChatGPT. (assuming you don't just copy-paste its first answer, and dig a bit more from it)

So eventually I was able to re-write One Colorful Grid, and completed an alpha version for Sound Horizons! You can spot some visual differences already between the two games. I actually have some plan for the look of Sound Horizons, and made some preparations for it. I will detail it later, for now all you can know is that it will be in 3D! Another difference between the two games is that I haven't implemented the beginning the beginning and the end, but I'm sure you can understand why I'm letting those for later.

For now, I have a playable prototype, that I can build upon. The next step will thus be to finally work on the game's aesthetic. This will start with the music! See you soon.