10 reasons why my games have crunched #gamedevelopment #programming

Every game I have ever worked on has had crunch or overruns or both. So here I thought I'd document why. This isn't a philosophical piece or a dig at producers. This is just a list of the reasons that actually caused crunch or overrun. I've had 17 good years out of the games industry and I hope to have many many more. Planning is critical, but it isn't a silver bullet. Here, in no particular order, are the reasons:

1. Breaking down the task ahead is tough. No matter how thoroughly you try, and no matter how much you sit in front of Project thinking, you will ALWAYS mis-estimate the job ahead. Main reason for me personally is that I'm normally asked to project tasks for a deliverable I've not done before, from a codebase I'm not fully knowledgeable about.

2. It's hard to visualise the current state of the project. Even with encyclopaedic knowledge of the code (which is impossible these days) there are hidden corners of technical debt and malfunctions which make the task of building more code fraught with uncertainty.

3. I'm normally doing something for the first time, so can only give guestimates. In any other industry outside of blind research this is a bit bonkers. But, lets be honest, this unpredictability and newness is the reason programmers like me think game programming is the only kind of programming worth building a career from. 8)

4. The cost of code maintenance is not taken into account. At the start of a project you spend most of your time creating and designing. By the end you're spending a huge chunk of time simpy maintaining older systems. Doesn't break down well into post it notes, and is very hard to predict. Neverthelss, it always happens.

5. External tech will change and cause lost time. Whether it be OS upgrades, 3rd party libraries, or internal tech written by the bloke next door, improvements and optimisations always cause some lost time which is hard to schedule. It's worth it in the long run because your game runs smoother and does more stuff, but it always bites you for time.

6. Time spent managing branching and code merging is tough to plan and can eat up lots of time. Over-zealous branching strategies and sloppy planning can cost you a couple of hours a day at the end of the project. Simply grabbing, integrating and testing bad branching schemes soaks up a galactic amont of time. Games these days are dozens of gigs big, and even with good networks simply moving data around takes a long time.

7. Team education. No matter how much you brief people about the pipeline and tools, you will always have people who are stuck and need help. Even after great team briefs and lectures the process and tools will probably change and trip people up. Helping others is a great time sink.

8. Game creators are passionate about their games and want to put everything they can into it. Even after a thorough design phase there will always be 'one more feature' that the team will try to squeeze in. Human nature I suppose.

9. The designers a probably doing stuff for the first time too, so expecting them to have it all sorted up front is a bit unrealistic. Just as coders have to refactor the code as the project moves on, so the designers will refactor the design. Best strategy here is the design your code for change, and make sure people know the realistic impact of those changes.

10. You will need to refactor bad code. Mistakes happen, and sometimes code is so bad the refactor can't be put off. Tough to predict, but it's going to happen.

So that's my list. I've probably missed loads out, like bad management, poor decision making, and lack of skill, but then those ones are obvious and by no means restricted to games development, so why bother going over them in any depth.

Games creation is a tough, passionate, rewarding and infuriating career decision, but I can't imagine doing anything else 8)


Popular posts from this blog

Personal Computer World Issue 1 February 1978

Rust, week 1.