How is Guitar Hero Programmed?
Author
how should I approach reading it? The pyo files also give blank screens. Opening in notepad gives a bunch of symbols.
You open it the same way you open mp3 files. You get a music player that can read them. VLC plays them for instance. If you want to play them in software you should get a library for it. I have no idea what the most appropriate library for you would be, all I know is there's one here.
Python source files end in ".py".
If the source didn't come with the game, you can probably get it from their SourceForge page.
If the source didn't come with the game, you can probably get it from their SourceForge page.
Quote:Original post by HollandQuote:Original post by Kwizatz
You can take a look at Frets On Fire's Source Code to get an idea.
This is assuming that FoF is programmed the same as GH, which it probably is not. I've played FoF and it doesn't seem as responsive or as fluid as GH.
A keyboard is not a game device, so to add to shadowisadog's post, you can't expect the same responsiveness from a keyboard that you get from a tailor made device for a game, specially because keyboards are evil.
Check out this link on a tutorial to making a Guitar Hero type game using C#/XNA, I believe there are videos to watch on this how to program tutorial and maybe what you are looking for if you want to know exactly how it can be done.
http://blogs.msdn.com/dawate/archive/2008/02/05/building-a-3d-game-in-xna-from-scratch-free-video-tutorial-series-now-available.aspx
http://blogs.msdn.com/dawate/archive/2008/02/05/building-a-3d-game-in-xna-from-scratch-free-video-tutorial-series-now-available.aspx
While I don't know how Guitar Hero is implemented, I can tell you how we did it for our upcoming rythm game for PSN.
We basically use the same method you mentioned, only with millisecond precision.
The notes themselves are converted into our own format from MIDI files, so everything is sequenced in Acid using the actual soundtrack on a reference track. We then check on button presses weather or not the time of the press is within the given note. We use four buttons, and each has its own track in both the MIDI file and our own format. Accuracy is calculated by taking the start and stop times of the note and calculating a [0..1..0] interval for it, where 1 is a absolutely perfect hit, and 0 is a miss. We use thresholds to add some room before and after the actual MIDI note to accomplish this, along with normalized note lengths for regular notes. For hold notes (the ones where the player needs to hold a certain button down for the duration of the note) we add note duration so that the note actually consists of two separate though connected normalized notes. In this case, the player must press down within the first "virtual" note, and release on the second. The calculated [0..1..0] interval makes it very effortless to add several different accuracy points, such as "Bad", "Good", "Ok", "Miss", "Perfect" etc by simply defining a range for the accuracy point. A perfect hit for instance, is in the interval [0.90 - 1.0], while a "Good" hit is in the interval [0.78 - 0.90]. Note that the accuracy works on both "sides" of the absolute perfect (1.0), so in the example of the perfect hit given a note length of 100ms, it would actually be triggered if the current relative note time is between 90ms and 110ms.
Edit: Yikes, I messed up my numbers in the example there, and also failed to provide a more complete explanation. I guess that's what you posting in a hurry. The correct example of a perfect hit given a note length of 100ms, would be that the threshold value is added in a relative manner to the *start* of the note only, which is simply a millisecond value. So if the note start is 2050ms in the MIDI sequencer, the new note would start at 2000ms, and end at 2100 after the thresholds were applied. A perfect hit would then be between 40ms and 60ms in relative/local time, and between 2040ms and 2060ms in global time. In other words, we only use the start value for MIDI notes, and construct our own normalized notes using that value as the desired trigger point. Hold notes are as I said earlier slightly different, there we use both the start and the stop, where the start is the desired button press point, and stop the desired button release point. So what I said earlier about the buttons having their own track is only a semi-truth. They actually have two tracks each, one for hold notes and one for regular notes.
[Edited by - cmv on September 17, 2009 1:18:47 AM]
We basically use the same method you mentioned, only with millisecond precision.
The notes themselves are converted into our own format from MIDI files, so everything is sequenced in Acid using the actual soundtrack on a reference track. We then check on button presses weather or not the time of the press is within the given note. We use four buttons, and each has its own track in both the MIDI file and our own format. Accuracy is calculated by taking the start and stop times of the note and calculating a [0..1..0] interval for it, where 1 is a absolutely perfect hit, and 0 is a miss. We use thresholds to add some room before and after the actual MIDI note to accomplish this, along with normalized note lengths for regular notes. For hold notes (the ones where the player needs to hold a certain button down for the duration of the note) we add note duration so that the note actually consists of two separate though connected normalized notes. In this case, the player must press down within the first "virtual" note, and release on the second. The calculated [0..1..0] interval makes it very effortless to add several different accuracy points, such as "Bad", "Good", "Ok", "Miss", "Perfect" etc by simply defining a range for the accuracy point. A perfect hit for instance, is in the interval [0.90 - 1.0], while a "Good" hit is in the interval [0.78 - 0.90]. Note that the accuracy works on both "sides" of the absolute perfect (1.0), so in the example of the perfect hit given a note length of 100ms, it would actually be triggered if the current relative note time is between 90ms and 110ms.
Edit: Yikes, I messed up my numbers in the example there, and also failed to provide a more complete explanation. I guess that's what you posting in a hurry. The correct example of a perfect hit given a note length of 100ms, would be that the threshold value is added in a relative manner to the *start* of the note only, which is simply a millisecond value. So if the note start is 2050ms in the MIDI sequencer, the new note would start at 2000ms, and end at 2100 after the thresholds were applied. A perfect hit would then be between 40ms and 60ms in relative/local time, and between 2040ms and 2060ms in global time. In other words, we only use the start value for MIDI notes, and construct our own normalized notes using that value as the desired trigger point. Hold notes are as I said earlier slightly different, there we use both the start and the stop, where the start is the desired button press point, and stop the desired button release point. So what I said earlier about the buttons having their own track is only a semi-truth. They actually have two tracks each, one for hold notes and one for regular notes.
[Edited by - cmv on September 17, 2009 1:18:47 AM]
I think that they have a tool where they play the song and add the notes. Then, in-game, everything is synced up (sound and notes stream). If a button is pressed when the corresponding note is due to be strummed, you've got a hit.
If I had to guess (and remember this is a guess)...
They would have the song file which is your normal ogg/mp3 whatever. They have the event of when the song file starts and then simply use a data file that indicates "this note is played here" type of data. The notes would have a start time, end time, etc... and it would all be relative to the song's start time. Assign the note an ID and you have quick and easy network play, the game would transmit that note ID is hit or miss. With a bit of dead reckoning logic involved, network code would be super easy.
They can then adjust the data file's time frames by the options window's visual syncing/delay setting. Then for easy/medium/hard/expert levels they vary the threshold of "missing" a note. That's why when you play GH you see that the notes you are playing "look" like they follow the song but in actuality, they do not actually follow the song as the instrument would normally be played. This is because someone took a more aesthetic approach to creating the data track.
Anyway, that's just a guess.
They would have the song file which is your normal ogg/mp3 whatever. They have the event of when the song file starts and then simply use a data file that indicates "this note is played here" type of data. The notes would have a start time, end time, etc... and it would all be relative to the song's start time. Assign the note an ID and you have quick and easy network play, the game would transmit that note ID is hit or miss. With a bit of dead reckoning logic involved, network code would be super easy.
They can then adjust the data file's time frames by the options window's visual syncing/delay setting. Then for easy/medium/hard/expert levels they vary the threshold of "missing" a note. That's why when you play GH you see that the notes you are playing "look" like they follow the song but in actuality, they do not actually follow the song as the instrument would normally be played. This is because someone took a more aesthetic approach to creating the data track.
Anyway, that's just a guess.
Author
Thanks for responses guys! I will try to use a mix of these to see what works best. Just as a disclaimer, I'm not making a guitar hero clone. A friend asked me to help program a game that uses rhythm, however. It still requires buttons to be pressed to the beat of a song, but not quite as complicated as guitar hero. Thanks for the link to the guitar matey game, I will look at the source code to see if I can find any last bits of information before I start coding this weekend.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
