 |
|
|
| |
Interview: CCP's Ward Talks Getting Agile With EVE
by Christian Nutt, Chris Remo
|
|
| |
|
April 15, 2009
|
| |
By switching from a "waterfall" development timeline to the agile method, EVE Online developer CCP was actually able to release Apocrypha, its biggest expansion yet to the space-based MMO, in less time than it took to release previous expansions.
Here, EVE lead designer Noah Ward talks to Gamasutra about how the team's new strategy of two-week sprints adapts well to the inherently-ongoing nature of MMO development.
He candidly shares some of the challenges in creating the free-to-subscribers Apocrypha expansion, which added new vessels, wormhole exploration and a new NPC faction -- and reveals how modular "coreifying" of key EVE assets allow the team flexibility in working on "other projects."
How did your development work before, and what made you change over?
We used to be on a waterfall development schedule.It worked that we would ship something in Winter, and then we would start again in the design and programming and key way phase -- approximately two months for the various phases -- and every six months, we would release something.
But now that we've switched over, we don't have these huge waterfall phases anymore, it's just iterative, agile two week sprints, and we have a demo day at the end.
Every two weeks, a demo day? What's that like?
Demo day is all day long; each team has twenty minutes to a half an hour, depending on what they did throughout the whole day.
And then there's an integrated demo, where it's only in-game stuff; we don't show any of the tools development, we don't show any Excel documents or PowerPoints --we just show working stuff that is going to add value to the game.
Every two weeks we do that -- and it's just amazing to see how much is actually produced in those two weeks.
What have you noticed as far as what's different versus your old method?
In the old waterfall method, you just had a bunch of designers off in a corner doing their designs. Then it would go to the programmers and they would bang away at the programming, and then... they would say, "Well, this design is broken; OK, start over to four months ago."
And so this agile stuff... I'm really gung-ho about it.
That seems to make sense also for MMO development, which is just inherently ongoing, as opposed to deadline-based. Previously, you had a stricter expansion schedule, though -- how long were you developing Apocrypha?
Well, it started in November. We have a yearly Fan Fest in the Winter, in Iceland, and every time that's coming up, everybody's getting their presentations ready.
They're making sure that the code we're showing off is polished, so everybody was in the frantic crunch mode before it.
"The players are coming! They're going to see! We have to have it by this day!" So we were doing that, and then once that was over, a week for some rest -- but then, we were straight into development of Apocrypha.
You actually developed Apocrypha in a quicker time frame than previous expansions -- but it's also your largest expansion yet. Is that due to the agile methodology?
The agile thing has really helped us, but also the number of people working on it is much bigger, because as I said, we took people off of little side projects, threw everybody in the cauldron and stirred it up.
We're doing something that our CEO likes to call 'Battle Tested': We've got a group of programmers under the core cell, and they make CCP's underlying technology that's going to be used in any other upcoming games that CCP may or may not be working on.
Is that a full-on internal philosophy? Can you explain?
The 'Battle Tested' philosophy is basically that we build stuff, and then it works in EVE, and then it can also work in other things.
So, the guys who previously were working on something else could come into EVE and start working on the same code base, and start developing features for EVE that would help in the other games that we're working on as well.
Since EVE's been around for six years, at which point did that modular code and tech philosophy creep in? I would guess that at its inception you probably weren't planning ahead for new products.
No, this is sort of a new thing. Previous to the merger with White Wolf, we didn't really have any reason. There were some people talking about what kind of other games might we want to do.
But there was no, "Hey, what if the EXE for EVE was just, you know, we could just drop in different content and it would be a different game? Wouldn't that be great, from a business standpoint?" So.
Is it really that modular, or is it an oversimplification?
That's an oversimplification, but if that's where we want to go with it, it's getting to that stage. We've basically being 'coreifying' a lot of the different components.
You moved to agile, but does it also involve restructuring your staffing, in terms of how people are organized for working on a project?
Yeah, we have been. It's been a little bit of "growing pains," trying to get this all to work right. And sometimes, there are conflicts between our top 3D FX programmer guys and what exactly it is that they're going to be working on.
You know, one producer really wants his lighting system and the other producer really wants his animation, and that kind of thing. So, there's some juggling, but we work through it, pretty much.
Any large-scale, collaborative creative effort is going to have those kinds of issues, but it sounds like you really are convinced that your productivity has been massively increased.
Yeah -- we really are convinced. And the CEO [Hilmar Petursson] is really convinced, because he can walk into that hour-long integrated demo once every two weeks and see all of this stuff that's been produced by everybody.
And it's also really cool, because other people can have a lot of input on it; they watch the demos and they go: "Well why did you do that?" or, "How come you didn't..." and then two weeks later, it's been tweaked slightly, to take that input into account. So it's pretty cool.
|
| |
|
|
And so this agile stuff... I'm really gung-ho about it."
So their problem was communication. I wonder if they really solved it or if they're just misapplying a different method now and just happen to have better communication by coincidence.
It seems as though using an agile system has shrunk the scope and shortened the workflow cycle, so that there is less downtime, and if something doesn't work you've only lost two weeks, not two months. There is a working prototype for a smaller chunk of the project in a two week time frame, instead of hammering away at a project for months and then realizing you have broken code in your test prototype or a major issue programming something the way it was designed.
Not that all waterfall processes work as above, but it sounds like that's how it was working for them. In this instance the agile process has helped their workflow.