Before this project, I had never imagined myself creating a teaching game. I used to associate educational games with topics that already felt academic, such as science, history, or mathematics. I assumed that a teaching game would mainly involve taking existing knowledge and making it more entertaining. What surprised me most was realizing that a game could also teach something deeply connected to everyday life. Scam prevention became especially meaningful to me because scams are increasingly common, yet many people receive very little systematic education about how scams actually work.
When designing Scamboo, I became interested in how mechanics themselves could carry the learning. Players did not simply read definitions of scam tactics. They collected and used tactics such as urgency, authority, flattery, false identity, and money rewards to scam different victims, while defense cards allowed other players to counter those tactics. The interaction among victim vulnerabilities, scam tactics, and defenses created a simplified model of how scams operate. Instead of memorizing a list of warning signs, players had to think about why a certain tactic might work on a particular victim and what kind of response could interrupt it.
One of the most important things I learned, however, was that making information visible in a game does not necessarily mean players are learning it. In one of our earlier versions, players could succeed mainly by matching icons. During playtesting, we realized that some players were paying attention to colors and symbols without really thinking about the meaning of the scam tactics. We then experimented with removing the vulnerability icons and asking players to infer them from descriptions, but this made the game too slow. Our final version tried to balance these two problems: we kept the vulnerabilities visible, but required players to explain how they were using a scam tactic or defense. This small change made the mechanics feel more connected to reasoning and discussion rather than simple matching.
Watching other people play was probably the most interesting part of the project. Players often noticed problems that were almost invisible to us as designers. Some rules that seemed obvious to us were confusing to first-time players, and some elements that we thought were minor strongly shaped how people played. I began to see playtesting not as a final check, but as part of the design process itself.
The project changed my understanding of educational games. I now think a successful teaching game is not a lesson with fun added on top. Ideally, the learning should emerge from what players repeatedly do, decide, explain, and experience through the mechanics. Going forward, this is something I want to carry into other learning experiences I design: instead of asking “what information should learners receive?”, I also want to ask, “What should learners actually be doing in order to learn it?”
