The goal of the class project was to create a game prototype, so our group set out to develop a unique idea, one that might not initially be successful because of its experimental nature. It would have to be tested repeatedly in order to make sure it would be fun. Every game development project is a research project of sorts. You have to create an idea that you believe could be fun, then test and test this idea on a group of subjects, iterating on the design as you go. In the end you can reach a conclusion about the original game concept, and hopefully have a product that is enjoyable to a large group of people. The iterative design methodology is critical to this research process, this cyclic nature allowing for multiple refining and restructuring of the original idea [4]. This production process was reinforced in the classroom multiple, and I wanted to keep it in the forefront of our game development. My personal interests lie in game design and human-computer interaction. I like to know what people enjoy, but, more importantly, why people enjoy what they do. So, with this in mind, I wanted to make sure we tested enough to discover what people found interesting and fun about our game, and how to capitalize on that to create the best experience possible.
We had two main design issues to deal without throughout the course of the project. The first was with translating the core mechanic to the player. Our project revolves entirely around the character interacting directly with interface assets in order to solve puzzles. This is non-intuitive to most players, however, so we had to develop a way to make the play mechanics obvious. In class we discussed design strategies for human-computer interaction, and the readings were also helpful in the area. Some general rules we tried to keep in mind were to follow conventions, use clear labels, and to reuse the same conceptual model throughout the game [3]. In this way it was our hope that users would clearly understand the use of the interface items and learn that mechanic quickly, then being able to move on to more complex puzzles by putting all of the mechanics together in unique ways. We implemented this by having ‘intro’ levels for each element. A wooden sign can be seen in the beginning levels that will deliver a simple message, telling the user how they can interact with the on screen object. Two other strategies we want to implement in the future are labeling each interface item (i.e. “Stamina bar!” at the bottom of the stamina bar) and also having visual feedback (i.e. a pulsing glow) when you click an interface item to drag it.
The second issue was to create a satisfying playground and aesthetic without having a story. Games will always create some kind of emotion for the player, whether it be boredom, happiness, frustration, or fulfillment. These emotions can be created without a story by introducing multiple styles of gameplay. For example, a casual puzzle can create contentedness or boredom, while a skill-based puzzle can create frustration and then accomplishment. The goal to creating an effective experience that the useful can connect with is to combine multiple gameplay styles, delivering multiple emotions [2]. To achieve this experience, we produced multiple kinds of puzzles. Some puzzles are thoughtful and slow, taking time but not being too hard, while other puzzle solutions can be seen easily but can be hard to accomplish unless you have the practice and skill. We also produced a unified aesthetic that aims to keep the spirit of play lighthearted. Eventually we would like to add a story to further pull the player into the experience, but this was not a feasible implementation for the prototype.
We finished an early build of the game for the Independent Games Festival, and were able to playtest heavily for the last three weeks going into the final turn-in. There are many sources on how to prototype and playtest effectively, and we talked about it in class many times. Lazarro nicely sums up how to develop quality strategies for playtesting:
Effective methods must be observable, salient to the player, relevant to the player’s experience of fun, apply to a wide variety of game genres and hardware platforms, and be adjustable by the game designer. [1]
Of course, we only needed a strategy for our specific game, but we found it useful to use methods that are already tried and proved. We had our game on a website early on, so this enabled us to simply send the link to a friend along with a brief feedback survey. Giving users the ability to playtest the game in the comfort of their own surroundings was probably good and bad. It gave a sense of familiarity to the player, but it also de-formalized the process, probably yielding some lesser results than we would have hoped for. However, we were still able to get great feedback and iterate on the game many times before turning in our final prototype. The main issues we heard of were the user not knowing exactly what they were supposed to do with interface objects. Sometimes it was unclear exactly the constraints were for individual objects, and they aren’t always consistent, which created user issues. For example, the stamina bar can be dragged left to right, the inventory can be dragged anywhere, but then the mini map can’t be dragged at all. These were necessary constraints for game design, but we initially did a poor job of telling the user which objects followed which rules. Eventually we should play simple animations when you click an object (i.e. pulsing arrows showing how it can be dragged).
The process for designing this game was an excellent learning experience, and probably one of the more useful projects I’ve taken part in at Georgia Tech in the past couple years. The readings were relevant and always helped me to focus my ideas and draw on a large set of tools to accomplish design issues. I was not assigned to design specifically for this project, but I am a designer and so naturally I had that design process in my head throughout the entire semester. I believe we delivered an extremely successful prototype that iterated multiple times upon our original idea, put us through a production pipeline, and allowed us to get a good feel for what the design process is all about.
Work Cited
1. Lazarro, N. & Keeker, K. (2004). “What’s My Method? A Game Show on Games.” In CHI 2004 Conference Proceedings, April 2004. <http://www.xeodesign.com/whatsmymethod.pdf>
2. Lazzaro, N. (2004-2005). “Why We Play Games: Four Keys to More Emotion Without Story.” Self-published white paper. <www.xeodesign.com/whyweplaygames.html>
3. Norman, D.A. (2004). “Affordances and design.” <http://www.jnd.org/dn.mss/affordances_and.html>
4. Zimmerman, E. (2003). “Play as research: The iterative design process.” <http://www.ericzimmerman.com/texts/Iterative_Design.htm>
Comments