Using medical stories and heart conditions to create musical challenges in Rhythm Doctor

The IGF (Independent Games Festival) aims to encourage innovation in game development and to recognize independent game developers advancing the medium. Every year, Game Developer sits down with the finalists for the IGF ahead of GDC to explore the themes, design decisions, and tools behind each entry. Game Developer and GDC are sibling organizations under Informa Tech.

Rhythm Doctor needs you to deliver life-saving defibrillation to the tune of the beat, tapping away to heartfelt stories to save lives.

Game Developer spoke with the team at 7^th Beat Games, creators of this Excellence in Audio-nominated title, to learn more about the genuine medical stories and heart ailments that inform the rhythm-base games, why they chose to have it all playable with only a single button (and the challenges that came from that constraint), and what drew them to design the game in such a way that it would enhance the player’s knowledge of music and how it works.

Who are you, and what was your role in developing Rhythm Doctor?

Hafiz Azman, lead game designer and composer: I'm the lead game designer and lead composer of Rhythm Doctor, and the original creator of the early 2011-2014 version of the game (together with my college friend Winston Lee who did all the art). For a few years I was also the sole programmer, but now that we have a bigger team, Giacomo’s able to tackle programming together with the other programmers.

Kyle Labriola, writer: I'm the writer on Rhythm Doctor. I worked with Hafiz on the main story, as well as wrote most of the character dialogue. Since we're a small team, I also wear other hats like "Community Management" and "Social Media."

Giacomo Preciado, lead programmer: I’m the lead programmer and UX designer for Rhythm Doctor. I entered the team in early 2016 when the game started development full-time and it was being ported to Unity.

What's your background in making games?

Azman: When I was a child in the early 2000s I came across Game Maker 3 by Mark Overmars. It’s since evolved into today’s Game Maker Studio. I learned from tutorials, released a few simple games on the Game Maker Community forums (including a platformer-runner Sonic fan-game with level design only a twelve-year-old would make). Maddy Thorson (who was ‘YoMamasMama’ on the forums) was my hero back then. I spent hours playing through all of her games, all also made in Game Maker.

Then, I forgot all about game making until many years later in college when I was playing Rhythm Heaven. I loved the game so much that later, when the main ‘press space on the 7th beat’ idea came to mind, I picked up all my old tools to try to make it. Rhythm Doctor is the first game I’ve made as an adult.

Labriola: Aside from doing the art for our other game, A Dance of Fire and Ice, working on Rhythm Doctor is basically my first experience with game development. In my spare time, I do hobbyist projects in Twine and RPG Maker. Before all this, I drew comics and went to college for animation.

Preciado: I used to make pencil and paper games for my friends at elementary school. Then, after telling my parents I wanted to learn how to make video games, my older brother and I were admitted to a technical school to learn programming thanks to a teacher that agreed to teach little kids (thank you Hugo Mixcan!). During high school, I spent some time making games using Visual Basic 6 but didn’t have enough discipline to finish anything worth showing.

After that, I made a very simple mobile game with some friends during university that took like 4 years Even though it didn’t sell at all, I learned a lot about OpenGL, making level editors, and how bad I was at managing teams. Thanks to this knowledge, I was admitted to be an intern at a mobile development company as the first gamedev there, and learned a lot about managing teams, delivering stuff on time, and making good code architecture for people to work together, but still didn’t know how super well-designed games were done. After 3 years there, I felt like I had learned enough, so I quit and joined 7th Beat Games shortly after.

Images via 7th Beat Games and indienova

How did you come up with the concept for Rhythm Doctor?

Azman:  The main seed of the idea was really ‘polyrhythms’. In my first year of university I dabbled in a bit of street dance and music composition for a play. Somewhere in between all the counting of dance steps and daydreaming in electromagnetics lectures, the idea came up to have a game in which the main point was to keep track of different rhythms at the same time.

I remember trying to explain it to friends while drumming on a table: "So imagine I have quarter-notes on my left hand and sixteenths on my right. But you need to hit it on the seventh beat of each hand!" It was weird and my friends didn’t really see the appeal. But the idea didn’t seem to have been done before, and so I set to work and ended up with a prototype. After making that first prototype and sending it to friends to test, I realized that it was actually much too steep of a learning curve, and that’s how the prototype became a late level in the game, and levels were added before that to build the player up to this idea.

Along the way, the concept expanded past polyrhythms and into other bits of music theory, and I ended up figuring out other complementary mechanics and twists. Those actually ended up being more fun than the original idea in the first place.

What development tools were used to build your game?

Azman: Our main tools were Unity, Visual Studio Code, FL Studio, REAPER, Sketch, and Aseprite. We also used Notion for organization and Discord for communication.

Rhythm Doctor mixes medicine and music. What appealed to you about bringing these two concepts together for your rhythm game?

Azman: For most of my life, I wanted to be a doctor. I took the related subjects in school, shadowed doctors in hospitals throughout their day during my holidays. Through shadowing doctors, I could listen to their difficult conversations with patients and stay in the OT while they performed surgery. Some doctors I shadowed were kind while others were fierce and nasty to their nurses.

At the last minute before university I switched to doing an Engineering degree, but I still kept a lot of those experiences with me. So, it was because of all of this that when I had a prototype for Rhythm Doctor with just squares, what came to my mind first was that the rhythm could be patient heartbeats. Winston’s (our artist who I started the game with) father is a doctor so he knew some things second-hand, and we both had close friends who studied medicine, so throughout development we could always talk to them and find out how their doctor training was like. It was nice to be able to convey some of our doctor friends’ stories through the game.

There are some fun parallels between heart-related ailments and how they can be approached in the context of rhythm game design—things like heart block causing an irregular rhythm, or supraventricular tachycardia where the heart suddenly beats much faster than normal, or other kinds of arrhythmias where a heartbeat can be skipped. So, it made sense to me for each patient to have a particular heart disease that would also be the new game mechanic of the level.

The game only makes use of the spacebar to interact with the beat. What interested you about only focusing on one-button inputs for the game? How did this decision affect the game's overall design?

Azman: It wasn’t an intentional mission at the start—just a culmination of my experiences and preferences. I like music. I like games. I don’t really like the multi-button-dexterity part of rhythm games.  Hence, one-button rhythm games. But also, I wouldn’t have gotten the idea of it without having played Rhythm Heaven.

Often game design decisions are a lot easier to make when you see someone else who proves it can work, and it's the same for me with sticking to one-button game design. The Rhythm Heaven series mainly uses two buttons throughout the franchise. It showed how such a thing was even possible, so it was a reason why the earliest prototype I made was limited to a single button.

After we released the first few levels as a Flash demo, it became a kind of challenge to myself to see how far I could go without ever introducing a second button. This one-button constraint made us have to really rack our brains to still make each level’s gameplay fresh. It was a useful guide rail to ensure we stuck to the mission of avoiding anything dexterity related.

And I’m proud that a bunch of mechanics in the game, as a result, have ended up really different from any rhythm game out there, but in a way that still reflects elements of rhythm used in popular music.

One interesting side-effect of the one-button focus is that our game mechanics were easier to translate into being blind-friendly, since there are no button prompts to watch for. So now we decided to have a second challenge in making the game which is to make all the mechanics be playable blind, without ever requiring assistance from someone sighted nor memorization for any part of it. And to make that experience not feel watered-down in any way either.

Images via 7th Beat Games and indienova

The game introduces many elements of rhythm theory to the player. Can you tell us a bit about rhythm theory and how you worked its concepts into the game in an approachable way?

Azman: Most of Rhythm Doctor's mechanics are about finding rhythm ideas used in pop music and making the player feel and interact with those ideas.

How we made them approachable is easier explained through video than text, so I’ll link to two videos where I’ve done that: this one going over swing beats, and this one explaining the ‘SVT’ mechanic of pressing on the 2 and 4 and the skipped beat mechanic.

In short, it’s about identifying a particular topic of rhythm theory and then making a music track and level design that communicates that idea with a few different variations. This is similar to practice drills for playing actual musical instruments—for example: Hanon’s famous piano exercises or the Suzuki method on the violin.

What interested you about creating an experience that is educational about rhythm theory, in a sense?

Azman: I’m fascinated by so many of the ideas and building blocks that go into making a song. It’s fun for me to identify these tropes while listening to music. One of my favorite classes during my A-Levels was Music because it had listening exercises where you’d listen to a snippet of music, and it’d ask you questions about the bassline or identifying the instruments that were playing. I see our games as focusing on just the rhythm part of that.

The most gratifying thing is when, after playing this game or our other game A Dance of Fire and Ice, someone tells me “I listened to a new song on the radio and I could immediately imagine how the ADOFAI track would look” or “I could hear the SVT beats in this new song I heard”.

If the games we design can help people engage with their favorite music in a deeper way like that then I’m really satisfied.

What thoughts go into crafting visuals that quickly communicate how players will work with the beat? How do you make it so players can "see" what they're supposed to be doing with their inputs?

Labriola: At the beginning of the game, Rhythm Doctor asks the player to watch a patient's pulse move down a green EKG line until it reaches the right-hand side of the screen. That's generally on the seventh beat. It's a simple core concept, which means we had to take special care that we didn't complicate or muddy the visuals with the new types of beats we would teach the player.

The goal is to get the player to feel the music themselves, whether they continue to rely on the visuals or not. So, each new type of beat has to feel clear and distinct from each other. The seven-beat pulses pop up along the EKG in a really mechanical, staccato way. By contrast, the two-beat "SVT beats" form a big bubble on the EKG and then slide across the screen smoothly. Then, our "held beats'' require the player to hold the spacebar, so each pulse builds up tension before popping up. There's huge red X’s where the pulses are silent, and even pulses frozen in ice to show that their timing will be delayed.

All of these animations and visual changes are there to teach you how it should "feel" to keep count in your head. It should feel staccato, or should feel like a sliding call-and-response, or it should feel like a building of tension. They also have to all look distinct so that players can play a level with four EKG rows running simultaneously without them all looking the same.

Images via 7th Beat Games and indienova

What thoughts went into the game's audio? How do you craft songs that feel good to play a game to? How do you craft beats that make for compelling gameplay?

Azman: The unique aspect of audio in music games like Rhythm Doctor is that, rather than the song reinforcing the level’s mood or themes like it’d be for most games, the song itself is the level. There are a few requirements for the song as a result: it has to introduce the musical gameplay mechanic in a clear way and evolve that mechanic throughout the song. There’s a lot of bouncing between the level editor and our music programs while a new level is being made.

We also have to think about the overall intensity graph of the song over time. For boss levels, for example, we may want the intensity to continuously build up to a big climax. This is not just for mood like it would be in other games, but also for increasing the difficulty for each phase of the boss because more intense and complex music generally would have trickier beats for the player to hit.

Likewise, what ideas go into the various musical stories that these songs tell?

Labriola: We come at the stories from a couple of different angles. Sometimes, they come song-first. Like how Act 2 ends with a very "radio" pop love duet and Act 3 ends with a Broadway-style musical pulling from shows like Les Misérables. So, in cases like those, the style of song influences the story and how we want the characters to be pouring their hearts out.

In other cases, we pull from life, thinking of ideas that are always on our minds or things that we see our friends and peers going through. So, we put the characters in this very strange setting (an understaffed musical hospital) and use that to explore burnout, creativity, career stress, self-worth, and all sorts of things.

In real life, hospitals feel like places where a lot of different struggles collide: struggles with technology, struggles with our own habits, struggles with work-life balance, struggles with hierarchy, and struggles against actual physical pain. It lays it all bare in a very direct way. I don't think we could ever run out of ideas for stories to tell in a setting like that.

What drew you to add a level editor to Rhythm Doctor? What challenges did you face in crafting systems where players could bring their own music into the game?

Labriola: During the game's "beta" phase, when Hafiz was emailing players prototype levels via newsletter, there was a poll to gauge interest in different game features. One of the options on the poll was a Level Editor, and it was an extremely popular choice. I think there's just a very big demand for being able to make your own stuff in games these days. You could practically sort all rhythm games into two categories: ones that have a Level Editor and ones that don't.

When Hafiz and Giacomo rolled out the early beta version of the editor, it became popular almost instantly. Even in its most basic form, players were using it to tell their own stories, make their own game mechanics, and do wild animations. Each time we released a new beta of the editor, players would raise the bar with what could be achieved in a level of Rhythm Doctor. The community started holding their own events: level-making competitions, sight-reading tournaments, reviews and awards for different level categories. At this point, players can even import new characters and also write their own code for conditionals that affect the gameplay.

In a sense, it's almost a blessing and a curse. By the time I joined the team, fan-made levels had reached the level of quality that the official levels had. That means for players who play community levels, all of that work is the measuring stick that our own canonical updates will be held against.

It's something we have to keep in mind when we make levels for the game: does this match, or exceed, the expectations of a community-made level? Part of the fun now is trying to stay one step ahead of the things our players have come up with.

Preciado: Making the level editor started as a fun and useful addition to the game because people could make levels and also the level designers like Hafiz could iterate much faster, speed up development and come up with better ideas. But as soon as you start making a tool not just for devs, but for everyone, you have to take into account every conceivable action the tool can do—for example, how many patients you can allow per level or which kind of audio formats we will allow for playback. And this really makes development time much longer. It’s totally worth it though; people have made really incredible levels. Shoutout to every one of you!

Users will really test the limits of the editor, doing things like trying to make a 1 hour level with tens of thousands of actions, or use stuff we’ve overlooked to their benefit. For example, there’s a feature that allows people to set the opacity of a patient. This value was originally programmed to be used between 0% (invisible) to 100% (completely opaque). But people soon found out that if you set a value of 150%, the sprite looks brighter, a particular effect that some people really liked and used to their advantage. We now had a problem. Years later we wanted to update this code but we now had to take this glitch into account, otherwise we would break all the levels that were using this “feature,” so we had to bake in a specific exception to allow for this, officially.

The other part you have to take into account when making an editor is that the person that is going to use it is not a developer. This means that you have to make it in a very intuitive way so that a person that may never have used a rhythm level editor is going to use it. Also, for example, everything has to be localized to every language available to the players, and it must be taught in a way that it’s fun to use while being relatively bug-free (to anyone that is a hardcore user, I know it’s buggy, but we try to make it stable enough!). We are extremely grateful for all the users that have reported thousands of bugs, improvements, and feature requests, as well as those have helped us to overcome lots of problems, and made the editor a much, much better tool for everyone.