It's been stated that we're going to have four big quarterly patches throughout the year. How are we going to make sure that we make those dates?

Okay, so I have to go back to last year. Last year we had, as we talked about, a massive amount of technical work as well as feature work to get 3.0 out. And that was just something we had to do to get us where we are. A lot of that work was about getting the basics.

The foundation.

Yes. And yes, we wanted to get it out a lot earlier. And one thing that we want to do regularly, because it's important to us, just as much as I'm sure it's important to the community to have regular updates, is because we want that feedback. We want to get versions out there. That's how we get that iteration. And iterating is really important in game development, whether we're doing it with the community, which is awesome, or internally. Usually in a normal project there's a huge amount of iteration that you'll never see: you do something, internal test groups give you feedback, all that kind of stuff. So last year, doing all this work was a big deal. And so what we talked about is, as soon as we get 3.0 out, we want to change to a completely different model. And the model is going to be date-driven, not feature-driven.

So this means, yes, we have a number of features, bug fixes, polish, whatever you call it, we want to do for a certain timeline. We set it up, and that's what the team works towards. We give ourselves a period of actual development on feature work, and that development is going to run typically to about 50 to 60% of the available time. And once we get to that level, hopefully, and it won't happen every time, just so you guys know, but we're going to work very hard on it, the vast majority of the features we want to put in are worked in that time. Then the team moves to a completely separate model, which goes from feature development to close-down: bug fixing, polish, minor bugs and so forth. So we get to this point and we go, okay, which features are done? Great, all those are in 3.1. Any features which have not made it, we go, okay, you're now going to be in 3.2, you're going to be in the next patch. And we're going to take everything that's done now, we're going to polish it, we're going to optimize it, we're going to do everything we need to do to make it much better. And then we release in our date time.

And it should be very doable and predictable that way, because what kills you is when you turn around and say, I really want that feature in, and it hasn't quite made it, but another two weeks and it'll make it. Another two weeks? Well, we'll polish here, but we're going to keep this feature going and hopefully make it. The problem is, as you're developing that feature, you're creating more bugs, more issues. The people who are typically doing the feature work are the same guys you want fixing bugs. So it creates this perpetual cycle of things slipping. And so we're going to be very hardcore: did it make it? Did it not make it? No? Close down, move on. And so you're still going to see the same features, but it may be that sometimes they slip to three months later. But the beautiful thing about this is that as a development team, we get great progress building it, and we also keep stability, because we're on a cycle where we have to keep GameDev stable, because we have to use it to keep going out and publishing live to the community. And it means the community then gets regular updates. If you're in Evocati or the first waves of PTU, you're probably only going to go from a live release six to seven to eight weeks before you see the next build. So people are seeing new stuff come online, they're seeing the delivery of that, they're seeing results a lot quicker, rather than us going away for a year to do this massive feature set and people going, okay, well, I've got nothing to do for a year now. And it's not just really cool for you guys in the community, but internally for the dev team it's a massive morale boost when we're getting stuff out there and people are playing it and giving feedback, good and bad.