Team Size: 5 Members Role: Game Designer, Co-Producer, Artist Engine: Unity Platform: PC
Duration: 1 Month
Project Description
Dutch Double was part of an ETC project called Jam Session, which focused on exploring rhythm games.
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.
Contributions
Game Designer
Led my team in brainstorming sessions
Worked with my team to develop ideas and mechanics for each of the individual prototypes
Implemented ideas in-engine
Playtested prototypes throughout lifespan of the game
Co-producer
Led daily Scrum meetings for the team
Worked with each member to ensure that they knew what work had to be done for the day
Kept track of what work had already been completed.
Wrote postmortems for the prototypes as well as keeping in touch with the many contacts important to the project.
Artist
Contributed models, textures, and particle effects for this game.
Project Video
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?
Design Thoughts
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.
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.