Don Daglow's Blog

What I Learned About User Interface from Our Freezer

(If you're seeing this post mirrored on Facebook or LinkedIn, the graphics look better on the original site at www.interactive-entertainment.net.) 

 

Our refrigerator still works fine, even if we've had it for a long time. 

It's from the Energy Saver era, so getting a new one won't save a lot of money on our electricity bill.

We're not people who need to have the latest kitchen appliances, the sleek black ones that strutted down the runway this spring in Milan.

So if it's keeping food the right temperature and it's energy efficient, why do we hope to get rid of our refrigerator sometime next year?

Somewhere inside that big black box is a sensor.  If you accidentally leave the door open a crack it lets you know before you have to mop the ice cream off the kitchen floor.

"Beep!  Beep!  Beep!"

You can tell where this is going.  For the last few months, we periodically hear the warning sound, run to the freezer... and find the door securely closed.

The alarm goes off again.  Adjust the contents again.  Slam the door again.

"Beep!  Beep!  Beep!"

If we call a service guy to fix a 79-cent part on our old freezer it will cost several hundred dollars.

So because of a 79-cent part we have "new refrigerator" on our wish list.  And when we get it, we'll throw out an appliance that otherwise continues to work perfectly well.

So what does this have to do with game design and software development?

How many times have you played a game you think you'll enjoy, only to have something drive you freaking crazy?

• You press a button and nothing happens because you're not in the right mode. 
• Before you can do anything fun you have to go bring back the Crown Prince's Diet Coke can that he dropped in the French Revolution the last time you guys went time traveling.
• You've spent 30 of the last 60 minutes re-playing stuff because you died and they're making you go back and do it all again.

Somebody spent $15,000,000 to build that game.

You're about to trade it in at the store because of something that might have taken $15 to fix.

But we see it all the time.  The same issue that's driving you crazy is all over the Net.  Three different major reviewers call it out, and it's part of the reason for a 71 rating for what could have been a really good game.

 

 

Why didn't someone fix it before the game shipped?  How much money did they lose by not fixing it?

We all get stuck behind deadlines.  We want to do more playtesting with real consumers and fresh pairs of eyes, but the submission date is looming and the A's on the bug list aren't cooperating.

But what's the cost when teams DON'T get the chance to tune the game properly, to fix the unintended cumulative effect of five other changes?  It can be millions of dollars and months and months of team members' lives.

The teams who handle these issues best have stellar track records.  Blizzard and Valve are just two names that come to mind. 

Why is it hard to think of a lot of publishers that give their games thorough testing and tuning UNTIL the player experience is flawless?

"Beep!  Beep!  Beep!"

I'll think about it while I fiddle with the damn freezer.

 

 

Some game publishers will accept a post-Alpha, pre-Beta milestone devoted just to tuning game play and the player experience.  What would happen if you pitched this for your next project?

What would happen if you actually reserved the time for tuning the game, instead of using it for the post-Alpha to-do list? 

What would happen if the game developers -- not the marketers -- got reactions from a series of first-time-on-the-game players periodically throughout development?

As difficult as it is to do these things in the real world with real deadlines, there are teams in the industry who do it.  I mean, Valve has done OK with Half-Life, haven't they? 

<<<<>>>>

Copyright (c) 2008, Don Daglow.

What I Learned from Alex Laurant's GCDC Session, Pt. 2

(If you're seeing this post mirrored on Facebook or LinkedIn, the graphics look better on the original site at www.interactive-entertainment.net.)

 

 

 

In my last post I discussed the first lesson I took from Alex Laurant's session at GCDC, called "The Transition from Film to Games: An Outsider's Perspective on Visual Design Challenges." 

 

In the words of the late-night TV pitch-people, "But wait!  There's more!"

 

 

The second key inference I took from Alex's talk -- in addition to a lot of useful information -- was about designers' true commitment to quality.

Most great games did not become great at the stage where they were a three-page concept doc.

They weren't great as a first rough prototype.

They became truly engrossing, fun, addicting as the little details got added, the tuning got done and the balance started to appear. 

Depending on the kind of game and the schedule, that process of finding the heart of the fun in the game play may take days, weeks or months.

Designers talk about it all the time.  The game doesn't feel right, milestone after milestone.  Then, as you struggle through a too-short period for tuning and refining, something starts to click.  And that moment comes where -- finally -- the game feels cool and special.

If you're lucky, you still have time to implement what you now know you need to do in order to have a really good game.

If you're not lucky, "they" come and tear it from your hands and ship it anyway.

In my first post about Alex Laurant's presentation at GCDC I talked about the way he role modeled an attitude best described as “I learn something new every day as I work on projects.”  And this is a guy who's been art directing for 25 years.

The second attitude he role modeled for us was attention to detail, focusing on quality in every possible detail of a project.   And then actually doing the work to get that quality detail implemented and integrated into the game.

In fact, one of the lessons he told us he learned coming from film to games was that he had to learn to make more compromises.  The need for an open world and interactivity simply gave him less control over the details of the appearance of some visuals.

You could tell he didn't like having to make those tradeoffs, even as he knew they had to be made.

That's one of the reasons I liked his presentation so much.  I like someone who gets upset at the idea of having to compromise on quality.

Even if we all have to do it eventually... because otherwise we'd never ship a game!

 

 

What is one place in your current project where you could make an improvement in quality tomorrow just by focusing on that issue and spending a little time?

Are you willing to actually take the time to do those improvements?

 

 

In my first post about Alex's talk I mentioned there was also an element of karma in his presentation.

One of his great stories was about working on effects for the film Minority Report.  Alex was struggling to find the right technology to create the empty eye sockets for the blind character Lycon, Seller of Black Inhalers.

All his ideas for how to use technology to take the actor's face and create this effect failed to work.  Then one night he looked in his refrigerator and saw a chicken carcass.  He took a whole roasting chicken, sewed shut the opening in the body and, Voila!  The correct look for Lycon's (very disturbing) eyes was born.

   The actor who played Lycon and whose performance combined so effectively with the special effects is named David Stifel.

Although the world principally knows David Stifel as an actor, in 1983 he was part of my team developing Intellivision games at Mattel.  He programmed a title called Game Maker, which was our homage to Bill Budge and Pinball Construction Set.

By the way, despite his ability to depict evil characters, David is an incredibly nice and considerate guy.   (Another quality he shares with Bill Budge!)

Stifel's game never had a chance to find an audience, because the video game crash of 1983 swept away all the console companies, and most of the jobs in computer games were lost as well.   

Alex spoke in the same room where I made my presentation in Leipzig, in the next time slot, so we went back-to-back.  Sitting there in his session I thought, "What are the odds that the same guy worked with me as a game developer, and was the actor whose face Alex transformed in a movie?"

It's a funny planet.

 

Next Week: What I learned about user interface from our freezer.

<<<<>>>>

Copyright (c) 2008 Don Daglow.  All Rights Reserved.

What I Learned from Alex Laurant's GCDC Session, Pt. 1

(If you're seeing this post mirrored on Facebook or LinkedIn, the graphics look better on the original site at www.interactive-entertainment.net.)

 

 

I saw a number of excellent presentations at GCDCin Leipzig and doubtless won't have time to cover them all.

Alex Laurant is an Art Director at LucasArts, and has a long track record in special effects for film, going all the way back to the original Star Wars: Return of the Jedi 25 years ago.  The Mummy, Minority Report and Saving Private Ryan are also on his resume.  He's an outstanding communicator who prepared thoroughly for his talk in Leipzig.

His presentation was called "The Transition from Film to Games: An Outsider's Perspective on Visual Design Challenges."  He covered design issues he'd faced as he transitioned from film into his more recent work on games.

But Alex's talk contained more wisdom than just the case studies he presented.

He reminded me of two important things that he demonstrated by example...

 

 

Years and years of work experience mean you've tried things the wrong way hundreds and thousands of times.

We always say we learn a lot from our mistakes.  But how much of that learning do we retain?  And how much of what we learned are we willing to act upon? 

The best creatives and the best managers can't always tell you why they do each little thing the way they do, but you can see they've learned thousands of little lessons through personal experience. 

Alex talked about how he follows this process of continual learning.  But he treated it as normal, assumed, routine.  That's the attitude he displayed that made me want to write this post. 

He treated it as a matter of course that he was continually changing how he does things.  It's the opposite of "We've always done it this way."  More like "We're going to have to change a lot of what we did last time in order to succeed in this project.  How will we take on this challenge?"

Not everybody does this as dependably as the best managers.  Some people keep repeating the same mistakes over and over.

They operate based on habits, the way they're used to doing things.  They are not focused on learning from their mistakes.

Alex smiled when he talked about having to learn a ton of new things under pressure on every project.  I think he likes it.

 

 

How we handle learning from our own mistakes is under our control as leaders.  Our attitude and approach have a dramatic effect on our teams as well as on ourselves.

The people on our teams hear what we say... kind of.

The people on our teams absorb every little detail of what we do.   Thoroughly.  In great detail.

Leading by example for an hour does more good than pontificating in emails and meetings for a week.

The best leaders consciously reassess what they've learned anew this day, this week, this month.  They role model that process of continual learning from every experience of the day.

In sports it's the athlete who obsesses over film and works with the coaches to make the next game better.  In game development it's the lead who assumes that every week on a game includes important lessons for him or her to learn... even if they're a 20-year industry veteran.

Being committed to constantly learning is an attitude, not an attribute.  And, as I probably say too often, "If you don't display the attitude, you don't possess the attribute."

 

 

What are some things you learned this week on your current project?  I bet if you think about it you'll come up with some.

And the minute you think about it, you win the leadership game for this week.

 

<<<<<>>>>>

Next Post: Lesson Number Two I took from Alex's talk, and The Karma Factor

Copyright (c) 2008 Don Daglow.  All Rights Reserved.

Games Convention Asia Conference

(If you're seeing this post mirrored on Facebook or LinkedIn, the graphics look better on the original site at www.interactive-entertainment.net.)

 

I'll be speaking at the Games Convention Asia Conference on September 18-19 in Singapore.  It's my first time at this venue, but the people I know who went last year said they made a lot of good connections they would not have made at other industry conferences.  The conference is run by the same people who organize the Games Convention and GCDC Conference in Leipzig, Germany.

In addition to speaking on a panel alongside Arne Peters of cdv, I'm giving a talk called "How to Think Small to Win Big."  It's about how to look at design and development on small-footprint platforms like handhelds and mobile, and how to treat small games as opportunities instead of hassles. 

The organizers are interested in hearing about how we approached game design challenges when the only platforms that existed were small.  Since our first Intellivision games had to fit in a 4K cartridge, we certainly had a different set of issues to consider than on Next Gen platforms today.

 

<<<<>>>>

Copyright (c) 2008, Don Daglow