Managing the Scope of Your Video Game Project

Scope-management is one of the most important things to do as a solo game developer or hobby game developer. You can’t hope to match the scope of any other games made with a team, or with a budget. Sure, your artwork may be better than anyone elses, but your programming probably isn’t. And maybe you’re amazing at both, but you don’t have time for both.

So you need to manage scope. Identify what you can do, how much time it will take, what a finished game looks like, and how to plan. Let’s go into some more detail on these.

How much work can you do?

This is really just a factor of how much time you have, multiplied by how much skill you have.

If you’re just starting, you can’t do much in the time you have. At least, not much in the way of additional features to your game, you’ll be doing a lot of learning though.

If you’re as experienced as I am in not completing games you start to make, you’ll find that you can get through a lot in a little bit of time. Right up until you attempt something you’ve not done before, and then you’re right back to getting nothing done and learning a lot.

But that’s all okay. That’s the process. So just how much can you do? Here’s some things to think about:

1. How many consecutive, uninterrupted hours do you have?
2. How long does it take you to get into the zone?
3. How long does it take you to implement a feature?
4. How organised are you?

I’ve found that answering these questions truthfully, gives you an idea of how long things will take. Multiply that by how much scope is in your games, i.e. how many features there are, and that’s the number of years you’re spend making your game.

For what it’s worth, here are my answers:

1. How many consecutive, uninterrupted hours do you have?
   Two hours at most, usually less than 1 hour, more than 30mins
2. How long does it take you to get into the zone?
   About 15 minutes
3. How long does it take you to implement a feature?
   Depending on the feature, 1 to 7 days
4. How organised are you?
   Very

How much time will it take?

This is a hard one to answer. For myself, making a Multiplayer Networked Pong with bells and whistles, it took me six months. This was starting off with the excellent SFML library, so I didn’t need to code sockets or OpenGL myself (though I’ve since moved to doing all that myself).

But I tend to think of my game as a set of features. As I’m writing this, I am working on a game that I believe is a small enough scope that I can complete it, with bells and whistles. See if you can guess what the game is by this list of features.

(I’m aware that I’m not using the term features in the same way that a game studio might, but that’s because I have no other word for this)

Features:

1. Player is a little ship, player can move it around like the thrust mechanics from Asteroids.
2. Camera is centered on player ship
3. Other players are denoted by identical little ships
4. Player can shoot bullets
5. If either player hits a bullet, player dies and other player scores
6. Game is over when one player has died 10 times

Pretty straight forward right? Two players shoot at each other until one player has won the match.

Each of these core features are something I think I can do in a week or less of part-time development. I have under 1 hour twice a day on my way to work and to home on the train, I work 4 days a week. I have maybe 1 to 2 hours after dinner, after my baby is asleep to do some work before it’s time to sit with the girlfriend and watch some TV. Weekends and my other day off I will have maybe just the 1 to 2 hours after dinner.

So in a single week, I think I can deliver one or two features. This is from experience. With the amount of time I have available, that means I’m taking about 18 hours a week to deliver 1.75 features, or with some math, about 12 hours to deliver a feature. That’s a day and a half if it was a full-time 8 hours a day job. This is probably inflated because my time is split up a lot, and it takes some time to get into the zone and doing something meaningful.

Good news is if this is what you need to do, you get good at it. Your brain learns to ramp up and switch on faster than it normally would.

Technical Features:

Don’t forget these. Those core features above aren’t possible unless you’ve got some of the architecture of your game done. This comes up a bit during planning (which we’ll get to), but we’ll just list some out now for my current game.

1. Networked multiplayer
2. Dumb-Client / Authoritative-Server architecture
3. Client uses input prediction
4. Client uses delayed rendering with interpolation and extrapolation
5. Server uses latency and timestamps to process input commands from clients
6. Game uses my existing 2D engine to handle graphics, sockets, audio, and input.

Anything else that’s an architectural thing, is like it’s own feature. I can’t have the feature of players moving the ships until I’ve got input prediction in the game client done.

So now that’s we’re thinking of your game in terms of features, we can move onto the next piece.

What does a completed game look like?

You might be surprised, but polishing your game, making it complete, adding the bells and whistles? That’s the thing that takes a lot of time, and a lot of patience.

You will find that you never thought about how all that polish will work in your architecture. You will find yourself tearing up great swathes of code in order to implement high-scores. Destroying beautifully crafted systems in order to implement an option menu for the player to change their input configuration.

In time you’ll learn to add these to your scope. But these bells and whistles will often involve what seems like an inordinate amount of time. Why do I care? you’ll say to yourself. The game is already working, so what if there isn’t a menu.

And you might be right. I’ve stopped a lot of games at that point. But getting past that is what lets you say, I finished. Even if it beats up all your project files, and is technically a poorly implemented menu.

If you couldn’t give your game to someone else without being embarrassed, then you haven’t completed it yet.

Music, sound effects, better graphics, menus, configuration options. These are all polish. Tweening the animation when the game-over text slides into view. Adding a fade out and in after clicking New Game. These are all polish, that take a lot to implement, but make a massive difference.

You need to complete your game.

How to Plan

Planning! Organisation! You need to do this. If your time is only hobby time, like most people, you won’t have a lot of time to dedicate to it. And you’ll obviously want to jump straight into it without doing much in the way of planning.

Yeah, I’ll start by getting my little guy drawn on the screen, make him jump, make him die if he falls off the platform… this is easy!

No, no no. Don’t do that. You’ll get to the point where you want collision detection, and you’ll realise that you needed an overarching game object that every derives from.

No. Plan it out first. It’s not hard. This is how I do it.

1. Decide what the game is, what are those core features. As above. Let’s just write down what’s in the game. Does your game have levels? As bad an idea as it is for your first game, you need to write all of them down. Exactly what’s in each level. Why it’s in that level. You need to know everything in your game before you write any code.
2. Decide what systems and architecture you’re going to need. This is where you decide on a library, or libraries, or a game engine. Then it’s time to whip out Open Office Draw, or BoUML, and start to figure all that stuff out now, before you start coding.
3. Break the features into small, manageable pieces. This is just smart planning. You should already be thinking of things in terms of classes and systems. So it’s easy to translate into classes and functions.
   Because you know what functions and classes you need, and you know what information each will provide and expose, it is much simpler to code each of these in a single sitting.

That’s how I made Pong. The last point was amazing, I coded everything sort of independently of everything else because I planned it out so well. All those snippets of time could be used to code an entire class. At the end, once everything was connected, it just worked. There were of course some bugs and things that needed to be fixed, but me independently focusing on individual, self-contained components, resulted in a game that basically functioned. Good use of time.

I hope that helps you realise what you can achieve as an independent developer, and allows you to get the most out of your time.