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.


[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." 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 {
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.



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.




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.


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.



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!!!!!!!!!!!!




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.

Tuesday, April 10, 2012

An overview

Games, Fun, and Learning.. What did I expect when I signed up? To be honest, I expected to do a lot of programming. I knew there would be more to it than just that, but I never really thought about it beyond that. For the first month, we didn’t even touch the computers--we didn’t even order any workstations until about the 5th week of class. We designed table-top games--board, card, and everything else. Let me tell you, playing games is easy (most of the time) but making games is far from easy. Beyond that, making a game with a specific goal--to teach kids something about museums--moves it even farther from being easy. Using a rapid prototyping design model, over the first two we made nearly 30 different games. Because of this model, and knowing not to dwell on aspects of our games that didn’t matter, we were quickly able to churn out prototypes and know which ones had potential, and which ones needed to be scrapped. Out of these games, we had 5 or so contenders for our final idea. So another two weeks went by where we still didn’t touch a computer, and we fine tuned our contending games. At the end of this, we had two strong candidates and were finally able to pick one to move on with. So nearly a month into this course of making a computer game, we finally were able to sit in front a computer and start actualizing our goals on the screen. Since then we’ve all been doing a lot more of what we signed up for. We’re not done yet, but the end is in sight it’s looking good.

Thursday, April 5, 2012

Ideas and Logos

Recently, Root Beer Float Studios, as we've named ourselves, decided that we needed an appropriate logo. Our artists took on the task of coming up with a few potential candidates that the team would vote on.

I had an idea for a very simple logo, one of a frosty mug, overflowing with ice cream and foamy root beer. In my mind, I had envisioned something specific, but when I went to explain my idea, I had a hard time verbalizing it to our artists.

My idea was to utilize few colors, which I couldn't figure out the proper name for (I've since learned that it's called monochromatic). Our artists took the idea and whipped up a cool logo.

It was interesting to me that I explained a half-realized and poorly described idea, and our artists were able to translate that into something actionable. What they were able to produce was almost exactly what I had envisioned. Exciting stuff!

Our artists also created a potential logo with a grim dinosaur holding a frosty root beer float.

Here are the logos:

The logo as it would appear on various colors of shirts
The dinosaur looks much happier in real life