Stone Librande & Galactic Adventures
(spoiler alert: don’t read this if you’re planning on attending Stone’s lecture… I give away all his secrets)
Stone Librande visited my program last Friday to share some words of wisdom on game design (and the job of a game designer), as well as to show off a beta of Spore: Galactic Adventures. Stone was an exceedingly eloquent and friendly guy. I’d spent the morning preparing some snarky comments to make about Spore, but his disarming charm and humility made me quickly shape up and realize that he was somebody whose words I should actually listen to.
Stone got into game design from a past career in programming and an ongoing hobby of creating board games for his friends and family to play. One of the first slides he showed were these cute “board games” he made as a kid because his parents wouldn’t let him see PG-13 movies. His sister’s boyfriend would come home and tell him what happened in the movies, and he’d make a game out of it.
He started off the presentation with a controversial claim: if you want to be a game designer, you should be equally happy working on projects such as Spore, Braid, Disney Princesses, Ponyz, match-3 games, and board games. Of course, there’s a lot to be said for this sentiment: most of the time, unless you strike out as an indie and take on a significant amount of debt to fund your first (or second, or third) project, you’ve got to earn your chops in the industry working on projects you might hate. Andrew Stern worked on the AI in Babyz and Petz before teaming up with Mateas for Facade… and there are cool board games, like Catan and Twilight Imperium… right?
His main lesson was that if you’re meant to be a game designer – if it’s your core desire and joy – you’ll be able to work on a variety of different projects and understand how they all contribute to your understanding of how games and gamers work. Apparently the Spore team hired a designer who had worked on Ponyz, because he could articulate what he learned about design from working on the project.
My main takeaway from Stone’s presentation was the fact that iterative design is alive and well at some companies. We read plenty of pieces by Eric Zimmerman and Tracy Fullerton advocating the importance of iteration and playtesting, but the lack of case studies on their part (usually confined to small indie, serious, or academic artifacts) leaves one asking “but is this how the industry actually works?” At Maxis it certainly does. I remember reading an article by Chaim Gingold (one of our program’s graduates, and a Spore designer) that described numerous early prototypes of Spore built into other Maxis games. Stone used a paper prototype to help the team behind the Civilization stage of Spore balance the tank/airplane/ship units, and he constructed this sweet wood block game called NanoBots to figure out how the Cell stage would work.
Stone also worked on an early build of Diablo 3, and while working at Blizzard he attempted to create a Magic-style card game based on Warcraft 3. Every day he would tweak the cards a bit and bring a new stack for people to play with during lunch. After a week or so he realized that nobody was taking the Troll Berserker cards, so he decided to tweak their stats a bit. People started using the Berserker cards in their decks. Somebody alerted the Warcraft 3 dev team to this fact, and when they looked at their data they saw that nobody was using Troll Berserkers on Battle.net either. That week, a patch went out balancing the damage on the unit. For Stone, and for everybody in the room, this showed the value of paper prototyping and iterative design. The Warcraft 3 team had literally millions of data points to work with, but they couldn’t see the glaring fact that one of their core ranged units was underpowered… until someone made a hobby-level card game during lunch!
He also worked as a design lead (I might be wrong about the “lead” part) on The Simpsons Game. This part of the lecture was a lesson in level/world design. While designing the game, they had access to every episode of the Simpsons. Even with all this information, they couldn’t figure out exactly what Springfield looked like from an objective point-of-view. There were some fan-made maps that attempted to lay out the geography and compile exactly what happened at each location, but there were some glaring errors and blind spots in them. Then they found one episode with a tiny, super-rough sketch of the town, and they went from there. One thing they noticed was that in almost every exterior shot of the town in the show, one has a clear view of the power plant far in the background. They designed their map around this fact.
Their workflow worked thus: they cut out pieces of cardboard and placed them on a table. Every day when the team came in to work, they had to pass the table to get to their cubicles. Over the course of a few weeks, the sum effort of hundreds of tiny tweaks gave them a decent 3D layout of the map. Then they made some sketches in Illustrator (Stone tried pioneering a method of using shadows to display height, which did and didn’t work) and sent it off to the 3D team. Using the Illustrator file, Stone laid out all the hidden Duff bottles for the game and color-coded them based on difficulty. Having these maps helped the team coordinate their activites. All the design documentation was kept on a Wiki so that people could edit it as they came up with improvements. Seeing what went into the design of the game made me want to play it right away (and you can get it on Newegg.com for $10 new right now).
Librande brought five copies of Galactic Adventures, and we broke up into groups to design a mission in it using the Mission Creator. Stone was excited to see what a bunch of game design graduate students would do with the tool set. The package is incredibly robust. You can basically create up to eight independent Acts within each mission, and each Act can have numerous objectives (all of which you script yourself). You can tweak the stats, behaviors, and dialogue on every unit you place. There was also a team devoted solely to creating environmental effects for the Creator: by far the coolest effect was a Star Wars-style red-and-blue laser battle that you can criss-cross your level with. Terraforming planets is incredibly satisfying, and the architectural options are top-notch. I hadn’t played Spore for awhile, and the bank of community-generated creatures has grown so immense that you can basically find anything you want with a little searching.
I’m not going to lie to you, though: the level creator, and the scripting tool, are not really created for people who already know how to code/make their own games. Just as with any user-gen game (such as LittleBigPlanet), experienced designers are going to want to do things that the tool just can’t handle. Your captain avatar can’t ride vehicles (something we wanted to do for our little Spore remake of Lord of the Rings), and you can’t design cut scenes to link acts. The AI is good at appearing to know what it’s doing, but it’s still kind of buggy and sluggish (maybe this will be improved in the QA phase). But for both casual and core gamers ages 4-110, there are multiple levels of detail that one can go into, develop, and enjoy. I could definitely see using it to prototype missions for other projects.
Let this be a lesson to other game companies: during the time between beta and gold, when your QA people and programmers are busy fixing bugs in your game… send your designers around to educate and share their knowledge! You’ll get better recruits in the long run, and giving workaday industry folks some face-time does wonders for your company’s image in the eyes of students and the general public.