Throughout the class we've learned many things about game design. We've learned how design in game is not random, and how character design can entirely change the perspective of a game community. We've learned to watch out for certain behaviors within game design groups, as well as to watch out for falling into production traps. We've learned how games target certain audiences, and how there are audiences just waiting for games to be made for them. We've learned how to keep things in perspective, and to not be stubborn – to try many things as well as let go of many things. Most importantly, we learned how to make our games fun.
The design process began with the brainstorming of an idea. In class we gained ideas that went with the no-killing constraint, and learned how games can both serve a sort of purpose as well as act as a type of social commentary. Monopoly was a game that taught how in a monopoly a single player wins and the other players often play a slow, unhappy demise as the winning player acquired all of the properties. In our game, we aimed to make the same type of social commentary – getting drunk can get you in trouble, but you still do it because it's fun.
After developing a basic idea (running around drunk, avoiding police and pursuing strange misdemeanors) we began to develop gameplay characteristics. We kept in thought the audience we were aiming for, and what sorts of gameplay elements would allow players to enjoy our game. Certain elements were deemed as possibly too frustrating for the player, or perhaps out of scope for our game and possibly conflicting with the basic gameplay idea we began with. Soon after, we began to develop our prototype, prioritizing the gameplay elements deemed most important, and letting the possibly conflicting elements fall to the bottom of the to-do list. We presented as many ideas as we could think of while trying not to grow too attached to any single one in an attempt to create a game that would work. We kept in mind the basic allowances and feel we would have for the game, but unanimously decided that it would be impossible to tell how “fun” a game would be without an actual prototype. The game passed the paper playtest (another handy skill we learned), showing as a rather mild but feasible game, so we moved on to programming.
In designing the game, my group struggled with the perceived as well as actual allowances (to use Don Norman's terminology) of the game. We wanted the players to be able to pick up the game and play, without hitting any major walls. In order to do so we had both learning by visual clues as well as direct verbal instruction. We let the player learn that by moving the world moves and the player stays stationary. We also let them know by direct text on the screen what certain elements were and how to play, such as avoiding police and the drunk meter. Blinking lights and warning symbols were placed on police as well in order to give the players a sense of danger. Some perceived allowances came into play in the form of bugs or incomplete coding, however. For example, the invisible border blocked players while they may have believed they could walk into that area due to the open space.
As we designed the game, we continuously thought of what sort atmosphere we would were creating in the game. We decided to make the game with a strong element of exploration in order to introduce a space (namely Georgia Tech). The decision was made with the idea that our game was to be a light-hearted one, that the player's enjoyment would come from exploring the various characteristics of the space as well as the jokes played on both college life and social patterns. We aimed for, in the terms of Lazzaro and Keeker from XEODesign, easy fun.
As we continued through our design iterations, we found that the game was hard for the wrong reasons, and too easy in our ideas. It was difficult to navigate the environment, which caused us to redesign our levels as well as take another look into our coding. After the fix, however, the game was rather easy. It was rather difficult to lose even intentionally, so we made it easier to lose, as “a 100% success rate eliminates most of the aspects that make a game fun” (Lazzaro)
After several iterations of programming and playing amongst ourselves, we eventually brought in other players, including family, friends, and fellow classmates. The feedback they gave was invaluable, bringing to attention things we never had thought of before. We learned from that experience that “a good rule of thumb for iterative testing is to err on the side of observation rather than guidance. While it may be difficult to keep your hands off the tester’s mouse, instead sit back and see what your audience actually does, rather than telling them how it is supposed to work.” (Zimmerman) By doing this and getting feedback from our audience, we learned what worked and what didn't, what the player understood and what they couldn't.
To conclude, I'm glad to have taken part of this class. While various concepts of game design that were introduced in the class felt like common sense, a lot of them were rather new to me. A lot of people, myself included, understood the concept of making a game fun, but didn't understand how. Even the concepts that felt like common sense I didn't fully understand until reading about situations in which they were practiced, as well as experiencing them myself. Some concepts we didn't really get introduced to until after we had completed our game, however. For instance, my group preoccupied themselves with the story of the game and explaining why the character exists and why the player was playing the game. I felt this to be rather unimportant to the enjoyment of the game, having experienced various forms of media that offer no background information. Zimmerman writes, “Rather than asking what the game is about, ask what the player is actually doing from moment to moment as they play.” This was a rather minor point, however. I felt the most important lessons were learned: We learned to create a game with purpose, follow design practices, and what it is like to produce a game within a time frame. These lessons enable us to pursue more projects in the future with design experience and wisdom on our side.
The design process began with the brainstorming of an idea. In class we gained ideas that went with the no-killing constraint, and learned how games can both serve a sort of purpose as well as act as a type of social commentary. Monopoly was a game that taught how in a monopoly a single player wins and the other players often play a slow, unhappy demise as the winning player acquired all of the properties. In our game, we aimed to make the same type of social commentary – getting drunk can get you in trouble, but you still do it because it's fun.
After developing a basic idea (running around drunk, avoiding police and pursuing strange misdemeanors) we began to develop gameplay characteristics. We kept in thought the audience we were aiming for, and what sorts of gameplay elements would allow players to enjoy our game. Certain elements were deemed as possibly too frustrating for the player, or perhaps out of scope for our game and possibly conflicting with the basic gameplay idea we began with. Soon after, we began to develop our prototype, prioritizing the gameplay elements deemed most important, and letting the possibly conflicting elements fall to the bottom of the to-do list. We presented as many ideas as we could think of while trying not to grow too attached to any single one in an attempt to create a game that would work. We kept in mind the basic allowances and feel we would have for the game, but unanimously decided that it would be impossible to tell how “fun” a game would be without an actual prototype. The game passed the paper playtest (another handy skill we learned), showing as a rather mild but feasible game, so we moved on to programming.
In designing the game, my group struggled with the perceived as well as actual allowances (to use Don Norman's terminology) of the game. We wanted the players to be able to pick up the game and play, without hitting any major walls. In order to do so we had both learning by visual clues as well as direct verbal instruction. We let the player learn that by moving the world moves and the player stays stationary. We also let them know by direct text on the screen what certain elements were and how to play, such as avoiding police and the drunk meter. Blinking lights and warning symbols were placed on police as well in order to give the players a sense of danger. Some perceived allowances came into play in the form of bugs or incomplete coding, however. For example, the invisible border blocked players while they may have believed they could walk into that area due to the open space.
As we designed the game, we continuously thought of what sort atmosphere we would were creating in the game. We decided to make the game with a strong element of exploration in order to introduce a space (namely Georgia Tech). The decision was made with the idea that our game was to be a light-hearted one, that the player's enjoyment would come from exploring the various characteristics of the space as well as the jokes played on both college life and social patterns. We aimed for, in the terms of Lazzaro and Keeker from XEODesign, easy fun.
As we continued through our design iterations, we found that the game was hard for the wrong reasons, and too easy in our ideas. It was difficult to navigate the environment, which caused us to redesign our levels as well as take another look into our coding. After the fix, however, the game was rather easy. It was rather difficult to lose even intentionally, so we made it easier to lose, as “a 100% success rate eliminates most of the aspects that make a game fun” (Lazzaro)
After several iterations of programming and playing amongst ourselves, we eventually brought in other players, including family, friends, and fellow classmates. The feedback they gave was invaluable, bringing to attention things we never had thought of before. We learned from that experience that “a good rule of thumb for iterative testing is to err on the side of observation rather than guidance. While it may be difficult to keep your hands off the tester’s mouse, instead sit back and see what your audience actually does, rather than telling them how it is supposed to work.” (Zimmerman) By doing this and getting feedback from our audience, we learned what worked and what didn't, what the player understood and what they couldn't.
To conclude, I'm glad to have taken part of this class. While various concepts of game design that were introduced in the class felt like common sense, a lot of them were rather new to me. A lot of people, myself included, understood the concept of making a game fun, but didn't understand how. Even the concepts that felt like common sense I didn't fully understand until reading about situations in which they were practiced, as well as experiencing them myself. Some concepts we didn't really get introduced to until after we had completed our game, however. For instance, my group preoccupied themselves with the story of the game and explaining why the character exists and why the player was playing the game. I felt this to be rather unimportant to the enjoyment of the game, having experienced various forms of media that offer no background information. Zimmerman writes, “Rather than asking what the game is about, ask what the player is actually doing from moment to moment as they play.” This was a rather minor point, however. I felt the most important lessons were learned: We learned to create a game with purpose, follow design practices, and what it is like to produce a game within a time frame. These lessons enable us to pursue more projects in the future with design experience and wisdom on our side.
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
Lazzaro, N. (2004-2005) "Why We Play Games: Four Keys to More Emotion Without Story." Self-published white paper. www.xeodesign.com/whyweplaygames.html
Norman, D.A. (2004). "Affordances and design." http://www.jnd.org/dn.mss/affordances_and.htmlZimmerman, E. (2003). "Play as research: The iterative design process." http://www.ericzimmerman.com/texts/Iterative_Design.htm
Comments