I believe you mean THQ? We HAD to be out of studio by 4pm. I always thought it was due to security with the current build data but now you mention it, we did have a lot more social time
Yeah, I think that was it. Still can't find the article! Also, can't help but think that's not such a good example anymore, what with THQ going bankrupt and all.
Since we seem to be on the topic of the game development process: Alex, how do you feel about small projects like your own hiring more people as they become more successful? That is, people who would be up to their arms in coding and testing and coming up/implementing with new features rather than doing more independent work on commission. (I'm not saying you need to hire someone btw, just wondering ) If I was running one it would be exciting to have faster completion and brainstorming, but I'd be worried about more and more time going into management and about losing creative control.
It's a complicated question. First of all, hiring a full-time programmer is really expensive; a project would have to be considerably more, ah,
successful than Starsector currently is to do that. You could possibly come to some kind of percentage arrangement, but that seems difficult to get right, unless the people know each other well and start out as partners. What's fair? How do you ensure that the person then pulls their weight?
Spending more time managing is a concern, of course. As far as ceding creative control, I think you have to be willing to do that if you're going to work with other people, regardless of whether they're a programmer/artist/sound designer. But really, that's not so much "ceding creative control" as it is letting people make awesome stuff they're good at making without getting in the way too much
I definitely *want* to have a shorter release cycle, and will do my best to make that happen.
What is your opinion on dividing releases into stable and unstable builds? Unstable builds could be released only in the forum whenever a new feature is implemented, accepting all the untied ends and, well, instability.
They could help to counter some issues a long release cycle has. I'm not talking about simple impatience or fading interest here. I think many of us feel increasingly disconnected with the current state of the next release, which means it gets harder and harder to understand and appreciate the new features you introduce in blogposts and patchnotes. That in turn means that it gets harder to utter constructive criticism, make suggestions or plan mods.
Yeah, I definitely caught that comment from mendonca and it makes sense. There are lots of potential issues with releasing unstable builds, though. First of all, 0.6a hasn't been in a releasable state - even as an "unstable build" - until very recently, just because some critical UI elements weren't in place. The other issue is that feedback on a build like that wouldn't be very useful, whether its bug reports (for things I already know are broken) or suggestions (for things that are incomplete and thus shouldn't be judged on their current merits).
Also, a lot of the time I'll be working on one feature while waiting on some assets/internal feedback for another, and when things are interleaved like that, it makes for pretty efficient progress but, unfortunately, less clear "this is releasable" points. So what happens is before a release there's a period where I've stopped adding features, and switch to playtesting while waiting on some assets (which, incidentally, is the phase 0.6a is in now.) For unstable builds, the time currently spent playtesting would basically be wasted. Unless you create a code branch, but that's a considerable pain to deal with, and, again, takes more time.
But really, for me it comes down to what I'm comfortable releasing. I'd hate for something totally busted to end up in the hands of someone doing a preview, for example, and screenshots of things tend to find their way around. That said, I really don't want the next release to take as long as 0.6a did!