Extra Credits: The Pre-Production Problem

This week, we kick off the Guest Art Marathon with a discussion on why games really need to start making time for pre-production.

Show Notes:

This week's artist: Molly Maloney

Audio Version:
Download

Recent Comments:

  • 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.

    This of course has to be structured somehow. There has to be specific deadlines and effectively a number of mini pre-productions. The name of the game here however is not to make the big AAA title or anything like it but to make the smaller indie type titles. What you want is you Beat Hazards, your Jamestowns, your VVVVVVs and all that jazz. This means that often the preproduction does not need to be as long and the developer will have more games to sell.

    Now to make this work the programmers has to have some stake in the game. They need to get a bonus based on how well the game sells (and of course the recognition for their talent, should they make something great). Of course investors also need a bit of the cake on this one. What this means is that the programmers will have something to do, they will be working on their own "baby" and they will have a financial stake in the product.

    Now it needs someone more knowledgeable then me to work out the details but here is how I think it should work:
    Investors will be told that by paying into the big project they will also be paying into x number of smaller projects any one of which might be the next Minecraft (unlikely but we are trying to sell them the skin before the cow is killed here). Some investors might shy away from this approach but some might see the prudence here. By betting on more horses you increase you chance of profit and reduce the chance of a loss. The developer themselves will probably have to swallow that their cut of these minor projects will probably be lower them expected but to them the main issue is to make back the money lost on having these "out-of-work" programmers employed. The investors cut should be negotiated as normal (or simply have it be the same as the cut for the main game). The programmers cut should be a function of how many people are on the specific project and on whether or not the cost for the person has been recouped yet. One programmer working alone might get 10%, 2 would get 15%, 3 would get 18%, 4 would get 20% and so on (shared equally if the group has no internal agreement and in some other way if they have an agreement - be strict with documentation on this). They would get a larger cut when the cost of them has been recouped (the 8,500 dollars a month). I am sure other people will have other ideas on how to cut the cake but the key is the financial incentive for the programmers.

    Now distribution becomes a problem in itself. How do you sell these games. Fortunately there are several digital distribution options these days. Any and all of these can function as distribution platforms for these games. An extra option would be to make compilations. Smack all the games made in a box and sell the lot. How well this option will sell is debatable. A third option could be shipping it in a special version of the main game with a higher price. Also dubious. This is one area where my head just says digital distribution over and over. Remember however that if the games are ready start selling them right away. Don't wait till the main game is done (unless the 2 games are somehow linked naturally). The revenue might come in handy and the bonuses that your programmers get might help with productivity.

    Another important factor of this approach is to tell people about it. Have the groups keep blogs on the development of their games. Tell the press. This is a project that will get you good publicity with the hardcore and indie crowd. They will love this. Don't hide that you are doing this to make back the money of employing the programmers but remember to play up that you are also giving your people a chance to shine. This will be both good will to your company but also a jumping of board for your big AAA title hype engine.

    There are of course problems with this approach. Firstly getting investors will still be a pain. New ideas make money men nervous. It is an odd thing but there you have it. Another problem is that you will be needing programmers to work with the preproduction guys. They may be a bit disgruntled that they don't get to make their own thing. There is also the problem with what to do if a team does not finish a game before the AAA title comes out of pre-production. All in all though, I think there is some merit in this idea. I am interested to hear if other people think so too or if I am completely of the mark.

  • 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.

    I wonder if the problem with game studios is mainly that technology can vary so greatly from project to project. If not, I can only imagine that programmers would have no shortage of things to work on to enhance the production experience for the next game. If that's the case, maybe the answer to the problem lies in making games using cross-platform technologies, so that effort spent in improving processes and tools can be multiplied over successive projects.

  • Any chance that you will create article/video about pre production?

    Not on the topic that it is important but how create good pre production process.

Join The Discussion: