Sign in to follow this  
GroZZleR

Designing a system for rhythm games.

Recommended Posts

Hey all, Lookin' to design an extensible system for rhythm games. I've come up with the basic concept and I'm hoping for some insights as I always prefer a second opinion. It seems to be pretty simple, which is why I have a feeling that I'm missing something. Create a Note class which is responsible for tracking which buttons need to be pressed to play the note and the time that they appear in the song. Have a Song class which keeps a list of Notes making up the song and the timing for the song. Song will require the starting time to begin and its update will need a current time and user input. That should be enough information to find out what note is next, how close it is to being played and if the user has fouled it up. Anyone have any insights?

Share this post


Link to post
Share on other sites
You'll have to excuse me, but I feel like making your life difficult.

* Do you store absolute times in your notes, or is it relative to the previous note? (If absolute, when do you verify that they are properly ordered?)
* Do you keep duration in the notes or start and end?
* What units do you store the times in? Seconds? Beats? Some subdivision of beats? (Watch out for triplet figures...)
* Are your notes digital only, or do they support analog inputs? How's the required control state to "score" that note stored?
* Do you store per note timings for how close the player has to be, or do you make them global? Or maybe you determine them as a multiplier based on tempo? (Note that DDR has multiple levels of closeness. Note that tempo can change over the course of a song.)
* How do you encode tempo changes that happen during a note? (Doesn't occur in GH to my knowledge, but does show up in DDR.)
* Do you store any scoring information per note? (Note that in some types of DDR scoring, notes are worth progressively more points towards the end of the song.)
* How do you determine that "special" controls are available during a note? Something akin to the GH whammy bar, for example.
* Do notes encode separate track control information? How much? (Does a track cut out if the note is missed? And for how long?)
* Are there any limitations to overlapping notes in time? Do you attempt to resolve situations involving impossible maneuvers? (For example, two overlapping notes on the same input, requiring a player to press a button, then press it again without releasing it in between.)
* Are simultaneous inputs expressed as a single note or multiple notes? (So if two buttons have to be pressed simultaneously and one is missed, some rhythm games will want to fail the other button and some won't. And don't forget to think about track control and scoring tying into that.)
* Are freeze notes versus non freeze notes differentiated explicitly, or are they inferred from duration?
* How do you handle multiple types of notes and the varying events they raise? For example, ITG has bombs which if hit will hurt your life bar. Those bombs require you to release a button before they are reached.
* Button must be pressed in time vs button must simply be down, and the same thing for released.
* GH style hammer-ons and pull-offs, where multiple different control inputs may score the notes.

There's probably more, but those are my immediate thoughts.

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
You'll have to excuse me, but I feel like making your life difficult.


Some suggestions, based on experience with Stepmania and ITG:

Quote:

* Do you store absolute times in your notes, or is it relative to the previous note? (If absolute, when do you verify that they are properly ordered?)


Absolute times are probably nicer to work with to avoid accumulation of round-off error. The ordering is implicit when you read in the data.

Quote:
* Do you keep duration in the notes or start and end?


Notes don't normally have a duration; they're a specific time for a 'tap'. I would store a start and end, because then you can mark the end in the data file similarly to how you would mark a beginning. Take a look at the .sm format to see what I mean.

Quote:
* What units do you store the times in? Seconds? Beats? Some subdivision of beats? (Watch out for triplet figures...)


In beats, using a rational number class. Convert to milliseconds when checking the user's timing.

Quote:
* Are your notes digital only, or do they support analog inputs? How's the required control state to "score" that note stored?


Nothing out there supports analog inputs that I'm aware of (sensors may be analog, but the value is thresholded or otherwise pre-processed in hardware). Trying to make analog input work is just too much of a game design headache, never mind library design.

Quote:
* Do you store per note timings for how close the player has to be, or do you make them global? Or maybe you determine them as a multiplier based on tempo? (Note that DDR has multiple levels of closeness. Note that tempo can change over the course of a song.)


It is generally accepted that timing windows measured in milliseconds, and held constant for the entire song, are the only sane way to go. At least one music game out there does different timing windows per-song (Beatmania IIDX), but this is widely considered gimmicky and not especially fun (though good for a laugh in some cases - obscure in-jokes).

Quote:
* How do you encode tempo changes that happen during a note? (Doesn't occur in GH to my knowledge, but does show up in DDR.)


'Note' inherits from 'Event', as does 'BPM change'. Each has a time value. No problem (except that the algorithm for deducing note-end time is nontrivial).

Quote:
* Do you store any scoring information per note? (Note that in some types of DDR scoring, notes are worth progressively more points towards the end of the song.)


Scoring is a property of the game logic, not the song data.

Quote:
* How do you determine that "special" controls are available during a note? Something akin to the GH whammy bar, for example.


They are always "available". When triggered, it's up to the game logic to determine if it *does something*.

Quote:
* Do notes encode separate track control information? How much? (Does a track cut out if the note is missed? And for how long?)


In Beatmania, there would seem to be events for "remap sample for this key".

Quote:
* Are there any limitations to overlapping notes in time? Do you attempt to resolve situations involving impossible maneuvers? (For example, two overlapping notes on the same input, requiring a player to press a button, then press it again without releasing it in between.)


Again, game logic. Some leeway is often required in 'holds' to allow them to be momentarily released in the middle. (In ITG, this can often be used to "cheat" quite flagrantly against the step creator's apparent intention.)

Quote:
* Are simultaneous inputs expressed as a single note or multiple notes? (So if two buttons have to be pressed simultaneously and one is missed, some rhythm games will want to fail the other button and some won't. And don't forget to think about track control and scoring tying into that.)


Expressed as multiple notes. The game logic can then "unify" them if desired.

Quote:
* Are freeze notes versus non freeze notes differentiated explicitly, or are they inferred from duration?


I don't think it matters.

Quote:
* How do you handle multiple types of notes and the varying events they raise? For example, ITG has bombs which if hit will hurt your life bar. Those bombs require you to release a button before they are reached.


Game logic. There's simply some kind of "type" data in the Note event. (We need to be able to create something like an "enumeration" at runtime. I imagine the Flyweight pattern is useful here.)

Quote:
* Button must be pressed in time vs button must simply be down, and the same thing for released.
* GH style hammer-ons and pull-offs, where multiple different control inputs may score the notes.


More of the same. A lot of things can be parameterized in a "game logic" file or something (as opposed to "song data" file), but many will simply have to be programmed. Or at least scripted.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this