Before this class, I thought that game design was primarily about innovating new game mechanics and overly technical. My initial impression was that every game was programmed “from scratch,” leaving the game designers to create their individual game engines. Previously, I have heard of Electronic Arts’ Frostbite engine that powered popular titles like Battlefield, the Unity game engine which gave us hits like Pokemon Go, and Activision’s IW game engine which is responsible for Call of Duty. I thought the narrative component of a game was viewed as an afterthought in the eyes of game publishers. Like a cosmetic weapon skin having a negligible effect on gameplay, I thought that the narrative and art style simply covered the mechanical skeleton that lies at the heart of each new game title, differentiating it from the sea of similar games within the same genre. I believed it was the game designer’s sole responsibility to invent a new successful game genre.
Throughout the course, I was able to build both an analog and a digital game with a team, from concept ideation to high-fidelity prototyping. I learned how play is not restricted to one domain, but can be found in a variety of formats, and how it can help build entire worlds through its narrative potential. The stories presented in games have been adapted to the big screen, such as in the case of Mortal Kombat, Uncharted, and The Last of Us.
Game design moves quickly. Designers must cost-effectively test their ideas, using prototypes to playtest with their intended audience to find ongoing pain points and possible modes of improvement. It was hard to scrap ideas after a playtesting session; you would imagine them to work one way, but commonly played out differently after a playtest. When we originally came up with the idea of Cavern Crafter: Homebound, we wanted to build a magic combat-based, rogue-like, dungeon crawler but had to pivot towards a puzzle-based game after learning about P2’s requirements. For example, we needed to convert a Python-based puzzle game concept into a testable MVP coded in Godot in one week and in another week refine the MVP further so that it would resemble our final game. This is complicated by the fact that no one on our team has had previous experience with Godot. This fact required us to learn Godot independently using freely available resources like YouTube tutorials. Not only did we learn and get hands-on experience with using Godot to build a 2D top-down RPG, but we also learned how to teach ourselves a new skill (programming in the Godot game engine) and how to research relevant information about any bugs/issues we encountered.
Conflicting feedback from different playtesting sessions complicated things further, as in the case of my P1 project, WorryWrecker. We would build a prototype, playtest it, be asked to change some game mechanics, implement the changes, playtest it again, and be asked to revert exactly what we changed in the first playtest. It was difficult to balance our team’s thoughts with the conflicting feedback from different groups of playtesters, but that gave us a reason to creatively brainstorm alternative ideas that would hopefully incorporate the most pressing issue of each session into a holistic solution. We better understood the Silicon Valley phrase: “move fast and break things”, as we had to break and create anew multiple times after this class.
The seamless onboarding process implemented by games like Plants V. Zombies and Portal inspired us to try our best to introduce our players to our video game mechanics in an organic way. The lack of a dedicated “how to play” instructional screen was refreshing and shortened the waiting time for players to start interacting with the mechanics. We implemented this philosophy in our onboarding process by informing the player of the basic controls as they needed them and designing the first few rooms of our first level as intuition-building exercises that required the player to understand the new mechanic before proceeding to the next level. Specifically, we introduced the player to moveable boulders by requiring them to accidentally walk into one (and observe it move out of their way) before navigating to the next level. This boulder-pushing mechanic was central to our puzzles and accordingly introduced gradually before the first official level of our game.
Next time, I will try to convince my game design team to incorporate an intuitive onboarding experience without direct instructions that not only allows our players to jump right into the action but also removes the “studying” involved in learning a new game via game manuals. This is especially important to me as I grew up playing video games that would normally only include a short manual with relevant instructions and narrative lore which were frustrating to deal with and made me less likely to finish the game. When faced with the decision to include probability, I will also attempt to avoid any of the dark design patterns that were highlighted in the article about gambling game design which are engineered to cause addiction. I find the deception involved in such games against my ethical code. I aspire to be transparent with my players and developers so as to promote a healthy relationship between gamers and game-makers. I have noticed many mobile, freemium, and subscription-based games begin to experiment with casino-like probability mechanics which is upsetting to me.
