However, Krug’s first rule of usability appears to directly contradict the purpose of video games, where the designed goal is precisely to make the user think about the interaction, so clearly this rule is invalid for game usability... right?

Wrong.

Like many classic rules of software usability, if we tried to apply Krug’s ‘don’t make the user think’ rule directly in all situations of game design we’d end up with a lot of very easy, very boring games, which is obviously not the intention. However, Krug’s rule is much more important to video games than you might think; albeit in need of a slight conceptual adjustment.

For video games Krug’s rule should read, ‘don’t make me think about elements that are unrelated to the primary gameplay loops’. The gameplay should make the player think, but everything else should support the game’s systems as seamlessly as possible. For example, if inventory management is NOT an integral part of the gameplay experience why would you force a player to spend time managing an inventory? It’s disruptive, pulls the player out of the actual gameplay, breaks immersion, inhibits flow, and just generally detracts from the player experience. Why not support the player by managing their inventory for them, so they don’t have to think about it?

The player should never have to think about non-gameplay interactions. So it is important to anticipate what the player is going to need to do and make it simple when the action is not part of the game. Everything else is just poor usability.

Since the last time I posted:

• I presented at 2 conferences
• Had 3 job interviews
• Found a job
• Co-authored another paper
• Moved to Montreal
• Started working at Ubisoft
• Had my first Christmas away from my family
• Was elected the Games User Research steering comittee
• Agreed to help organize the Games User Research Summit
• Found time to finish: AC:B, LIMBO, Bastion, Deus Ex: HR, Darksiders
• Found time to sink 40+ hours in to Civ 5
• And a ton of stuff I'm forgetting

I do still have all those things that I want to post. Maybe now things are starting to stablize I'll be able to find a regular time to post something. 

Here's hoping, in the new year.

This week on Tuesday (June 21st) I defended my Thesis successfully. *cheers* I'm now frantically making final edits and preparing for a job interview.

I realize that I haven't posted since Feburary, but I've really been THAT busy.

Regardless, I promise (mostly to myself) to actually put something interesting up here before the end of July, maybe two things. :)

Laters.

In software development there is a concept known as the iron triangle. The concept is based on the principle that to develop a quality product three points must be balanced. The three points are: scope, resources, and schedule. Scope refers to size or feature set of a product, schedule refers to the time constraints, and resources are the costs or budget associated with the product. The basic idea is that it’s easy to balance two of the three points, but to balance all three requires careful management.

The iron triangle also applies to game development; a game is just another software product after all. However, what about game design? Design is different from development. The design of a game is only a single part of the overall development process. Personally, I’m not convinced that the standard points of scope, resources, and schedule are sufficient when we start talking about game design.

A game design iron triangle, made up of business, science, and creativity.

So I’ve been kicking around is the concept of a game design iron triangle. Where the three points are: business, creativity, and science. Business refers to design considerations like brand and marketing, creativity refers to the appeal of the design, and the science is our understanding of the design. Like the traditional iron triangle a balance between the three sides results in quality, however it’s design quality rather than product quality.

I need to flesh it out a bit more, but I feel the idea is interesting and might have some legs. I think it's a topic for future discussion.



Commercially, no matter what is discussed, accessibility is paramount. Do consumers have access to your product? Can they use it? Does it reach the largest market possible? The term ‘accessibility’ is overloaded, so in these posts I’m referring to the level of accessibility offered by a product to a consumer (player). However, this interpretation still contains many nuances. These nuances – and their relationship to the success of a game – will be the topics of these posts.

There has been much talk about the success of casual games over the past couple of years. We’ve seen the rise of Farmville, Angry Birds, and a host of other successful games. The initial success of the Wii also demonstrates the strength of the new entertainment age – games have reached a mass market. But why have we seen such an impressive rise? Simply put, these games are accessible.  As I mentioned, there are many facets of accessibility. I want to begin my discussion of accessibility and first impressions.

First impressions

First impressions are important. From social situations to consumer electronics, the first contact between a player and a game will be used as a basis for evaluating all future experiences. Do they like it? Do they play it? The first impression will bias their overall opinion of the game, and what they expect when a game is first loaded.

In the context of first impressions, accessibility refers to the ease of which a player is able reach their expected experience. There is a complex dance of cognitive and physiological affects – a mix of expectation, desires, and bias – that combine to form an expectation. A game that facilitates a player in reaching their expected experience is accessible – it facilitates access to the expected experience.

Anything that inhibits the access of a player’s desired experience will produce a negative effect; it’s not what the player expected. Devices such as long cut scenes, slow load screens, or excessive menu navigation may be contradictory to what the player expected, and thus make the game significantly less accessible to the player.

The importance of a player’s first impression and expectation cannot be overstated. A player expecting a racing game when they load Dragon Age is going to be disappointed; their experience will not match their expectation despite Dragon Age being a great game. The game would fail to provide the player with a way to access the experience they expected based on their first impression.

While the above example is clearly contrived it does illustrate the importance of an accessible first impression, a matching between what the player wants/expects and what the game provides. Matching what the player wants to what is provided by the game will increase the overall accessibility of the game, making the experience more enjoyable.

That’s it for now. In the next post I will dive into the importance and meaning of accessible gameplay.

That's all you should need to do. It would be nice if Netflix just said this, but instead you're forced to jump through some hoops. Regardless, I hope this little post is helpful to some who find the same problem.

Since today is the last day of 2010 I thought that it would be prudent to explore what I was able to accomplish this year.

1. I married the most beautiful woman in the world
2. I was an author on 4 articles: 2 conference papers, 1 workshop, and 1 journal article
3. I visited 4 game companies: Value, EA, Radical (twice), and Next Level
4. I visited Montreal, Ottawa, Vancouver (twice), and Seattle (thanks to an amazing boss)
5. I worked on the amazing Indie title Capsized with some very talented folks
6. I learned the ins-and-outs of physiological measures, and discovered statistics aren't that hard.

I'm actually very happy with that list, I think its been a good year. However, there have been a few things that should have been finished, but just didn't make the above list.

1. Didn't quite finish all my class work (still have one outstanding class project to finish)
2. Didn't finish my thesis. (that's kind of a big deal)
3. Didn't get my paper accepted to CHI (which is really my fault for doing sloppy framing)
4. Didn't go on a honeymoon (was waiting until I finished the thesis)

These 4 are kind of major... especially the thesis thing. Honestly, the thesis is really the limiting factor for the other other 3. Regardless, the plan for 2011 is very simple. Publish the final work for my thesis, graduate, go on a honeymoon, and find gainful employment at an awesome company that makes games. By this time next year this blog won't been the bland ramblings of a graduate student, but rather the insightful remarks of an industry insider. :)

As a games user researcher my job is two fold:

1. I need to understand the visions and goals of the designer(s).
2. And I need to apply my knowledge in a manner that fully supports what the designer(s) are trying to accomplish.

Optimally, every game will provide a player with a unique and memorable experience. That experience is defined by the designer’s vision. However, precisely because games are unique from one another, it would be naive of me to believe that there is a game usability silver-bullet. Each game must be approached differently.

If there were one statement that I could make that sums up my role it would be this:

My job is to streamline all elements of a game in a manner that best supports and showcases the goals, visions, and experiences of a specific game.

If I’m successfully in achieving that goal then everyone involved would get exactly what he or she wants, and most importantly the player gets a great game.

Let's look at an example, suppose a player becomes stuck at a specific point in a level. Let's also suppose that you've tested a total 10 people, the other 9 having no problems at all. It's easy to look at the results and conclude that 1/10 is fine, and that the vast majority seems to have no problem with that level. However, we don't know how or why the player became stuck, or if the problem is unique or systemic. Personally, these are the questions I strive to answer during, and after, I run a playtesting session.

When I run a playtesting session I break the process down into 3 sections.

1. Play and observation
2. Survey
3. Interview/discussion

My sessions usually run about 2 hours. The first hour being play and observation, and the second hour for the survey and interview. Obviously this time changes based on how much you are trying to test.

I’ve found that the survey is best used as a method to measure the overall experience of the player. While the interview allows me to really explore the observations made during the play session. By combining the three sections I've found they provide a rich data set that can be used in the analysis and fixing of observed problems.

Here’s a real example from the session on Saturday; one player was observed having difficulty navigating through a level. The level in question required a significant amount of vertical traversal and it was clear that the player was becoming frustrated.

Me: "How are you feeling right now?"

Him: "A bit annoyed right now. I can't get... ahh, up there." - he gives up

Me: "Why were you trying to get up there?" - I noted that he was trying to reach a catch of items.

Him: "I need to get that jetpack fuel, so I can fly to the top again."

The problem wasn't that he couldn't reach the items (in fact he could), the problem was that he had missed the training in the first level that taught him to use his grappling hook to move around the levels, a conclusion that was drawn from the post session data analysis. The player was unaware of the cause of his problem, and if we had simply asked him – without observing the problem first hand – we might have dismissed it, or incorrectly assumed it was a problem in the current level.

I'm happy with the process I've been using. It seems to work very well within the limitations found in an Indie title.

The project is a cool little initiative describing the expanded use of data collected from video game reviews as a tool to inform future design decisions, and to help in the assessment of quality during the testing process. The project goes hand-in-hand with my previous published work, which described a heuristic evaluation technique that I call Critic-Proofing. If you're interested in novel evaluation techniques designed specifically for video games, then this is worth a read.

There was a very interesting feature article on Gamasutra a couple of weeks ago.  The article explored a very simplified description of some usability tools available to developers. Worth a read, so go check it out.

CHI submissions are done finally. :) It was a mad rush at the end, iteration on top of iteration, but I feel that We (my co-authors and I) submitted some really good works with solid contributions. We'll see if the reviewers feel the same way. :p

It's nice to be able to take a breath again, but it's right back to work. I have a few projects on the go currently (Capsized for example) and I'm really excited to work on all of them. I'm going to work hard to keep updates about projects and important discoveries flowing onto the website. :)

Peace You'll