In-Depth: Ugly, Quick, And Dirty - The Power of Working Fast

At the IGDA Leadership Forum 2009, held last week in the Bay Area, Luna Cruz, producer and designer for Asian casual game developer Boomzap (Frogs In Love), discussed the company's unique approach to creation, which calls for full-length prototypes, as well as its distributed development process, which uses contributors across the region and beyond. The company, which currently focuses on PC casual download games, has 18 people and organizes its development into small cells of four or five, relies entirely on a virtual office paradigm -- and is a "results only work environment", meaning that what is measured is your output, not butts-on-seats time. Cruz's team is six, which she describes as "extremely bloated" for Boomzap. However, the small team and results-oriented workplace has its benefits, she says. "This all contributes to the fact that prototyping really works for us. It's about quick results, and that's the only way you can find the fun in the game." Quick and Dirty Boomzap practices what Cruz calls "quick and dirty prototyping". "We are all about speed and efficiency. We like to build prototypes as fast as possible," says Cruz. "We like to keep things ugly till the last possible second. We want to be able to have the freedom to revise things, or scrap entire features, just to keep the game fun." The company has some unusual practices -- during publisher pitches, of course, the games are brought up to a high level of polish during a three week production period. But once they make it through that process, the game reverts to Boomzap's "keep everything ugly rule." The game is developed as a black and white prototype as the art team works on the final visuals -- with the designers delivering the sketches. And the developers deliver a full, playable build of the game every day. "The purpose for this is that we want to be able to test if an asset or an idea is good or not," says Cruz. Cruz says, "We always actually say to each other, 'If it's not in the build, then it doesn't count.' That means that every single day the developers have to put the work in the build. They could be wroking on the most beautiful piece of art, but if it takes two weeks, it's useless to us." Artists do have more time than 24 hours to create final art, it's worth noting -- but it just doesn't make the build till it's ready. Gameplay must always be evolving, rather than waiting for art. Also, Cruz notes, "We share every build with the publisher, even our crappy ones. Because we share everything and keep things public we try and keep our builds consistent in quality." It requires some publisher education, says Cruz, but pays off. "You have to find the right publisher, as well. They're used to seeing shiny things." "Because we are working virtual we have to make sure everybody can put their work in the build without bothering anybody else," says Cruz. The company uses a MS Excel spreadsheet with all assets and gameplay elements tracked -- which exports to the build, automatically, without programmer assistance. Keep Things Ugly "At the end of the day everybody puts their work in the game. The problem with that is that not everything takes a day to build," says Cruz. "Not everything can be done in a day, especially if you want it to be pretty. Our trick is to keep things ugly as possible, until the last possible second. We use a lot of placeholders -- and I mean a lot of really crappy looking placeholders." According to Cruz, this approach lessens wait time and dependency, for all disciplines. At the prototype milestone, the entire game is playable -- in a "terrible looking" form, sure, but it can be completed. "It's only when we're happy with how the game plays in black and white that we move into rough playable," says Cruz. "You'd be surprised how much you can find the fun. We're not about being shiny, we're about being fun." Cruz says that artists have the biggest problem with this working methodology -- but the rest of the team just encourages them to dump in art as soon as they can. "When the publisher says the puzzles make sense, and maybe they're okay, that's when you go into something remotely pretty," says Cruz. "All of that, really, is to reduce the cost of change, so we can scrap any feature until the game is fun." Designers, of all disciplines have major guilt issues with cost, says Cruz. "As a designer there is a lot of guilt, I think," to not abandon bad designs because assets have been created. "Having that second guessing can be really detrimental if you were right, and it wasn't good in the first place, and you left it in." However, "if you did quick and dirty prototyping, the cost of change is so much cheaper." Ranking Tasks When the daily build comes in, "I would go through the build every day and make sure it works, and I check them off, and if not, I send it back," says Cruz. "The harder question is, is it fun? We do a team-wide playtest. Everybody gets on Skype, and everybody plays a particular room or a sub-game, and we find out if it's fun, and how long it takes," says Cruz. The team ropes in friends, family, and the publisher to find out more. "You get a whole long list of notes," she says, but "if you're not careful you could overdesign, you could have feature creep, and what we do to deter that is have 'rank'." As the producer on the project as well as a designer, a responsibility she shares, Cruz is in charge of the daily build -- and maintains a spreadsheet on Google Docs which lists all of the tasks that the game requires for completion. "Only one person really owns the task list. As the producer, I'm the only one who can prioritize it, who can assign it to people, and who can scratch something off as done. Which is really good, because someone will think something is done, but I check it." "Anything priority 3 or 4 we hide from the team," says Cruz. "This means they won't waste their day doing 10 little things and instead attack the major bug that they're afraid of." When it comes to publisher requests, the rank system translates -- Boomzap explains what can be done in a reasonable time, and spells it out. "We taught them how to prioritize stuff too. We told them, we can do A but that means we can't do B and C."
 The big problem with working so rapidly, says Cruz, is that "you have to learn when to stop revising. That is very important. The problem with any rapid or agile environment is that you can just prototype forever -- you always have a better idea. So you have to have hard and fast milestones." Says Cruz, "In our company anybody can tell anybody else their idea sucks. But having a main designer really helps. But that doesn't mean I always get what I want. If I give an artist a level... She says 'wouldn't it be fun if we change this for that?' because we encourage everyone to speak up, they know that if it's a good idea, you'd take it."