One dev blog in and I’ve already missed a week – We’re off to a great start!
Truth be told, I was a bit busy with my regular job and some other stuff last week, and as a result very little progress was made. However, I have made progress this week, so hooray!
Basically Valkyrie is going to be a rhythm game with a lot of similar mechanics to Dance Dance Revolution and whatnot. However, it’s going to have some distinguishing features that will bring a fresh new twist to the tired dance game formula. One such feature is the ability for the arrow receptors to move during gameplay. Now this aspect presents some programming challenges, and that’s what I’ve been working on tackling this week.
My initial incarnation of the arrow generation routine worked like this: Loop through every line in the simfile, calculate the offset, and generate the note off-screen. Then I would simply have all of the arrows move up towards the arrow receptors. This, however, was a very inflexible system, as I would have to loop through every arrow object and recalculate its position to do something like move the arrow receptors. And then if I want to move the arrow receptors independently of each other it just creates more nightmares. In addition, I need to be able to do other things like change speed mods during gameplay, which again would require mass recalculations. Clearly a new system had to be created.
After a lot of thought on how to do this, here’s how the new system will work: Arrows are now generated from “emitters” (will be off-screen) and they move towards the “receptors”. Using the BPM and distance calculations, we can figure out how long it would take for an arrow to scroll from the emitter to the receptor, and using that number we can figure out an exact time when we should generate the note for it to reach the receptor at the right time.
The system is still a work-in-progress but I’ve started working on one major aspect of it – moving the arrows between the emitter and the receptor. It may seem pretty easy at first; just use GameMaker’s built-in functions to move towards another object. However, now we have to consider that when we move the receptors we are also presumably moving the emitters (although we don’t have to).
So how do I handle this? Basically, every frame, the arrow object creates an invisible line going from its emitter to its receptor, then looks at a timer and determines how far along this line it should be (currently hardcoded but will eventually be based on BPM).
Unfortunately, the system only kind of works right now, but we’ll get there eventually. I have an animated GIF for you guys showing a test of moving the receptor (currently not moving the emitter). Hopefully I can iron out the bugs and have something presentable for tomorrow’s Screenshot Saturday.
Anyway, see you next week (for real this time)!