Prior to taking CS 377G, I was quite interested in games and game design in general, but had not truly formalized my knowledge. I took CS 146 and built a game during that course, but that was the extent of my game design experience, and much of my efforts and learnings in that course were centered around building a video game rather than game design principles. Nonetheless, I did come into CS 377G with a fairly solid intuition for game design, having been an avid player of both video and board games nearly my entire life. I was initially worried that there would not be enough novel material for me in the course, but this proved to be untrue; CS 377G taught me several new game design concepts and solidified my existing knowledge.
I felt that the readings, combined with applications in projects, made for an effective learning experience. One particular example that stands out is the MDAO reading coupled with P1. I had scarcely heard of the MDAO framework before, despite it being a standard paradigm in most designers’ toolboxes. I’d certainly never thought to reverse the order either. Conceptually, I believed that a game’s mechanics were its defining characteristic, and that all other aspects of the game were auxiliary. The MDAO (or OADM) reading changed my perspective on this, particularly when I made a concerted effort to apply it to P1. Having a learning game made the Outcome easy to decide: we wanted players to learn about earthquake safety. Deciding on the Aesthetics was entertaining and fairly easy, as we didn’t need to be too specific; we wanted panic and companionship to play a role. Dynamics felt similar to Aesthetics, which perhaps indicates I could solidify my learning there. However, by the time we got to the Mechanics, they almost seemed to write themselves. Being able to use our Outcome, Aesthetics, and Dynamics as a roadmap made it simple to decide which Mechanics were in keeping with our vision and which weren’t. The end product was not just a jumble of interlaced mechanics. It was a cohesive, fully-realized earthquake survival game. In creating future games, I will absolutely reference the OADM approach, especially in the ideation phase. I’d be particularly interested in applying this approach to a video game, where I have traditionally viewed mechanics as the core experience. The interesting thing about OADM is that you don’t know what you will end up with mechanically, which can make a large difference with video games especially, where implementation is a huge part of the work.
Unfortunately, I felt that my takeaways from P2 were more limited. To me, the learning objectives for this project were not as clear as P1 (create a game that teaches a topic using OADM). What I did learn was fairly specific to interactive fiction as a medium of game, but was useful in that context. In particular, I experienced the extreme cost of branching fiction firsthand. Prior to this class, I had a vague understanding that branching narratives were costly and needed to be contained. Yet in games with an interactive fiction component I still tended to criticize incomplete or unsatisfying choices. I now have much greater empathy for anyone working with interactive fiction. Even just to make my small game with five endings was an enormous undertaking, one that took far more hours than I expected. This was amplified by the difficulty I experienced in crafting a satisfying branching narrative. Initially I was stuck wanting to write a single story and felt unsure of how to branch it. It wasn’t until Chris suggested that I focus on decision points and mold the story around those that I made any headway. That was not a formalized reading or piece of lecture material, but if this assignment returns I’d certainly recommend it! The kinds of games I want to work on in the future may include narrative components, so these learnings are applicable, despite being more about narrative design than game design.
For P3 and P4, I worked on a single game, Recidivism. I’d already had a chance to make a game modeling a system in Christina’s CS 377I class, so I had some level of experience with the assignment. Making Recidivism certainly solidified my understanding of system modeling, however, and gave me very valuable experience in creating a high quality product, particularly when it came to playtesting. I had done very little playtesting prior to this class, despite understanding its value on a basic level. The tests I had done were informal, full of classic playtesting mistakes, and thus not as informative as they could have been. I also had not followed a single product across many rounds of playtesting, iterating throughout. Taking Recidivism through both P3 and P4 gave me this opportunity, which proved to be very educational. I was able to apply most of the numerous readings we had on playtesting in my own playtests, usually to much success. I do wish that we had read the article on the different “stages” of playtesting earlier, so that I could have experienced the early “core mechanic” playtesting as well. In future games, I will return to these readings as I draft playtesting plans for what I will test, how I will test it, and what I hope to learn.
Overall, CS 377G gave me a bevy of new tools, and greatly improved my grasp of those I already knew about. Many of the readings were essential for achieving this learning outcome, as was the constant hands-on project experience. I leave this class feeling empowered, inspired, and enabled to design and create more games, serious or otherwise.