How does timing work, from a programming perspective?

[Travelsonic]

I am a computer science major who loves DDR/ITG/PumP [obviously, since I've been here for a long time].

I want to program for fun a little PumP/DDR like game just to see how I do - naturally taking some time not only due to the nature of the game design/programming process, but also because of ym busy class schedule.

Thing is, how would you say the timing judgement algorithm works?(in abstract of course, not how would you program it, I can do that.)? This is the only thing I am having issues comptenplating, hopefully somebody here can shed some light on it.
_________________

I'll believe that when me **** turns purple, and smells like rainbow sherbet.

[jq1790]

Well, I know basically nothing about stuff like algorithms and all that, but it would seem, from a logical standpoint, to work like this:

There's one timing that is considered exact. Call it 0, I guess, for no offset from exact timing. If the player hits whatever key or button at this point, it's a hit. Otherwise, it's not, unless you alter the timing window. However, there could be nested timing widows surrounding this 'perfect hit' zone, and the exact '0' value wouldn't actually have its own category, I'd imagine. For example, using random numbers for the point...

Say that a Perfect(or equivalent, whatever) is scored when the player hits the button within the ranges of -.05 and +.05, again with 0 being the exact timing.

Then Great, maybe, is from -.10 to +.10, but at a lower priority than the Perfect timing. (So that if it falls in the Perfect area, it only counts for that, not for the Great one as well.)

Rinse and repeat for all other timings. Not sure if that helps at all, but maybe it'll give some thought on it, I guess. Good luck!

[Travelsonic]

I think I get it. Really, I think I do. Given the way I have outlined the classes for the arrows and targets, this should be very easy to implement (though Freeze arrows will be a little bit of a PiTA, especially if I go PumP style).

Thanks for your insight.
_________________

I'll believe that when me **** turns purple, and smells like rainbow sherbet.

[Xanthros]

You can actually download the stepmania source here: http://www.stepmania.com/download.php?file=stepmania_v390_src.zip

That should be quite helpful

I'm also a CS major. I've completed most of my degree, so if you have any more questions or issues with the code I'd be happy to help. I'll try to check this forum and my PMs frequently
_________________

My GrooveStats

[..DJ..Sterf..]

I had Communications and Religion majors in my undergrad, so maybe I can help (lolol).

Do you want to do this via bpm and offsets? What language are you planning on using?

If I were to write this in, say, VB.NET 2005 (lolz), I'd probably go Managed Direct3D w/ XAudio2/DS (pretty easy) or OpenGL (pain in the butt) and think of doing these things:

- Keeping a monitored music file, i.e. making sure I can track its ms value to keep measures snapped to the file or in case of processor/GPU lag.
- With a BPM value, you can calculate how many ms each measure constitutes. With input files (or an input file as a continuous string), you could take 1 line at a time for input and detect how many characters are in the line. Each of those individual numbers (diff steps, e.g. you could put 0 for Nothing, L for Left, R for Right, or just go by SM conventions like 2, 4, 6, 8, etc.) could be placed at (msPerMeasure / numOfStepsThisMeasure) ms. This way, you can have virtually unlimited possibility of measure division (you can have 18482th notes if you want), ANDDDDD you can have 3/4 time, 5/4 time, etc. coded in as options if you wanted if you took it to the next step.
- You could add in BPM change lines in the file (or have it in the header like SM) in case of slowdowns/speedups.
- For timing windows, you only need 1 positive value for each window (unless you want to make the 'window' asymmetric). If you want a 50 ms window, do a compare statement like is TimingWindow.Great < Math.Abs(ArrowLocation - TargetLocation) and then make the arrow disappear if so

Yeah, you'd have to give priority to better judgments:
Take this value and throw it through something like:

Select Case TimingDifferenceBetweenArrowandCorrectTiming

Case is <= TimingWindow.Perfect
ShowPerfectJudgment(1)
MakeArrowDisappear()
EXIT SUB ' lol get out of here, you got a Perfect

Case is <= TimingWindow.Great
ShowJudgment(2) ' JudgeWindow 2 show (Great)
MakeArrowDisappear()
EXIT SUB

' ... Other windows go here.

End Select

You'd also have to have some kind of Timer to monitor whether the step has gone by unhit (Miss). You could do this with a HUGE For loop with an iteration for each indiv step in the song, OR you could figure out a more economic method (wise).

tl;dr: I like to watch birds
_________________

Site - Recall - Pluto Oni AAA - Overall Arcade Heavy/Oni AAAs: over 1200

[Xanthros]

You got some pretty solid advice for a Comm and Religion major

The only thing I wanted to say about that is that you don't need to code anything about 3/4, 5/4, or any other time signature. You would define different notes with msPerNote. The program doesn't need to know about the time signature of the song because it only cares about each beat, not measures. 4 measures of 3/4 and 3 measures of 4/4 look exactly the same to the program, because they both are comprised of 12 quarter notes.

You should really only need support for quarter notes (4ths), eighth notes (8ths), triplets (12ths), 16ths, 24ths, and 32nds to be able to handle any song with time signatures x/1, x/2, x/4, x/6, x/8, which is pretty much every song ever.

tl;dr: What he said but with notes, not measures. Also birds are cool
_________________

My GrooveStats

[..DJ..Sterf..]

Dance Praise (1/Original) was actually coded in that same manner -- there was a program that took input and recorded the ms value of the keypress. The game would then read those files and bring arrows up based on their ms value. (I beta tested DP1 for the company and they didn't fix the problems before release of the Original, either -- hopefully the newer ones are better, but I honestly doubt it.)

However, the caveat of that is that there NEEDS to be a program to check for linear regression (find the slope = bpm) or a way to edit each individual step. What DP1 ended up doing was having kids step on pads like crazy who didn't really have polished timing accuracy, and there was no edit to the charts after that. The charts were HORRIBLE, and if you stepped on beat, you would get a wretched score.

Soooo if you go the "exact ms" per arrow and want to be dead-on-beat, you need to have a good program to make and edit those charts. You're going to see some ms variation with manual human input.

Other than that, for greatest neatness, I'd definitely recommend making an option for diff timing. e.g. making the stepchart for Cutie Chaser or Holic is really messy in SM with 4/4 measures. If you're just messing around and want to make some easy, yeah, then ignore this paragraph.
_________________

Site - Recall - Pluto Oni AAA - Overall Arcade Heavy/Oni AAAs: over 1200

[Travelsonic]

[dlm]

As a previous poster mentioned, you do *not* want to use absolute timings for note locations (at least not in the way you store your data).

At the beginning of the track, you need to know the distance between the exact start of the song and the point where beats start, along with the initial BPM value.

From then out, you can build your stepchart where you'll basically have "lines" that will declare one of the following:
- A set of arrows and a timing for them OR
- A new BPM value

Any time you read a line with a set of arrows (or blank space if that's what you have), you'll extrapolate the real time when you would expect the input to come in.

When you receive an input, you need to consider three filters:
- If you're more than a certain distance away from the nearest event, then the input should be ignored
- Be careful of the difference between "KeyPress" and "KeyDown" events. One will only trigger on a key state change, the other will trigger any time a key is held. Held keys need to be ignored near the start of a step.
- A freeze shouldn't need to be held 100%. You need to have a buffer where letting off the step won't break the freeze for a small period of time. This matters less for keyboard input, but is critical for pad input.


I'd recommend trying to get something working with only support for constant-BPM songs initially, then attempt to layer in the BPM changes. You may even consider just using the Stepmania file format as your file format for ease. It's well-documented, so you should have a pretty easy time with it.
_________________

Reverie
Columbus, OH / Cedar Rapids, IA
Live Trance

[Travelsonic]