Last semester, I was part of a pitch project team at the ETC that spent 16 weeks researching, exploring, and creating rhythm games. Each of the 8 prototypes that we created focussed on answering a specific game design question. Our 7th prototype, “Dutch Double” asked the question:
“Can we make a rhythm game that simulates the real-life, rhythmic activity of jump rope/double dutch?”
First of all, some background.
What is a Rhythm Game?
A common understanding according to Wikipedia defines rhythm games as a subgenre of action games. Nice, but we want a bit more clarity. After much more research, as a team we decided that a rhythm game is a game in which an understanding of rhythm, and being able to act accordingly, is necessary to succeed. Great! Now how about Jump Rope?
Jump Rope is one of those games that seemingly everybody knows how to play once they get going. The only major criteria of success is being able to swing a rope around so that you are able to jump over it. Almost all variations of rope movement+jumping technique revolve around that basic concept. The Rope Swinging is a constant motion, meaning it is predictable. Jumping over the rope has to happen at a particular moment to achieve success. Therefore, at it’s core, one can consider Jump Rope to be a kind of rhythm game.
So what happened when we tried to virtualize it?
Phase 1, Research
We set out to make a direct copy to port the experience onto a Dance Dance Revolution pad. A big item for discussion was, or course, timing. This turned out to be much more difficult than we had anticipated. When you physically participate in Jump Rope, your body does so many calculations in the background that you just focus on the feeling of the rope and jump. For the majority of playtesters, the action seemed so natural that almost unanimously there was “no thought” about when participants needed to jump. They just “felt it and did it”.
A nice video showing proper and improper jump rope techniques
Digging in more scientifically, the auditory feedback that a physical jump ropist gets is quite interesting. There are two sound components: The swish of the rope around the participant, and the smack of the rope as it hits the ground. The Swish actually depends on the handling of the rope by the participant. Different people had different styles, so the swish could be constant, or only at a particular point. We figured that this wasn’t inherent to the experience, so we arbitrarily chose a timing position for that sound. The Smack, on the other hand is critical to the experience. The core of jumping rope is jumping after you hear the smack. More specifically, you have to be in the air at the time of the smack to ensure you are able to clear it.
Different people have different jumping habits, so the time interval varies between the Smack and the Jump. Some people make big jumps, requiring there to be a long interval, and some people make tiny jumps, making the interval last milliseconds.
Perfect, we have all of our info and made a build. However, testing went completely awry.
Phase 2, The Direct Copy
We talk about Douch Double at 3:17
Using a DDR pad as the control interface to register jumping, we made a “direct copy” of jump rope in the virtual realm. For timing the smack, we tuned the average delay so that it was a comfortable “PAPAM”, where PA is the Smack, and PAM is the land of feet. When we tested it, it went okay, because we knew what to expect. However, Naive Guests were a completely different story: There almost no successful tests
Almost without fail, our playtesters just couldn’t grasp the concept. Which very odd. We spent a lot of research to make a direct replica of the experience, recreating timings and purpose being a huge focus, however playtesters just weren’t having any of it. The longest jump chain we got was maybe 2. So what happened?
Phase 3, Analysis
After looking over all of our playtest data, a couple of things became apparent:
1) Jump Rope is a “Full Body Experience”, and taking away the actual rope removes that feeling entirely. Now with the DDR pad, it turned into a weird timed jumping smulator
2) The act of Jumping varies from person to person. Heights, weights, and styles affect the timing of everybody’s jump mechanic
3) This direct copy completely violates traditional game design handeling of Cues (or action points)
This last point was key. You see, as we mentioned before, a rhythm game can only succeed when a player is able to act accordingly to a game’s rhythm. When a player sees or hears a Cue, they expect to perform an action in response. In real jump rope, it turns out that the auditory cue of the rope smack is NOT an indication that it’s time to perform a jumping action, as you should already be in the air. That cue instead is an indicator of something that is yet to happen, (the rope is about to pass under you).
Having the player only experience a cue that indicates a delay of an action/event causes confusion and uncertainty for that player, and is a design element that goes completely against the traditional game design of a rhythm game, which is why our example of virtualization with a DDR pad did not work.
Our further design iterations made it so that a player has to Land when they hear the smack cue, and that instantly made playtesters able to attain longer combo chains, but ultimately it turned the experience from a Jump Rope simulator to a creative jumping game.