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:

  • 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. I was worried that the process of actually making my game would expose how inherently bad my concept was. But that was back in my fledgling days, years and years ago.

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

    Whilst feature creep is something you need to avoid during production, it's actually a part of pre-production, where your product is continually evolving on a day to day basis.

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

Join The Discussion: