Wednesday, May 2, 2012

Games and Learning


Games have been a part of civilization for centuries. They have been a source of entertainment in people of all cultures and regions. In modern times, digital innovations have allowed us to expand the ways in which we can play games, and we have begun to realize that they may be more than simple diversions. We’re finding more evidence that suggests that games have a lot of potential beyond their entertainment value.
Videogames have the ability to be powerful tools for teaching and learning. The biggest hurdle they face, however, is that what they teach is different than what is typically taught in an American school. In the classroom, external forces often stress the need to have high scores on standardized tests, so teachers sometimes feel constrained to teaching the material on those tests. In contrast, videogames present a variety of situations and force the player to think and strategize about the problem they are facing, thus creating knowledge through experimentation. According to game designer Raph Koster (2005), “[games] are on the same order as learning to drive a car, or picking up the mandolin, or learning your multiplication tables” (p. 34), and that “it’s one thing to read in a book that ‘the map is not the territory’ and another to have your armies rolled over by your opponent in a game” (p. 36). They give context to knowledge, creating scenarios in which learning becomes useful and necessary on an intrinsic level. A videogame is best served when used to build skills and problem-solving abilities, and application of knowledge becomes just as important as the acquisition of it.
The way videogames can accomplish this is by presenting a conflict that the player must solve. In order to overcome this problem, the player must gain mastery over some sort of skill; this can be as simple as aim-and-shoot or as complex as organizing an empire. The player is driven by the challenge and the sense of accomplishment gained upon defeating it. In her article about motivation for playing games, Cheryl Olsen (2010) puts it simply, “an easy game that does not require much time or focus to beat is not as much fun” (p. 183). Challenge is an essential part of the game experience and directly relates to how enjoyable the game will be.
Beyond that, games offer many other potential layers for learning and mastery. By necessity, a game must present the player with choices; there has to be at least two paths that the player can take, and the result is determined by the action taken by the player. Often times more than two options or results are available, and some more complex games offer a large amount of creative freedom to the player. For instance, games like The Elder Scrolls V: Skyrim allow the player to choose their race, appearance, and type of skills they want to improve upon, all in a large virtual world to explore with an abundance of quests to complete. Even more, some players “mod” (or modify) games, changing or adding more elements. These sorts of creative freedoms allow players to explore and experiment in ways they cannot in the real world. Educators could take advantage of this and create learning experiences in which the player is not only learning, but also doing so by choice and with enjoyment and creativity.
There are benefits in social learning as well. Games can give less confident students the chance to build self-confidence, since it affords the chance to fail and experiment without the pressure of being a “let down” or a “failure.” Olsen (2010) notes, “For some, video game skill seemed important to their self-esteem, especially if they had less success in other areas such as academics or sports” (p. 181). This is especially true of children who were reported to have a mild learning disability. Olsen (2010) states, “Children in this group were more likely to be victims of bullying and to report being excluded by their peers; thus, they may put a higher value on connecting with peers through video games” (p. 182). Games provide a common ground on which players can relate to each other, and they may prove to be a good source for peer-based learning and teaching through their ability to “motivate [players] to learn through a combination of affiliation and competition” (Olsen, 2010, p. 182). More experienced players can help newer players improve, and players can share what they have learned or discovered with other players or collaborate to achieve a common goal.
The diverse and substantial ways that games can teach demonstrate limitless possibilities. As a newer medium, videogames have a lot of potential that has not yet been fully explored. Since most games are commercially produced, the focus tends to be on their value as entertainment and their ability to sell; sadly, this has led many to believe that videogames have little worth beyond being trivial distractions. Harry Brown (2008) recalls in his book Videogames and Education, “In 1982, the case America’s Best Family Showplace v. City of New York concluded that videogames are ‘pure entertainment with no informational element’” (p. 63). Furthermore, the majority of media discussion about videogames in the past has been centered on the portrayal of violence and aggression, rather than on the positive potential of games. Brown (2008) makes a powerful point about this debate:
If the key to this potential lies in videogames’ capability to induce a state of heightened identification between players and characters on screen, then we must consider that games, if they can teach aggression, can also teach empathy, one of the core ideals of liberal education (p. 78).
As videogames become more prevalent and explored, new attitudes are emerging, and with it comes new types of games that explore their potential to teach and guide.
The implications of this can be applied in many different areas. In the classroom, games can be used to teach more complex concepts or to provide experience. Historical events can be recreated and experienced from the point of view of a character in that time, and scientific models can be tested and explored without danger or expensive equipment. Beyond school, games can be used as a tool for training, or even as a method for creating empathy to issues otherwise far removed from the average person. For example, Brown discusses a game commissioned in 2006 called Darfur is Dying, which centered on the humanitarian crisis in Sudan. In the game, your character is required to get water for your village, but the stakes are high; “if we fail, we learn that boys captured by the militia face torture and death, while girls meet with kidnapping and rape” (Brown, 2008, p. 71). Success allows you to continue, completing tasks to keep your village supplied, as well as interacting with non-player characters. While games such as this have met criticism for being “too shallow to provoke critical thinking or active political response” (Brown, 2008, p. 71), some theorists and designers believe that this type of humanitarian games have huge social potential. Reality is Broken: Why Games Make Us Better and How They Can Change the World by Jane McGonigal discuss the idea that games are popular because they provide for human needs, and that the knowledge gained from creating these virtual worlds as well as the motivation to play them can be utilized to improve the real world. They provide the opportunity for players to empathize more powerfully with the position of the people in conflict, and, most importantly, to realize that the issue at hand is not fictional but rather reflective of a reality they may not have been aware of.
Games can be as useful as they are entertaining, and we still have a lot to learn. Digital games have opened up many possibilities, and new technologies continue to emerge and improve. Luckily, incentive to play games has existed for thousands of years, and we will continue to enjoy and explore them for years in the future.
       
Works Cited:

Olson, C. K. (2010). Children's motivations for video game play in the context of normal development.Review Of General Psychology, 14(2), 180-187.

Brown, H. J. (2008). Videogames and Education. New York: M. E. Sharpe, Inc.

Koster, R. (2005). A Theory of Fun for Game Design. Arizona: Paraglyph Press, Inc.

McGonigal, J. (2011). Reality is Broken: Why Games Make Us Better and How They Can Change the World. New York: Penguin Press.

Thursday, April 26, 2012

Lesson on Team Communication

Throughout this semester, team communication has been one of our biggest learning experiences. When we began this project, our communication skills were less than ideal, but I like to think we’ve made a great deal of improvement over the past couple months. I thought I should share the biggest lesson about team communication I learned this semester: be aware of how your work affects others.

Working on a single product with such a large team means much of the work is interconnected. In a given day one person might design a UI layout, another person writes the code to implement the design, a third person writes the text that will appear on screen, and so on. Each one of these steps is challenging work, and it is easy to get so focused on your task that you forgot to consider how your decisions will impact the other steps in the process. If the layout designer creates a design with space for only two lines of text, but the text writer needs four lines, the designer must spend time to revise the design. Now suppose several people had already begun implementing the original design in code. This code must also be revised and more time is wasted. Something as simple as adding a couple extra lines of text to a screen can often take several hours of team effort to accomplish. Lack of communication is one of the biggest impediments to team productivity.

The solution to these communication breakdowns is to be cognizant of how your work will affect others. When making any decision (art, design, CS, or anything else), take a moment to consider the “ripples” that decision will create. If I change this section of code, will it conflict with changes another developer is making to the same section? Will my change interfere with the UI layout someone else is designing? Will it force some art assets to be modified and resized? Asking these questions to yourself will sometimes reveal consequences you hadn’t considered before, but often you will still be unsure of what your change will affect. This is a sign that you need to go talk to other people. Ask the other developers if they are working on the same class you are, show the layout designer the change and listen to their opinions and suggestions, and ask the artist if the change will force the assets to be modified and if this really is the best course of action. Not only will these quick discussions save time by avoiding later revisions, they also show how other disciplines approach problems differently and that your approach may not always be the correct one.

Wednesday, April 25, 2012

A Deeper Look at GUI Design

One of the most important parts of a game, often the most overlooked part, is its Graphical User Interface, or GUI.  It’s easy to tell when a game has an awful interface.  Yet when a game’s interface is good, it’s easy to overlook because it fits in seamlessly with the rest of the overall experience.  There are a lot of guidelines on how to make a good GUI, but the best one I’ve come across is CRAP from Usability Friction.  Obviously we don’t really want our interfaces to look like crap.  This is just a mnemonic device to be able to remember these guidelines: Contrast, Repetition, Alignment and Proximity.  Now this article wasn’t directly talking about game user interfaces, but a lot of this can still be translated to work as such.

First we have contrast.  Specifically, if two things have nothing in common, don’t make them look like they do.  A really good example from the article was that of an ‘ok’ and ‘cancel’ button.  The ‘ok’ button stands out versus the ‘cancel’ button because it is almost always the choice the user will make, so it should stand out more.  For our game, we could incorporate this when taking pictures of artifacts.  Specifically, we could try to draw the user’s eye to the “Keep” button and make the “Discard” button less desirable.  Or since all of the information is available to us, if the picture doesn’t contain anything useful, we could instead make the “Discard” button the more desirable of the two.  In our game we also have “Create Exhibit” and “Clear” buttons, referring to the photos played to the tableau.  Here is an example of where we would not want to make one button more desirable than the other because this would reveal our mechanics and information we wanted to keep hidden.  For instance, there’s no reason to make the “Create” button desirable when the proper pictures are played because we don’t want the user to know if its correct or not until after the “Create” button has been hit.

Next they listed repetition as a basic principle.  Basically, this is reusing patterns throughout your entire program.  A good example from the article is how all of Google’s search tools use the same text input field and a styled ‘search’ button that reflects what you’re searching.  In our game, our dialog boxes are the same, so it’s not jarring every time a new one pops up.  Another good example from our game is how the map button is consistent--it would obviously be a bad idea if we moved the map button from place to place depending on what part of the game the user is currently in.  It seems like a simple thing, but it can be easy to overlook when the core mechanics are still being worked on.

The third item listed is alignment.  For this, the article is specifically mentions vertical alignment of things in a list.  While aligning elements vertically isn’t necessarily the kind of alignment wanted in game’s GUI, alignment is still an important factor.  It’s important for visual elements to be aligned in an aesthetically pleasing way that makes sense.  Placing buttons near the corner of the screen for ease of use and being out of the way of the focus of the game is important.  Having those buttons spaced appropriately to each other is also important.  So for designing a UI, it’s good to have a nice flow from one visual aspect to the next.  This property is reflected in our game in a few places.  There are two places where we have buttons that are functionally similar aligned horizontally next to each other.  A third place where we have things aligned is our photo collection.  The player’s collection of photos is aligned across the bottom of the screen in a clear and organized manner.

The last principle mentioned is proximity.  This is just having like-items near each other.  Think of any role playing game on a console or PC--things like health, magic power, fatigue, or hunger are almost always displayed near each other.  This is because these elements are related so they are proven so by being shown near each other.  Likewise, buttons to bring up menus such as the player’s statistics, inventory, or spellbooks are usually near each other for the same reason.  A relationship is created when things are placed near each other, so it’s important for the developer to strengthen existing relationships by doing this instead of implying a relation between elements that aren’t actually related.  In the introduction of our game, we have two arrows that represent a forward and back button.  It might seem obvious to place these next to each other--it simply wouldn’t make sense to place one in the bottom left of the screen and the other in the opposite corner.  However, they must be placed near each other to create visual cohesiveness.  Likewise, in the challenge state of our game, the placement of the cards for the challenge are next to each as opposed to randomly placed about the screen.

We went through many iterations of our game.  We weren’t following these guidelines throughout our design process.  But from testing and failing to eventually succeeding, we found a GUI that worked.  While we didn’t know about the CRAP guidelines while we were designing the interface, it’s apparent that the design does follow the four principles described.  In the future, we could reach a more optimal design sooner by starting with these principles rather than using the trial and error method we employed.

Wednesday, April 18, 2012

A Reflection on Pair Programming

At the beginning of this semester, all of the Computer Science students met and decided on the methodologies we would adhere to for the duration of the project. One technique that we chose is pair programming. This process is a part of Extreme Programming, which is a popular Agile methodology that emphasizes “communication, simplicity, feedback, respect, and courage” in software development [4].
In pair programming, “all code to be sent into production is created by two people working together at a single computer” [4]. Tom Dommett explains the basics of pair programming on Jeff Atwood’s blog Coding Horror.

The idea is two developers work on the same machine. Both have
keyboard and mouse. At any given time one is driver and the other
navigator. The roles switch either every hour, or whenever really.
The driver codes, the navigator is reading, checking, spell-checking
and sanity testing the code, whilst thinking through problems and
where to go next.

For the most part, pair programming has worked out well for our development team. It is easy to see some of the benefits that proponents of pair programming mention. For example, Jeffries points out that the navigator can catch the small errors that the driver may miss. Tom Dommett adds that pair programmed code is less likely to contain defects than code created by one developer working alone because there is someone watching to catch things that would cause problems later. I have seen this happen many times this semester. It is so easy to overlook those little mistakes when I’m in the middle of typing out an idea. With a partner to look over my work those mistakes can be caught sooner rather than later, saving precious time trying to find the source of defects later on. I am confident in saying that my partner very often influenced me to write better code than I would have on my own. Even just the act of explaining my ideas to my partner generally produced cleaner code.
Other benefits described by advocates of pair programming include that there are two people working to find a solution whenever a problem arises, which increases the chance of coming up with a good idea. Also, learning can occur between the partners when one person shows the other some new programming concept or trick [1]. Studies have shown that even student pair programming has a positive impact on learning, despite the general lack of knowledge of those involved [2]. While it was sometimes necessary for a third party, our professor, to step in and point us in the right direction, I still feel that I learned from the various partners I worked with.
Advocates of pair programming “have found that with very little practice, most people adapt quickly to pair development. They get to like it, because progress is discernibly faster” [3]. However, in my experience so far the progress does not always feel faster, and there are some bumps along the way. I tend to agree more with Don Wells’s explanation that “Pair programming is a social skill that takes time to learn. You are striving for a cooperative way to work that includes give and take from both partners regardless of corporate status. The best pair programmers know when to say ‘let's try your idea first.’ [You can’t] expect people to be good at it from the start. [...] It takes time to get used to pair programming so don't worry if it feels awkward at first.”
Learning to slow down enough to explain ideas to a partner has taken some work. Prior to pair programming my usual approach for solving a problem was to try whatever came to mind first, with little to no planning and preparation. While that approach is still possible with pair programming, it seemed to negate some of the methodology’s benefits when I encountered the situation. As the driver, if I did not explain my idea and where I was going, the navigator had a harder time pointing out mistakes in my logic and reasoning. As the navigator, when the driver took off on an idea without explaining it to me, I was left feeling lost and in turn disinterested. It became harder to pay attention when I could not understand where my partner was going with the idea. Avoiding these situations has taken work, and I am still learning to be better at it. Pair programming requires partners to communicate efficiently and express their ideas with clarity.
Working with different people every day has also been difficult to adapt to. When our team decided on our methodology it was also decided that we would switch pair programming partners periodically instead of always working with the same person. This is an attempt to make sure more than two people understand each part of the system. As an introvert, working with just one other person for long amounts of time can be hard, but switching partners and interacting with multiple partners in one week is harder. Over the two years that I have been using pair programming I can say for a fact that I have gotten better at working with other partners. My first experience with pair programming I actively avoided having to work with new people, and worked only with one specific person whenever possible. This semester I have tried very hard to be more open to working with other people. It is still difficult for me, but it is getting better. Sometimes when I am working with a partner, I get so immersed in writing code that I forget my reservations about working with new people all together.
Overall I have no doubt that pair programming has contributed to the quality of our team’s code. I have experienced its power to reduce small mistakes, and also to discover creative solutions to difficult problems. The experience has been wonderful at best and interesting at worst, and has helped me become a better programmer. While I do sometimes wish I could just work alone, adhering to the pair programming process was a good choice for our team and our project. Pair programming might be hard work, but it has been worth it.


Sources:

[1] Atwood, Jeff, and Tom Dommett. "Pair Programming vs. Code Reviews." Coding Horror. 18 Nov

[2] Braught, Grant, Tim Wahls, and L. Marlin Eby. "The Case for Pair Programming in the Computer
Science Classroom." ACM Transactions on Computing Education. 11. (2011).

[3] Jeffries, Ron. "Pair Programming."XProgramming.com An Agile Software Development Resource.

[4] Wells, Don. "Pair Programming." Extreme Programming. 1999.

Continuous Integration of Better Practices

Q: What’s the worst code I’ve seen recently?
A: My own.

Jeff Atwood posted this question in his 2009 blog post, “Nobody Hates Software More Than Software Developers.” After this semester at the Virginia Ball Center, I immediately see the value in his statement.

As I look back at the code that I wrote those few short months ago it seems foreign. One example of this is the following method:

public double calculateNeededAverage(double desiredGPA, StudentRecord record) {
double knownCreditsEarned = 0;
double unknownHoursAttempted = 0;
double totalCreditsAttempted = 0;
int unknownClassCount = 0;

for (ClassGrade x : record.getClassList()) {
if (x.getGrade() != Grade.UNKNOWN) {
knownCreditsEarned += x.getCreditPoints();
} else {
unknownClassCount++;
unknownHoursAttempted += x.getHours();
}
totalCreditsAttempted += x.getHours();
}

if (unknownClassCount > 0) {
double neededAverage = ((desiredGPA * totalCreditsAttempted) - knownCreditsEarned)
/ unknownHoursAttempted;
// Check is desired GPA cannot be reached
if (neededAverage > 4) {
log.log(Level.SEVERE, "The desired GPA cannot be reached, "
+ "throwing IllegalArgumentException");
throw new IllegalArgumentException(
"Desired GPA cannot be reached");
} else if (neededAverage < 0) {
// Any grade will meet desired GPA
return 0;
} else {
return neededAverage;
}
} else {
log.log(Level.SEVERE, "No unknown classes, throwing IllegalArgumentException");
throw new IllegalArgumentException("No unknown classes");
}
}


At the time, it was the best I knew how to do but now that I know better it looks awkward and clunky. Here is an example of code that I wrote very recently:

private void ProcessPictureAttempt ()
{
if (_photoAlbum.IsFull ()) {
PlayCameraClickErrorSound ();
NotifyListenersOfFullAlbum ();
} else {
ProcessPictureAttemptWithPartiallyEmptyAlbum ();
}
}

The new method looks much better. The individual tasks have been refactored out into their own methods and the code is therefore much easier to read. Still, I know that it is probably far from perfect. This isn’t a bad thing. On the contrary, I think that this single truth is the best thing that has come out of this semester.

So what has changed in these last few months to bring about this change in myself? It’s simple, really - I know more about the 
better practices of industry than I did then. Throughout the semester, the Computer Science team has been reading Robert Martin’s Clean Code. His book contains tips for becoming a craftsman of code by using better principles, patterns, and practices of writing code. A result of this is that your code becomes easier to read, more maintainable, and generally more robust. As I read through this book, I was able to immediately apply its lessons one by one and see an immediate improvement in my coding style. It feels very empowering to look back at week-old code and say, “This is not clean, and here is why.” Each day, I see my code improve incrementally with each chapter I read in the same way that I see the game improve with each consecutive release.

I’ve come so far this semester, but I am still not satisfied with my ability because I know that as I read more literature on the topic my ability will continue to improve. I’m currently working through The Pragmatic Programmer and will soon move on to Effective C#. The books that follow will be based on the ideas i discover in these texts. As I read these, code that I write today will feel outdated, yet this is a good thing; it shows that I am still learning and growing as a developer.

You may have noticed that I use the term “better practices” as opposed to “best practices.” This is because I always want to be on the lookout for new, better, “best practices” as they become available. This is the only way to stay on the edge and keep ahead of the curve.

When I look back at this semester, I think the most important thing I learned was how to learn. Learning how to apply lessons from books as you read them is an invaluable skill that I will use for the rest of my life. By continually integrating new skills and better practices, my code will continue to become cleaner and more robust. No one’s code will ever be perfect, but with each new idea that I integrate I move closer towards the impossible goal.

Tuesday, April 17, 2012

The Evolution of a User Interface

I never quite realized how much thought went into the programs we use every day until I joined this project. Most things in a program or game seem reflexive, normal even when you use them. Things such as tabs in a web browser to the X button for closing a window have all been carefully crafted over time by people trying to figure out how they themselves would do something. Even outside of a computer, think about the buttons you select on appliances, in your car, and basically everything. It's all about usability and how people interact with things.

Our game initially began with a simple concept: taking pictures in a museum. To represent that, we needed a way to have a camera, a way to show pictures taken, museum rooms to go in, navigation from room to room, and a way to play photos in challenges . Sounds easy enough doesn't it?

The Camera

Probably the only thing that survived through all iterations of this game is the camera itself. This game mechanic was inspired by a game called Pokemon Snap. We needed to represent the camera in a digital space in a way that would be familiar to children. Cell phone or Smartphone cameras became the inspiration because they already did what we needed them to do. When entering a room the players mouse turns into the reticle on screen for them to take pictures. For taking a picture, the reticle is white but changes to a green while playing a camera click noise. The color change and camera click were necessary because they provide feedback to the player that they are actually doing something. It's the most obvious example of feedback but people truly need positive feedback to keep going. Think about how much fun Portal would have been without your portal gun making noise when you fired it or if Mario didn't have all those little flashes to indicate if you were getting hurt. There are so many little things in games that let you know if you are doing something right or wrong that are very important to the overall experience.


The Pictures

Next question, the player has taken a picture now so where does that go? On a camera you can just select the menu button to browse your photos. Our pictures are different however because they have special characteristics that a player needs to be able to see at all times. That immediately removed the idea of a separate window to view the photos. At first, the photos were always on display at the bottom of the screen in the Collection Widget area. That way the player would always be able to see the information on the photo for when they would come across a challenge in the museum. Recently we reworked the whole game to the point where we had more information we needed to show on the photos than in the original. The extra information led to a collapsible photo area at the bottom of the screen. The photos and the name of the artifact in the photo are always visible but if a player needs to see the photos information, they can click any card at the bottom to toggle up full view cards. Along with being able to see the whole photo with information, players can click a small X in the right corner to delete a picture from their collection.

3/28/2012

4/17/2012


The Museum

Originally the game was designed to have 12 exhibit rooms that would be randomly assigned from a pool of 20 exhibit rooms. This was inspired by a board game called Betrayal at House on the Hill. Betrayal uses a modular game board mechanic in which there is a stack of room tiles that each player uncovers as they explore an old mansion. This allows the players to build a different game board every time they play and drives exploration. We tried to replicate that idea in our game by having a map of the museum that starts you off in one room with unknown grayed out rooms around it. The player can click on any room around it to go to that room and have the exhibit name revealed. This was also going to play into the Challenges by not knowing when one would show up on the map. We had used a small lock icon to represent rooms with Challenges. However all that did was make play testers think they could not click the locked room, thus preventing themselves from attempting challenges. Through visiting with the Indianapolis Children's Museum we realized that we needed to scale down the game. We were trying to put too many rooms in the game and too much on the map that were confusing play testers rather than keeping them engaged. Changing the scale of the game by shrinking the map down to 6 rooms that do not change was the first step. Instead of being exhibits, now the game actually takes place in the collections or storage area of a museum. That still gives the exploratory feeling we wanted while letting the player go behind the scenes and look at things not currently on display. Rooms the player can currently visit are highlighted and rooms further than that still use the lock icon. To represent challenges an exclamation mark icon is used and the map now has a key on it to remind players what the icons mean. The one thing from this that lasted what the use of a star icon to mark your current location on the map.

3/28/2012

4/17/2012


Navigation

At first I'm sure we all had grandiose ides of making an elaborate 3D game in which we could physically move through spaces. The time we actually had to do this plus one person who could draw everything made us quickly realize it was not something we could really pull off. This is why the use of a map came in. It was the simplest way we could represent a space in 2D. The use of a map however presented a dilemma on how the player would actually enter a room from the map. The first way we tried out was to take the player into a room the instant they clicked on where they wanted to go. Then we had to think about how they would get back to the map from the room. Solution: a map toggle button in the room. Previously when we had a crazy huge map we also had multiple challenges in the museum along with a final challenge that involved luring a mummy back to the Egypt exhibit. The map toggle would have worked for the first few challenges but would not have worked for the final challenge because you had to be able to see the mummy move on the map along with playing photos to feed him. Changing how the map button would toggle on and off for the final challenge alone would have been a bad idea because it would have been different from what the player had learned to do in the game already. We never got to the point where we implemented the mummy challenge because of feedback from the Children's Museum again. We told them about that challenge but also mentioned a Curator challenge from which the player would have to present a good collection of photos to a Curator at the end for approval. From that alone the game became what it is now and we were able to keep the map toggle button for use in a room only.

Challenges

The purpose of taking photos in the museum was that they had certain characteristics that could be played against Challenges that popped up. The Challenge UI needed to have a place for these photos to go along with a way for them to be played from the Collection Widget Area. Originally photos were always visible and to play a photo you would click the photo for it to slide up a few pixels, similar to the digital version of Hearts. That allowed us room for Challenge text on screen and some fun artwork to go along with it. When we had to somewhat overhaul the game, this completely changed. The way I previously mentioned photos being handled and displayed was purposefully created for how the new Challenges work. There is now an on screen dock area for which clicked photos are animated into when they are played. Along with that we have given the players a clear button in case they want to play a different photo in the challenge than the ones they've already played. There was also still room in this version for each Challenge to have artwork of a Curator displayed on each side.

3/28/2012

4/17/2012

Honestly all of this really only begins to scratch the surface of what we have done to get to where we are now. There are so many tiny details and things people do that you don't realize until you watch them interact with what you have created. No matter what you do when designing things for people, many more questions and issues will come up along the way. That's why accepting that it won't be perfect the first time is key to this whole process.

Monday, April 16, 2012

Different...But the Same: Exploring Coherency in Audio Design






When playing a video game or watching a cartoon show do you ever notice how many different types of sounds and characters there are? Furthermore have you ever noticed that even if you aren't looking at a main character you can still make an accurate guess as to what franchise it belongs to?


Pop quiz: What show is this character from?
Don't pretend you don't know.


The same thing happens with audio. There's virtually no mistaking the "pla-king" of collecting coins in Super Mario, or the "rut-rut-ruch" sound of going down a pipe (I'm not entirely sure I spelled either of those onomatopoeias correctly).

Creating coherency between the different sound effects and music has been a challenge for me throughout this entire project. It's something I have never needed to do or even thought about having to do in previous projects. Cue the research. I listened to hours of video game audio, taking notes as I went to figure out what elements made them sound like they were "laid back" or "epic" or "insert-emotional-adjective-here".

Good news: The research worked.

Bad news: The research worked.


Pictured: Your reaction

I found exactly what I was looking for: how to make the sounds and music different from each other. My staff of Ra was too tall. I was digging in the wrong place. What I should have been observing was how the songs were related to each other. Because I learned how to make sounds and songs different, albeit inadvertently, when I modeled my songs and sounds after my research everything sounded different. Too different. So different that even I, their creator, couldn't tell that they all belonged to the same game. I was going in a wrong direction and didn't know how to find a right direction (there are multiples of each).

Then one day I looked at Diane's characters she had created for the game and I immediately noticed 3 things:




Exhibits A-D
1) They looked fantastic
2) They were each unique
3) It was 100% clear that they all belonged to the same game, cartoon, art direction, project...Whatever you want to call it, they were all a part of it.

I imediately asked her how she made them all "same, but different" she said, "I just did."
It was not helpful.

But then I prodded her brain more, asking about her process and what she thought about as she was drawing and creating. She started to talk about how when she starts drawing characters the wire frames and shapes she uses are the sa-THAT'S IT!!!!!!!!!!!!

EUREKA!

LIGHT-BULB!

AH-HA!

I realized that the "sameness" comes from the starting point; the fundamentals; the building blocks. In music it's things like tempo, key, and mode. In visual art it's things like shape, color palette, and medium.
The differences come from the details; melody, harmony, and instrumentation for music, and for visuals it's hue, gesture, line, etc.

So it was time to put this little theory to the test. I made three song loops each the same tempo, duration, but each with a different beat, instrument, and melody line. The result was astounding.

1, 2, 3

At first I wasn't too sure if I had found a path to success, but when I put the new songs in the game in conjunction with some of the songs that I had not created in tandem, it was perfectly clear which songs stood out (in a negative way).

Although this is one path of solution to my problem I'm sure it could be solved in other ways. This one worked for me so I'm going to stick with it and "fix" the rest of the music and sounds of our game.