Rhythm Game

Started by
9 comments, last by Funkapotamus 18 years, 1 month ago
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]
Advertisement
I'll bump this once...just in case.

I'm really stumped on this one.
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.
Thanks for the reply.

I'll check back through the forums a bit to see what I can find. Anybody else have any ideas?
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!
my siteGenius is 1% inspiration and 99% perspiration
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
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
- John
About beat detection --
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.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
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
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?

This topic is closed to new replies.

Advertisement