Encouraging Creativity

by Darius Kazemi on February 14, 2006

in management

So I’m currently reading a book called Creativity: Flow and the Psychology of Discovery and Invention, by Mihaly Csikszentmihalyi. It’s a study of creativity, honing in on the kind of creativity that (1) comes from an individual, (2) is recognized by others, and (3) changes a culture in some significant way.

One passage in this book discusses corporate creativity, and how Motorola in the early 1990s would attempt to encourage creativity in its engineers by holding brainstorming sessions for free association of ideas. The problem with this was that while many novel ideas were pitched, the management still needed (and didn’t really have) a way “to recognize the valuable ideas among the many novel ones, and then [find] ways of implementing them.”

This immediately brings to mind two practices that I hold in high esteem.

Google’s “20% Time”

Google has a very famous practice for encouraging innovation among its developers. It’s called “20% time”. The gist is that for 20% of the work day, Google engineers get to work on a pet project. The project has to be remotely related to Google’s business in some way, but it can be basically anything under the sun.

What’s nice about this system is that, aside from the initial purchase of a computer and an IDE, software pretty much costs only time to produce. If a carpenter wanted 20% time, her company would have to shell out extra resources like lumber and paint. In Google’s case, software only costs bandwidth to deploy, which means they can have things like Google Labs, where they can debut the “valuable ideas” mentioned in Csikszentmihalyi’s book, and those ideas can be validated by the general public’s use or disuse of the product.

(Edit 2/6/07: I just read that 3M had a “15% time” rule way before Google ever existed. So there. 3M did it first.)

Lightweight Prototyping

Chaim Gingold gave a presentation at the Experimental Gameplay Workshop at GDC 2005 on the topic of lightweight prototyping. You should take a look at the presentation yourself, but it boils down to code/content prototyping through multiple fast iterations of small-scale prototypes. When I say “fast”, I mean it: These are prototypes where a new iteration can be coded in a half a day or less. And when I say “small-scale”, I mean it: the example he gave at the workshop was tackling the problem of organically generating roads to link buildings together. The prototype itself was little more than a graph theory demonstration with slightly better art.

The basic idea is something I hold near and dear to my heart: prototype often, and do it in baby steps (as the P.I. of the electrical engineering lab I used to work in would say).

Where I’m Going With This

Games are software, and while AAA titles are not cheap to make, small game prototypes are very cheap to make. They can even be done with scrap paper and a pencil if you want.

What if a game company offered something akin to 20% time to its developers? What if the only direction given concerning this 20% time would be “prototype often, and in baby steps”? Skeptics will counter, “We’re always in crunch, we don’t have time for this crap!” Well, if you’re always in crunch you’re totally mismanaged and you have bigger problems than encouraging creativity. Furthermore, I realize that 20% is pretty hefty. That’s cool. What about 10% or 5% time?

I could imagine what might happen:

  • An artist goes out on a limb, building risky architecture that might not fit in with the design vision–but then, a designer sees it and gets inspired to create a new level to include it.
  • A graphics programmer says, “I wonder if I can get the engine to render everything cel shaded?” Maybe it’s not useful for this project, but the next game the company makes now has cel shading as an option when discussing visual aesthetics.
  • A designer builds a pencil-and-paper prototype for a completely alternative combat system to the one being developed. It doesn’t replace the combat system as it exists, but it does shed light on inherent weaknesses that were not apparent to the developers beforehand.
  • A developer dabbles in a completely different area than he or she is used to, and discovers that maybe they’d like to switch job roles. Or maybe that developer just learns enough about that other field to make working with people in that field a much easier task.

Just some idle thoughts about HR policy for that distant (but inevitable) day when I am running my own game company…

{ 4 comments }

Craig Perko February 15, 2006 at 12:22 am

I’m finding that rapid prototyping is more difficult than it’s made out to be. The pieces don’t end up fitting together as well as I want – although that’s probably my inexperience rather than a flaw in the idea.

Still, it means I do “moderately sluggish prototyping” instead. :P

Patrick Dugan February 15, 2006 at 10:43 pm

It definelty works quickly when you’ve got a stable platform to build off of. I discuss this in my next Escapist article, about the Storytron; you can litereally code some verbs and characters and Fate dynamics in less than a week and have a basic model of a game, and then decide on the rest of the boatload from there. I think this’ll make it easy for non-technical people with political or experimental gameplay/art concepts to test and express them in interactive form.

You’re definelty onto something, and I think the prototyping process lends a designer to having a solid system of metrics to accompany the underlying mechanics.

On that note, I’d like to hear your thoughts on this: http://kingludic.blogspot.com/2006/02/mdma.html

Darren Torpey February 17, 2006 at 1:05 pm

I’m glad you’re helping “break the seal” on this kind of thinking. The lack of creativity I feel when I read about how games companies work is stunning.

I can also imagine that it’s a big part of why some people — the kind of people we want working on games — wouldn’t want to join the industry and others are planning on leaving it. It’s not too hard to imagine someone getting far more creative stimulation from their game dev project on-the-side than they ever do at work.

Of course, it can’t always be, er, fun and games, even at a game dev company, but still… if Google’s doing it with people who aren’t explicitly in the business of creating (potentially) radically innovative entertainment, then what does that say about a much tamer and less inspired games industry?

My hope is that this kind of officially-encouraged creativity and out-of-box thinking time will start to flourish at companies that have a stable enough development model (and good enough management!) that they can both see the value of the occassional brilliant idea (Froogle, anyone? — actually, a good deal of Google’s best products resulted from ideas started in 20% time) and can also afford to give it!

Aprotim February 7, 2007 at 3:21 am

It’s worth noting, that one of 3M’s most ubiquitous and recognizable products, Post-It Notes, were basically developed by a chemist on his own time. I don’t know if this was part of the 15% time you mentioned, but shows what kind of value fostering this independence can be.

Comments on this entry are closed.

Previous post:

Next post: