A rhythm game for the Pico-8.
Controls: Press arrows with timing for great justice.
Music Credit: Wistful Waltz by 0xbad1dea, see this thread (big thanks).
UPDATED 0.3: Silly title screen, particle effects, persistent high scores. Still only one song, more coming soon(TM).
I'm no musician, so if anyone would like to submit a song for the Pico-8 for the full version I'd much appreciate it (with full credits included of course).
P.S. My high score is 7660, apparently that's pretty good?
Glad to see some more people experimenting with rhythm games! I tried making one myself a few months ago but dropped it because I couldn't sync the visuals to the music very well and I didn't know about stat() at the time.
The solution you're using is a bit prone to getting out of sync, for example if you spam pause and unpause in the web player the might will quickly start lagging behind. You might want to look into using stat(16-23) (as described in this thread) as a way to sync the timer up with the music every now and then (I have no idea if it actually works, but it's what I would try).
Excited to see what will come out of this, I hope you'll continue working on it!
Thanks for the tip and the kind words.
I just got my current version "pretty much working" via trial and error, and it seems to be pretty reliable on the desktop client although I haven't tried too hard at breaking it (on any platform). I'll experiment with stat to see if I can get it doing a better job.
Here's a version instrumented with the stat() output. On the desktop my count stays quite close to the stat numbers, but seems to drift slightly later on. I'm interested to see how it does in web player.
If it does vary and you can programatically tell by how much, then could you also adjust for it in code?
I also tryed making a rythm game some times ago. I launched parts of the music manualy instead of relying on music() (and I didnt know about stat() for music). The sound would still not perfectly loop, but by setting the sfx to loop in Pico tracker, it wasnt too bad. I will post the cart if I can find it.
U mad??? 7540 being "not so great"??? I managed to get only 7400 twice! There's something not right with how it's all set up... I keep confusing left with down :(
People might be confused because you have the arrows in a different order from DDR or FFR. Normally they're like this: < v ^ >
Maybe I have a skewed view because I played it a million times while writing it. :)
Changing the order is easy, I just picked an order that made sense to me to get started with. I'll look into what the common order is.
@TonyTheTGR stat is one of the pico 8 system calls/api functions. In the documentation only a few calls are listed but there are some other uses people have discovered by various means. It looks like the 16-23 range allows you to get the current music playing status.
Well... I think part of the tracklist thing is really getting the most mileage of the SFX/track editor. Being able to copy a string into SFX memory will boost your number-of-songs potential significantly, and so will having multiple songs that share stuff like the same backbeat, and then simply changing the lead/bass layers, or factors like the music speed.
FWIW, in the project I was scoping like this, I was just gonna go with a simple "Intro/Verse/Chorus/Outro" format; and then if desired for song length, just loop the Verse and/or Chorus twice. So a song that has some logical string like "1, 2, 3, 2, 4" ~ Intro, Verse, Chorus, Verse, Outro. Then just associate some stepcharts like they're layers of the song, and if they total an odd number of steps, LR-Flip that shish. shrug
But this is where I need to understand the SFX string format way better than I currently do!
So now... I'm thinking of doing a similar kind of thing with a lot of backbeats and such premapped to the SFX channels... then making each "verse" a function like PHRASE(P1L1, P1L2, P1L3, P1L4, P2L1, P2L2, P2L3, P2L4...) where each one is one of the musical layers of each part (a SFX ID)... and then there's a song function that ties the stuff together.
Also, 1st Mix "Ouch Mode" on, huh?
Okay. So, fiddling with Pico a bit...
-The "speed" variable (in the sound/music tracker) is literally the number of programming steps between notes. So with arrows that are 8x8 px; this just means to move one pixel up that many programming steps as well. I'm using 16x16 in my PPR thing; so it's basically just doubling that.
-You can layer different SFX with a common factor of speeds (IE: a 9 ~ 18 ~ 36 ~ 72 set); the slowest (biggest speed number) will determine when it moves to another track, where the fastest (lowest speed number) will loop indefinitely until the slowest reaches it's end.
This lets you use one channel (like a bass layer) to control song progression while layering it with faster sequencial sets; and you can top it off with a fast, driving percussion beat. So a DDR-length song can be comprised of just 4-6 music sequences; especially if you use a string to play a sequence of them. I'm also thinking of a way to take the intro/outro and mash them together in one sequence - so the intro is at the end and segues into the first verse, and the end loops back and plays the outro, which is actually at the beginning of the same sequence.
It might also make more sense for the slower instruments to control the easier stepchart rhythms, and the faster ones to control the harder ones.
-You can use two channels with a common instrument to make chords. Typically, two of the same note, a +/- 1 note, or a +/- 3 note seems to make the best sounding effects (A + D, for example). You can also layer percussion together.
-Sawtooth is your percussion, sine wave is like a church organ, triangle is more like guitar (?) riffing, and the two square waves are almost identical and piano-like... but the "short" one will drill the key if used consecutively, and the "wide" one will sustain the key, instead.
A handy update60() conversion chart for BPMs (half it if it's even to use it with regular "update()")
600 BPM = 6
300 BPM = 12
150 BPM = 24
75 BPM = 48
278 BPM = 13
138 BPM = 26
69 BPM = 52
133.3 BPM = 27
66.6 BPM = 54
514 BPM = 7
257 BPM = 14
128.5 BPM = 28
64.25 BPM = 56
240 BPM = 15
120 BPM = 30
60 BPM = 60
450 BPM = 8
225 BPM = 16
112.5 BPM = 32
56.25 BPM = 64
211.76 BPM = 17
105.88 BPM = 34
400 BPM = 9
200 BPM = 18
100 BPM = 36
50 BPM = 72
190 BPM = 19
95 BPM = 38
360 BPM = 10
180 BPM = 20
90 BPM = 40
170 BPM = 21
85 BPM = 42
320 BPM = 11
160 BPM = 22
80 BPM = 44
One more thing! You can make your scores go up to a million. See, the main score really is only four-five digits; what gets displayed is a percentage of "your score vs. max score" [10000 / (Marvelous~Perfect * step count)].
The last two digits? Just have it print "00" on the end, and every time the player scores points, change it to "13, 26, 39, 42, 55, 68, 71, 84, 97, 00". It's only there to create the optical illusion that the points counter is trying to keep up with the points that the player is scoring, and will rest at "00" whenever there isn't arrows being pressed. :D
Finally, throw a sprite across the screen one direction or the other every time the player hits an arrow. There's your background effects. ;)
[Please log in to post a comment]
