# Rhythm Game

## Recommended Posts

Hey all, I'm currently trying my hand at developing a rhythm-type game (think DDR, Beatmania, Guitar Hero more recently, etc...). I have a bit of it working right now, but I'm attempting to get my steps (not really...let's call them arrows from now on, defined as when a player should do something on a song beat...I'm a DDR player) to sync up with the music. I'm planning on having songs set up like in StepMania, a DDR clone where users have to sync up songs by trial and error and users will tell the program what BPM to use as opposed to the program figuring this out on its own. However, I'm trying to figure out: 1)How fast to move my arrows according to the BPM 2)How often to check for the next set of arrows (ie: the next row of arrows in DDR) and add it to what is currently visible. I have a few songs where I know the actual BPM and was trying to find a certain constant (K) that would work as far as regulating the speed of my arrows when multiplied by the ratio of BPM to 100. So when I move my arrows, the translation would look as: Position -= ( BPM / 100 ) * K I'm not sure if this is the correct approach, though, because as of yet I have been unable to find such a constant. As far as my second problem, I'm unsure how such games work and am not sure if I should be adding arrows to the stream at constant intervals or if it should also be BPM dependent. Thanks much all. I'll (hopefully) be looking at the StepMania source code in the meantime, but all input here is greatly appreciated. Thanks, Jeff EDIT: In all that, forgot to title post..heh [Edited by - GodlyGamr on March 6, 2006 11:46:52 AM]

##### Share on other sites
I'll bump this once...just in case.

I'm really stumped on this one.

##### Share on other sites
I am sorry that I cannot really help you on this one. But I wanted to make sure that you got at least one reply.

I have seen questions along this line posted in the past. If I remember correctly, the general consensus was to use some form of beat detection algorithm and display the arrows accordingly.

If there is no way to find a constant ratio for each song the only idea I can think of it to follow the past recommendations and develop a beat detection mechanism. After that, you can pre-detect the songs you wish to use and generate a file listing each beat and the appropriate time to add it to your display queue.

Something tells me this might be overkill for the issue and there is likely a MUCH more simple solution. Good luck on this, a very interesting topic. I wish I could be more help to you.

##### Share on other sites

I'll check back through the forums a bit to see what I can find. Anybody else have any ideas?

##### Share on other sites
From what I've read, beat detection can be really difficult. You could probably pre-create some sort of beat file that stores when the beats occur, the beats per minute, and any changes in tempo that happen. If you have the beats per minute, just make the arrows or whatever scroll up at an appropriate rate given screen resolution. It really depends on the game, so the only real advice here is to not try and do realtime beat detection. Take it with a grain of salt; I haven't really tried it before, although I have read about it a couple times. Good luck!

##### Share on other sites
As silverphyre673 has said, beat detection is quite difficult. Take a look at this article that shows a way to do it, but good luck, it's quite complex! Beat Detection Algorithms

##### Share on other sites
I haven't played these games much, but from the little I have played I seem to remember the patterns of arrows being the same everytime. If that's the case, then it makes me wonder if the arrows and timing of when to step on an arrow aren't simply authored by someone. In other words, I think it might not be all auto-magically detected by the program.

Like, if you had an editor where you could scrub time and look at a waveform and then go "Right, here's a nice beat at 4.57 seconds. I'll put a left arrow there." Whether this is the way those games work or not, if you're going to be using pre-defined music tracks then this is probably an easy way to get things working well without a lot of technical trickery and guesswork.

Just an idea...

-John

##### Share on other sites
DDR and its related clones don't attempt any direct analysis on the music. There's a music file, and a separate file which encodes the steps, BPM, BPM changes, etc. These are all composed by hand (or foot, as the case may be).

As for the scrolling. The arrows need to be at their final "hit" position when that beat occurs. You know the current beat, and you know that beat. That means you know the time remaining before it gets there, and you can position the arrows arbitrarily. The speed is whatever you want, but the speed will affect the density of the arrows. The trick is finding a good value, and I'd suggest you drop into the Stepmania source and use whatever they use. I've been through the source before, it's not bad at all.

##### Share on other sites
Thanks guys. Like I said, I'm in no way attepmpting to do any kind of beat detection at all. This is strictly going to be a game where the user will define their own BPM per song.

EDIT:

Quote:
 The trick is finding a good value, and I'd suggest you drop into the Stepmania source and use whatever they use. I've been through the source before, it's not bad at all.

I've been looking through it. It's not so much that the source is bad, it's just finding the file that has those values.

-Jeff

##### Share on other sites
Suggestion:

If you know the BPM then you can calculate the delay (in seconds) between each beat:

BPS = BPM / 60;
Delay = 1 / BPS;

Then

if( ElapedTimeSinceStarted >= NumRowsSpawned * Delay )
{
SpawnNewRow();
++NumRowsSpawned;
}

For accuracy you'd have to adjust the height at which the row is spawned based on how far off ElapedTimeSinceStarted is from ( NumRowsSpawned * Delay )

Am I wrong?

##### Share on other sites
Im in the process of writing a PC version of Guitar Hero using Java and a controller port. I don't recommend using math to determine BPP or things of that sort. It simply isn't reliable enough. In the end, a human is always required to edit notes to make the song playable and challenging.

Here's the strategy I use (Pseudocode)

long songStartTime; // Time song started on the system in nanoSeconds.long currentTime;  // Current system time.long noteTime;  // Time a note is occuring relative to the start of the song.long marginOfError; // Most DDR-type games allow you to press the note slightly before or after it actually occurs.  This is the value which determines the note's available window.  long difference = abs(currentTime - noteTime);if(difference <= marginOfError){   // We are within note window   if(noteHitWasSuccessful){      long quality = difference / marginOfError; // PERFECT!, GREAT!, OK!, FAIR!      if(quality <= .1)         // PERFECT      else if(qualtiy <= .3)         // GREAT      else if(quality <= .7)         // OK      else         // FAIR   }}

As like DDR, the farther away the button press is from the success window, the less points they get. "quality" allows us to measure this as a ratio between the difference to the total allowed margin of error.

As far as displaying the notes: Given the size of the game's window, and the BPM, determine how long it would take for a note to go from the top to the bottom of the screen. Display notes when they reach this threshold. BPM shouldn't have anything to do with the song, rather, it's the speed of the notes. If BPM is 20px/second, and the game's screen is 200 pixels high, then start showing the notes 10 seconds in advance. This isn't true "BPM" but it's a start.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
627719
• Total Posts
2978790

• 9
• 21
• 14
• 12
• 42