Brace Yourself Games launched its rhythm-based roguelike Crypt of the NecroDancer earlier this year. Here, creator Ryan Clark explains how he stumbled upon -- and carefully tweaked -- the game's signature beat mechanic.
Game Design Deep Dive is a new series from Gamasutra, with the goal of shedding light on specific design features or mechanics within a video game, in order to show how seemingly simple, fundamental design decisions aren't really that simple at all. Check out last week's installment on the digging mechanic of SteamWorld Dig. Also don't miss these developer-minded looks at the movement system in Road Not Taken and Amnesia's "sanity meter."
I’m probably best known as the guy who designed and programmed Crypt of the NecroDancer in 2014, but I began my journey as a “game developer” in 1984 when my dad taught me to program terrible games in BASIC on our Apple IIe, when I was 6. I continued making games as a hobby for the rest of my life, eventually founding the Game Programming Wiki in 2004 to help share some of the knowledge I’d gained. In 2005 I took the plunge and went full time, co-founding Grubby Games and releasing our IGF nominated puzzle game, Professor Fizzwizzle. You may also remember Grubby for our two other IGF nominated games, IncrediBots and FizzBall. In 2009 we sold the company to Big Fish Games, and in 2013 I decided to start over again, founding Brace Yourself Games to create Crypt of the NecroDancer.
Crypt of the NecroDancer is a rhythm game 
that goes to great lengths to require as little rhythm as possible. What caused us to stray so far from the traditional rhythm game formula of “PERFECT” “OK” “MISS”?
My design goal for Crypt of the NecroDancer was to make a dungeon crawling roguelike game that felt fair. “Fair” in the way that Spelunky feels “fair”: When you die in Spelunky, you can usually only blame yourself. You didn’t see that arrow trap. You foolishly feel onto spikes, etc. As long as a game is fair, it can be extremely challenging without frustrating the player. Each death is the result of a lack of knowledge (“Oh, I didn’t know that those faces would shoot arrows at me! Now I know!”) or a lack of skill. Gaining the necessary knowledge or skill is entirely in the hands of the player. Contrast this with the original roguelike, Rogue. I played the hell out of it when I was young, and despite my wealth of experience I often died due to lack of food, inadequate equipment, or just plain bad luck. I believe that the majority of Rogue’s generated dungeons are actually unwinnable. Yet, for some reason, I kept coming back time and time again. Despite its unfairness, I still loved it. But recently I wondered: Would I have loved it even more if it were truly fair? So began my quest! To achieve this goal of making “a fair roguelike” I ended up making a roguelike game that is turn-based yet-time limited. This, in effect, made the game a rhythm/action game, but that was not my original intent!
I believe that the real-time nature of Spelunky is what permits it to feel fair. There are no random combat dice rolls, as in Rogue. It’s based solely on skill: You either whipped that bat first, or it touched you first. But I didn’t want to strip Rogue of its turn-based nature entirely, so I hybridized: There are still “turns”, but they are fast! I hoped that this would retain the best aspects of both games. When I tried prototyping this, having turns of enforced duration felt like moving to a beat! So I tried playing the game to the rhythm of “Thriller” by Michael Jackson, and it was both hilarious and fun -- but there were some problems. First, I implemented the game with about 20 percent leeway around the beat. For a 120bpm song you have 500ms per beat. A 20 percent leeway means you have to be within 100ms of the beat or your movement will fail. I did this because this is what rhythm games traditionally do — they require you to be accurate. But I found that the times when you are least accurate are the times when you are most stressed! If a miniboss dragon has just bashed down a wall and is about to fireball you, the fact that you’ve been startled means that your next movement is likely to be less accurate. But if you “MISS” the beat and fail to move, you’ll die and get frustrated. So I tried increasing this leeway value and was surprised to discover that it felt best at 100 percent! I think I was unwise to emulate rhythm games here. Most rhythm games require you to simply obey commands, and their challenge comes from doing that accurately. In NecroDancer the challenge comes from the fast tactical combat itself. Requiring accuracy is just frustrating. 
Second, my initial prototypes had the player move on the beat, while the enemies moved halfway between the beats. I felt that this gave the game a predictable, “I move, then you move, then I move…” type of structure. And it also made combat obvious: If an enemy moves into your tile, it attacks you. If you move into an enemy’s tile, you attack it! The drawback, however, is that it doesn’t feel like the whole game world is visually synchronized to the beat. You move on the beat, but the enemies don’t. This makes it more difficult for players to get into the groove keep the beat themselves. However, the alternative is to have both the player and the enemies move at the same time, but allow the player’s action to take priority. I worried that this priority system would be confusing to players, so I didn’t try it at first. It was only after persistent prodding from Matt Thorson (creator of TowerFall) that I gave it a shot. And he was right; the game does feel much more unified when everything happens on the beat. There are some strange corner
"When I decided that rhythm gameplay was the way to go, I did not expect to end up removing the precise rhythm requirements that are a hallmark of the rhythm genre!"
case drawbacks created by this simultaneous movement scheme, but since they crop up so rarely, I think the benefits greatly outweigh the disadvantages. Last, for debug reasons I was logging data that showed how far off the player was from the beat, each time they moved. From looking at these logs I noticed that players naturally drift away from the beat when stressed, then drift back toward it afterward. As mentioned above, they would sometimes miss a beat due to this stress and get frustrated, so I used a leaky integrator to implement an “autocalibration” system. If the player is moving a little faster or slower than the beat, the game will slowly shift the effective position of each beat to match. This can only be pushed so far, but it does help to ensure that the player doesn’t receive a “MISS” when they feel like they were indeed on the beat. My reasoning was this: A player hits the key when they perceive the beat to be. They might be wrong, but that’s where they feel that the beat is! And if the game tells them that they’re wrong, in the heat of battle, they get frustrated. So this autocalibration system bends the rules a little (without drifting more than 1/2 beat away from the true beat position) to give the player as much benefit of the doubt as the gameplay rules can bear.
When I set out to create a “fair roguelike game,” I did not expect to end up with Crypt of the NecroDancer. And when I decided that rhythm gameplay was the way to go, I did not expect to end up removing the precise rhythm requirements that are a hallmark of the rhythm genre! But I am very pleased with how it all turned out. I think the key for me was iteration (playing the game a ton myself, playtesting with friends, relatives, and other game designers), while staying open to having the design go to a place that I did not initially expect! Are you a developer interested in contributing to Gamasutra's Game Design Deep Dive series? Email editor-in-chief Kris Graft: [email protected]
You May Also Like
