Game Design as Cultural Practice

Throughout the semester, I have learned many things about game design in this class. The class has taught me to look at games from many different perspectives. Never would I have thought that there would be so many social and cultural factors that have affected games throughout history. The final project was a test of all the knowledge we have learned in this class. More importantly, it was a chance for me to try out new ideas and work with other people to create a new play experience.

In our initial brain storm session we had a total of six different game ideas. Each game idea was constructed with a parameter of play values to target a certain type of game play(Zimmerman). Eventually we settled on the Cupid Game idea for its originality and target audience. The game industry consists mostly of males making games geared toward a male audience(P2 Hegemony of Play). We wanted to make a more gender balanced game. The central theme of match making in the Cupid Game will appeal to female players while its point and click shooting system will appeal to the traditional gamers.

I was assigned the role of lead designer and artist by the group. Having control over these two elements of the game made my work flow more fluid. A major part of the game design is the representation of character stereotypes, and the interpretation of the character trait database on the user interface. I designed the art and game mechanics around each other so they could work together to form a play experience without sacrificing much of the art aesthetic values.

I approached the art following conventional usage(Norman). High school and romance is something that everyone experiences at some point of their life. It is something that everyone can relate to one way or another. The game provides the player with different high school stereotypes to choose from during the match making process. There are a total of ten different character stereotypes. My high school had a very diverse student body, so I used pictures from my high school year book as a reference to stylize the look of each stereotype. The compatibility of the characters is based on their character traits. I used standardized symbols on the user interface to show these characteristics to the player. For example, I used the boy and girl sex symbol to show sexual orientation of the character.

After going through a couple game prototypes, we finally locked down the basics of the game. All the concepts were coming together to form the basic layout for a game. However the game was still missing the mechanics that induce difficulties into the game. It is not fun if all the player has to do is point and click to rack up a certain amount of points. The game needed a challenge to focus attention and reward progress to create emotions such as frustration and Fiero(P3 Lazzaro). Thus the love meter was born into the game to measure the progress and accomplishment of the player in the game. Every action of the player affects the level of the love meter one way or another. The love meter ties together all the different mechanics in the game, making them somewhat dependent on each other. In addition, the love meter also provides meaning to the game mechanics. As the name suggests, the love meter measures love. The power of the cupid is based on love. Therefore the power of the cupid is dependent on the amount of love power available.

Toward the later stage of the project, power ups were implemented in the game to award or punish players for different behaviors. Instead of using graphics as a cue to the power ups, sound effects are used. At any given time on the screen, the game has a lot of movements. The player has to constantly examine the character traits in the user interface and look for the right characters to make the best match possible. Adding sufficient graphics to represent power ups on screen would make the screen too busy. As a result, the sound effects add a very humorous touch to the overall sound texture of the game which contributes to the easy fun of the game(P4 Lazzaro).

Play testing was absolutely vital to the formation of the game. This is due to the fact that the Cupid Game relies heavily on a complicated database system. The feedback from all the play testing inside class and outside of class helped us to refine the game. It was absolutely frustrating to watch a player playing our game looking really confused and bored. Many times I was very tempted to step in and show the player how to resolve the situation in the game myself. On the other hand, the observation of the player’s reaction is exactly what the group needed to tweak the game(Zimmerman). Many new features were implemented due to the result of the play test to simplify the game for the player.

Even though the Cupid Game did not completely live up to our vision, I feel like we have created a solid frame work for a game that has many unexplored potentials. The game may lack certain things as a single player game, but it may fulfill its potential as a social game on social networking sites such as Facebook. Additional features would have to be implemented in the game such as a llowing the player to match people up on his/her friend list. People will get a notification when they get matched up with someone else and they can comment on it. Overall the making of the Cupid Game has taught me many things about game design. I am going to use what I learned in this project and apply it to future game projects.

Fron, J., Fullerton, T., Morie, J. & Pearce, C. (aka Ludica) “The Hegemony of Play.” In Situated Play: Proceedings of Digital Games Research Association 2007 Conference. Tokyo, Japan, September 2007. http://lmc.gatech.edu/~cpearce3/PearcePubs/HegemonyOfPlayFINAL.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.html

Zimmerman, E. (2003). “Play as research: The iterative design process.” http://www.ericzimmerman.com/texts/Iterative_Design.htm

Here is the link to play Nightmares:

http://harrisonleach.com/Nightmares/

Design Documentation

When our group first met, we came up with five or six completely different game ideas, ranging from a balloon blowing game to a platformer, to a matchmaking game. It was the idea for a game that exploited peoples traditional knowledge of highschool stereotypes, and of relationships, and forced them to realign them more with reality, to look at the underlying traits of characters, and at what it really takes to make a relationship work. It was with that concept in mind that our group sat down to work on this game and to fit together all of the pieces that would later become Cupid Academy.

One feature that did not make it into the game, but that was initially discussed with quite a bit of gusto, was that of making it a multiplayer game, where you made your own character with your traits and it wondered into other players games, where they would match you, and see how well the couple lasted. This feature would add a whole new dimension to our game, that of social fun. Players would use this game “as [a mechanism] for social interaction.” Unfortunately, the amount of work that would require pushed this feature far outside the scope of this project, and so we moved past it.

Unbeknownst to ourselves, the way our team developed the game was definitely an iterative process of design. The games progress mirrored Eric Zimmerman’s projects almost identically. Like Eric’s LOOP, our initial prototype was quite ugly, and only tested the core mechanic of With only poorly-drawn stick men, the game was almost comical in how bad the appearance was. However, it attested to the strength of the core game mechanic and how well the core game mechanic matched up with the scientific backing it had. The character behaviors and compatibilities enabled the user to make matches based on the characters personality as opposed to the stereotypes. However, again like Zimmerman (although this time his LEGO Junkbot), “We played that first prototype. And it was not very fun.” I knew I would have to make changes to code to allow for more interactivity between the player and the game model. The problem at the time was that our game had little “percieved affordance”(norman). While a player could click and shoot a character, there was no way for the player to know who he or she had shot, and forced the user to remember it and keep track of it. After our first playtest, we got overwhelming feedback that that was an overwhelming task for the player. We came up with a long list of new elements, and as Zimmerman said, “each new element addressed something that was lacking in the experience of the previous prototype.” The most effective of these elements was the blue glow that surrounded a character when you had him or her selected, the red glow that appeared when you had shot a character, and the overlapping stats bars that appeared once you shot a character and selected another. These elements drastically diminished the amount of un-mechanic related challenge that the user had to handle; it reduced it almost to zero, in fact.

Furthermore, there was little to tell the player how good a match would be or to let them know what the game scores couples on. In response to this we added several attributes that significantly enhanced the users ability to enjoy the game, allowing users to have “easy fun” or an emotional state where the user is left “wanting to figure it[the game-play/storyline] out,” enticing “the player to consider options and find out more” (Lazzaro). Even though that existed, our game still had the challenge and difficulty that allowed for “hard fun”, or the emotional state where the users “play to test their skills, and feel accomplishment,” as they were “playing to see how good [they] really [are]” (Lazzaro). Players could still test how well they could match people, and how good they were at meeting the Myers-Briggs criteria. When we playtested again, however, a new heavily debated issue came up: the color of our characters skins and the sizes of the males vs females. Knowing from class how much debate race in games can cause and not having an effective way to incorporate race into the game without playing to the stereotypes we were trying to knock away, the team and I decided to keep the characters colors non-racial. The issue of males and females was addressed by the team with a firm decision towards equality in how the game handled them.

As the program came more and more together, we had to start dealing with and directly addressing the graphical interface, and the users’ interaction with it. We brainstormed as a team and came up with a system that used three out of four of Don Norman’s principles for screen interfaces. The first idea we actually got from play-testing results, and that was to add icons and bars to the screen. We choose very conventional icons so as to convey each bars meaning as clearly as possible. The second change we made was by using metaphor to show that clicking was similar to Cupid’s shooting of an arrow. It conveyed the games purpose and concepts very quickly, since most everyone in America is familiar with cupid. The third way was by adding text, and explaining what everything did.

As the game came together, and more and more aspects were fleshed out, it became apparent that our design had come along way from the beginning idea. Each and every core aspect of the game, and indeed the idea behind the game itself, had changed because of something we learned in class, or saw demonstrated in our or another groups’ playtesting in class.

Works Cited

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.html

Zimmerman, E. (2003). “Play as research:The iterative design process.” http://www.ericzimmerman.com/texts/Iterative_Design.htm

We wanted to create a board game in the computer space, because combining the two mediums offers affordances which are not available in either by themselves. Our rules governing the acquisition of points, for example, would take prohibitively long if done by hand. In our paper prototype, it four people to play a two player game in the span of one and a half hours, which on the computer can be played in under ten minutes. We were heavily influenced by the Romany Fortune Telling Game of the Victorian era. This was a game based entirely on luck, with the player rolling the dice and moving across the board in a winding path without deviation. Each path was unique, with a different set of events found along the way. When designing Lifelines, we wanted to capture the winding path through the player’s life from the Fortune Telling Game, but we also wanted the game to be based entirely on skill, the opposite of its predecessor.

Of Lazzaro’s four keys of gameplay, Lifelines most greatly exhibits the first: hard fun. Players are playing the game to test their skill and want to feel like their actions directly affect the outcome of play. Players compete with each other to see who is better. Lifelines is entirely skill based after the initial random placement of checkpoints, requiring strategy to outwit your opponents. Throughout the game players are rewarded for their actions in the form of points which determine who eventually wins the game. Additionally, one of the tenets of hard fun is having multiple objectives. In our game we have check points and goal zones which can grant large sums of points for those who reach them, but this is not the only way to win. Under certain strategies, a skilled player can win without ever reaching even the first checkpoint. Every path has a distinct play style, and a player well versed in one path may still be beaten by someone utilizing a strategy he is not familiar with. Of course, Lifelines also embodies

From personal experience and through reading DeKoven’s The Well-Played Game, we know that a game is much more fun if players are more evenly matched. Even though some of our paths turned out to be much more powerful than others, the game could be easily adjusted to suit individual player skill through the options menu, for example, if a player is consistently winning, players can choose to limit that players action points per turn to give that player a game balancing disadvantage. The strategy aspect of the game may be too complicated for some players, and they may have more fun without the low limits on action points. Lifelines plays entirely differently with changed parameters.

WORKS CITED

Lazzaro, N. (2004-2005) “Why We Play Games: Four Keys to More Emotion Without Story.” Self-published white paper. www.xeodesign.com/whyweplaygames.html

DeKoven, B. (1978) The Well-Played Game: A Player’s Philosophy. New York: Anchor Books.

While creating our game, The Cupid Game, which is a match making game where you are graduating from the Cupid Academy, but you must still complete your final assignment by going to a real high school and testing out what you learned, my fellow group members and I tried to take in to account many of the readings that we had looked at during our class.  What we tried to do was to create a game that would be as unique as it would be fun, and also a game that broke many general stereotypes that exist in many games as well as in the real world.  One of the major stereotypes that we tried to completely remove from our game was racial stereotypes and the fact that the majority of video games today are “made by white men, for white men” (Pearce 3), a feat that we did by making all of the male characters in the game blue and all the female characters were pink, eliminating any specific ethnicity from being in the game at all.

One of the readings that we used during our extensive design process was Nicole Lazzaro’s “Why We Play Games: Four Keys to More Emotion Without Story.”  What we took from this reading was that there is more than one way in which to make a game fun and entertaining.  One of the Lazzaro’s “keys” that we tried intently to employ into our game was the “Easy Fun” key.  While trying to implement this, though, we found that, given our time limit and aversion to wanting to add too many elements to the game, it was very challenging to get this done.  One of the main problems that we encountered on our way to this was the fact that the vast majority of our core game mechanic was based around the Myers-Briggs personality and compatibility tests.  What this did was it meant that we were determining a character’s personality and compatibility with other characters using the traits extrovert/ introvert, sensing/ intuitive, thinking/ feeling, and judging/ perceiving, which, at a quick glance, seem very ambiguous and hard to understand.  In order to fix this, though, we decided to change these traits on the visual level into traits that are much easier to understand right of the bat, and we changed them to sociability, creativity, intelligence, and tolerance, respectively.  In the end, we believed that this would allow the game to become much easier to just jump into and play (Lazzaro).

Even though we spend a great deal of time trying to make sure to employ the “Easy Fun” key, something that we failed to realize was that our game also implemented Lazzaro’s “Hard Fun” as well.  The reason that our game includes this key is due solely to the fact that the entire back end of the game is based around the Myers-Briggs tests and the fact that, in these tests, comparisons are not always made from exact matches, but in fact, the best matches are often made between those with completely different personality traits, meaning that creating a match in the game requires much more skill than you you initially think (Lazzaro).

Another aspect from our readings that we used to a great deal during the design and implementation of our game was the idea of iterative design, in the sense that we used “play testing throughout the entire process of design and development” (Zimmerman).  The reason that our game required that we do play testing throughout the entire process was because of the fact that there were a multitude of variables that we needed to take into account while playing our game, such as how many points does an arrow shot cost, how many points is a good match worth, or an average match, or a bad match, and how many points do you lose when a couple breaks up, and how many points does it take to win?  These were just but some of the many variables that we had to take into account while making our game in order to make sure that our game is fun but also at the same time to make sure that the game stayed challenging.

Through play testing though, we did not just fix variables and scoring.  We also used play testing as a way to figure out if there were any features that either the game had that it should not have, or features that the game did not have that it should have had.  Some examples of this are the fact some people who tested the game for us mentioned that they did not like the fact that once you clicked on your first character and then scrolled over another character, there was no way for you to know which character you had previously selected or what their stats were.  To fix this, we added a glow feature where the character that you selected would glow red, and any other characters that you scrolled over would be highlighted in blue.  We also added that, once a character was clicked, their stats would stay shown on the interface and any new character’s stats would be shown on the bottom half of the bar so that you could quickly compare stats between the two characters.

Works Cited:

Fron, J., Fullerton, T., Morie, J. & Pearce, C. (aka Ludica) “The Hegemony of Play.” In Situated Play: Proceedings of Digital Games Research Association 2007 Conference. Tokyo, Japan, September 2007. http://lmc.gatech.edu/~cpearce3/PearcePubs/HegemonyOfPlayFINAL.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

Zimmerman, E. (2003). “Play as research: The iterative design process.” http://www.ericzimmerman.com/texts/Iterative_Design.htm

When thinking about what kind of game we wanted to make, we wanted to focus on making something that was fun and something that felt new, not necessarily something that was challenging. Our original design for Tethered Together had a more open-ended design and included a lot more exploring of levels than what we currently have. The idea was similar a three-legged race, or Knots, which is described “Sustainable Play”, where one could have fun by being bound to someone else and asked to accomplish something.

The game introduced a cooperative concept that was not usually seen in games, one where constant communication and teamwork is required in literally every step since you cannot stray too far from your partner. Whether the person you were playing with took the game seriously or not, the team’s success was dependent on the conjoined effort of both players. No one player could do “most of the work”.

Our original concept involved the characters being brothers, but looking at the distinction between males and females in “Hegemony of Play” we made them a married couple instead. We also gave them androgynous names like Alex and Jamie, and don’t clarify which of the two characters on screen is the husband or wife. Similar to how Samus Aran was in a suit in the original Metroid, players played her like they would any other action game, which could probably only be accomplished when the female’s identity is hidden. When it becomes apparent that the character is female, the temptation to make their attire revealing usually presents itself (although since our artist was female, that probably wasn’t going to happen). The gameplay also attracted people of both genders because of the focus on having fun and working together instead of defeating anything/anybody.

We also wanted to get away from the serious nature that many popular games today seem to have. We created a story that is completely nonsensical and filled the game with bits of humor to make exploring the levels more interesting. We felt that having characters whose only goal was to steal things would make them a bit too one-dimensional, and they probably wouldn’t appeal to many people if that were the case. So having a silly story kept people interested in the reason behind why everything is happening, but never detracted from the gameplay, which allowed the players to have the best of those two elements without them clashing with one another.

When we were playtesting our game, referring to the “What’s My Method” reading was helpful in distinguishing the elements that create a good game user-testing case versus a user-testing case for a piece of productivity software. We had to look at things such as whether the process of playing the game was fun and not focus on whether they could easily reach the desired outcome. We found that even when the levels were a bit hard for their first time playing the game, they didn’t mind because of all the fun they were having, so we knew that we were successful in creating a good game based on that feedback.

So drawing on the readings, and the types of games we talked about in class, we were able to create something that felt original in the way it is presented, the story it tells, the way the mechanics work, and the overall experience you have after playing it. It would have been too easy to create something that is similar to the types of games that saturate the popular market today, but it was more rewarding to do something different so that we could be reminded that we don’t need the elements that are in those games to make a game fun.

Fron, J., Fullerton, T., Morie. J. & Pearce, C. (aka Ludica) (2005). “Sustainable Play: Towards A New Games Movement for the Digital Age.” Digital Arts & Culture Conference Proceedings, Copenhagen, December 2005. http://lmc.gatech.edu/~cpearce3/PearcePubs/DACSustainablePlay.pdf

Fron, J., Fullerton, T., Morie, J. & Pearce, C. (aka Ludica) “The Hegemony of Play.” In Situated Play: Proceedings of Digital Games Research Association 2007 Conference. Tokyo, Japan, September 2007  http://lmc.gatech.edu/~cpearce3/PearcePubs/HegemonyOfPlayFINAL.pdf

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

Natural Rivalry began as a simple capture game between two characters, or one character and AI, and conceptually evolved into a non-combative real time strategy game with many facets including, but not limited to, controlling animals individually for bonuses, having animals impact the play of the characters after being captured, and having the world change dynamically as the game progressed. These were all ideas that were based on a game of larger scale with around twenty animals on a larger level as opposed to ten in a small arena. For us, this game had as much hype as Duke Nukem: Forever. I think our design was brilliant, but beyond the scope of this course. A platformer would have been a much safer bet, but go big or go home, right?

In the later stages, the game regressed to its initial inception of mediocrity. When we prototyped this game, it was awesome. Unfortunately, I don’t think any of us realized that the scale of the game was not well suited for flash. We designed the game with a full professional game engine in mind, and not just our 800×600 2d scenario. Many of the original concepts did not make it to the game because of the constraints of the engine and aesthetics. In summary, great ambition leads to great games and failed deadlines. (see Blizzard) But enough on dwelling upon spilled milk, it’s time take a look at what great feats we did achieve.

An aspect of design that was kept in mind was the rules of what makes a game entertaining that were set out by a lot of the earlier readings in the class. The threat of defeat at the hands of the other player makes our game fun when playing with another player, and the ability to interrupt the other character’s progress by releasing the animals in the opponent’s pen provides a type of childish mischievous fun. The higher orders of play that could have been influenced by strategy didn’t make it to the final version, but they would have added a level of depth to the gameplay that would have made it real fun instead of very elementary fascination with just collecting objects faster than an opponent.

We liberally used Zimmerman’s ‘Iterative Design’ method of testing, analyzing, and designing. [1] I think this is something that almost didn’t need definition because of the implicit nature of this method in developing games that can be changed and tested very quickly. Not to say that it’s not required for games that can’t be tested very quickly, because many games have very large balancing issues, such as competitive Massively Multiplayer Online games or games like Defense of the Ancients, Heroes of Newerth, and League of Legends which rely on a huge deal of data to balance the metagame over all. These games release patches nearly every few weeks in attempt to keep the game balanced, fresh, and ever evolving. Our game in the ideal concept would need the same sort of similar nurturing, because the game would be based around player versus player action in an uneven playing field.

Aesthetically, I think our game also set itself apart from many of the current mainstream flash games by trying to communicate a pro-nature scenario if the innocent girl wins by transforming cityscapes into something influenced by nature, but also providing an alternate dystopian outcome for the scenario of the corporate businessman winning the game. This is a small victory and actually turned out quite well in terms of victory conditions and giving the game a sense of progression for winning. Many games just fall off when they end and there is no real sense of victory for the player other than the satisfaction of beating another person in a game. Our victories provide a sort of illusion of change happening in the world of the character as a direct result of the interaction of the player. Many games lack this sense of accomplishment when dealing with player versus player interaction, and merely focus on the aspect of combat or dominance.

I also think our game addressed one of the issues discussed earlier about maintaining gender neutrality in game. The game focuses on gathering, which in the readings was considered to be a playstyle that catered to females, but our idea of adding in a sense of strategy would also manage to attract the male audience because of their deep fascination with strategy games. The real time strategy culture is one of the most male dominated of all the gaming genres. Providing playable characters of both genders also allows for the same gender neutrality, but one change that could have been implemented would be to choose a gender for each stereotype, so that the innocent child could be male or female and the corporate businessperson could be male or female. For example, say a young boy would not want to play as a girl character, but he also would be unfulfilled by playing a corporate businessperson. Providing a young boy he could identify with would allow him to feel more at home in the game. I’m not saying that people only play characters that they can identify with; this is just a hypothetical scenario to explain something we could improve to provide more gender neutrality in our game.

Overall, I think our game could be a blast if we had the time and resources to implement every one of the strategy aspects that we originally planned, but right now it is functional, and that’s what we were aiming for at this point. The design process gave me personally a great deal of insight into other avenues of game development aside from the generic side scrolling shooters, and provides some realization of what a game could communicate if designed with a political goal in mind instead of just a repetitive game mechanic. Overall, I think this class changed my idea of what a game should be, and provides some insight into how to develop a great indie game.

[1] Zimmerman, E. (2003). “Play as research: The iterative design process.” http://www.ericzimmerman.com/texts/Iterative_Design.htm

Link to Kongregate: http://www.kongregate.com/games/shartpear/cupid-academy

Final Design Doc: Design_Doc_40710_Final

ConceptPitch: Cupid_Game_concept_pitch_edited_FINAL

Summary:

The Cupid Academy challenges traditional concepts of compatibility based on external characteristics (stereotypes) and emphasizes internal characteristics based on personality.  In order to graduate from the Cupid Academy a student Cupid must pass a final exam that is based on his matchmaking abilities.  The player takes on the role of a student Cupid.  The player must match characters based on their personality traits and sexual orientation.  The objective is to increase and maintain the level of the Love Meter, in order to pass the exam.  The player will start with the sexual orientation trait being visible by default and must create couples in order to reveal more traits.  The Cupid Academy is a prototype of a matchmaking social game designed to be implemented on Facebook.   Future online options will include the ability toinvite friends to play using their own personalized avator.  All of the couples that are matched will be notified via Facebook at the end of the game. The notification will be displayed on the participant’s feed for comments. There will also be additional features such as character customization. Each Facebook user will be able to create their own avatar with customized stats and appearances to represent themselves during gameplay.

Audience:

Our target audience includes players of online social games.  The game is designed for traditional high school teenagers, age 15 to 19. 

Narrative:

You are a student Cupid from the Cupid Academy. In order to graduate from the Cupid Academy you must pass the final exam. The final exam is a real world test of your matchmaking abilities. Your task is to match up high school students and produce compatible  relationships.

Game Play Interaction:

The Cupid Academy is a strategy based first person shooter (FPS).  The game play mechanics revolve around the underlying compatibility model, which is based on the Myers Brig Compatibility Test.  Game play utilizes concentration techniques, in order to match characters with similar attributes. A secondary shooting mechanic will use timing and agility, in order to control the player’s ability to hit the target.  Obstacles will be added to reduce accuracy and increase difficulty, by increasing the density and speed of NPCs.

Style/Presentation:

The team has decided on a 2-D artistic style that is consistent with many online social games websites, such as Zynga.  Referenced games include Cafeworld, YoVille, The Sims.  The basic UI will consist of a vibrant high school hallway background, which will capture the social aspect and movement of high school students as they move between classes. 

Prototyping/PlayTesting:

Limited prototyping has been done.  The team has done some rough drafts of the user interface below.  However, the majority of our time has been spent working out the compatibility model.  We have finalized on the Myer Brig Compatibility Test.  So far, we have worked out the compatibility model, which is illustated below:

Figure1: Basic wireframe of the user inface

Figure 2: Initial playtesting Myers Brig Compatibility Model

Figure 3: Myers Brig Compatibility Chart: Myers-Briggs-Compatibility_Sorted

Figure 4: Interim Team Status Presentation

 Architecture:

• Interactive Layer: Contains main interface, love meter, scoring, and stage for character movement.
• Characters: Contains array of characters and controls character movement.
• Couple: Contains couples array.  Tracks compatible couples.
• Compatibility: Checks the Myers Brigs compatibility of each couple.
• Orientation: Checks the sexual orientation of each couple.

Team Members/Assignments:

Tony “Dr. Debugger” Lockhart – Project Manager/Programmer(compatibility Mechanic)

1. Character Compatibility Classes
   • Compatibility class – Class containing Myers Brig Compatibility check.
   • Orientation class – Class containing comparison of character gender.
2. Character glow- Function to enable character glow on mousescroll and mouseclick.
3. Screen Loading
   • Programming transitions from Opening, tutorial, and game screen.
4. Project Management -
   • Kept track of all deliverables.
   • Kept team informed of all project deadlines.
   • Organized and posted all team documentation including concept and design documents.
   • Created/Edited in class presentations.
5. Researched the Astrology compatibility.
6. Developed initial compatibility model prior to Myers Brigs
7. Participated in a brainstorming, playtesting, and design meetings

Stephen “Angelvoice” Joy – Designer/Art(Character/UI Design)

1. Character concept art
2. Drafted character models for 12 characters (6 male characters and 6 female characters)
3. Created the grade reports at the end of the game
4. Game Art
   • Created Heart icons for break-up, match not allowed, good, bad, and normal matches
   • Created an Arrow to display clicked character (may not make it in to the game since the glow seems to work fine)
   • Created the Obstacle characters
   • Created Win and Lose Screens
5. Sound
   • Assisted in creation of several sounds for different events in the game
6. Team stuff-
   • Participated in brainstorming mechanics for the Myers-Briggs test
7. Design
   1. Helped design core game mechanic
   2. Helped to decide on power-up abilities
   3. Created/Edited powerpoints for in class presentations
   4. Motivated teammates to actually get work done
   5. Worked with the coding team to integrate code with art
   6. Troubleshooting visual design issues (adjusting how it looked in the game-play)
       and game tuning

Jack “The Bard” Tang – Art Director (Character/UI Design)

1. Character Models -Created 16 character models(8 males and 8 females for eight character stereotypes)
2. Game background art
3. Game status side bar art
   • Title
   • Love meter
   • Character trait bar
   • Character trait icon
   • Compatibility meter
   • Assisted with  layout design
   • Score
   • Sexuality sign
   • Title screen art
   • Tutorial screen art
4. SoundEffects
   • 4 event sound effect: shooting arrow, good match sound, bad match sound, and average match sound
5. Writing
   • Wrote the theme song for the game
   • Wrote outline for game mechanics
   • Wrote the game narrative and general game premise
6. Helped to design core game mechanics
7. Character animations

David “Big D” Donahue – Programmer (Dialogue Display/Shooting Mechanics)

1. cupidGUI class
   • implemented the display of the current character’s stats (gender, preference, and attributes)
   • love meter
   • score display
   • compatibility meter
2. Base attributes for all character stereotype
3. Integrated majority of the gui into the interactive layer class

William “The Bishop” Bishop – Lead Programmer (Character behavior)

1. Created and Coded Character Class,
   • Character Movement and Behaviors
   • Trait Randomization Algorithm
   •  Character Generation and Spawning
2. Created and Coded Couple Class
3. Coded pop-up(heart) creation and movements
4. Integrated and optimized Tony and David’s code with the main game file
5. Created and Coded Obstacle (“teacher”) Class,
   • Obstacle Generation
   • Obstacle Movement and Behaviors
   • Coded obstacle removal
6. Created and Coded Game Logic Classes
   • Occlusion, Scaling, scroll over, shoot, breakup behavior
   • Dynamic Obstacle SpawningGame Debugging
7. Coded power-ups
8. Added Sounnd
9. Coded fade out of compatibility meter
10. Game Debugging
11. Coded power-ups
12. Added Sounnd
13. Coded fade out of compatibility meter

Don Norman mandates that designers should “follow coneventional usage, both in the choice of images and the allowable interactions” (Norman). I find this statement to be interesting because in a sense, the process of designing a game was very conventional. For example, the game that our group developed was mandated to be developed for the Flash platform. The constraint of making a game for a particular platform served as a limiting factor that resulted in a very specific kind of game. Since Flash games are meant to run in web browsers and conserve data transferred, we produced a game that was not graphically intensive and played much like conventional console games of old where resources were limited.

Another convention we used in design was the control mechanism we implemented. Often, computer games are played with a mouse and keyboard. Our group followed this convention by using standard keys for motion (WASD and the arrows). On one hand, the arrows serve as a standard that result in the player being able to learn how to play the game more quickly. On the other hand, the control mechanism implies that moving characters are present in the game, and that they move in four directions.

In asking the question what is a game, Salen answers that “a game is a form of art in which participants, termed players, make decisions in order to manage resources through game tokens in the pursuit of a goal” (Salen, 196). Important in this statement is the remark that a game has participants, meaning more than one player. Our design reflects this notion because our group put a focus on generating a game that could be experienced by two people at the same time. We knew that we wanted our players to be sitting next to each other interacting from an early stage. We felt that a cooperative experience would help to alleviate potential frustrations that might come up when playing the game since they could learn from each other and make fun of each other’s mishaps.

In What’s My Method?, Nicole Lazzaro writes that “games and productivity offer similar interaction” (Lazzaro, 1). One can see that in designing our game, we unintentionally created a productive one. As the player navigates the space presented before him or her, the player gradually learns that collecting objects results in positive outcomes such as the flashy complements and the eventual “win state” of the game. The game is productive specifically because the player feels the need to complete tasks and “finish” the game.

Our design process is reflected in the final game. During development, we were intent on creating a sense of accomplishment in the player whenever a difficult puzzle was solved. Level design focused on gradually teaching the player simple mechanics so that those simple mechanics could be used later to execute  more complex actions required to complete a puzzle. Overall, we felt that productivity was a natural generator of enjoyability.

Works Cited

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

Norman, D.A. (2004). “Affordances and design.” http://www.jnd.org/dn.mss/affordances_and.html

Salen, Katie, and Eric Zimmerman. The Game Design Reader: A Rules of Play Anthology. Cambridge: MIT, 2005. Print.Salen, Katie, and Eric Zimmerman. The Game Design Reader: A Rules of Play Anthology. Cambridge: MIT, 2005. Print.

Zimmerman, E. (2003). “Play as research: The iterative design process.” http://www.ericzimmerman.com/texts/Iterative_Design.htm

A few months ago,  I embarked on a journey with the Smoking Duck Squad(ron). We set out to create a game heavy in art and narrative, but also one containing a strong central mechanic. What actually resulted is Nightmares: a game with a beautiful art style, a fun mechanic, and an overall interesting feel and experience. There is still much we plan to implement in the near future. During my experience working on this game, I employed several useful concepts I discovered in sources recommended by Celia Pearce.

One of my particular interests was one of the most basic ones in game design – how the game affects the player’s emotions. We originally conceptualized a highly emotional storyline, and we are still considering implementing this; however, we decided to look at more core aspects of the game first. I applied what Nicole Lazzaro of XEODesign calls the “four keys to emotion without a story” (1). Because we decided on a platformer, “hard fun,” or play that allows the player to test his skills against challenges, was an implied implementation, as the player must traverse each level in attempts to find the end (Why We Play Games, 3). We developed the “hard fun” of Nightmares yet further by the addition of our core mechanic, the lucidity bubble. Because it shrinks over time, it adds an additional challenge for the player. At the same time, because Nightmares is set in a dream, we had the freedom to include nearly anything we wanted. Due to this ability, we were able to develop an intricate “easy fun” factor. In particular, we created an interesting, explorable dream world. It is a challenge to explore this world due to the shrinking vision bubble, and this seems to offer a hybrid of hard and easy fun. Also, it is easy to gain a sense of relation to the character the player controls. One the most interesting aspects of working on Nightmares was choosing music and sound to complement the dream/nightmare experience. I feel the chosen music is very appropriate, and it generally breathes a childlike and eerie feel. The sounds are subtle, but they could be categorized into more “easy fun.” The way I implemented the sounds allows for a somewhat emergent addition to the soundtrack of the game; it plays a bass bump whenever the player walks, alternating high and low bells upon removing an enemy, and a cracking snap sound whenever the player attacks. It can be a game of its own playing with the goal to keep up with the music while getting through the levels. Players may also  play the game for the reason of “altered states,” where they happen to enjoy changes in their internal states (Why We Have Fun, 4). The music is definitely a factor here, but the fact that the game can be quite scary at times is another. Often, there are moments where the player must take a leap of faith in order to continue a level. There is much hurry and excitement from the dwindling vision. I personally find the bouncing action to be stress relieving and fun due to the minimal, yet constant amount of thought it requires.

Play testing was probably the most important part of developing Nightmares. If I could not playtest the game myself or get input from others, the game never would have gotten anywhere. I studied many aspects brought to mind by Lazzaro such as usability, challenge, and how fun it is (Whats My Game, 2). The only thing in mind was the experience of the user. I monitored how difficult it was to follow our tutorial, how easily the players grasped the controls, how long an average game lasts, and some other factors. These of course developed over time. The true playtesting did not begin until we got the vision bubble to shrink. When this occurred, there were many more factors more important than the previous, such as how much it grows, how fast it shrinks, and how much an enemy hit takes away. We based our results on providing players with the ideal amount of challenge. This relates to concepts brought about by Eric Zimmerman and Don Norman. Throughout the entire development and playtesting period, we followed the iterative design process which is a “design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a work in progress” (Zimmerman). Every time we discovered a needed change, we discussed it and made the appropriate refinement. Norman’s ideas directly relate to the iterative design process. They particularly relate to the means by which we made certain improvements to Nightmares. I applied his idea of affordances to be certain players could understand how to use the player. For example, in getting the bouncing mechanic to work, I tried to visualize what button combinations would be the most reminiscent of the actual activity. I decided on holding the down arrow because it affords hitting the ground harder and thus coming off the ground (Norman). It was not until we added the animation for bouncing that the control became more of a “perceived affordance” because the child character places his bear under his feet (Norman). It gives the player visual feedback that the down arrow did something. The alteration from having no clue how to bounce to understanding it due to the animation is probably the most visible playtesting effect I have noticed in the production of the game.

Altogether, I feel very proud of where these techniques have taken me and the rest of Smoking Duck Squad. Interestingly enough, I do not believe I consciously made use of these concepts during the creation process, but rather, I discovered they were hiding in the back of my mind all along and took effect subconsciously. Regardless, I did apply incredibly useful concepts, and they immensely helped in the growth of Nightmares.

Works Cited

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.html

Zimmerman, E. (2003). “Play as research: The iterative design process.” http://www.ericzimmerman.com/texts/Iterative_Design.htm