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.
The idea that programming resources can be wasted is completely alien to me, in a good way. I've always been employed in non-video game industry companies who liked to build proprietary software to support their main business, but also liked to run lean on programming resources. The result was a near-infinite backlog of programming work to be done. If a programmer wasn't attached to a particular project, they would be fixing bugs, upgrading technology, improving configuration management tools and build scripts, standardizing and documenting processes, or creating prototypes on crazy ideas that would make everyone's life easier and more efficient. But in my industry, programmers were attached to projects about 98% of the time, so a lot of that good stuff just wouldn't get done.