Hey, I’m David, and I’m one of the interns at SeeThrough Studios. I selected a rhythm based game as the first of my ‘Prototype Fortnight’ prototypes. When we were brainstorming ideas, rhythm was an element that a lot of us were really interested in doing. I’ve also had an idea kicking around in the back of my head about a rhythm based combat system. It has some very interesting elements to work with, and has some implications for pacing which I’ll outline below.
The idea came from a class I had on video editing. We learned how to use music for pacing, and as a base for editing film. Watch any trailer, and you’ll see that the rhythm and pacing of the music flows (usually) perfectly with the action of the clip. Observe how powerful this tool is, and how rare it is to find it used as a gameplay pacing element.
Controls: WSAD to move the player. UP, DOWN, LEFT, RIGHT to shoot in the direction that you want. Shoot in time with the music. If you can’t figure out the rhythm watch the boss’ movement patterns. Red bullets do double damage and mean you have shot on time. White bullets mean you have shot off time. P will reset the game too if you get stuck.
[kml_flashembed publishmethod="static" fversion="8.0.0" movie="http://www.pdyxs.org/seethrough/prototypes/RhythmCombat/RhythmCombat.swf" width="550" height="400" targetclass="flashmovie"]
After deciding my direction I wanted, I needed to find the gameplay to fit it. I took inspiration from WoW and ‘The Binding of Isaac’ to get the base gameplay down. I only had 4 days all up to finish the prototype, and I didn’t want to spend much if any of the time focusing on the art. Because of this I went with shooting for the rhythm element so I didn’t have to animate melee combat. I wanted to make a boss fight for several reasons. Firstly, boss fights are usually a few minutes long, which gives the player time to learn the rhythm of the battle. Secondly, it means less work for me because I only need to code one AI that deals with the player.
So after I had my basic gameplay idea, it was down to prototyping. I started coding on my second day and by the end of it I had a top down game with shooting, collision detection and terminator AI. I use flash with ActionScript 2.0 to prototype things (I also used it for Ludum Dare). This is so that I don’t have to worry about rendering, collision detection or animation. It has some downsides, some of which I discovered during Ludum Dare. Swapping between frames and using global variables do not work well together. Also, because there is no real object orientation, the code can be hard to maintain (though it’s not much of an issue with smaller projects like this).
Day 3 was the rhythm/testing day. With implementing the original music I had I realized a clear problem that cannot be easily solved on such a small time scale. The music you pick is incredibly important, especially if you are basing the player’s timing strictly with the rhythm. It takes a fair while for a player to ‘master’ a certain rhythm. The rhythm in the song also needs to be incredibly clear, otherwise the player will generally get frustrated and give up. This requires having a mechanic that displays the rhythm inside the game. For example, Mother 3 used the heartbeat system while someone is asleep, Patapon uses an outline around the screen that pulses with the beats.
I wasn’t prepared for testing as well. I think I only had 30 minutes notice before we had testers coming in, so I had to scramble to get the game in a testable state. The main feedback I got was that the rhythm needs to be very clear: you have to know what you’re shooting in time with. Also, some people weren’t very good at killing the boss. I was able to find a single, simple solution to both problems: the boss only moves with the rhythm. This means the player can watch the boss and get an idea of when to shoot. Secondly, having the boss moves in a predictable pattern makes it much easier to kill.
On day 4, I fixed up a couple of bugs, and made the game more approachable. It now has a reset button, a start screen and the changes based on feedback from testing. The prototype accomplishes what it was trying to do, and allowed me to find several future problems with rhythm combat.
Some notes I found with the concept to anyone who may try to to emulate the concept:
- Pick/make a song with very distinct rhythm patterns. What I used was the clearest I could find, and some testers still had problems with it.
- People have a much harder time with picking up a rhythm element than what I had initially expected, so you need to be very careful with tuning the difficulty curve of the game. I also haven’t yet figured out how to ramp up and change rhythms within a fight (one of my initial plans) while keeping the rhythm clear.
- Giving clear feedback to the player about whether they were on the beat is really quite difficult to do on a project at this scale. Spend plenty of time on this and on communicating the rhythm to the player. Your #1 goal is clarity in the mechanic.
There are many things that I would have loved to put into the prototype, but I haven’t been able to do. Using the music to emotionally pace the fight needs to be tested. Having more boss behaviours, and phases that change the music. Additional abilities for the player.
Overall I’m relatively happy with the prototype. It tests a small part of an interesting field and I discovered several new things while making it.