Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
(2 edits)

Thanks for the kind words! Since it was just a minigame for a jam and I am not experienced on Game Maker I didn't want to make it very complicated. For me the priority was to have something running to submit it on time, more than to have something accurate. I just needed a simple, quick, easy to play casual method with a single track: Yes, I move the pads using room_speed as reference. Everyobject that moves left has this code in their Step:

x -= INPUTS_PER_SEC * DISTANCE_BETWEEN_INPUTS / room_speed;

Where the constant INPUTS_PER_SEC is the amount of keys you'd need to press per second to make it perfect, and DISTANCE_BETWEEN_INPUTS is the screen distance (in native resolution) between the pads. I manually tweaked these values, without reading by code data from the song, to make sure that more or less follows the rythm of the music while at the same time you can see enough upcoming inputs. I also wanted to make sure that difficulty was easy enough for non rythm game players, making sure that almost everyone could achieve a perfect score with maybe just a couple of atempts.

In order to make sure if the inputs have been pressed on time, I use colission of the pad with the white box when a key is pressed. If it's fully inside the box, counts as perfect ("Cool!"), if it's only partly inside the white box counts as "good!", if it only collides with the black bar counts as "Miss!" (too late press), and if it only collides with the blue bar I don't do anything to make sure it's easier for players. I'm not experienced with the collisions in Game Maker and I think it has a couple of collision related bugs, but I thought it was decent enough to submit the game.

I didn't know the BPM of the song, but if it was a fixed one that I was able to sync, it would be easy to modify the formula seen above. A general programming trick (not just GM) for precision calculations in games where you traditionally work with small integer numbers: use real numbers instead of integers and if needed use separated numbers for both things or multiply and divide when needed by a big number (like in the case of the art: In GM you use reals as coordinates, and in pixel art you need to use round() to make sure doesn't look ugly, but if you program somewhere where screen coordinates are int you can use screen pixel coordinates x 1000 (or some other random number stored in some constant) for the game logic, and to divide by this number when drawing. By doing this you'll have an accurated way for the logic precision, and at the same time a small number for when drawing allowing smoother movement.

For a future project I want to investigate a bit the music related code in order to extract stuff like the BPM you mention from the track itself.  Not a rythm game, just to coordinate some background stuff with the music. But for many reasons (like a possible Switch port) I think I'll use Unity for that other project.

Ah thanks for the detailed reply! I think you did plenty well for the jam otherwise, especially if it's been part of a learning experience for you with gamemaker, i was just curious about the different approaches for tackling a game like this. I never got as far as considering using actual collisions for the input timing but now that you mention it it makes a lot of sense. i think that part worked well in the end though and i didnt really have a problem with lining up with the boxes, just the boxes lining up with the music that i noticed came out of sync. but you're right its still good that you managed to submit in time and have everything look so polished otherwise, kudos