Give Yourself a Deadline

Feb 28, 2013

Anything creative can be worked on indefinitely.

No matter what state it’s in more could be added, any part could be torn down and remade differently (“better” often varies by tastes), and more feedback could be gathered or accounted for.

Game design, the creative part of it (as opposed to the implementation end), is a divergent problem rich with choices between apples and oranges. I.e. it’s more like coming up with a name for a character, in that the criteria are up to you and there are many possible satisfactory answers that could address your design guidelines or personal tastes in different ways. That creative part needs to be complemented with the production-minded angle, the business type of thinking that deals with practicality, time limits, and the need to at some point declare something done in order to move on to the next task or project.

The luxury of not having a boss for a task, as we do with hobby, extracurricular, and indie projects, brings with it the responsibility of being your own boss. People that work effectively on their own aren’t batting without a pitcher, so to speak, they’re batting their own pitches. People that work well seemingly without guidance are not creating answers without having questions to address, they’re simply posing their own questions to be answered.

They’re not working without direction, they’re giving themselves direction.

And one of the most important questions to pose to yourself, so that you can look yourself right in the eye and provide a thoughtful answer, is when this is going to be done by. Any deadline is better than no deadline. Another important question, tied to that one, is what you’re going to figure out, make, or otherwise do this week (every week) that’s going to keep you making forward progress toward that planned deadline.

It’s often possible to scale the implementation complexity of any high level task to fit whatever timeframe it’s given. Game jams are testament to the huge variety in what can be rushed into existence with a very short period of time, while commercial indie games demonstrate just how simple of a core game can result from years of iteration and polish. I could spend a decade making an incredibly polished Pong-style game (though I wouldn’t feel good about it), and I could pull together a pretty crude “first person shooter” very rapidly in an evening with Unity (ditto). Somewhere in-between, sliding along both axes of game complexity and time dedicated to it, are virtually all other projects that we’re likely to actually work on.

If you’re hired as an entry-level code monkey to implement what someone else designs or directs, you may not be in position to change a task to fit time allotted. When the same person doing the design or direction is also doing the programming, or when those people are closely collaborating as equals on a project, it can become less about how long will this project take (fixed goal, time scales), and more about how long are you looking to spend on this project (fixed time, goal scales).

“I want to make a better game, though!” is a perfectly reasonable reaction. There’s simply not a 1:1, or even monotonic, correlation between development time and resulting game quality. There’s such a thing as spending too much time second guessing yourself, or trying to cram too much into one game, and the probability of either goes up the longer a project drags out from the time of its initial inspiration. Beyond diminishing returns, negative returns for additional work can happen.

There’s also some risk that a fundamental, central, or critical flaw, even just crummy timing or unsuccessful distribution strategy, can kind of doom the project into being dismissed by most players before they ever get to the parts or features you really poured your work into that you felt were coming out well. While it’s good to see your ideas through, and valuable to set your work apart by putting more time, work, and iteration into it than a typical game jam project, spending too much time on a single project equates to putting a lot of eggs in one basket. One reason to wrap it up and move on is to be able to diversify, to try out some other ideas and implementation strategies that may pan out better another day.

In many cases the game you’re working on may already be about as good as it’s going to get, no matter how much time gets poured into it, a fate sealed early on during development in deciding on a certain premise, core gameplay model, story concept, level creation pipeline, or the other ways that we gradually paint ourselves into a corner on every project designed to be completed. That’s not bleak, that’s reality, but it can even be a source of good when we learn to lean on that to realize our game’s pretty much done at some point anyway, and it’s time to wrap up the last loose ends then put it out there.

The first step to making a better game may be to simply finish the game you’re currently working on, to win back your freedom to work on the next project. And the first step to finishing what you’re working on is giving yourself a deadline.

It’s not a videogame until other people are playing it. Make videogames.

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.