I’ve worked in two different AAA companies, so I’ve seen what game producers roles are like from the developers end. To a coder, a producer is that slightly annoying person who keeps asking you how long stuff will take, and when it will be done, and how sure you are about that, and fussing about task-lists and todo lists and ‘the schedule’ which is this almighty document that is basically like the 2001 monolith as far as they are concerned, such is its importance to them.

tma1

As a coder, I always entered thrilling and enthusiastic, occasionally even sarcastic debates about how long a feature would take. My best guess was always somewhere between a day and infinity years. Basically, we are always doing stuff we don’t know how to do. if we’ve done it before, we will just copy and paste or re-use existing code. If we have *not* done it before…then things get interesting. We aren’t just typists. A good coder is basically a researcher, who works out how to achieve things. Knowing how long that takes is HARD. It might not even be possible.

With gameplay design, its even harder. Nobody knows whats in the design document is fun. It might not be fun, and then the whole schedule turns quickly to bollocks.

Now thats all kinda fun as an employee coder, but as a producer/publisher, I realize now its fucking mayhem. For example, ShadowHand and Democracy 3:Africa are both appearing at the PC Gamer Weekender show. This is aiming to be close to when both games ship, but will they? I may need to book some advertising in advance, can I do that now? Will they definitely ship? Will the coders hit their targets?

I feel like the producers that I worked with must have felt, standing behind someone who is typing away, wondering if they are about to turn around and say ‘this won’t work’ or alternatively ‘it’s done’.

Publishing games is basically a bit of a roulette.

 

4 Responses to “A game producers job is not easy”

  1. CdrJameson says:

    And yet producers still ask for exact dates and put them in spreadsheets and GANTT charts and ‘won’t hold you to them, it’s just something to put in the figures’ and then treat them as 100% correct.

    Agile planning helps here, and is no less inaccurate.

    For tasks in the future you give it a quick’n’dirty assessment of trivial/small/reasonable/large/gigantic.
    For imminent tasks, the person who’s actually going to do it splits it up and give actual hour estimates for each section (no more than 15 on one item, or it needs splitting again).

    The first doesn’t waste time on unknowables.
    The second gives a far more accurate estimate because the bits are small and detailed enough.

    Works particularly well if you also start from the release date and work backwards, making sure you’ve got something working at several intermediate stages. Then the question changes from ‘When will it be ready’ to ‘What will be in it when we release?’ This is a lot less intimidating, and as most publishers are far more interested in the release date rather than the exact detail of features, more reassuring.

    On an aside, I really wish people would stop comparing programming to building a house. As a metaphor it really doesn’t help.

  2. DerekD says:

    Yep, you’d be shocked how many people on Steam just say “well, why can’t you do this or that?”. Well, it isn’t always as easy as it may seem, and many of the multitude of whining folks on there can’t understand that. There’s careful planning and work that goes into coding anything, let alone something as subtle and tricky as a good, solid playable game.

  3. Les says:

    Hi Cliffski,

    I am quite confused – are you coding Shadowhand yourself or outsourced it?
    Would you mind to share your experiences how to manage such project?

  4. Chria says:

    What language do you mostly program in? Also, which game engine do you use? I’ve seen suggestions that you have made your own, but that seems very labor-intensive compared to Unity or UE. On the other hand, being able to do exactly what you want and knowing exactly how to do it has great benefits.