Author: by Christian Nutt, Leigh Alexander

Next-gen development can be challenging, to say the least, but it doesn't need to be hellish -- at the IGDA Leadership Forum 2007, Seven Studios director of engineering Kenneth Yeast presented a discussion called "How Not To Dine In Hell: Next-Gen Development Without Killing Your team," on strategies to preserve the sanity of all parties in the process. First, Yeast clarified, "Even places I've been in hell, we've produced great things... a lot of the time, the talk of how bad development can be gets confused with the fact that we can produce great stuff -- and this further confuses the issue, because then people believe that's what you need to produce great stuff, and that it builds the team... I don't believe this." Yeast was a part of the Lord Of The Rings: Battle For Middle Earth episode now-infamously documented by "EA Spouse," which raised issues of quality-of-life problems for game developers under the gun. As he recalled: "It was a perfect storm of misconceptions and misdirection, and many different things which led to the situation that caused that... we worked 60-something days without a day off, and those were 10 to 14-hour days." Yeast continued, "I want to not denigrate work where you go through hell to reach that work... I just want to separate the two." Essential Feedback An agile development process is one solution, and Yeast added that careful monitoring is another. "Not monitoring something allows it to go foul really quickly, but monitoring a process or anything allows you to adjust and change things," he explained. Feedback is essential, too -- development "in a vacuum," is not real iteration, he said. "Feedback comes in different parts of production. During work, I think feedback is very important for the actual close-up cycle. I'm surprised at how many studios don't ... it's the concept of the live updating of assets, the tools dealing with the game, as much as possible. It's easy for engineers to develop a system where it's easy for engineers to put something together... more convenient for the developers, but less convenient for the artists and designers." Yeast also highlighted how letting team members see their work in the process of development helps provide context to build the next steps, and quick turnaround is important to supporting this. "During next-gen development... you really want to see the quick turnaround. The way things work on the PS3 or Xbox 360 or PS2 or Wii are all very different. When you are iterating on a part of your work, animation, changing models, being able to see it in the in-game environment is very valuable." It also provides a good forum for feedback during work when the process has an agile system. "This is giving us the most gain, and the one I'm most excited about... this is combining the task, bug and proposal tracking into one live database that everybody works from. A task is something you work on. A proposal is something you ask for. Things that are in this that are being tracked -- people say they are working on a task, the tool tracks time for them. The data about the task includes time estimates." Info Sources Dev wikis are also "...very good for collaborative feedback, when I want multiple departments to work for each other. Email people tend to get distracted. Documents only have one particular author at that a time." Information stored in people's heads -- what Yeast calls "Move lore out into an open forum," to provide universal access for certain techniques or specific processes that are not common knowledge. That way, the system can always persist even if someone's out sick. Yeast says it's important to tie QA together between software and design. "We have a QA client in every game, no matter what platform it's on. This thin little client is used to send information back to the QA server, providing the build version and then any information that a designer or artist might want to be tracking, " he explained. "The immediate use is when you crash to package that data up... say you add a bunch of weapons, you want to make sure that these weapons are all being tried." He also recommended postmortems after every milestone. "You do need to keep 'em short, but it's more important what you do to handle this -- you decide on things that are actionable and things that can wait," he explained. Additionally, hacks can be reported on and corrected after milestones. "Postmortems after an entire product delivery are so long... that you become overwhelmed," he added. Continual Iteration Yeast is also a proponent of continual iteration as part of the process. "Just the nature of iteration allows you to understand the essence of the game. This continual delivery evaluation, decision making, and cycling once again means you are improving your understanding and you will end up with a better game... as you cycle forward you will find low hanging fruit that, if you weren't iterating, you would find at different times in the process." He cited iteration issues that can arise with the publisher, however, cautioning, "Never describe iteration as a fluid and unpredictable process... I had the fun experience of doing that once... because they [the publisher] went completely into a panic." He continued, "It's not that iteration is completely wild and unknown and 'hey I have no idea'... it's more exposing the decision making... you are exposing that and making the work and planning and decision making transparent." This transparency with the publisher is important, explained Yeast, because "...both of you have common goals. The game has to be great. It has to be delivered on time. That's how we all get a return on this." He concluded, "We're still a very young and dynamic industry. I think there are lots of changes that we don't think about as they happen... there are lots of dynamics that we should be prepared to change and adapt to... The changes that I think need to happen come easier through adaptation., something that changes more gradually and in pieces... a collection of small process changes."