Dev Blog: Two Constants of Game Development

Hey guys and gals, I’d like to talk about two concepts I've discovered in my experience to be constants any time you develop games. Hopefully arming yourself with this knowledge can help defend against some potential issues of game development.

#1.  As a project approaches completion the appearance of progress exponentially slows.

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." —Tom Cargill

People completely new to game development aren't familiar with this concept, and those just wetting their feet are conscious of it but probably don’t allow time to plan for it. (Methods like burn-down charts exist to solve this problem.)

Even worse is the accidental ignorance of the difficulties faced by other development disciplines, or all disciplines for non-developing managers/stakeholders.

• To those who aren't programmers, with each feature that is added more things break. Old things break, new things break, and they all take time to fix.

• To those who aren't artists, even if you think something looks great the artists will still want to improve it, and just like code, each art revision takes longer too.

#2. The chance of “burn out” increases both with project length and project intensity.

Burn out is when developers get sick of working on a singular project or aspect. They tire of the similarities of their day to day work and lose both motivation and the quality of their work.

Burn out occurs not only when a developer spends a lengthy amount of time on a project, but this can be accelerated if the project is particularly intense; requiring long hours, stressful conditions, or tough challenges to be overcome.

In our experience the best way to mitigate burn out is to provide short term breaks, and long term partitioning. In the short term, the entirety of a single day should never be spent on a single project, breaks should be taken to work on research or side projects, which also has the benefit of pushing several carts uphill at once. Looking at the bigger picture, you should be prepared to partition a project at the first signs of burn out; spend a whole week or longer on a side project or prototype, then you can come back with a fresh point of view and no burn out!

Make sure to watch for and plan against these issues in your projects to keep your team happy and your project on track!

Until next time, Calum.