Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
A new game production modelling tool to fully encapsulate the anguish of game development, and how you can reduce it. Warning: may trigger flashbacks to suppressed memories of nightmare projects.
Last year I was invited by a former colleague to give a talk about project management to game development students at Manchester Metropolitan University. During my career I have held the role of both lead designer and game director, but since I have never actually been a project manager, my initial reaction was to submit to the creeping sense of impostor syndrome the invitation had provoked.
Having recently made the move from the world of big budget, big IP development to running a small indie studio, I realised that I could no longer afford to pretend that project management was somebody else’s responsibility. More importantly, if we were to flourish, I knew I had to slay the demon of impostor syndrome whenever and wherever it raised its ugly head. So, I accepted the invitation, and set forth into the darkest corners of my memory, in search of the dreaded closet of development nightmares I had buried there.
Instead of applying the experiences I found to models pulled from project management textbooks, which presumably the students had studied to death, I thought it would be fun to create a new model to properly encapsulate the sense of anguish I wished to impart.
The model I came up with is called the Development Diamond, and this is how it works:
Often, when we measure the progress of a project, we look at tasks and bugs. These are assigned to team members, and the rate of resolution versus the rate of creation gives us a sense of project’s progress.
However, tasks and bugs are but a drop in the ocean. They are well-defined subsets of a much larger universe of problems which amounts to your project. That’s right, your project isn’t made of ideas and mechanics or art and rainbows. It is, at the quantum level, nothing but an infinite soup of problems.
Not all problems can or should be formally encapsulated in a task, but we need to be aware that for every task and every bug there exists a multitude of additional problems which affect the progress of the project. Here are a few examples:
Here is the Venn diagram again, this time with every potential problem I can think of:
This universe of problems is both vast and constantly evolving. After the big bang of entering production, it will and must inflate, but more importantly it must at some point begin to contract back towards a big crunch if you want to release your game. This, of course, is the tricky bit.
The Development Diamond is a way of encapsulating this idea of inflation and contraction. For the ideal project it would look like this:
Start: A singularity of infinitely exciting ideas erupts in a big bang, and we plunge into the unknown convinced that it will be the best project yet, and that “this time it will be different”.
Inflation: The period of inflation is a cauldron of problem creation, as design documents, art tests, prototypes and plans conspire to rapidly expand the scope of your project.
Turning Point: Somewhere before the turning point, the high-level structure of your game materialises and you can now comprehend the bigger picture. You’ve stopped adding new features, and at the turning point you begin to sense that you are now solving problems faster than you are creating them. Since this is the ideal project, the turning point occurs about one third of the way into your allotted time.
Contraction: With the turning point occurring early, you have an extended period to continue solving more problems than you create as you gradually collapse the project towards completion.
Release: Your game is alive, and you have created and solved all the problems you needed to reach a releasable state.
Finish: As Leonardo da Vinci said, “Art is never finished, only abandoned”. Somewhere beyond the actual release of your game is the theoretical “finished” state. Like a mirage in the desert, you can never actually reach this point, but if you’ve done a good enough job, your consumers won’t know about it anyway.
The ideal Development Diamond, if it exists at all, can only be observed in hindsight. When we recall a project from memory, we subconsciously edit the tedious bits out of the narrative. If you are lucky you will believe that you have experienced it at least once in your career, but this is probably just rose-tinted spectacles playing tricks on your mind. I believe that I have come close to experiencing it once, maybe twice, but I am almost certainly wrong.
In reality, the Development Diamond of your project will end up looking warped, stretched, and mutated, like something out of the lab scene from Alien Resurrection.
Here are three monstrosities let loose from my aforementioned closet of development nightmares:
We all know the rule: never go grocery shopping when you are hungry. Similarly, you should never define the scope of your game when you are excited by the possibilities of your awesome ideas. If you do, you will end up with an extended period of inflation, leading to a delayed turning point, an intense contraction period, and a broader set of unresolved problems on release. This bloated beast can be painful to give birth to, but if you battle through, you can still end up with a great game at the end of it. Then, when a journalist casually comments that the game is “a bit on the small side”, you can indulge in a face-palming session of Picard-like intensity.
Just as your project is about to start, all of your plans are turned upside down by the decision to overhaul the development pipeline at the eleventh hour. Or perhaps there was no plan, and you are thrust into production completely rudderless. Maybe your entire team are pulled onto another urgent project, leaving you with a skeleton crew as you set sail into uncharted waters.
The deadline for releasing the game is immovable, but forget about solving problems more quickly, you are not even CREATING them fast enough to properly kick-start the inflation phase.
The mutant of eternal despair develops multiple tadpole tails, each one emerging from the last, because not only is it poorly planned, but the fundamental design of the game keeps on shifting beneath your feet.
Goalposts aren’t just moved further away, they are uprooted and launched into entirely different stadiums. The cause might be difficult-to-tame technology at the heart of your project or loose cannon, nutcase managers. Perhaps it is the result of an overly ambitious, unrealistic design or the switching of publishers half way through. Perhaps it is a mixture of all of the above.
If you are lucky, this abomination is mercifully euthanized — shot dead by concerned investors, or slowly suffocated by a dwindling team, as bleary-eyed developers question whether the games industry is really for them. Sometimes, however, whether through grit and determination, pure tenacity or naked naivety, the turning point is eventually reached, albeit years later than planned, and with a drastically reduced scope, the mangled project finally crawls towards release, amidst mutterings of, “I no longer care if the game is any good, it just needs to die” from the team.
Killer of companies, destroyer of souls, the mutant of despair will leave you a shell of your former self, but if you live through it, you will be eternally bound to your teammates, even after they have been scattered to the wind. And when your paths cross again, you will exchange knowing glances across crowded rooms with an unspoken acknowledgement that you are never to speak of it.
The mutated Development Diamonds described above represent some of the more difficult projects I have come across, from a production point of view. No doubt you could describe some interesting abominations of your own.
Although the circumstances were different in each of these cases, the fundamental problem was a disruption to the inflation period, which was either swollen (whale of glutinous over-scope) or prolonged (tadpole of piss-poor planning and mutant of eternal despair), leading to a delayed turning point and therefore a bigger set of problems to solve in a shorter period during the contraction phase.
When I cross-reference these with the smoothest production experiences I can recall, the key difference was our ability to control the inflation phase, and if you can control the inflation phase, the contraction phase takes care itself.
That is easier said than done, and even if you do achieve it that doesn’t mean the project will be painless. But there is standard project painful and then there is, in the words of one insightful former colleague; “I no longer see the point in anybody’s existence” painful.
So, how do you control the inflation phase? Here are a few strategies.
Picture the scene. Project leads are gathered around the boardroom table discussing how to get development back on schedule, when the producer casually throws the C-word into the conversation. A shiver ripples down the spine of the lead designer, culminating in a prolonged sigh which sinks the room into silence. The design team had been pushing for more time and more resources, but once again the dreaded “cutting content” conversation is rearing its ugly head.
It doesn't have to be this way. Experienced designers learn not only to plan for the cutting contingency, but also to actively embrace it as an opportunity to practice design by subtraction and to focus in on the features that matter most. Defend crucial content passionately and vigorously, but also be prepared to re-examine the structure of your game objectively. The requirement to cut is just another constraint forcing you to find clever, creative solutions.
The end consumer doesn't know what content you planned; they only know what you deliver. They can’t miss content they never knew about, but they can appreciate a focused, elegant and polished design.
Hindsight is a wonderful thing, and many studios routinely conduct post-mortems to channel lessons learned in hindsight into the next project. However, each project is different, and no matter how much you learn there are an infinite number of new problems waiting to be discovered.
While it is very difficult to predict specific problems before they occur, you can help to prepare yourself for the consequences by conducting pre-mortems not just at the start of every project, but routinely throughout development every time a major production decision is taken.
The pre-mortem works by imagining the worst-case scenario and then constructing a narrative that gets you to it from where you are now. Imagine yourself, for example, as the Democrat party in early 2016, constructing a narrative for the seemingly impossible scenario in which Donald Trump actually becomes president. As you invent the story of your own nightmare, you may discover that not only is it less far-fetched than you imagined, but that there are some clear dangers which you can prepare for, if not prevent, by considering and acknowledging them beforehand.
So far as I can tell, the pre-mortem was originally devised by the Harvard Business Review.
The requirements for each project are different and there will always be difficulties which are unavoidable. If you are working on a movie tie-in game, for example, then cutting content becomes a much bigger challenge because your backstory is fixed.
The pre-production phase is the ideal time to draw up a PCU (Preventable, Controllable, Unavoidable) table of problems that might afflict your project, so you can prepare and mitigate accordingly.
First you draw up a list of every potential problem you can think of, like this:
Realistic setting: Can you name a realistic Nintendo game? Why give yourself the trouble of things needing to make sense when you can design freely in an abstract setting? Consider how far you can push towards a more abstract setting within the constraints of your IP.
Too many mechanics: If you’ve ever worked on a game with a large cast of super heroes, each with their own set of mechanics, you will understand intuitively that each unique mechanic in your game brings with it a multitude of problems. Boil your game down to as few mechanics as possible and make them shine.
Technical issues: As sure as death and taxes, you are guaranteed some technical complications during your project. Although this subset in your universe of problems is of unknown size, you can expect it to swell into a monster if you are doing anything innovative or ground-breaking.
Personality conflicts: Hopefully this doesn’t happen too often, but it is always a possibility.
Losing team members: If you are working at a large studio, you may find team members are pulled off your project to firefight elsewhere, and at any studio there is always the possibility of crucial team members leaving.
Scope too big: Problems increase exponentially with the scope of your game. Sometimes, you have no choice but to build Middle-earth in its entirety, but always consider how you can rein in the scope of your project further.
Fixed narrative: When you can adapt the story, you have more flexibility to find solutions when things get tight. If you are working with a license, be aware that this will limit your control over the project scope.
Feature creep: Every time you add a new feature to your game you are unleashing a Pandora’s box of additional problems that will prolong the inflation phase.
Building your own game engine: It is difficult to imagine a more catastrophic decision in terms of the volume of problems it will create. Unless you are a AAA studio with mammoth resources, don’t do it!
Untested innovation: Innovation is great, but don’t underestimate the work involved in getting it right. Test and prototype as much as possible before entering full production.
Weak high-level design: Make sure you have specified the high-level structure of your game before production begins in earnest. Without a framework, your project can feel rudderless.
Next, you put each problem into the appropriate column in your PCU table, like this:
While you won’t be able to identify all of the problems which could afflict your project, at least you have thought about how you can tackle those that you can.
I thoroughly enjoyed delivering my Development Diamond talk to the unsuspecting students of Manchester Metropolitan University, and I trust that my “universe of problems” analysis wasn’t too disheartening. Making games is, after all, supposed to be a dream career.
But that is the point; despite all the anguish involved, making games is a dream career.
Many other jobs are full of stress and pain. The fact that game development is also thrilling, captivating and wonderous is what keeps us pushing onward through the storm, but it is no use pretending that the storm does not exist.
As Theodore Roosevelt so eloquently put it, “Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied many people who led difficult lives and led them well”.
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
