Jam Session is a student-pitched discovery project focused on exploring rhythm game design. Our team included one artist, one sound designer, one programmer, one game designer, and one programmer/game designer. In developing the pitch for the project, we asked ourselves, “How can we make innovative and engaging rhythm games?” To answer that question, we set out to create several prototypes of rhythm games on different platforms, including PC, VR, and using alternative controllers. The deliverables at the end of the project included several publicly-available game prototypes, as well as an article summarizing our findings and providing tips on how to create rhythm games. We’re attempting to publish this article to game design sites to inform future designers of rhythm games.
What Went Well?
Towards the end of the semester, when we were running just a bit behind on creating prototypes, our team hosted an informal “game jam” for ourselves. For a Friday and Saturday, we devoted ourselves entirely to making two new prototypes, making sure we wouldn’t be interrupted or distracted by other classes, meetings, or anything else that may have come up. This proved to be very effective, as we had developed the bones of two prototypes during that short period of time.
The team’s brainstorming methods evolved over the semester as well, helping us become more efficient and creative when thinking up and subsequently building our prototypes. We tried several different brainstorming methods, each with their own positives and negatives. At the very beginning of the semester, the team’s ideas were all over the place with no clear direction. Before long, we decided that we needed to make a distinction between rhythm games and music games, since many of our ideas didn’t have rhythmic elements. This helped the team in solidifying our goals; from then on, we decided that our official goal for every prototype was to create innovative and engaging rhythm games with an emphasis on simplicity of controls, replayability, and potential of mastery.
What Didn’t Go Well?
We had a long discussion during the middle of the semester about each person’s role within the project. Up to that point, each many changes were being made to the prototypes by each person on the team. We came to realize that this was not productive or good for the team’s motivation, as many times, team members would be surprised by the addition of or changes made to game features, music or sound effects, and art assets. It felt like each person was working to make the game they had in their imagination, rather than something the team agreed upon. After realizing that we were all guilty of this, we created a new chat channel where we would keep others up to date on changes we were each making.
The team also had some difficulty in determining when a prototype was “completed”. At the beginning of the semester, we decided that a prototype would be finished once there was nothing else we could learn from it. That meant that even if we had ideas on how to improve it in ways not related to rhythm, we would still stop working on it. This allowed us to move onto other prototypes sooner, but also added issues in playtesting. Some players thought that the somewhat-unfinished presentation of the games prevented them from understanding the “full” experience of the game. We decided that we agreed with that sentiment, so the team worked carefully to balance completeness with polish. Things like extra instructions or visual and auditory feedback helped provide that extra polish that allowed guests to understand the complete intent of the prototypes.
One other issue we ran into was dealing with overscope. During the pitch process, our team declared that we’d be making 10 prototypes. As we started working this semester, however, we realized that quantity may be difficult or impossible to achieve given the timeline and the extra focus on polish and research that we had not previously expected. We eventually decided that this wouldn’t be an issue, as those other points of focus were vital for the project to be successful. 8 prototypes with polish and more solid foundations would give us much more useful information than 10 half-baked prototypes.
Outside of the several lessons we learned about rhythm game design specifics, we learned a lot about the creative brainstorming process, quick prototyping, and working with a team with very diverse skills and backgrounds. One of the most interesting learnings was how much research was required before going into making prototypes. It turned out to actually be pretty difficult to pull ideas from out of the blue, so having a good base of knowledge on the subject of rhythm games helped our team significantly.
We also learned that different forms of brainstorming lead to vastly different ideas. Our first few brainstorming sessions were focused on combining rhythm games with other genres (such as fighting games, platforming games, and puzzle games). When we realized that we were having trouble developing new ideas on top of those, we switched to a more question-based brainstorming system. We came up with design questions such as “How can we innovate on note highway displays in VR?” WIth these more strict constraints on ideas, it became much easier to create innovative concepts.
The team hopes to continue with some of the work on this project to improve it or get more publicity for it. Alongside releasing our article for publication, we’re looking into trying to show some of this information at conventions such as GDC. We’re currently researching the process of doing so. The team also enjoyed some of the prototypes so much that we’re talking about continuing work on them and porting them to other devices, allowing more people to play them. Right now, we’re working on porting Jelly Tracks to mobile devices, and we hope to build the VR experiences for Oculus Quest, giving us a wider audience. Since this information will be publicly available, we’d love for other game designers, programmers, artists, and sound designers to pick up where we left off and continue the research.