Design Reflection: QUO

Posted by arussell31 on Friday May 2, 2014 Under Blogpost Assignments, Design Reflection

QUO is a game on a 2D collaborative platform where the goal is to reunite a scientist (player 1) and explorer (player 2). While they are exploring ancient ruins their time machine breaks and the scientist is sent to the past while the explorer is left in the future with the time machine. The only issue is the time machine can only send things to the past because the power source isn’t working. The two must work together to get through obstacles and find the power source to fix their time machine. Once this is done the two will be reunited in the present day.

There are several aspects that went into developing the game. We needed to consider the interactions between the players and if it was even possible to implement some of the actions. The best way we were able to approach these issues was through play testing. This allowed us to take advantage of Iterative Design (Zimmerman). Iterative design is when developers reinvent the way the game is played based on previous developments. After each play test we received positive comments and constructive criticism. Using this feedback allowed us to change our game mechanic to best fit the users. One criticism we received was that players did not understand what buttons needed to be pressed, or who was in the past or future. We fixed this issue by adding the cut scene and dereasing the number of buttons a player needed to press to navigate the game. Zimmerman said creating game is “a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a work in progress.”  we definitely discovered it is easy to come up with an idea and  hypothetically implement it but actually implementing ideas and creating a flawless game mechanic is a different story. Through these play tests and iterative design we were able to achieve a better game mechanic.

Lazarro talks about four different types of fun. They are easy, hard, serious, and people fun. Easy fun comes from exploration and creativity. Hard fun comes from overcoming challenges and achieving goals. Serious fun is when a player feels excitement over changing the environment and players. People fun is created through competition and cooperation with other users. Our game used serious and hard fun to give the user a sense of people fun. Users can change the environment to affect their own world or the other users world. They must also overcome obstacles to reach their goal of finding the power source. Through these two aspects of our game we have created an environment where the user feels “people fun” because in order to be successful the players must work together by changing their environment to overcome obstacles. For example, There is one moment in our game where the scientist is stuck at the bottom of a ledge, but the explorer is physically able to move on. If the explorer chooses to move on he will find that there will be obstacles later in the game that he cannot get through without the scientist there to change the environment. This then forces the explorer to help the scientist and vice versa. While the game was not created for “easy fun” AKA exploration and creativity, it is possible for a player to explore the environment and there are a few solutions to some of the obstacles so the user is able to get creative.

I was in charge of the background art and the item text that pops up when a player picks something up. The biggest challenge of this task was making sure my art matched the art of my other team mates. It can be difficult to make the work of several different artists look like it was made by one person. The idea of creating text popups was an idea that came after users were having trouble what to do with items or when they reached an obstacle. We used the popups to let users know the capabilities of each item and the necessary actions to get over an obstacle. For instance, there is a pillar that is fallen over in the game. If I was playing the game I would not assume that I could use it as a ramp without some sort of indication. We added a popup that appears when the user gets near the fallen pillar that hints they can use it as a ramp. We used visual affordances such as these popups and a cut scene to help the user perceive what we want them to do. It is important to give the user some guidance throughout the game without outright saying what the solution to an obstacle is. (Norman) This balance was delicate, but eventually we came up with game interactions that make it easier for players to know what to do.

Overall I feel like we successfully implemented our game and I enjoyed the whole process. I definitely believe the cut scene was a necessary and interesting addition to the game. It told the back story and helped the users understand what to do during the game. Before we implemented this idea users were easily confused and the game play became somewhat disorganized and unsuccessful. After it was implemented we realized the class liked our game much more because they understood the point and game mechanic.

SOURCES:

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://ericzimmerman.com/files/texts/Iterative_Design.htm

Tags : | Comments Off

Design Reflection: Hotel Potemkin

Posted by mvogel6 on Thursday Apr 24, 2014 Under Design Reflection

Here I’ll outline some of the design choices that the Hotel Potemkin team (D’Miria Collins, Devon Cryts, Yan Zhang, Alvina Atmadja, and myself – also known as team #sochiproblems) made while creating our game, as well as the reasoning behind these design choices.

The Unity game engine gives creators access to a multitude of affordances – and, correspondingly, a great number of actions that the designer can allow the player to take. Despite this, we decided to limit the ways that the player can interact with the world: the core mechanic is simply to walk around and click on objects, thereby either picking them up or examining them to hear voiceover narrations play. We followed the convention of WASD keyboard controls and mouse viewfinding, with left-click mapped to “activate” – the only real “action” the player can take.

This brings me to a design choice that reveals something interesting and problematic about the nature of conventions: we got the suggestion, partway through development, to switch the WASD controls from typical first-person-shooter forward-backward-left-strafe-right-strafe to so-called “tank controls,” in which A and D are mapped to rotate view left and rotate view right. In theory, this mapping is arbitrary (just as words – “signifiers,” in semiotics – are only arbitrarily connected to what they signify). WASD controls are the offspring of the first-person shooter genre, having become the norm when Quake and QuakeWorld made them part and parcel of competitive play, and they have since bled into many other genres, including ones from over-the-shoulder third-person-perspective games and games with overhead views. On top of the arbitrariness of the scheme (discounting the iconic relation of the “backward” key being lower of the keyboard, and so on), there further is no essential reason why the left and right keys should make the player strafe, as opposed to the much more natural walking pattern of changing one’s heading while still moving forward – a control scheme more analogous to “tank controls.”

However, the current WASD scheme is an entrenched convention, and we felt that the game handled less naturally (though of course this “natural” feeling is, ironically, an artificial consequence of arbitrary convention) with tank controls. Here, we took to heart the pragmatism of Donald Norman: “Those who violate conventions, even when they are convinced that their new method is superior, are doomed to fail” (Norman 2004). But if we are concerned about the fact that the typical WASD scheme forfeits being true-to-life (i.e. the way people actually walk and run) in favor of controls that allow players to kill enemies more efficiently (i.e. strafing), how can we expect this convention ever to change? Each designer is trapped in a prisoner’s dilemma – to pervert the term just a little – in that designers can screw themselves over by flouting a convention, even if it might be in everyone’s interest for that convention to be less hard-and-fast.

Our concession was the one made by many games with the WASD layout: the arrow keys offer the “tank” scheme with rotation instead of strafing, and WASD represents what WASD always does. We concluded that this path was the best one after iterating; and our iterations were not just for refining a particular bit of functionality, but rather to do design research, as described in Eric Zimmerman’s article on the iterative design process: “Design is a way to ask questions. Design research, when it occurs through the practice of design itself, is a way to ask larger questions beyond the limited scope of a particular design problem” (Zimmerman 2003).

An example of the result of one of these iterations was the addition of visual feedback shown when the player hovers the cursor over an interactable object in the game. User testing showed us that it wasn’t always clear when an item could be interacted with, or already had been interacted with or picked up; this is a serious problem for users, because as Lazzaro and Keeker note, much like productivity software, “game challenges require clear and consistent feedback” (Lazzaro and Keeker, “What’s My Method?”). The user should always know what’s going on unless there is some rhetorical reason they should not.

One further reflection: we tried to achieve a flow and tone somewhere between The Stanley Parable, which was humorous yet stately, Gone Home, which is a much more somber exploration-based game, and the irreverence and fun of games from Blendo Games, such as Gravity Bone and Thirty Flights of Loving. But how could we do that, with the minimal toolbox allowed by our limited amount of time and developing experience? We wanted, in the exploratory vein of Gone Home, to probe: “Is it possible to build emotions into games by adding emotion-producing objects or actions to game play rather than cut scenes?” (Lazzaro “Why We Play Games”). Our game is object-based; although we eventually incorporated non-player characters, they are far from essential to the experience, and the primary experience we sought was one of experiencing a space through the mere stuff lying around, inert and yet full of story, history, and meaning. This approach is not new to Gone Home – games such as Myst and Riven felt out the exploration-based design space, and games have allowed close examination of meaningful objects for decades, although this would often take place in a player’s item inventory, which is something we purposely did not include in our game so as to avoid a cluttered design.

Working on this game was a great pleasure, mostly because my fellow #sochiproblems team members were a delight to work with and consistently open to new ideas and interesting design approaches. The game is an étude – a study – and succeeds handily at that.

 

 

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). “Why We Play Games: Four Keys to More Emotion Without Story.” Self-published white paper. http://xeodesign.com/xeodesign_whyweplaygames.pdf

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://ericzimmerman.com/files/texts/Iterative_Design.htm

Tags : | Comments Off

RA LIGHT REFLECTION

Posted by vsueksagan3 on Thursday Apr 24, 2014 Under Design Reflection

RA light is an exciting mummy-themed puzzle game that teaches the player about the properties of light. The game starts when a mummy wakes up from the pyramid after the mummy has been trapped for a long time. The idea of mummy and light puzzles might be something that is completely unexpected, but we like this element of surprise. The RA light is essentially a light based puzzle game. We conclude that we would have three levels in the game. On the first level, the player will explore the reflective property of light by moving mirrors. Then they will move on to the second level where they will have to change the wavelength and frequency of the light. Third level will require the player to combine their knowledge in first and second level to complete the game.  We agree from the very beginning that we want this game to be educational and target towards middle schoolers. The game is educational because we wanted to teach the player about how light reflects and changes frequency and wavelength. We then have to think about different objects that would be appropriate for the game. We decide to add mirrors to allow the user to reflect the light beams in order to solve the puzzle. We also add gems in order to change the frequency and color of the beam from red to blue. We realize from the start that the challenge we have to face when creating an educational game is how to make the game complex but entertaining. In order to create this game, we use the principles that we have learned from Zimmerman, Lazzaro and Norman.

 

Zimmerman states the principle of iterations that,

 

“Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a work in progress. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.”

 

From this statement, we learn that iteration is very important when it comes to creating games. From the very simple concept such as the main character in the game to the complex game mechanics, iterations play a significant role that make the game more polished. THe iterative process begins in the very beginning stage when a team puts out on the whiteboard all of the game mechanics that would be a good fit in the game. Then we followed another Zimmerman’s principle  and listed pros and cons of each game mechanic. We analyze each game mechanic carefully and then refine it to get the best of out the best ones,

“Test; analyze; refine. And repeat. Because the experience of a viewer/user/player/etc cannot ever be completely predicted, in an iterative process design decisions are based on the experience of the prototype in progress. The prototype is tested, revisions are made, and the project is tested once more. In this way, the project develops through an ongoing dialogue between the designers, the design, and the testing audience.” (Zimmerman)”

 

Playtesting also has a pivotal role in the process of creating this game. Norman states that, “…what the designer cares about is whether the user perceives that some action is possible (or in the case of perceived non-affordances, not possible)” (Norman). We have learned what the player likes and does not like through playtesting. The issues that the players have during playtesting sessions are taken into our consideration. For example, the players were having a hard time interacting with objects in the game. Some players complained that some of the pushable mirrors seemed as if they were unpushable. Some did not get the sense that they were moving the objects around the game. We brainstormed and fixed these issues by attaching a base into the mirror to give the sense that it is pushable. We also outstretched the mummy arms for the player to get the sense that they are supposed to move objects around the game.

 

Lazarro states that the concept of “hard fun” often demonstrates the sense of frustration for the player. Therefore, we decide that the level of difficulty will be there but it will not be in the amount that would make the player feel frustrated. As I mentioned above, the challenge of creating an educational game is to make it fun. By “fun”, I mean creating an exciting experience for the player. Lazarro claims that easy fun means that the players would feel curious and intrigued. The environment of the game and the game mechanics play an enormous part to make our game easy fun. We have a dark room with a mysterious music playing along in the game to create a “puzzling” environment. The curiosity and intriguing aspect of the game came from the puzzles that they have to solve. We decide that we will not have an instruction in the beginning of the game because we do not want to be too “obvious”. Overall, we were impressed with the level of difficulty of the game.

 

Another important aspect of the game is the mummy’s gender neutral. As mentioned above, this game gears towards the middle schoolers. We want to have boys and girls to be able to relate to the game. Therefore, we make the mummy as the main character in the game covered in cloth and its arms outstretched forward to push the objects.

In conclusion, with great principles from Zimmerman, Norman, and Lazarro, we are able to create a game that we think everyone would enjoy. Personally, I love the moments when the players have to think about what do they have to do during the playtesting sessions. But what I like even more is when they have an ah-ha moments when they know the answers to the puzzles. I truly believe that this game can be played and enjoyed by everyone, not just middle schoolers.

 

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://ericzimmerman.com/files/texts/Iterative_Design.htm

Tags : | Comments Off

RA Light develops

Posted by aschneider8 on Thursday Apr 24, 2014 Under Design Reflection

Our group created the game RA Light.  In the game, the player takes on the role of a mummy that has escaped its sarcophagus and is attempting to also escape the tomb.  The player starts the first level next to the opened sarcophagus and proceeds to move from level to level – represented by rooms – by solving puzzles having to do with light, such as reflecting the light into the right place.  The audience focused on middle school students by teaching basic light properties such as reflection and the concept of energy level differing between colors.

The game setting follows around a mummy within his tomb.  We, as a group, opted for a gender neutral representation as a main character.  Though the final game only shows the wrapped hands of the mummy, which shows no favor toward one gender or another, the original character design that included an entire body representation also shown through as gender neutral, since the character is completely wrapped and players could easily assume the character is whatever gender they wanted it to be.  But why did we go to lengths to create a gender neutral character? Well, as Laurel reminds us, “Computer games as we know them were invented by young men…” (Laurel 23).  Game development has always been dominated by males and thus the games were created from a male perspective.  Thus, a gender-neutral character allows for either gender to place themselves into the role of the mummy without considering that it might not be representative of the player.

In addition to the game character, the surroundings were taken into heavy consideration during the creation of the game, but for different reasons. These aspects of the game design were important to me as a model designer.   Norman summarizes my experience when thinking about design in that what was important was “whether the user perceives that some action is possible” (Norman).  For example, the user could move around mirrors in order to reflect a beam of light in the correct direction.  Our original idea was to allow the players to pick up the mirror, which meant that it should be designed to appear light, and have somewhere the character could grab to pick it up. Thus, I decided a skinny pole that the player could justly assume that the mummy could pick up.   Eventually we changed the plan so that the user could no longer pick up the mirror but would instead push it.  Therefore it became imperative that the design gave the user the idea that the mirror was too heavy to pick up, and wide enough to push.  So we mounted the mirror on a thick slab with enough room on the sides for a player to conceivably put both hands on it and push.

I mentioned how we changed the process of moving our mirrors and other puzzle pieces.  This touched on another important aspect of the development of RA Light.  We went through an iterative design process that Zimmerman describes as a “cyclic process of prototyping, testing, analyzing, and refining a work in progress” (Zimmerman). Which meant for us and our game, as Zimmerman later bluntly states, meant lots of playtesting.  As others played our game, we had to refine it. When the player picked up the puzzle pieces, they could not tell how the light was affected by the pieces – which direction would the mirror send the light?  So pushing the pieces meant that the line would always be at the same place on the y-axis as the mirror and the player could see immediately how the current mirror position would affect the light.  General debugging aside, other aspects of the game also needed to be altered after finishing with various rounds of playtesting.   The theme of the game was hard to get across to the player until eventually we got enough game assets that made the player certain that they were a mummy in an Egyptian tomb.  For instance, the mummy’s hands were not part of the initial design but were later deemed necessary since the user got no other chance to decipher what creature they were controlling.

Another important aspect of the game was giving the user the sense that they were actually in an Egyptian pyramid.  As writer Caillois would say, this type of game design would be considered mimicry.  The game environment was meant to simulate, and ideally mimic, the setting of an Egyptian pyramid from the inside.  To be honest, since most players and none of us game designers had an accurate knowledge of the inside of a pyramid, the true goal was to mimic the users expected idea of the inside of a pyramid. After all, the main goal was not to teach Egyptian history, but to create an easy and relatable experience centered on an understood idea of a mummy’s tomb.  Thus, another goal of mine as a model designer was to determine what type of artifacts would be most conducive to convincing the user that they were inside a pyramid.  Certain tools, like an Egyptian shepherd’s crook were created.  The ankh symbol was used as a typically Egyptian symbol.  Some unused artifacts include a large bust of Anubis that would give a clear connotation that the setting was Egyptian.  With all these tools, we were able to convince the players that they were in a pyramid in ancient Egypt without ever saying it, and without showing shots from the outside that would more clearly display that the building was a pyramid.

The application of these lessons forged our ideas on how to create our game.  These principals came together to develop a game that was both fun for people of various ages and educational for the members of our target audience. As well, the entire process was a blast to go through and the game was exciting to see in its completed state.

Works Cited

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://ericzimmerman.com/files/texts/Iterative_Design.htm

Laurel, Brenda. (2001). Utopian Entrepreneur. Cambridge, MA: MIT Press, 2001.

Tags : | Comments Off

Potemkin Hotel Design Reflection

Posted by dcollins36 on Thursday Apr 24, 2014 Under Blogpost Assignments, Design Reflection

Our team created a first person exploration game that encourages the player to pose as a journalist and explore the Potemkin Hotel they are staying in for the 2014 Winter Olympics in Sochi, Russia. The goal is to maneuver through the hotel and its catastrophes in order to find the hotel room and get a good night’s rest. There is a narration that guides the player throughout the game like an inner monologue. The narration provides hints and funny oddities to direct the player through the game. For young adults and adults 14 and older, we hoped to provide some insight into the 2014 Winter Olympics experience in Sochi along with the political issues in Russia.

Throughout the production of our game I was responsible for the models and art assets that are scattered through the hotel. When I began creating the models for the game, I had to have an idea of what the design of the game would be like. Because we are trying to recreate the experience of Sochi, we had to consider the affordance of a bad hotel. The affordances of our hotel encourages the player to examine how bad the hotel really is. There is also the affordance of the game itself. During the first play-test, we had the issue of using the game to explain the game. We knew that we would not be standing over every players shoulder and telling them what to do. By having icons and a narrative to play throughout the game, we were able to provide a meaning to each action (Norman). When an object is clickable, a finger icon appears. When an object has a narrative attached, it shows a volume icon. There were also signs and arrows to provide clues as what the player was supposed to do next. I believe the games’ affordance is closely linked to Norman’s stance of the weight that affordances have in a game.

In addition to the narrations throughout the game, we noticed that it still was not enough to help the players we were appealing to. What if someone did not understand the Sochi references or what if they mistook the goal of the game? Based on the play-testing and our own experience, we had to find an additional way to move the player along. Here is where our poster guides come in. Throughout the game, the player sees posters that clearly do not belong in the story line of the game. When you first enter the hotel, there is the poster that introduces the controls for the game. For people who do not play games as often as others, they do not have to suffer with endless random button-pressing. As you continue you begin to see more “art work” that appears to belong inside the game. There is the note that explains that the player needs to find the owners room and their hotel key. There is also the countless arrows that are somewhat begging you to go in the right direction.

During the design process of the game, I believe that some of Lazzaro’s keys for effective play were pretty evident (Lazzaro). First, we wanted players to enjoy the game by exploring and overcoming obstacles. There was also the process of acknowledging actual Sochi problems to connect with the reality of Sochi. During play testing, every player would make comments about the game. And each player would always mention something I had never considered. Overall, I feel like the way we created the game leaves room for unlimited amounts of interpretation. What one player may not notice, another player will.

Through the process of play-testing, I honestly believe that it helped make our game what it is today. Zimmerman says, “As a game evolves, it defines and redefines its own form and the experiences it can provide for players. Through iterative play of design itself, entirely new questions can come into being.” This supports the idea that our play-testers helped shape our game in some way. For example, during the first play-test many players had the same issue of not knowing what to do. Many were content on finding different ways to break the game while others became somewhat frustrated which led to members of the group guiding the player through the game. Many play-tester also made a point about their ability to click on certain things. While some items in our games have a reaction to being clicked, like the flowers, others are not intended to be relevant, like the trash can. This encouraged the icons that we decided to add. When it came to guiding the player, we also had to account for those players who like to roam. While we encourage exploration of the hotel, we needed to direct the player in hopes that they can actually finish the game. This led to many obstacles in the game such as unfinished stairs, broken elevators, and locked doors. Because we could not anticipate what each player intends to do, the only thing we can do, as developers, is find a design that works well with our idea and the players.

When looking back on our original ideas of our projects, I can see a drastic difference. However, I can safely say that these differences have been made for the better and with the player in mind. For example, when it came to the functionality of Twitter, I wondered if it would have made the game more complex than intended. Would it have taken away from the exploration aspect? Through the constant play-testing and critique, we were able to demonstrate a fully functional game that sticks to our initial notion of experiencing Sochi during the Olympics. I feel that while we successfully got the point across that even though Sochi has its ridiculous moments, there is also the fact that they have serious issues as well. While there will always be things that we could have done to make it better, I feel that we created a strong foundation.

 

Reference

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://ericzimmerman.com/files/texts/Iterative_Design.htm

Tags : | Comments Off

Hotel Potemkin: Design Reflection

Posted by dcryts3 on Thursday Apr 24, 2014 Under Blogpost Assignments, Design Reflection

I had the joy in participating in the game called Hotel Potemkin. The game is meant to bring awareness and make commentary on certain problems or issues that have come up in Russia recently. The game is a 3D exploration based, point and click style game that uses its environment and narrations to tell a story, or create an experience. In its final stage, Hotel Potemkin is about a reporter who has come to Sochi, Russia from America to cover the 2014 Olympics. Upon arriving, the reporter is extremely tired and just wants to go to sleep. Unfortunately, their hotel seems to have numerous wacky and sometimes problematic features, forcing the player to figure out how to get to their hotel room. The earlier content in the game mostly pokes fun at problems that were in the media pertaining to strange qualities of hotels in Sochi, while the later half of the game content forces the player to realize some of the social issues in Russia today and provides a blatant metaphor for how these issues may affect Russia. The player can click to interact with items in the game, and must do so to complete the game.

Our game was focused on telling a story, or an experience, rather than focusing on providing a more game-like mechanic with clear win and lose conditions. But we didn’t start out like that. At the start of our design, we felt we needed some sort of mechanic that would drive the game forward and let the player know that they were progressing. This was before our story was taking shape, so it made sense that it needed something more to supplement the lack of gameplay. We explored ideas pertaining to something like a health bar, except we called it a frustration meter. With this concept, our game’s content was supposed to be annoying or frustrating to the player (although hopefully humorous at the same time). But with a frustration meter, we needed a penalty, and a way to reduce frustrations. We couldn’t come up with a logical penalty to the frustration meter that would directly relate to our characters situation while also still making the experience fun for the player. Although we did, at this point, come up with the idea to integrate twitter into our game. This matches the journalists that the character is based off of because they would upload pictures of weird things in their hotels to twitter to make humorous commentary out of things that were probably very frustrating to deal with. So tweeting pictures in game was going to be our unique mechanic to reduce the players “frustration”. Iterative testing and logical observations showed us that we didn’t need something that increasingly seemed irrelevant to the story; we just needed to develop our story more (Zimmerman). Although we realized this, we still wanted to integrate twitter into our game so that players could post pictures of their experiences within our game. This part became something we were designing for fun rather than something we needed to have for our game to be good and consistent. And in the end, I couldn’t figure out how to actually integrate twitter into the game, so we had to leave that idea behind.

Because our main mechanic was to just click on objects to interact, the interactions took a lot of scripting. Some games can program their core interaction and then release it into an area and it works. For our game, we had to have each item interact the way it needed to. Oftentimes it was difficult and even frustrating to script an interaction, and then watch as playtesters wouldn’t realize that it was in the range of their possible interactions. The objects needed their perceived affordances to match what the object would do in the game (Norman). This was an extreme challenge that, in all honesty, was pressured mostly by the amount of time available to work on this project. Many objects in our game could be interacted with; but there were also many that couldn’t. So once a playtester realized that everything wasn’t able to be interacted with, they would usually give up on trying to interact with everything. If we had had more time, we could have scripted almost every object to have an interaction that would match its perceived affordances.

Near one of the later playtests we put different icons on the cursor depending on what the cursor was hovering over so that the player knew which items could be interacted with. Lazzaro states that “game challenges require clear and consistent feedback” (Lazzaro, Keeker). This feedback was great for most players who were just trying to complete the game and didn’t want to try to click on every single thing, but it also took away from other players who enjoyed actually trying to click on everything. In their minds, every item was a mystery of its interactions, and I would imagine that their imagination was stimulated much more. But upon adding icons to let the players know, the mystery no longer presented itself. Since our gameplay was mostly exploration based, the icons seemed to take much of the exploration out of the game. But there were still enough interactions and a large enough space that the player could feel successful in exploring. For this reason, our game speaks more to player who like easy fun and enjoy emotions of curiosity while playing games (Lazzaro). Although at some points through our design, we had tried to add more difficulty to the game to appeal to other types of people, it ended up seeming unnecessary and would almost seem inconsistent. In our game we had a maze on the third floor. At the start, it was a featureless maze that caused many players to get lost and feel frustrated. We concluded that this isn’t the emotion that we were attempting to incite in the player and instead, turned the maze into a passage with signs that led the player through easily, but also made the player think about what was written on the signs.

Our game was highly scripted and was meant to have countless interactions that would evoke exploration-based emotions and appeal to players with a strong curiosity. The biggest challenge was creating interactions that matched the perceived affordances of the objects in the game in a way that the player could figure out what to do the way that we scripted them to be able to do. With more time, our finished product could have had much more important interactions that would satiate the need for exploration and discovery, but I am proud of how much we were able to accomplish with the amount of time we were given.

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://ericzimmerman.com/files/texts/Iterative_Design.htm

 

Tags : | Comments Off

Shadow Box Design Reflection

Posted by ggranados6 on Thursday Apr 24, 2014 Under Blogpost Assignments, Design Reflection

As we saw in class and in our readings, there are many ways to subvert game conventions. We also discussed gender, race, and representation in games. We were given the goal of undermining game conventions and to appeal to a demographics outside our own. We brainstormed many ideas and came up with making a murder mystery game. The reason we chose the mystery genre is that it appeals to a wide range of demographics.  To subvert game conventions, we decided to make the setting of the game in the “mind palace.” The mind palace is a concept found in the BBC Sherlock series. By setting the game in the mind palace, the idea was that the player’s character would be piecing together the murder after inspecting the scene and evidence.

 

This game concept would satisfy Lazarro’s The 4 Keys to Fun model. The first key is Easy Fun which is the curiosity created from exploration, creativity, and role play. Our game satisfies Easy Fun because it is open-ended and allows the player to explore many possible murder scenarios. Because of the many possibilities, players can re-explore the world and come up with many conclusions, both serious and funny. Another factor in our game that satisfies Easy Fun is that the perspective was first-person view with no indication of gender, race, or age. Because there is no representation any player can take on the role of detective. The second Key is Hard Fun. Hard Fun is the challenge and satisfaction of accomplishing a goal. Our game provides the challenge of solving the murder. The satisfaction comes with finding a solution, or finding many possible solutions and choosing one. The third key is People Fun which is the amusement of being with friends. The game is single player but it is fun to play with others around. Players and bystanders can try to put the clues together and find the many possible solutions. The fourth key is Serious Fun. This is how the game changes how the player thinks. Our game uses the idea that you can solve and piece things together using your mind. This concept can change the way players believe they can use their minds.

 

For the game design process, we used what Zimmerman calls the iterative design process. The iterative design process involves “testing, analyzing, and refining a work in progress.” In this class, and many others I’ve taken, iterative design was implemented in the class schedule. We had a total of four playtests during class time. The first playtest was paper and pencil. We tested our concept and I took video and photos of the playtest. We realized our idea did not have structure so we met up the next day and discussed and decided on a method that create structure. This was our first iteration in our design. For the second playtest, we had a rough prototype that was very buggy; however, we had our first game mechanics implemented and we were able to test those. Again, afterwards we met the next day and discussed the playtest. We did a total of four iterations using this method. Through these iterations, we found what work and what didn’t work. We also figured out that our initial concept and scope was way too broad for a game that is made in one semester. During every analysis stage in the iteration process, we would cut ideas that we discovered were “nice to haves” and not necessary. Using the iterative design process, we were able to make our final game. If it wasn’t for this process, our game would not be as complete as we had it. Also using playtests, we found that players wanted more background and story in the game. They had no incentive to piece the clues together and figure out a murder scenario. We also refined how the clue connections were made in the game so that it would be more intuitive. By the end of the semester, we had a structured game, with background, and a more intuitive gameplay.

 

Through the iterative design process, we found areas where we had lacking intuitive mechanics but we also found that we had intuitive designs. Looking at Norman’s Affordances and Design, our final game has good affordances and implements his four principles of screen interfaces. Through playtesting, we found what people afforded an action or object should do. We tried to make actions and objects have good affordances.

 

Norman’s first principle is you should follow conventional uses. Our game has many actions and game mechanics, e.g. movement with WASD or clicking an object with mouse. The second principle is to have words to describe actions. We had phrases where actions were needed. For example, we had “Press N to close” when the notebook was open. Norman’s third principle calls for using metaphors. We had many metaphors in the game. Our two biggest metaphors was letting users look at clues and using a notebook for notes. In many detective games, these two metaphors are used so this also satisfies the second principle. The last principle is having a coherent conceptual model. Many of our prototypes did not include background information and instructions which lead to a bad conceptual model and a high learning curve. Once we implemented our story background and a solid set of instruction in our final game, the conceptual model was complete and coherent and players were able to learn quickly and remember what they learned.

Looking back, we used all the concepts from Lazarro, Zimmerman, and Norman’s concepts. Even though we weren’t consciously thinking of these specific concepts during our game design process, the class was structured in a way that we learned these concepts through making our game.

 

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://ericzimmerman.com/files/texts/Iterative_Design.htm

Tags : | Comments Off

Design Reflection: Shadowbox

Posted by gth684f on Thursday Apr 24, 2014 Under Blogpost Assignments, Design Reflection

I always find it amazing how at the end of a project, I can still find the desire to go back and work on it again. To try to improve it. Even when it ends up being a really interesting little game like Shadowbox.

The game has come a long way from our original conception. Though we always set out to make a game within the mystery genre that undermined the concept of a single clear solution, how we got from that initial idea to the current game was a process of continually rethinking our design. Our first paper prototype attempted to capture some of the ideas we wanted to incorporate within the game. The idea of a person looking at a piece of evidence and coming to a conclusion, which then led to another piece of evidence was our core concept. We then wanted to use a combination of these expanding trees of evidence to conclude a part of the mystery. Originally, this was broken into 3 sections. Find the murder weapon, the means, then the culprit. However, when left up to the free form brainstorming style of the original, not only did it devolve into silliness (which was fun), but we also realized that we were dealing with a massively burgeoning stack of evidence. We needed a way to constrain the game. But we needed to do it in a way that left the player free to explore multiple veins of possibility.

So we constructed multiple storylines for how the murder might have possibly happened, with various end goals established. The victim was a corrupt FBI agent. Or he was killed by his wife. Or perhaps he was a good FBI agent and was just killed because he got too close to the mob. All of these could be possibilities based upon how a player chose to interpret the evidence. But now we had distinct story lines. Which was great for me, because I could start modeling the evidence we needed. But it also caused problems…how did we link the evidence together to craft this story in a logical sense for the players, but still allow them freedom to really explore the game? This became extremely apparent when we got to play testing the game, as one continual cry that we got was that people wanted to know whether they had chosen “correctly.” Within our player’s heads, we were battling what Donald Norman refers to as a “Cultural Constraint”. Mystery stories specifically highlight that there is only one very specific conclusion. One which accounts for all the evidence. Added on top of this…how do we connect inferences from all these pieces of evidence to create a cohesive story? Do we leave this in the player’s hands, allowing them to craft their own answers? As a short answer…that is a bad idea. Left too free form, it made no sense in people’s heads why an inference might lead to the next piece of evidence. We needed to script it somehow.

So we kept iterating. And cut scope a couple of times. Get to the core mechanic and work with that. As Zimmerman says “What is the activity of the game? Rather than asking what the game is about, ask what the player is actually doing from moment to moment as they play. Virtually all games have a core mechanic, an action or set of actions that players will repeat over and over as they move through the designed system of a game.” And our core mechanic was look for inferences/meaning, select them, and combine them to achieve some form of cohesive story. Select and combine. The story flows from there.

So the story and scripting grew. When you passed over an inference, you received a little story about what it meant. And we started working the stories back from the evidence we had created. Instead of looking at the story and saying, here is the evidence necessary for it, we looked at the evidence and said…here are the stories we can craft. We scrapped much of our 3 arc storyline and settled for producing a means. How did this guy die? Our programmers then set about creating a system to allow these to connect reasonably. And our writers start crafting the evidence combinations. Meanwhile, I continued modeling, producing anything needed to fill in the gaps.

However, we realized that we faced another problem. How did we communicate to the player what they were supposed to be doing? During much of our early play testing we were focused solely upon the game mechanics that we neglected to communicate how to interact with the game. Many of the cues built into the game didn’t seem to be serving the function we were hoping. Alterations to the cursor to denote different states were not overly clear, though we as designers felt like they should be. Adam came up with a two pronged approach…provide context for the scenario in the intro as well as instructions within the notebook itself. So in the end, we used the second of the design principles for communicating possible actions: describe it with words. Sometimes spelling it out is just a necessary evil.

In the end, we got a game that was pretty interesting with a nice level of ambiance. I don’t think we could have come anywhere near this without the continual iterations we worked through and I am really proud of the results. However, as I mentioned at the very start of this post, I think we could make it better.

Looking at our game now I feel like there are some areas in which we are lacking. Particularly in terms of game play, the game lacks a certain amount of engagement with the player. The level of mastery a player can achieve within our game is very limited, which is a key element towards achieving goals as noted by Lazarro. In many ways, our game play goals are somewhat easy to achieve, which leads to less satisfaction than might otherwise be possible. Looking at Lazarro’s other paper, I would argue that in its current state, our game only touches on two of the Keys to Player Experience. Most strongly, our game grasps the idea of easy fun. People want to figure it out. They want to examine evidence and indulge in the ambiance of the level. It also touches somewhat on the hard fun aspect, as some players will experiment to find the last piece of evidence in a trio, trying to puzzle out the last possible option. However, this is somewhat limited due to the range of mastery available within the game. But where we really need work is in our altered states. Our interactions as they stand now lack a compelling visual or audio stimuli as feedback. The rewards we provide our players for being correct are too small.

In short, I love our game. So much so that I want to continue work on it. We spent only a few short months working on what we have now and I’d be interested to see where it goes from there. But regardless, I will be proud to have this piece in my portfolio.

 

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://ericzimmerman.com/files/texts/Iterative_Design.htm

Tags : | Comments Off

Game of Games : Design Reflection

Posted by mjernigan3 on Thursday Apr 24, 2014 Under Design Reflection

Developing Game of Games was a lengthy and exhausting process, but one that I feel was successful because of the knowledge we gained from the readings and lectures in Game Design as a Cultural Practice.

Our inspiration for Game of Games came from the class itself. We learned a lot about the history of games. From information about the first game we have record of, Mancala, to the transition of the Vizier chess piece to the Queen chess piece, we had a lot of information at our disposal. Since one of our assigned readings was Birth of a Chess Queen, we knew a lot of information about Chess, and thus decided that would be one of the games we focus on, with an emphasize on Queen Isabella of Spain(Yalom). After the History of Games lecture, we also knew we wanted to focus on the first game ever, Mancala, and its origins in Africa. The only thing we had to decide then is what 3rd game we would focus on that brings everything together.  We decided on either Backgammon or Go, but after our concept pitch, the feedback we received suggested we go in a different and easier direction. Thus, after much consideration, we decided our last game would be Liar’s Dice, a version of BS played with dice that pirates were known to play, as seen in Pirates of the Caribbean: Dead Man’s Chest.

Since the games were decided, our next goal was to decide on the difficulty of the game, as well as the target audience. We decided 5th graders (ages 9-11) would be a nice target audience, as we wanted a game that teaches kids, but the mini-games like chess might be way out of scope for anyone younger than 9. We also wanted the game to be extremely casual, as to not evoke frustration to the players (Lazarro, “Why We Play Games”). So even if you lost the mini-games, the story still does progress.

Once the focus and audience of our game was decided, before any coded was written, we decided to do a pencil and paper playtest to test out the core mechanic, which is solving puzzles by finding objects, then somehow using those objects to play the games (Zimmerman). While finding the objects, the player not only learns about the games they are about to play, but they also learn information about the time period they are in. So for example, while in Ethopia in 1490, the player learns about Mancala while also learning that church had a very negative viewpoint towards games.  Applying these concepts to the pencil and paper prototype, we had the players go around and find pieces from a Mancala game set hidden on group members around the room. When the player found a person who had a piece, the person would give the player some information about Mancala. Once all the pieces were found, the player could bring them to the person sitting at the Mancala table and play Mancala versus them. I viewed the pencil and paper prototyping experience as successful as it showed us that our core mechanic was indeed iterable(Zimmerman). Thus began the coding and testing of the first level.

After incorporating the first level, we had people in class play the game to find bugs and receive feedback. Then we ourselves played the games and tried our best to answer the player feedback. This was done over the course of a few weeks. We continued to play the game, we had our friends play the game, and even had friends of friends play the game and give feedback. One of the very first problems of the game was that we only allowed the use of WASD to move, but not the arrow keys. While WASD has grown in popularity is almost considered the norm for moving, the up, the down, the left, and the right arrow still afford movement to some users. So in response to this feedback, we made it so the player can use both the arrow keys and WASD for movement. Another problem was that talking and interacting with NPCs did not afford pressing the space bar. Since this was an affordance that cold get quite frustrating to guess, we put a quick button tutorial at the beginning. Sometimes you have to use words to describe desired actions (Norman).

Very rarely do games at final product resemble games at conception, but ours barely strayed from our original design path. We really only had one extra feature, the addition of the port city of Zeila to better connect the first level of Ethiopia with the now third level of the pirate ship. Also, although our target audience was 5th graders, we do realized they may not get a few references or concepts that were addressed in the game, such as modern debate of games making kids more violent.

Overall, I feel as though Game of Games was successful in the eyes of its creators as ultimately, we met all our expectations and achieved everything we wanted to achieve. We have a multi-level game where the player not only completes quests and learn about the specifics of games, but also learn a few details about that time period as well as how games were perceived at that time. The mini-games turned out extremely well. Keeping in mind that the AI could be too over-tuned, we made it so beating the computer isn’t necessary to progress. This way, there would be no pressure on the player, and it could still remain fun(Lazarro, “What’s My Method”) We were going to add instructions before each game, but we felt that with the way the games were set up and presented, the player would be able to learn the rules in only a few turns.

 

 

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

 

Yalom, Marilyn. Birth of the Chess Queen. New York: HarperCollins Publishers Inc, 2004.

 

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

Tags : | Comments Off

“Reflection” of Ra Light

Posted by jcook61 on Thursday Apr 24, 2014 Under Blogpost Assignments, Design Reflection

We created the game, Ra Light. In this game, the player is a mummy that is trapped in his tomb and must escape to the outside world. The pyramid is sealed by a series of light puzzles. We attempted to target middle school kids and teach them about a few properties of light. Some of the lessons are not completely obvious, but we do have at least subtly hint at how reflecting light works and how different colors imply different wavelengths, which also implies different energy levels. For example, blue light has a higher energy than red, so when objects are affected by these two light colors, red items stop or deactivate objects and blue items speed or activate objects.

Game design is challenging. It requires the utmost dedication of the developer so that the game can be perfect (or as close as possible). “Test; analyze; refine. And repeat. Because the experience of a viewer/user/player/etc. cannot ever be completely predicted, in an iterative process design decisions are based on the experience of the prototype in progress. The prototype is tested, revisions are made, and the project is tested once more. In this way, the project develops through an ongoing dialogue between the designers, the design, and the testing audience” (Zimmerman). We found that things would often break for no apparent reason at the hands of the user. When play testing, users do not know what to do, so they naturally they just press random buttons hoping that something will happen. “In the world of design what matters is: if the desired controls can be perceived [and]… If the desired actions can be discovered” (Norman). We realized that it was hard to figure out what needed to be done, but one thing I have learned is the design of something should be obvious without being explicit. We solved this problem by creating hieroglyphics that visualize the instructions without explicitly telling the player what to do.

We wanted the game to make sense and flow, so we tried implementing a few mechanics in the beginning that did not go so well when we play tested. The first mechanic was picking up objects and placing them in different spots to move things like the mirrors, but people found that hard to use and said it make more sense to push the objects along the ground. We started using this method and people responded more positively to it. It felt more natural. From there, we made different types of pushable objects, such as the mirror and the light modulator. The mirror reflects the light of course, and the modulator changes the light color to the color of the gem it passes through to simulate different wavelengths and energies of light. The red light has a low energy, so things slow down or stop when they are affected by red light and speed up or activate when they are hit by a blue light.

Honestly, these lessons are very subtle, but I personally think that instead of teaching people completely about light, this game should subliminally put curiosities in the mind of the user to do further research on later. That has always been the case for me, and once I look up what I was curious about, I understood its context within the game. At first glance, you might think the first level is completed by making the light hit the target, but at a second glance, it is blue. This means that the inactive door has a very high energy when activated by blue light and opens. In the second level, the fast moving spikes are supposed to be hit by red light to slow them down, as the platform that forms a bridge is inactive (hidden) until activated by blue light. The third level is a bit trickier when the giant tower comes in to play. The tower is subdivided into four different sections: red, yellow, green, and blue. Hitting a certain colored gem with the appropriate light color will activate and rotate that part of the tower. What someone may not notice is that each tower rotates further than the one beneath it, meaning that the yellow is further than the green, the green further than yellow, and blue further than green. Why is this? Because it is going across the spectrum, with each color having more energy than the last.

We did have a problem with difficulty though. As the developer, I obviously knew the game and was very good at it. It is hard to test puzzle games when you are the creator and know the solutions off the top of your head. We aimed for easy fun, as Lazzaro describes, “Curiosity from exploration, role play, and creativity”, where the player would want to explore this environment and be the mummy who wanted to escape. We succeeded in this regard, I think. On its own, the game is fun to play, and it is fun to explore the pyramid, and it is fun to solve the light puzzles. However, we may have gone too far into hard fun, making the game more frustrating than fun. Again, as one of the developers, I knew the puzzles, so when I made more, I scaled them up in difficulty but in relation to myself. With regards to the average user, the scale may increase exponentially. Only time will tell. Given enough time, it would be cool to add more levels so that the difficulty increases at a normal pace.

Overall, it was a very cool project to work on and complete. As a programmer, it challenged me find creative solutions to find ways to reflect light and calculate occlusion correctly. As a designer, I had to find ways to lay out items and levels to make sense to someone who has never played before. This project was challenging but a good way to further develop these skills and produce content that people will want to play and appreciate the design of it.

 

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://ericzimmerman.com/files/texts/Iterative_Design.htm

Tags : | Comments Off