Lessons from The Unfinished Swan's unique development journey

The Unfinished Swan began its life as a student prototype before it achieved acclaim on the PlayStation network created by Giant Sparrow's 12-person team. It's something of an unusual journey, but creative director Ian Dallas says important takeaways from his education at USC's Interactive Media division helped him flesh out his vision and create a fully-fledged game with a major publisher. In the game, players explore the mysterious world and its storybook narrative by splashing paint on the environment to reveal the shape and detail in its white landscape. As part of his fellowship, he'd make a new prototype every week for faculty advisor Marc Bolas, and The Unfinished Swan came from there. "At the time, I was interested in how people move around space," he muses. "That's what ended up segueing into this whole Unfinished Swan... monstrosity." The prototype debuted at 2008's Sense of Wonder night, and a YouTube video caught Sony's attention. The students signed a publishing deal, somewhat unusual at the time -- iOS, Android and other indie-friendly platforms were less accessible. "For us, it ended up being a really good decision, because the game we wanted to make was a little bit bigger and lusher, and that's something that really benefited from having a publisher involved," Dallas says. More interested in scope and quality than in financial returns, for him it was a good decision. The game also came in 400 percent over budget and well behind schedule, he laughs. Some of the most important things he learned in school happened outside of the classroom environment, he says. Having the opportunity to dig into tools like Maya and Microsoft Visual Studio and pushing to use them in new ways was valuable. Fluency with the core tools helped make the world richer in the game's journey from prototype to full game. "Knowing how the tools work... allows you to pivot and solve the problems that come up," he says. "That's where you get into the really interesting territory." Designing for any kind of larger games means you end up spending most of your time debugging, at least on the programming side. "You spend a lot of time just tuning, and figuring out how to make things just slightly better, and being really fluent in the tools gives you a better insight into how they work... the more you know, the better." Being exposed to miscellaneous tools that aren't core to his daily work also helped Dallas. USC sees much cross-pollination between the cinema team and the ineractive entertainment team in terms of understanding and sharing practices for resources like AfterEffects and ProTools. Familiarity with these ended up being "really valuable." "Instead of writing a dock for the animators, I could make... a really crappy thing, but it actually moved around, and it was much more helpful," Dallas says of Unfinished Swan's animated story portions. He also learned the importance of negotiation, and suggests strongly identifying what elements are most valuable to you as a developer versus what elements add the most value for the publisher can help with the give-and-take of those deals. And having the peer support from the USC scene mattered, both during the development process and during the equally-beneficial festival circuit. The challenges of showing at festivals can also be learning opportunities: "The first day on the show floor you have 100 people playing the same tiny section of the game, and they're going to break it!" Dallas says. Being able to edit the game on the show floor is "empowering," and allows developers to test out different audience feedback -- and also eases the stress of having a game crash as new people try it for the first time. Once the team began to grow and development of Unfinished Swan as a full-fledged game began, Dallas initially wondered if a producer was even needed -- choosing to have one turned out to be the right decision. "If you don't have somebody to jump on grenades, nobody's going to get any work done," he laughs. Frequent playtests are clearly good for design, but are also valuable for giving teams a sense of investment in their work. Everyone is motivated to have things ready to share at the next test playthrough. "Games are a marathon; it's hard to know three miles into the marathon if you're really on pace. But having weekly playtests is a good gut check for you, to see [how] things are coming together. It gives you some fail points, to fail gently." He advises keeping task management as simple as possible -- using Google Docs and a spreadsheet was available and frictionless for everyone, versus having complicated workflow software. And a weekly team lunch gives the team an opportunity to get out of the office and to bond, and to see one another as people from various disciplines versus fellow employees. "It's interesting how the process of making a game changes when you [pass] around seven or eight people. That was the point it stopped feeling like a family, and a little more like a company. At seven or eight people is where you start to need another layer of management." This means huge improvements can come late in development: "At the end of the project, you're like superheroes... and the biggest factor is that you actually know the game you're making, by that point. And you have better tools that do exactly what you need to do for your game," Dallas says. For Gamasutra's full GDC 2013 event coverage this week, check out the official GDC 2013 event page.