Welcome to part 3 on my series about running Lioncode Games. Here are part 1 and part 2. All caught up? We’re talking about scope today.

What is scope?

It’s not mouthwash. And you don’t use it in your sniper rifle. I mean, it is those things, but in our context scope refers to the size of the game: all the features the game has and, by extension, all the work that needs to be done to create those features.

Project managers live and breathe scope. It goes like this. A game director or a creative director will write a document with everything that the game needs to have: player abilities, enemy types, environments, missions, etc. That’s the scope. The project manager will then break it down into smaller tasks and get estimates for how long it takes to do those things. And thus the scope is converted from game features into time and, if you remember from part 1, into money.

Needless to say, there is eternal tension between project managers and game directors over scope. The game director wants to add wall running to the game, or 20 new missions, or a co-op campaign. The project manager then starts talking about the iron triangle and says we either spend more money, or sacrifice something. This tension is a good thing. This tension is what ensures the game is going to ship and won’t turn into Duke Nukem Forever.

A common mistake many indies make is to not manage the scope of the game carefully. Sometimes this is due to inexperience but not always. If you’re the game director but there’s no project manager keeping you honest, you’re likely to bite more than you can chew. With this in mind, I’d like to talk about three principles that help me stay on track.

Money on the screen

Not all scope is created equal. Some features in the game are more expensive to create than others. And some features will have a greater impact on player experience than others. Use the “money on the screen” mantra: whenever you spend time/money on something, make sure the players will see it. When you’re in that meeting trying to decide which part of the game is getting cut, always think about the players. Often, they won’t even notice something is missing if they didn’t know it was planned.

The opposite of being player-focused is what I call gold plating. We love our art and we love pouring attention to every detail. And sometimes it’s important to have those little details, but not always. The opportunity cost of spending a lot of effort on the blades of grass of the environment might mean that you don’t have time to add new missions. Which one is the player going to care more about?

Bad crunch, bad!

There’s a romantic notion of the super-hard-working developer emerging from their basement with a shiny copy of their game after working 14-hour days for the last 6 months. People love heroes. Surely this is a way to solve the scope problem: just work harder!

There are two issues with this. Well, actually I’m sure there are many more but I’m going to talk about two.

First, after that kind of death march you’re not a functioning human being anymore. Overworked people suffer from all kinds of health issues. Often, they need to take long vacations to recover and, if this is not possible, their condition might worsen to the point of preventing them from working at all. After you ship that game and you think you’ve reached the finish line, think again. You’ll need to keep supporting the game and/or start on the next one. You can’t do that if you’re in the hospital.

It gets worse.

Crunching doesn’t even help in the first place. You might be able to increase productivity for a short time by working long hours, but that will quickly lead to diminishing returns as you get more and more tired and soon you will be less productive overall than you were working normal hours. So you’re killing yourself for nothing.

Sustainability is one of the principles of my studio. This is not just to maintain a healthy work-life balance for myself and my family, but also to make the best possible game in the time I have. Ironically, the way to maximize scope is to not crunch.

Laziness is a virtue

Larry Wall is famous for saying that laziness and impatience are virtues for programmers. He’s talking about true laziness, the one that makes you stop and think how to get something done with less work. Maybe a less cheeky way of saying it would be to “work smart, not hard.”

Game production is an optimization problem. You’re always looking for the bottlenecks and removing them to keep the game progressing nicely. Sometimes, that requires looking ahead.

Early in my career I learned that production of a game varies wildly depending on the tools and workflows that you build for yourself. Often you have to make an investment up front that will pay off later. This is true laziness. I take these principles to heart and I’ve created tools for editing levels, balancing the economy, and even simple things like automatically combining images to create the weapon cursors that Mech Armada uses. An obligatory disclaimer is that you can take this too far, and spend all your time working on tools and not get anything else done. Don’t do that. Solve your specific problem and move on.

Did we solve scope, then?

No, we didn’t. Remember when I said that the tension between project managers and game directors was a good thing? It’s still true.

The secret with scope is this: you can be efficiently working only on the most important stuff and you’ll still have to cut some features from the scope. Because time and money are finite, but our appetite for making a great game is not.

So do all the things I talked about, work smart and use every trick in the book. And then go ahead and cut that feature anyway, because it will make your game better. And your game will actually ship one day.

By the way, I hope you’ll forgive the plug. Mech Armada is shipping this summer. If you wishlist it on Steam you’ll get an email when it’s out!