I've read articles on pre-production in software engineering. I even took a class with a project that was 75% pre-production (requirements, estimates, risk management, etc.) so going in I knew how vitally important pre-production is. It was interesting to see how it applies to the game industry.
I'm glad they pointed out the problem of not having a deadline. I've been in that situation myself, doing "design work" while just putting off the actual production phase because I wasn't ready to commit to what I had created.
Been there, done that... It's a tricky thing, working without a set deadline, it's where I am right now. These days I can tell when I'm just spending too long expanding and refining my ideas. I also have numerous factors that limit the amount of time I get to work on my projects, so spending too long in pre-production is risky because it'll cause more delays. It's why I try to prototype as I design these days. So I never really let myself get away from the knowledge that at some point it needs to stop being ideas on paper and become something tangible, and I have elements to build off of when it comes time for full production.
As far as the unused programmer issue, it seems like more of an issue with games that use existing engines like Unreal. If the programmers are building an engine from scratch, they can still spend time building level editors and other custom development tools without necessarily knowing all of the mechanics. If any unknown functions are properly stubbed out and isolated from the rest of the program, they can be quickly filled in once the details are available from the pre-production team.
I'd say this depends. You could lay the foundations for the engine, but without knowing all the mechanics of the game you could find yourself having to go back later and switch around something which is now firmly built in. It might save time and give the unused programmers something to do, but if you're not careful it could also become a waste of time, manpower, and money if you then decide on features that mean parts of the engine need to be thrown out and worked on from scratch.
So, snooping around Facebook I stumbled upon this from Extra Credits:
Also, we had to cut a section on good vs bad preproduction methodology. It depends as much on how you use that time as how much time you have. (I can't find the link I was looking for and have to get back to work, but there is a really good article from popcap about doing prototype centric preproduction)
I'd be interested to hear more thoughts on the idea of using iterative prototypes during the pre-production process, since it's what I myself try to do, but the only mention I could find was a brief segment in an interview on Gamasutra.
"Our path of development is extremely prototype-heavy," said Gwertzman. "We'll make half a dozen prototypes, and pick just one of those to be a hit casual game. And once we develop that one, it's a very iterative process. It's a sandbox model. We try different things out, and find out what's fun. Only when we find out that the core mechanic is fun do we worry about the art, content, and all the other little details."
"We really obsess over the core game mechanics. In a game like Bejeweled, hardcore developers look at that and might think it's kind of...it's very easy to kind of dismiss it, but we literally spent weeks on just the right way for the gems to fall when you make a match. In a game like that, it's little details like that. How does it feel? Getting those little details right is what we prioritize. So when we're designing a new game, we'll spend months and months prototyping core mechanics."
I'd definately like to see the thoughts of other developers who perhaps use similar methods.
Any of you guys know of any articles, or have any thoughts of your own? I'd be interested to see the pros and cons of such a methodology when it comes to pre-production.
As a member of the Black Mesa team, I can quite safely say that "no deadline" turns into an enormous problem. You pretty much NEED some level of pressure and fast-pacing to development not just to make sure it releases, but to make sure everything's coherent with each other. You spread out development time too much, and you forget the great lessons you learned.
Right I have rolling this thing around in my mind for a while now and I I think I have a coherent thought on the matter.
The big issue is the programmers twiddling their fingers for a time. They are doing nothing or very little. I am going to assume that there are other production guys who also are not doing much, such as music, guys and animators and the like. What I am getting at is, that I assume there are mini production teams in the people not doing anything. If this is not the case I am sure some of the programmers have some experience in those fields. So here is the idea (in a nutshell): Have the out of work people make their own game a la the episode on innovation (an old one). I am sure the guys on the floor also have ideas and thoughts on games to make so tell them to go do it.