What are the difficulties faced with releasing content in 2019 when it was originally described as a less aggressive year? [Why is game dev tough?]

Well, I think part of it is, with anything, there's a certain amount of aggression. With our roadmap, Chris uses it as the best case possible, whether that be somebody got sick and therefore a feature didn't come in on time. And that actually happened with one of our features in 3.6. One of our guys got sick and he was basically the main coder on it. And it's coming in for 3.6, but it's coming in late. And so therefore that cascades into other things. Even with 3.5.1, that did cascade a little bit into 3.6 and basically getting 3.6 out to the Evocati on time, which is unfortunate. This is the second release in a row that we haven't been releasing on time, and I don't like that, because basically we should be date-driven, not feature-driven on this. And sometimes a feature requires a little bit more work. There's too many bugs, when a director plays it, it's just not right, and it needs a little bit more time to percolate. And I think when you start on the feature, the view of it might be this, and then as you start working towards that actual release, the view of it is, OK, now it's laser-focused, this is what it is, and this is how it works. Here, all the edge cases are worked out, and then we go. But at least through all the game development that I've done in my life, it's always gone like this.

And we do still see a lot of the date-driven stuff. That was the promise we made at the beginning of 2018 when we said we were switching over to the quarterly date-driven model: if a feature wasn't ready, we weren't going to hold up the patch for an extended period of time like we did with 3.0. So that's why things like the 890 Jump moved to a 3.6.x. That's why customization moved to 3.5.1. We try our best to find that balance between not cutting everything out so that we can make a date, but at the same time making sure that as much of what we want to be in that patch is still in that patch.

For example, if we break down this quarter, the idea is, OK, we're going into planning week. The first week of July is planning week. And that's where all the directors and all the pillar producers and everybody come together and say, OK, I need something from your team, I need something from your team. And then at that point in time, it becomes a priority. I don't want to say nightmare, but it's basically, I'm juggling priorities, Sean's juggling priorities, Tony's juggling priorities for what we want. And then at that point in time, we go into actual developing of those features and you have X amount of time. So let's say maybe two to three sprints, or four sprints if we're lucky. And some features just can't be developed in four sprints. Some features can be developed in two sprints. Some of them take six or eight. And so then at that point in time, you start evaluating it and you start looking at it and saying, OK, is this what we want to put out as a company? And most of the time it has been a yes. And sometimes it is looking at it and saying, no, that needs more time to percolate.

And then, of course, there's always the unexpected, the bugs. Everything works fine until the integrations come.

No, and one of our guys lost a week just for integrating because there were some issues with Perforce or other things. There's a lot of these kind of outside factors. And the way I've always described game development is that it's an art. It's not a science. That's the truth.