Prompt: How can we gamify a familiar rhythm-based activity?
Prototype Goals
- Can we make a rhythm game that simulates the real-life, rhythmic activity of jump rope/double dutch?
- Can we make a rhythm game that requires players to be active?
Details
Platform: PC
Players: 1
Controllers: DDR Dance Pad
Description
In Dutch Double, players jump on a Dance Dance Revolution Dance Pad to emulate jumping rope. The main screen of the game shows players what buttons they should be jumping on and if they should be doing single (jumping with both feet at the same time), or double (jumping with alternating feet). An auxiliary screen provides players with a visual indicator of when to jump. The more the player continues to jump on the beat, the more layers are added to the game’s soundtrack. After three failed jumps, players lose the game.
Iteration Thoughts
Music
- This was a sound effect focused prototype, with music being secondary.
- Almost through the entirety of the creation and playtesting period, there was only 1 sound effect group:
- The sound of the jump rope crack on the ground
- The swish of wind as the rope passes by
- Music and additional SFX were only added later for a sense of progression and to provide feedback during changing parameters.
- A simple layered music approach was created, with additional layers of music added as the player maintained a jump streak
- Almost through the entirety of the creation and playtesting period, there was only 1 sound effect group:
- Jump rope is all about timing.
- While a huge part of this prototype was fine tuning accuracy parameters and visual feedback by the art and programming, comfortable timing mimicking “real” jump rope was tested out
- Ultimately 6 levels of jump rope speed were decided upon, from 72 bpm to 106 bpm in 8 bpm increments (8 being a noticeable enough change without being too drastic).
- Double Dutch mode was a doubling of tempo for each stage
- Ultimately 6 levels of jump rope speed were decided upon, from 72 bpm to 106 bpm in 8 bpm increments (8 being a noticeable enough change without being too drastic).
- Due to random changing of tempo during gameplay, a different framework for music had to be created
- Each successful player land during a continuous chain would trigger a note. Therefore, the soundtrack needed to be divided up into each individual note for each individual instrument, named chronologically
- FMOD allows for the creating of buckets or groupings of audio files inside of individual tracks. Simply adding the chronological audio files to each grouping within an instrument track, and selecting a global chronological follow/file select mode for each grouping was all that was needed. The music would then simply be triggered, note by note, by the programmers parameters as needed, allowing for a dynamically tempo-ed soundtrack to be used and created.
- While a huge part of this prototype was fine tuning accuracy parameters and visual feedback by the art and programming, comfortable timing mimicking “real” jump rope was tested out
Design
- This game was really, really hard. Many of our naive testers had a hard time getting more than a couple of correct jumps.
- We already had a leeway system built in that ignored bad jumps after certain events, such as when changing the players’ foot positions. One idea we had was to give players a couple of jumps of leeway after making 1 bad jump — however, this made it hard for players to self-correct, because there was no feedback during the “invincibility period” that would help them fix their timing.
Jumping Mechanics — More difficult than you think!
Our initial goal for this prototype was to create a digital version of jump rope, as it is very rhythmic. We wanted to stay true to the act of jump rope as much as possible. The first iteration of the game was exactly that. When the jump rope hit the floor, there was a predefined window of time in which the player needed to be in the air, before it was ok to land again. To prevent players from taking their feet off the DDR mat entirely, we implemented a check that made sure that players had to touch the ground before the next slap. (However, in real jump rope, it’s possible to remain in the air for multiple turns.) While this tactic was accurate to real-life jump rope, this didn’t play so well. Players were constantly thrown off by the beat and had to rely on visual input to determine when to jump.
We initially believed that it would be easier for people to jump on the beat — it made sense to us, since people can control when they jump, but they can’t control when they land. However, our playtesters found it easier to land on the beat. Why was that the case? We think it’s because rhythm games almost always involve hitting a button on the beat, and that familiar action causes players to somehow be better at landing on the beat — ostensibly similar to hitting a button — instead of jumping on the beat. Weird, but makes sense!
The combination of this alternative control scheme and the baseline difficulty for rhythm games ultimately made this game really hard. We did realize, though, that it was possible for players to improve over time, which meant that there was definitely some potential for mastery in the mechanics.
Lessons Learned
- Even though the act of jumping rope is a rhythmic activity, it seems that most people (especially novices) don’t perceive its true rhythm when doing it. Therefore, translating that true rhythm to a video game doesn’t work so well. To make it work, we have to make the game similar to other rhythm game mechanics. (Landing on the beat)
- A/B testing the two input schemes we had (jumping on the beat and landing on the beat) proved really useful in determining which was the better choice for our game.
- Physical interfaces that use non-traditional forms of input (i.e. not just button/key presses on a keyboard or a gamepad) require a lot more work than we foresaw. There are completely different paradigms about usability and user experience when using jump- or even foot-based controls. Rhythm games are already pretty difficult, so mashing that up with a wacky control scheme makes the resulting game extremely hard.
- Testing a game that’s supposed to be more like a festival/exhibition experience is tricky, especially when you can’t bring a ton of equipment with you. This game required multiple monitors with a very specific orientation.
- Players need to be allowed to self-correct their input when they make a mistake. Rhythm games that focus on beat-matching action need to give players some sort of feedback about how far off-beat they are so they can rectify their own inputs.