You shouldn't use mp3s for games. OGG files are capable of going very small without sounding "Watery". You can have a 4 minute song under a meg and it'll still be listenable.
Check out my Telekinesis'em'up Thread and the ALICE Machines -
I attempted a Guitar Hero engine for use in my "accordion hero"... oughta get back to that... But I had an issue with timing... I recorded the button configs by using a recording level, but stupid me used a list object, which apparently doesn't seem to want to cooperate. It read at a different speed than it wrote. (Even though I made it read one line at a time every .02 seconds...) Mind telling me how you're doing it?
If I were to make a recording level, then I would use an array. Using the average human reaction time (160ms, according to Wikipedia) to construct an event that reads for input every 40ms or 20ms. (In other words, every 0.02 or 0.04 seconds.) At those intervals, the recorder would add a value (equaling what buttons are pressed) to the current line and then set it to the next line.
Then we'd need a way to find what buttons are pressed. I'm using a 4-button setup in this example: A, B, C, and D, with Spacebar as strum. Pressing A would add 1 to a counter. B, 2; C, 4; D, 8. We're doing powers of 2 because then you could hold any combination of buttons without it equaling any of the values they use. While the key(s) is down, the counter would be positive. But, upon pressing (and while pressed) the Spacebar, the counter is multiplied by -1, making it negative. By differentiating between positive and negative, you'd be able to create the initial note gem or a sustained note; The parser would interpret negative values as being when to strum. The button-combo value would then have to be compared to the current line of the array.
An early problem is determining what values equal what combined keys, but that's easily rectified:
0 = none
1 = A
2 = B
3 = AB
4 = C
5 = AC
6 = BC
7 = ABC
8 = D
9 = AD
10 = BD
11 = ABD
12 = CD
13 = ACD
14 = BCD
15 = ABCD
Adding more buttons would just mean that higher numbers would be needed. 5th button = 16, 6th = 32, 6th = 64, Nth = 2^N... And then all of the values in-between have to be determined. Also, my primitive understanding is that all 16 values (we have to include 0) have to be their own seperate conditions. And this is just to create the appropriate notes on screen.
Actual gameplay would be much simpler:
+ Counter = current value ("Array")
- Add to score, destroy note gems, what have you.
+ Counter <> current value ("Array")
- The player missed a note or whatever.
I could go on some more about this, but then I might as well just make my own GH-esque game. Plus, I forgot what I was originally going on about.
Advertisement
Post Reply
)
Edited by the Author.
