One of the things I’ve been rambling on about a lot lately is the ‘How’ of NS2 development. That right now the ‘How’ is more important than the ‘What.’ Specifically, I spend heaps of time talking and thinking about the idea of ‘rapid iteration.’

In isolation, that all sounds a bit wishy-washy. The actual changes to the game are what matters, right? Everything else is baggage, provided changes are being made to the game. Wrong!

The process by which we figure out what changes to make, and then how we execute those changes, is critical. It isn’t a chicken and the egg situation: the ‘What’ is very clearly a product of the ‘How.’ If we create a better ‘How’ then we will tend to create better ‘What’, and if we create better ‘What’ then we create a better game.

Still wishy washy. Here’s a specific example of a potential ‘How’: No more builds. No more Build 2XX (Or XXX, if you’ve been around since the early days…). The phrase I’ve used in some previous posts is ‘No more monolithic-builds.’ But really, I mean it. No more builds. Any developer can push any change to the public at any time. With, if they so choose, no testing.

At this point, I can see peoples eyes widening through the internet. I’ve talked through this idea with countless people, and the response is usually something along the lines of “Are you actually trying to destroy the game?” I know they know I don’t want to do that, and I know I don’t want to do that, but damn I think that’s a very fair response.

Since forever, NS2 has had a monolithic build update process. UWE started it, the CDT maintained it, and it’s never changed. Various systems have sprung up around it to try to make it better. Processes, procedures, methods, stages, and so forth. It’s a system that despite everyone's best efforts, has made it hard for clever, smart, motivated people (Like those on the CDT, and the UWE team before it) to make good changes to NS2.

How do you have a software development where there are no monolithic builds? Theoretically, under a ‘rapid iteration’ system, we could push changes as often as our build infrastructure can compile the game. Imagine if we could get that time down to 25 minutes - That would mean, theoretically, NS2 could be changed twice per hour. (Right now, I can hear Brock, who has been working on that infrastructure, wincing and pulling his hand back to slap me).

That’s insane, right?

What happens to server operators, to people in game, to play-testers, to competitive play? What happens if a buggy change goes out that crashes the game? What happens if a developer wants to make a very risky change, that needs thorough testing? How do we even communicate how changes are being made, and measure the effect the changes are having?

Needless to say, many people have given me a stern talking to about this craziness. And they’re right too. There are a great many questions that need to be asked and answered before NS2 could adopt a rapid-iteration model. I’m asking them, the NS2 dev team is asking them, and a great many people I’m talking to and working with are asking them too.

The purpose of this post, is to make sure that discussion is as public as possible. There are more questions out there that I haven’t thought of, Brock hasn’t thought of, and everyone working on this hasn’t thought of. What other problems could rapid-iteration cause?

This is a really exciting discussion to have. Not only is rapid-iteration a challenging concept, it is a concept with huge potential. It is risky precisely because the potential pay off is so high. This is not an insane idea. Insanity is trying the same thing over and over again and expecting a different result. We (UWE, and then the CDT) have been using the same process for years now. This is a risky, crazy, exhilarating and potentially immensely positive concept.

So what do you think about it? What other problems could arise? How can builds be made available to play testers, when a developer needs something tested? How can the CDT be enabled to contribute changes to the game as well? What has not been thought of, and how could we solve it?