Game Studio Don'ts

Every title I worked on, no matter how large or small, had fundamental flaws in direction, conceptualisation, focus, planning, distribution of responsibilities, or even all of them at once.

I’ve heard every defensive excuse in the book. “It’s always been like this.” -- “It was worse last time.” -- “Do you really think someone else does it better?” -- “The publisher made us do it!”

Not to mention every ham-fisted motivational speech ever attempted. “You should feel lucky to work in games at all.” -- “Next project...” -- “Think of the royalties!” -- “Just one more crunch and it’s done!”

But in the end, it ultimately made me fed up with the industry. I was ready for something not quite as arbitrary. I could have left the industry and never looked back, but thanks to a friend's recommendation I moved on inside the same industry instead and widened my frame of reference a bit.

A couple of years later, I stumbled onto the opportunity to start a new development studio making educational games in Sweden. I was signed on as Game Product Director for Calm Island in the second half of 2014.

I had no idea what to do.

I spent the first two weeks listening to the already established team, hoping to figure out what kind of direction they really needed. That’s when it hit me: I had way more don'ts than dos with me. I could see many of the don'ts repeated, and it hurt me to see that game schools didn't do a better job of preparing people for real-life production work. But frankly, I couldn't think of many dos at all from my own experiences. I'd have to start from a clean slate.

So I started with the don'ts. The nine biggest don'ts are what I'm sharing here.

1. Don’t Misuse Agile
People have explained agile project management to me in more ways than there have been people talking. Titles this, terms that. But what always happened where I worked was that an expensive consultant was hired and a more expensive software acquired, followed by the very same broken processes used in this new software. Nothing ever changed. It just had user stories added, and maybe some post-its on a wall somewhere. If you don’t go through with your changes, you shouldn’t try them to begin with. Fixing what's wrong takes more than words - it takes sacrifice and determination.

2. Don’t Rely on Titles
Some projects I worked on had people who constantly motivated their positions simply by generating more work for others. Often outside of schedule. Or people waved their titles like magic wands that would supposedly grant them immunity even from common sense. Not to mention the trash-talking and name-calling that could come with the titles, as people turned the office into a political playground in the name of various power-grabs. Almost always at the cost of the project's quality. Game development normally involves too many people to be a democracy, but titles for the sake of titles will never solve problems, and they won’t grant unconditional respect to unproven, unknown or even unpopular individuals.

3. Don’t Build Blame Culture
When you stop discussing who did what and start discussing the problems, you can also start finding solutions. In a company where blame gets pinned on individuals, everyone becomes deadly afraid of becoming that guy, and will start going to great lengths to put blame on others so they avoid becoming that guy. In the end, it’s irrelevant who it was that did something, since problems usually come up for structural or practical reasons. Discussing problems will let people be creative with solutions - discussing whose fault something is will shut everyone up.

4. Don’t Departmentalize Focus
I’ve known specialists who didn’t ever start the game engine to test their work. People who named files “test_3” or even “test 3.” Worse than that, I’ve known people who knew that this was wrong, and simply didn’t care, never reflected that others would care or even willingly ignored that such "small things" are actually important. All because they considered it to be outside the scope of what they were hired to do. Why should an artist care that “test 3” breaks the file system? Why should a programmer care that the textures are too dark with the new shaders? Everyone has to work towards the same goals even if their specialisations are different. Look beyond the singular task on your screen and do what’s good for the project. Don’t hide in your department.

5. Don’t Condone Elitism
Elitism goes much deeper than titles (mentioned earlier). The reason process is important, for example a system for reviewing what gets done, is that the process should be exactly the same for everyone and never give a free pass to anyone - especially not based on title, company history or personal relations. If you rely too much on elitism or favoritism, you easily forget what's most important, and career development or project decision-making starts becoming a struggle to have lunch with the right person rather than doing a good job. Give people the good and bad criticism they need and deserve, no matter who they are.

6. Don’t Overdo Meetings
Most meetings I can remember had very little substance. Whether we talked about if players would understand a certain segment of a game or if an idea was good or bad, there was never any meeting schedule or relevant data, just pure assumption. No metrics, no testing, no project-specific guidelines, nothing. Just vague arguments like “I don’t think anyone will get this,” or “this other game I played last night does it this way.” Empty arguments with no concern for the whole of the product. I’ve argued like this myself, but these days I try not to. No statement should ever be based on supposition, unless the meeting is a freeform brainstorming session. If you care to argue for something, get your facts straight. Don't confuse creative process for a situation where anything goes. Define the process, then get creative. Admit it when there’s something you don’t actually know.

7. Don’t Punish the Team
This is a hard truth: it’s never the team’s fault if a release fails. It’s the manager’s. Forcing people to crunch endlessly, cancelling holidays or threatening people’s jobs is simply not the way to go. It will crush morale and will create a situation where it’s the team against the management or where people make it part of their daily routine to search for new jobs or polish their portfolios. This is terrible both for the product and for the team overall. A manager has to protect the team and care for the team to bring out its best, and this is a constant process that starts with taking responsibility. People have to feel like they couldn’t do your job, or they won’t respect you as their manager.

8. Don’t Do Feature Creep
If you fill a glass, you know that you can't pour more water. Yet, one of the biggest issues in production in every place I've been has been feature creep and other kinds of spot requests. They're often more or less panicked, "do this NOW!" They're also often formulated in a trivialising manner, and from people outside the affected field of work. "That can't be too hard - it's just X." But what they all ultimately do is that they pour more water. This is another situation handled best by process - define how you do things, then make sure to do it that way. Use proper deadlines and follow them. If you say content stop, then there's no room for "just one texture." Be consistent, be fair and follow the plan even when it hurts in the short-term.

9. Don’t Rely on Iteration
One of the biggest wastes in game development is to do the same work multiple times. It's often an outcome of working on something before anyone even knows what that something is supposed to be, and it often hides bad process behind the game development adage, “it’s an iterative process.” There has never been proper preproduction, prototyping or conceptualisation phases on any project I've worked on. It just jumped straight into production and didn't stop until five minutes after the first release candidate. The same level would be rebuilt a hundred times, inside the game, rather than getting reworked on a whiteboard or low-LOD where it takes hours to make important decisions and not weeks or months. Often, this was just to keep people busy because they happened to be at the office - not to meet actual needs. Define the product carefully and tangibly. Build it only when you know what to build.

End Rant
I haven't seen attack ships on fire or c-beams glitter, but I have seen things in game development that have shown me over and over that there's a very long way left to go. But these don'ts are just the beginning. Now comes the hard search for the dos!