GDC: ThatGameCompany's Santiago, Hunicke Talk Exploratory Development

Game development is one of the highest-pressure, most anxiety-inducing careers there is. An exploratory development process can be a solution, but only if it's managed with confidence and honesty, say ThatGameCompany's Kellee Santiago and Robin Hunicke. ThatGameCompany's process emphasizes exploration -- especially long prototyping periods that are highly flexible, and the pair shared personal insight in a talk at GDC 2010. "We know it's expensive. It's costly; you have to throw stuff away, you have to wander looking through the truth, and you have to explain it to other people -- and that can be really difficult," says Hunicke. Santiago says the TGC team evolved their methodologies first-hand after dealing with an extremely stressful period for critically-acclaimed Flower. "Even though we had a fantastic response from the public and from the press and our publisher, they actually asked us to spend more time and money making the game even better," she says. That made the team "generally miserable," she adds -- morale at TGC hit an all-time low. So the process had to change, she continues, based on two assumptions: "We could have done better," she said, "and two, it was unsustainable. TGC was going to collapse if we continued on the path we were going on." Sustainability matters, says Santiago. "Fantastic games and a lifetime of successful video game development are not two separate things," she says -- her philosophy is developers don't need to "starve and suffer... to create truly beautiful works of interactive art." It was that philosophy with which Santiago and Jenova Chen founded TGC, she says, identifying a pyramid of qualities they wanted to build into their team culture to make it thrive -- but at that time, she says they were failing at all of them. The picture was grim: There was no motivation toward common goals, with individuals getting lost in personal objectives. No one was invested in decisions, people felt a lack of responsibility, and it led to a lack of trust in one another. "Development of a game is a great excuse to dismiss all these problems," she continues. But there's no motivation to invest in ideas when one fears being responsible for all the work associated with them and people don't trust each other. People fear appearing weak too, so they work solitary rather than approach a collaborative process. So over the year, the team focused on developing better-defined roles, and they worked better to distribute accountability to give everyone some feeling of ownership. Hunicke says one thing that's essential about accountability is having a goal, not only for the project but for the company. There are many elements that come into play when thinking about a company's identity -- motivations can be anything from art to craft to profit. But whatever the goal is, everyone on the team should share it, she advises. Composition of a team can change depending on what everyone's motivations are not just for the company but for the game, and even for working together as people. "It's very important to figure out what your priorities are and where everyone stands," says Hunicke. But it's not so simple as merely choosing roles. People can be tempted by titles, like the desire to be a lead designer -- "but the things that are required of a lead designer, especially in light of responsibility and accountability, can be very different than what you might have expected when you were playing Super Mario Kart as a kid," she says. And if everyone sticks to a strict role definition, it can create gaps in the team. "These are the sorts of things that make development painful," she says. If one member of the team isn't on the same page on a given day and someone else has to make up for it, "it can be hard to get up in the morning and be super motivated to fill in those gaps," says Hunicke. Knowing the project's scope is also important. "We're referring to the amount of resources that will be required in order to complete your game," says Santiago. Resources can be anything from time and money to personal sanity -- but the general scope should be defined up front. Since all games are creative gambles, says Santiago, "You don't want to bet anything you aren't prepared to lose." To allow for exploration in the design process, scope should be relatively small. In a pre-production process that involves many unknowns, it's hard to determine what shape that exploration process should take. Discovering the game that manifests the core idea of what the team wants to achieve can take a very long time -- and what allows TGC to spend so much time on it is that once they achieve the core idea, they can build it relatively rapidly. Digital distribution makes that easier because consumers have different expectations. Ultimately, the total time spent is determined by a sustainable use of resources, but once it's defined, the team must determine what qualities of a prototype will best serve the team in making forward progress in development. "This is definitely an aspect of your process you will discover over time," says Santiago. But TGC evaluates on three levels: Interactivity -- game mechanics -- art, and audio, and the goal is to bring each element to the same level of quality. It's a high goal that they don't always attain, but they aim to get as close as possible. "We're always a little hesitant to move on from a prototype if we haven't achieved these goals," she says -- however sometimes, due to other constraints, they have to. "You have to be flexible in your understanding of the final game," she says. The exploration process is about discovering what the game is. "Sometimes we find the game and it doesn't really look like the game we thought we were making at the beginning, but you know intuitively that it's right... it's just a gut check." "It's a creative endeavor," Santiago continues. "If you can't recognize it when you see it, it justifies throwing away all of the plans you made... and following what that goal is. It's like following your passion... that's the place where you'll find success." They make a calendar that defines the time period according to a lot of different goals -- each discipline has a different timeline. "It's like what I call a fake schedule," says Hunicke -- it keeps everyone on track to approach goals loosely on a timeline. Realistically, Hunicke says they know a game will take 20 months, for example, so they make a 20-month calendar. "We know that it takes more time to do our style of development and we plan for it," she adds. Morale may get low at the pinch points -- those items on the calendar that can't be moved. "That's natural; it's totally okay," she says. "Because we understand the difference between estimates and commitments." Although "it's your job to be good at guessing," according to Hunicke, it's critical not to hold oneself accountable for estimated in a way that makes them feel over-committed. "We're not a traditional agile team; we actually encourage people to admit when they failed estimating," Hunicke continues. TGC asks people to think in two week chunks and review that thinking three times a week. Over time, things get checked off, but things that stay on the calendar for a long time are examined -- is it unresolved because people are no longer interested in the idea or because it's no longer relevant? Calendar items aren't permitted to merely sit there causing anxiety. "We try to be really honest with ourselves about the fact that process improves us," adds Hunicke -- admitting problems, failures or lack of understanding is encouraged. "If it's not okay for you to say that to your fellow developers, you're kind of screwed." "I think there's just as much personal exploration," says Santiago. The smaller the team, the greater the impact of individual needs. "The process of development has to be flexible to the ebb and flow of individual lives." "If you think someone else on your team has to lose at whatever they're trying to do for you to succeed, then you're doing it wrong -- yet we see this behavior repeating itself over and over in our industry," Santiago continues. "You're on the same team, we all win together and we all lose together." There will be stressful times where everyone thinks the game sucks, but everyone must remember while they're all on the same page. "To turn on each other while everyone's already having anxiety is just a complete epic fail," Santiago says. Honesty is essential to make this approach work. "We can call a task easy in one of three cases: we really want it, we have no idea what it entails or we don't have to do it ourselves," says Hunicke, quoting a friend of hers. "You can't underestimate the value of being honest with yourself about the expense of individual tasks. It's not something that humans are good at because we're optimistic by nature, but it's definitely something that you need to recognize." "This can be an enjoyable conversation because you can celebrate the fact (like we are right now) that you're getting better at this every day," she adds. But what about answering to publishers? "If you've gone through some of the process that we've talked about, you've either determined how you work best and what your goals are for the project... or you've had these discussions as a team about what your goals are so you can express it to someone else," says Santiago. If developers choose to work with a publisher whose understanding of making games is completely different from their own -- "it's your fault if your games get canceled," states Santiago. "Not everyone who gives you money is stupid, and you shouldn't approach them like they are." The solution is to be as up-front and clear as possible, and continually communicate. For example, when TGC was supposed to have finished a prototype for Flower, they decided to admit they didn't think they had a complete prototype and had to extend the phase. This really prevented us from getting into a much worse situation later in development," Santiago says. "Please, please differentiate between your contractual commitments and your best guess as to what's going to happen." Make it clear that something in the design document is an idea targeted for exploration versus a decisive feature. "In general," says Santiago, "Don't be afraid to have difficult conversations. When you're working with such a volatile system, really the best tool you have available to you is just constant communication." Lack of transparency is what creates the worst conversations between developers and publishers. And how one communicates during difficult conversations can make a big difference, says Hunicke. If one approaches a tough conversation with a feeling of personal shame, it sets the tone. "If you have pride in the fact that you're making changes every day that are getting you closer to the game that you know is gonna be awesome and you recognize that bumps in the road are just bumps, you're going to come across very differently... be confident that you know where your game is. It's in your heart. They can't see in there, but you can." "Be honest with yourself and with everyone around you, because wandering is okay in every role on every projet until you die," she adds.