In Battle of the Bands, I was primarily responsible for gameplay design. As noted in the writeup, the most challenging aspect of the iteration process was figuring out “how to teach players the rules.” This has been a persistent issue throughout my game design career. Whether in video games or board games, players invariably describe their initial experience as “puzzled” or “confused.” Impatient players tend to quit early on. Patient players, however, might comment after the game: “I was confused at the start, but once I got the hang of it, it was really fun.”
This issue resurfaced in Battle of the Bands. So, what exactly did I do wrong? Was my rule design too complex? Was the presentation of the rules unclear? Or was there some other underlying issue I hadn’t realized?
About two months ago, P1 (American Dream) made me realize the importance of Occam’s Razor. Consequently, for P3, I made a conscious effort to “keep the rules concise.” My rule design revolved around a system map (as shown in the figure). Any new element had to find its place within this map without making the map itself overly complicated.
Therefore, the problem likely lay in the “presentation of rules.” To address this, we experimented with dozens of methods and continued to iterate throughout the testing process, as illustrated below:
During the iteration process, what struck me most was that when I presented the system map—which I believed to be crystal clear—to the players, their feedback was quite negative. They felt the diagram was unhelpful for understanding the game and only added to their confusion.
Why was this the case? First, the diagram contained a lot of implicit information that existed only in the designer’s mind; players reading the map lacked the same prior knowledge as the designer. Second, as the designer, I considered the game’s multiplication formula to be the most important element and centered my explanation around it. However, the players cared about rock ‘n’ roll and guitars—things that had nothing to do with multiplication. This perfectly illustrates the MDAO framework: designers start from Mechanics, while players experience the game starting from Aesthetics. Therefore, designing instructions from the player’s perspective is the correct approach.
However, the psychological concept of the “Curse of Knowledge” reveals a truth: once you know something, it is very difficult to imagine what it is like not to know it. How can a designer truly design instructions from the player’s perspective? Extensive playtesting helps, but the biggest takeaway from P3 was learning to challenge the premise: Why do we need to design instructions at all?
Because my games are often criticized as “confusing,” I have a deep fear of this feedback. I always hoped that a 10-minute pre-game briefing would allow players to master everything, clear up confusion, and then play happily. But in P3, the most successful playtest was actually the one where I said nothing at all. This session didn’t eliminate the “confused” feedback, but compared to other sessions, the confusion dissipated much faster, and players quickly developed their own strategies. Furthermore, every playtest revealed the same truth: the game has four rounds (with almost identical flows). Before the first round, no matter how much I explained, players were confused. After the first round, I didn’t need to explain anything—players began to understand the game on their own.
Therefore, I realized that confusion is a normal phenomenon in games. Our goal shouldn’t be to eliminate confusion through “teaching,” but to let players jump into the game as quickly as possible and provide “distributed” assistance during gameplay (e.g., using visual design to increase the font size of key information or using colors to categorize different data). This resonates with what I learned in the School of Education, such as “Constructivism” (knowledge is represented differently in everyone’s mind; practice is an effective way to build representation, rather than one-way information dumping) and “Distributed Cognition” (utilizing tools distributed in the environment to reduce individual cognitive load, allowing people to use limited cognitive resources for more complex tasks, like a pilot using a cockpit dashboard).
Continuing this line of thought, I gradually realized the fundamental difference between Balatro and this game: as a video game, Balatro provides faster feedback on player inputs, allowing players to learn the system by observing the consequences of their actions (in contrast, in Battle of the Bands, players have to wait until the end of two phases to see the scoring results). Automated mathematical calculations mean players don’t need to focus on specific numbers, just the sensation of “increase.” Thus, Balatro can incorporate more complex mechanics and richer content.
If learning is done through “practice” rather than “instruction manuals,” video games may have an advantage over board games. In video games, valid player inputs are constrained by code. Board games, however, contain a paradox: to learn the rules, players need to take action; but without knowing the rules, players cannot judge whether those actions are legal.
In conclusion, this experiment has indeed given me a deeper understanding of “rule learning.” I will no longer fear player “confusion.” I will break the myth of “must teach them first,” boldly design games with complex systems, and distribute guidance tools throughout the game environment and the entire player experience.
