if (game < design) betterDeveloper = true;

The GDC 2015 ( #GDC15 ) session titled “game < design” offered sound advice for an effective development workflow.

This session was delivered by Stone Librande  |  Lead Designer, Riot Games

Stone is a veteran game designer. He’s had a long and prominent career in the industry, working for such companies as EA, Blizzard, and currently Riot (for my students – Riot is the developer of League of Legends). Stone has seen the industry evolve over the past 19+ years. His insights on design carry a lot of weight.

As usual I’ll post the GDC session summary, followed by my thoughts and take-a-ways. Let’s jump right to it.

Session Summary

“Game designers frequently emphasize the “game” part of their title. In this inspirational talk, Stone will focus on the “designer” aspect. How is game design similar to other forms of design, such as fashion design, automotive design or industrial design? What can we learn from these other disciplines that will help us grow as game designers, both personally and professionally? Stone describes his own personal design journey and the lessons he has learned along the way. Topics will include design history, the lives of famous designers, techniques taught in design schools, and the philosophies of world-class design studios.” – gdconf.com

Hodge’s Thoughts

Stone began his session with an observation that has been nearly two decades in the making. He’s attended GDC every year strait for 19 years. Every year he gets together with his fellow game designers, and they spend their time talking about making great games. Rarely, if ever, do they talk about design.

Stone then spoke about the larger world of design processes. He addressed the fact that it’s a part of every industry, and that it needs more attention in ours. I’ll break down the key points I’d like to remember.

1. Research and evaluate the design process of great designers.

The first designer brought up was Leonardo Da Vinci. What Stone found interesting in Leonardo’s designs is that the process doesn’t go from idea, to sketch, to prototype. Those three phases all intermingle in a more organic flow. The idea might start as the sketch, or building and tinkering might first create the idea. It’s a break-a-way from the traditional order of operations; brainstorm, document, sketch, build. The pattern of operations can change per idea. Whatever part of the design process inspires an idea is what comes first, and at anytime one can jump between stages; or, you can think of it all as one stage.

Other designers were discussed. One was noted for the design tactic of creating miniature versions of many product ideas in order to find a handful that are worth putting into full production. From the rest of this portion of the talk I took away that successful design often includes test runs/production on a small scale. In the world of software development this is expressed as the idea, “fail faster”. I first heard this idea from Rob Walling who is an expert on self funded start-ups. The concept is that one rapidly develops as many ideas as they can, into working prototypes. The developer then soft launches them to a select crowed. The couple of ideas that gain traction with audiences are then developed into fully polished software products, with formal releases.

While the information on this point wasn’t entirely new to me, I had not yet heard it discussed at length within the game development community. This is exciting not just because it’s good information, but because this is exactly what I’ve been trying to express to my Interactive Game Design class at CART. For those that don’t know, my course at CART is for high school seniors, and combines the subject of game development with their English requirement. The English portion of my course is delivered by a properly credentialed English teacher. We work together closely to present literature that will help them with the “design” portion of our “game design” program.

This year we’ve looked at the lives and design processes of Bruce Mau, Daniel Burnham and Frederick Law Olmsted. My students often feel like we’re stretching to try and include this material as an important part of game design. I feel like the connection should be obvious. Perhaps we do need to take some time and rethink how it’s presented; or, perhaps seeing the connection is something that simply takes a few years of experience to reflect on.

Here are a couple of design books that I’m personally recommending:

2. Create your own design process.

The second portion of Stone’s presentation focused on taking information about the design processes of others, and then formulating one that is custom tailored to you and/or your team.

The global design company IDEO invited him to guest speak about the design process of games, and companies he’s worked with. He hailed IDEO’s methods of bettering themselves. Noting their desire to bring in professionals from seemingly unrelated industries, and learning from their experience.

He reflected on the design processes he experienced at Blizzard, and EA. He also explains the design process of IDEO, and then revealed his personal dream process. The info graphic slides he included explain those well enough; so I won’t detail them here. You can view the images, and interpret the information (with the exception of EA, and I’m sorry IDEO is blurry).

Blizzard North Model
Blizzard North Model
Stone's Dream Model
Stone’s Dream Model
IDEO's Model
IDEO’s Model


Stone admits that his dream process is just that, a “dream”. It’s the model to shoot for, but we are often doing work for clients (often the players) who like to jump in at any stage and alter the flow of work. We need to account for that. Perhaps create channels that allow the client to input their ideas at any point, but funnel that input back to an idea stage.

Due to factors such as individual creativity and design habits coupled with client demands, there is no “one size fits all” design process. Stone emphasizes that his dream process is HIS dream. It’s not necessarily right for everyone. This is exactly why we need to study and discuss the processes of others across many industries; so, that we have a strong foundational knowledge for figuring out how we best work.

There will be at least one more GDC 2015 post; so stay tuned, and thanks for reading!


Leave a Reply