Scope, or How I Learned To Stop Worrying And Start Planning

Honestly, how much planning do you put into a project? A lot of people just dive right in and let the code take them as far down the rabbit hole has it needs to go, like a painter on a canvas. Well, guess what, Bob Ross, this is programming. There’s no happy little tree, no titanium white, and no happy little gnarly accidents that will save you. Diving in without any idea of what you’re going to be working on, or what tools or patterns you’re going to need, is the biggest killer of any project. I don’t care what you think the front-end should look like – you’ll just be left with default assets if you can’t visualize it.

I can say, at this point, I’ve been working on video games for 10 years. I can’t tell you how many projects never made it up to this blog, let alone out in to other peoples hands. All of them started with an idea, a gimmick, and then, as the project grew and got more fleshed out, more was added to it in a fever feature creeping, and then, bam, the project would die. Why? Many reasons: bloating features slowed down the game, asset creation became absurd, code became unmanageable, people dropped off the project, and so on. But it all boils down to one centralized issue:

We fell out of scope.

Stay A While, And Listen

Lets talk about Scope. What is scope? That’s a silly question. Seriously, I mean, I expect that you’ve found this blog because you have an affinity for creating digital art, or programming, or have some basic knowledge of the flow of a project. But, all walks of life are different, if you want me to drill into it, read the next paragraph. If you’re good, skip it.

Scope is the boundaries of your project. It’s the target. It’s the circular maze you must travel through to get the finish in the middle. All the goals you set for yourself exist within the scope. It’s your timeframe that you have to work on this project, as well as a culmination of your skillset. You don’t want to go outside your skillset or your timeframe, right? So you have to plan. And that’s the kicker, right there. The scope of your project is the planning you’ve set to reach your milestones within the boundaries of your skillset and timeframe. This post, “How to define the scope of a project,” by Jason Gotto does a good job of defining scope, and recognizing the hurdles you’ll face along the way.

Alright, cool. Definition’s out of the way. But, the problem with the definition it that it really doesn’t hold any weight to what scope really is. For instance, I’ve done a lot of different game jams. Had some good success with some, and a total flop with others. I’ve worked with talented people – people I’ve seen craft amazing worlds out of thin air! But when we started jamming, they would peter out. Why? The tasks may not have been hard, or even time-consuming, but their heart wasn’t in it. The task didn’t feel challenging or rewarding, it was just tedious. Creating that world, writing that code, doing that work, it just wasn’t fun for them. It wasn’t a good use of their time. Yes, they could do the work, but, in reality, did they want to do the work? If somebody can’t dedicate them-self to doing the work, it falls out of scope. I don’t care if you can do it – do you actually want to do it? I run into this a lot with my own games! I’ve made some decent AI, the mechanics are fleshed out, progression is there for the most part, now it’s time to work on UI aaaaaaaaaannnnnnddddd the game is shelf’d.

UI isn’t hard, it’s just something that floats in the back of my mind. Then, when it comes to actually doing it, I realized that: I can’t pause the game without breaking some key aspect of gameplay, that none of my sound is hooked into anything that can be controlled with a graphical slider, and a bunch of other crap that started as a mountain of tasks that were left on the backburner now coming back for revenge! That, in of itself, is another scoping issue: don’t just plan the fun stuff; plan out EVERYTHING.

I’m sure we’ve all been there, right? There are a number of “planned” ideas that you might get to, maybe. You’ll say to yourself, “Maybe I’ll have Networking in this game,” or “Maybe I’ll cutscenes.” You work on your main gameplay, and then, after getting the bulk working, you’ll realize how hard it is to implement those “Maybe“s. Don’t say “Maybe.” “Maybe” is a catalyst for procrastinating, and can really screw up your design process. Trust me when I say have a clear, concise list of features and requirements for your game at the get-go. Saying you’ll maybe have multiplayer is like preemptive feature-creep – especially when you’re referring to a bear like Multiplayer.

No one will tell you Multiplayer is easy, or is some switch you can turn on anytime you want. You need to have familiarized yourself well with multiplayer – on any aspect of gameplay you’re not familiar with. This brings up 2 good points: Research is a key part of your planning process,  and if you feel you can’t do it, cut it.  It sucks, I know. Takes a big hit to your pride when you have a feature you really, really want, you research it, only to find out that you’d have to refactor everything to get it in. That’s a big killer for a number of projects I’ve been on. But there’s always something to learn from these experiences. You find out you can’t do whatever it is for this project, but you figure out how to do it for your next. You take a moment to understand your limits and how to get over them.

Scope is never a limiting factor; rather, its and understanding of limits. It’s an exercise in laying out all you’re capable of, and how to use it to complete your project. And when (and I do mean, when) you hit that brick wall that you can’t seem to figure out how to get over, you must learn from it, and find a new path. That’s the key to being a good developer/project manager: for every obstacle you encounter, you must learn from the experience. People will say “you always learn from your failures,” but, from my experience, that isn’t always true. More times than not, I’ve seen people go on repeat with falling into the same routine of over-scoping, wasting a ton of time, and then come out like “I thought I could do it.” I have no problem at all with them trying something new; in fact, I encourage it! But there’s a time and a place for everything, man! A Game Jam is not a place you want to learn how to do procedural world generation on a Minecraft level. Game Jams should be a place where you take your collective knowledge and put it to use, not to learn brand new technologies. “But Keith,” a Keith from 2010 is asking, “You learned how to use Unity for the first time at a Game Jam! Aren’t you being hypocritical?” First off, kid, the next 8 years of your life are going to be a doozy. Hope you enjoy feeling dizzy all the time, jackass. Second, yes, the 2010 Game Jam where my team and I made Beer Gnomes was the first time I ever used Unity. I was also freshly right out of college, and game design was no stranger to me. I was able to pick up this new development environment, and, with the help of people who were already familiar with Unity, pick it up and apply what I knew. But we were making more-or-less a simple platformer. This wasn’t multiplayer, no random world generation, no external APIs, or anything of the sort. We had the team, we had the people with the experience, we had the talent. And when we figured out what everyone was capable of and where to allocate those resources…

We kept it all in scope.


Scope is fickle. Scope is to be feared. Scope is your most valuable asset. Scope can keep you in line. Scope is your guidance. Scope is your compass. Scope is your Master Sword. As long as you understand what you’re trying to do and flesh things out properly, keeping things within scope will bring you to a finalized, proper product. Just keep these key things in mind, and you can accomplish anything:

  • If somebody can’t dedicate them-self to doing the work, it falls out of scope.
  • Don’t just plan the fun stuff; plan out EVERYTHING.
  • Have a clear, concise list of features and requirements for your game at the get-go.
  • Research is a key part of your planning process.
  • If you feel you can’t do it, cut it.
  • For every obstacle you encounter, you must learn from the experience.
Advertisements