Bongo Machine is a a two-buttons rhythm game based on a mechanic that everyone knows: a rhythmic pattern is played, the player has to repeat it. Actually, it can be summarized better in a gif:

The game is composed of several songs, each with their own time signature and patterns. Songs are divided into several measures. that loop until the player play the correct pattern. Which means that to proceed through the song, players have to play correctly every single segments!

The game is thus mostly about learning (and rehearsing) different rhythms. Score are calculated by the number of repeated segments. Play all the song correctly in a row, and you get a perfect! If you have to do some parts several times, your grade won't be that good. But in the end, everyone will reach the end of the song, there's no fail state. And songs are designed to sound great even when looping!

***

I've been working on this project since mid-September. Its purpose is for me to learn how to use Unity, and to use music dynamically in games. My main inspiration here is Rhythm Heaven, a very basic rhythm game that can be really challenging, and actually teach some musical concepts!

I'm also learning music composing, which sure will be really handful!

So far I've been able to create a prototype that can track the rhythm of any song, as long as it knows its time signature. Then it can play a partition on it, and expect the player to play it back. There is even three difficulty modes

I've also very recently been working on the game's look! Previously, it was just an ugly prototype, and it is only since this month that I made my decision about how the art should be. I opted for a minimalist design, inspired by 140 and Jazzpunk's intro.

Finally, I've spent most of October composing the first song of the game! Here is a little preview:

***

What's next then?

First, it would be great if a level could actually be finished. Currently it just loops on itself. So next thing for me will be to give a score to the player, and redirect them to the track selection menu. Also, I need to save player's score, and lock/unlock levels, as well as some other unlockable bonus (more on that later).

The art is not done either! This needs some background, with a music visualiser and a fake scrolling to make it dynamic. Colors must also be configurable by song, so that each level has a different color set. Finally, I need to find a nice font to use in menus, and of course for the title.

The last big part is… Well, the songs. I have one so far, but I plan to have three levels. So I will probably spend most of my work on those last two songs! I already have some ideas for them. Oh, and let's not forget a little music for the game's menu.

***

My goal is to release an alpha version before the end of the year, with a single level. Then I hope being able to release the full game early in 2017.

Thanks for reading! Your thoughts on this are welcome.

Lately I had to make some game-design decisions that are worth sharing.

But first, some fonts:

Lovely fonts. Although I'm still not sure about the color for the game screen's text. It has to be blue, but… Meh.

Also, I've discovered that the game is incredibly hard if I let a delay of only 0.55 sec before and after each beats. So I've twitched this value, and found a nice balance with… 0.56 sec. Yep, turns out 1/1000th of a second can really have an impact! Still, I think I'll need to add a "calibration screen" to the game. The comfort zone might vary for each player.

Anyway, let's talk about the main subject! I want to explain how the score system work.

The Score in Bongo Machine

So, here is my initial idea, that was first implemented:

• Player get a rank at the end of a level. Ranks go from D (lower) to Perfect (higher).
• When the player finish a level, they unlock the next one. Ranks allow them to unlock some bonus content. There are five bonus to unlock: one for each rank superior to D (C, B, A and Perfect), and one for completing the level in hard mode.
• Rank is determined from the number of mistakes the player does. The player starts with a perfect score, which is the number of measures (playable parts) in the song. Each time the player fails a measure, their score goes down by 1. As the player plays the same measure again, it keeps decreasing when they fail. At the end of the song, the player gets perfect if they have still all their points, A if their points are higher than 2/3 of the initial score, B if higher than 1/3, C if higher than 0, D for 0 and below.
• When player fails a measure, the screen gives them a feed-back with a red "FAILED". When they succeed, it gives them a different feed-back according to their number of tries for that measure: "PERFECT" on the first try, then "EXCELLENT", "GREAT", "NICE" and "OKAY".

That's all. Seems pretty simple and fair, right? Well, actually, it is fair! The problem is: it doesn't feel so.

First, feed-backs don't predict correctly player's final score. They seem to correlate to the rank, though. But since we're decreasing for each mistake, and not calculating an average, they don't give any real clue about what the final score will actually be. For example, a player can miss every single measure only once: they will have an entire game of "EXCELLENT". But their score will be 0, and therefore they will have a D! A little bit disconcerting.

There are several possible solutions. One is to compute an average instead. But with that few ranks, players might not see a difference between two different games (say, one consisting of only "EXCELLENT", and one with only "PERFECT" and an "EXCELLENT", would both give an A, although the player improved a lot). It seems coherent to me that a player missing all measures, even if only once, would get a bad grade.

Another solution, more brutal, is to get rid of the nuances in feedback. Since they don't give clues about the player's global performance, they are only confusing. We can just keep "FAILED", "PERFECT", and "OKAY". Player will know that succeeding on the first try is good, and more attempts are just accepted, but will have an impact on their rank.

But there is another issue I didn't mention yet! Well, I did in the introduction actually: the game is hard. Purposely hard. Not because I want it to be "for hardcore player only", but because its goal is to teach player to practice until they get a rhythm perfectly. So when they fail somewhere, they repeat. Again, and again, and again. Until they master it. There is failure, but no fail state: you win the level eventually. And you do because you learned it well. Demanding, but not punitive, is the game's core philosophy.

Except it does feel punitive! That's a big issue I hadn't foreseen. I played with a tight margin delay, and had a lot of failed measures. That was infuriating. I was getting stuck on the same measure, each time making probably a little mistake on only one beat. But that was enough for the game to tell me that I've failed ("all or nothing"), and keep me in the same part. As with every rhythm game, I started to doubt the accuracy of the machine. Sometimes I felt completely offbeat, and it would still accept, and other times I had the impression the game was just not cooperating! But it had been tested, and it works fine (… I think). It's just the difficulty was too high for me. This is why I decreased it a little by according an additional 1/1000th sec before and after a beat. However, it is still likely that some players will get stuck like me, and it won't be fun at all.

So, how to change that? I still want the game to be difficult, but I don't want it to feel punitive. And after some thoughts, I think I nailed one important mistake I've made: when the player does a mistake, the only answer they get from the game is a big red "FAILED". And this plays a lot in exasperating the player, and making them feel like the game is too hard for them and doesn't want them to succeed.

So I've made a simple, but quite important change. When the player misses a measure, the first two times, they gets a "FAILED". But after the third failure, the message becomes "YOU CAN DO IT". And let's be even more encouraging: if they do two more mistakes, the game will display "DON'T GIVE UP"!

Also, remember how I explained why I gave up the nuances in positive feed-backs? Well, I've came back on it (again). Because actually, diversifying messages creates a dialog between the game and the player. It's not just a cold "GOOD/BAD" indicator, but a more precise acknowledgement of how the player is playing. It is actually pleasant so see the game reacting differently for each one of your success, and in a quickly understandable way: the less you fail, the more positive the game is. But when you fail too much, instead of being neutral about it, the game becomes more patient and encouraging. Therefore, we changed "If you play bad, you will have a bad remark" into "If you keep getting better, I'll will applaud even louder". Oh, "EXCELLENT" also became "GREAT" (and "GREAT", "GOOD") because it feels less judgmental, and not linked to the rank.

Lastly, I decided to stop decreasing the score if the player does more than 4 mistakes in a measure. Getting stuck on a particular segment will still be really bad for the score, but not as much as initially. The game should let you learn without necessarily giving you a D.

I'm quite happy with those decisions, and how the game feels now. It was a great learning by experience!

Coming next: some animated backgrounds!

Allocating time for this project is harder than I planned. But still, making progress!

Now it only needs some particles, and it should be good.

***

Also, I've come across another issue. It is still related to the game's difficulty, and my attempts to make it the less frustrating. It's simple, look quickly at this screenshot, and guess if the dot are aligned:

<img src="http://pix.toile-libre.org/upload/original/1481393507.png" >="" <="" p="" data-vivaldi-spatnav-clickable="1">

If you'd have just a quick look, you could think that they are. But…

Problem is, the player doesn't have the time to check the alignment. Once the measure is done, everything is erased. So they have just a fragment of a second to tell if their beats are roughly the same as the ones above. More than often, it appears that yes, they are. But the game quickly remove everything to reveal that no, they weren't. Players don't have any clue about which one was wrong, and if it was too late or too soon.

This is kind of a recent issue, since the game was originally designed with the two lines close to each other. But I then had the idea of a screen split, and moved them on both side. Now that they are far away, they have become less readable!

So far I came with two solution. The first one is to draw a grid on the screen.

This fix the issue, but… It's a grid, and it's ugly. Not only it makes the screen too loaded, but it also make this presentation feels more… "mathematics". It can be improved visually, but it would still result in the beat presented as a grid, and not just an indication relying on the music.

Alternatively, I could add some animated beats that would go to the center:

Again, this could work fine, but… I'm feeling I'm adding complex behaviors to a simple system, just to answer a specific concern. Why would there be additional beats? Why going to the center? Do they disappear then? Or should be they displayed under the textual feedback?

There are other imaginable way. Like instead of making beats appear on the lines, they come from up or down to a central line. This completely change the current look of the game. And again comes the question: where would we display the text? I like the symmetry, and I'm trying to figure out how to keep it while solving this problem.

So for now, I'm going with the grid. I'll try to make it look nice, and not too invasive. Maybe I'll come with another idea latter. Suggestions are welcome!

Happy New Year everyone! Today, I have some good news, and some bad news.

Let's start with the good one: Bongo Machine is available in open beta!

(click to access)

This beta includes the first level, with 3 difficulty modes. I've even been able to put some music for the title screen and menu! Right on time for the end of 2016! However, you won't be able to save your score. If you find any bug (actually you're likely to), please report them to me.

Now for the bad news… Well, it appears that Windows version has some latency! A very little one, but for a rhythm game, it's enough to make it less enjoyable. I've tried several things to fix it with Unity, messing with audio settings and the sound assets properties, but to no avail.

So, unless I succeed to work around this huge performance issue… I think I will simply cancel that project. After a few bug fix, and an implementation of the save system and some bonus content, I will just let it in this beta. I have other projects in mind, I feel they would be more interesting than struggling with a flawed game (that was supposed to be little).

Of course, there is the eventuality that this is just bound to my machine, or that I'm the only one bothered by this latency. Although I seriously doubt it, tell me if you have the same issue.

Last but not least, I would like to talk about the game's timing again. Especially, if you are trying out the game, you can help even further in that aspect if you are motivated! I will explain.

Lastly, I said that 0.056 seconds was an optimal delay. Actually, I was wrong again. During a test, I've been stuck on the same measure for at least two minutes, and trust me it's frustrating! This made me think about the purpose of the game. How it defines rhythm, and why I chose in the first place to repeat each part until the player does the right pattern. And I've come to the conclusion that rhythm is less a matter of precision than it is about understanding patterns. Or at least, in this game. I want to be close to the feeling of a jazz jam: musicians might be slightly off for individuals notes, but that's okay, because the music their play is more about the pattern, and their global understanding of "the flow". Each note don't need to be strictly on the correct micro-seconds, as long as the rhythm is respected on a global scale.

That's why I decided to make the game less difficult! It isn't about being super precise, it's about understanding a rhythm in a song. Thus, I set the delay to 0.07.

However, since there is this latency with Windows… Well, I have to increase that value again. So it is now up to 0.1 seconds. That's right, it's pretty tolerant! But it's the only solution for now.

That's where you can play! On the game's first launch, a configuration file will be created (which path can be found in README). It contains only the mentioned delay. You can try to twitch the value to find the one you feel comfortable with. My preference is 0.07, but maybe this would be too easy for you, and you would like to try 0.06 or lower? Or this is still too punitive, and you want 0.08? You can try different values, and tell me your favorite one! I suggest though that, between each try, you listen to something else, and try a different activity. This way you will come fresh each time, not like me who have done test while I had still the rhythm in mind and, unable to detect the difficulty, concluded that “0.055 is too hard but 0.056 is okay!”.

Anyway, have fun with the game!

Welp, that's it.

As I mentioned before, the game suffer from a bug on Windows. This is actually due to an error in Unity regarding audio that needs to be fixed.

In the meanwhile, I have other projects I want to try. This one's purpose was mostly to learn unity and rhythm in game. This goal is already fulfilled.

So instead of wasting more time on it, I will simply move on. I think it's for the best.

I've made some fixes since last time. The game have now more feedback, and is easier for notes starting measures. To go more into details:

• Beats length have been increased so that their alignment is more readable
• Wrong beats don't make sound anymore, and appear red
• Player can actually play one beat before their measure. This way, they can have a little advance that will still be validated.