For this Ludum Dare, we made a rhythm game that's heavily inspired by Crypt of the Necrodancer. It was quite a journey to figure out how to make everything follow the rhythm. But now, almost a week after the end of the jam and after fixing some nasty bugs, I finally feel like I understand what I was actually doing last weekend, and I want to share what I've learned in this little "How to Make a Rhythm Game".
Get the beat
I'm a programmer, not a musician, so I can't tell you how to make a beat, only how to get the beat into the game. Ask your favourite musician to give you a file with the time of every beat in the song (along with the song itself). One way to get file like that is to export the "beat" track as MIDI and then convert it to a JSON file using one of the many free online converters. Then you can load this file into your game engine. The beat of our first song is 90bpm and has a simple 4/4 rhythm, it looks like this in the code:
beat_array[0]=0
beat_array[1]=0.67
beat_array[2]=1.33
beat_array[3]=2
beat_array[4]=2.67
beat_array[5]=3.33
beat_array[6]=4
This approach lets you be super flexible with any beat your musician throws at you. Even if they make some weird polyrhythmic noise, you could easily import it into the game (playing that would be a whole different story though). Here's an example of the slightly more complex beat of our second song:
beat_array[0]=0
beat_array[1]=0.67
beat_array[2]=1.33
beat_array[3]=2
beat_array[4]=2.33
beat_array[5]=2.67
beat_array[6]=3.33
In the code, you can then compare the current position in the song with the beat array to see if a beat has occured and how long it is before the next one.
beat beat
-----0.67s--------------------1.33s-----
| |
| |
Move to the beat
In our rhythm game, the player has to give input to the rhythm of the beat. If they manage to hit a beat, they'll move in a direction, but if they don't, they'll lose health. The issue here is, what exactly does it mean to "hit" a beat?
The player will never input at exactly the same time as the beat because they're an imprecise human and the game logic runs in frames, so it'll never detect the beat at exactly the right time. So, you need some kind of buffer time that allows for delayed input:
beat beat
-----0.67s--------------------1.33s-----
| |
| |
------+------ ------+------
input allowed input allowed
| |
| |
The key thing to consider is that this buffer time has to be applied in both directions. The player might hit a key slightly after or before a beat happens. To take this into account, we do the following each time the player gives input:
- check if the time difference to the previous or next beat is smaller than the buffer time
- if yes, check if the beat has already been hit
- if not, mark the beat as hit
- move the player
Now the player can move to the beat, and with the buffer time you also have an easy tool to scale difficulty.
Get hit by the beat
The next thing to do is to get the environment, or enemies, to move to the beat as well, and make them damage the player if they collide. Movement is pretty straightforward: every time a beat occurs, all enemies move. The nice thing about this is that now the whole world can potentially vibe to the beat.
beat beat
-----0.67s---------------------1.33s-----
| |
| |
------+------ ------+------
input allowed input allowed
| |
x x
enemies moving enemies moving
| |
| |
But now it get's a bit trickier. How can you check for a collision with the player? If you do a basic collision check every frame, you're basically undoing the buffer time we added earlier. If the player wanted to move out of the way of an enemy, they would need to move away from it slightly before the beat actually happens. Likewise, if a player wanted to move to a tile where there's an enemy who'll move away next beat, they would have to move slightly after the beat happens. Ultimately, it would make the whole game feel unfair and broken.
You can solve this problem by doing the "movement" and "damaging" of enemies at different times. For example, you can check for collision once exactly between two beats. So, the enemies are moving to the beat, but damaging to the "off-beat".
beat beat
-----0.67s---------------------1.33s-----
| : |
| : |
------+------ : ------+------
input allowed : input allowed
| : |
x : x
enemies moving : enemies moving
| x |
| enemies damaging |
This might look a bit weird, because you can sometimes see the player "glitching" through enemies during the buffer time, but it actually plays way better than with enemies that move and damage at the same time.
You could also check for collisions right after the buffer time is over, but this can cause a problem that I didn't think about during the game jam: What happens when the beats are really close together or the difficulty is so low, that the buffer times of two beats overlap?
```
beat beat
-----2.00s-------------2.33s-----
| |
| |
------+-----------------+--------
input allowed input allowed
| |
x x
enemies moving enemies moving
| |
```
If you've just set it up so that the enemies are doing damage at the end of the buffer time, you're now hurting the player during the buffer time of the next beat. This might not sound that serious, but it can actually break the game if you remove too much of the buffer time for the next beat. Just play the jam version of our game on the "basically cheating" difficulty. The enemies are damaging so late, it can feel like they have a hitbox lagging behind them. It can make the game a lot harder, because you have to hit every beat just so slightly too late.
So, the most important thing I've learned from making our rhythm game is that you can't just focus on one beat. You've always got to check the timing between the last and next beat.
If you want to try our game, and give us some feedback on how we implemented the rhythm or anything else, you can do so here: https://ldjam.com/events/ludum-dare/59/cableman-a-rhythm-game
You could also check for collisions right after the buffer time is over, but this can cause a problem that I didn't think about during the game jam: What happens when the beats are really close together or the difficulty is so low, that the buffer times of two beats overlap?