Comments on: Putting a Deadline Is Not Impossible (It’s Pretty Easy Actually)

By: Jake Birkett

Jake Birkett — Sun, 22 Feb 2009 23:31:33 +0000

Yep I should be an aim that no indie or casual games takes longer than 1 year (imho). This ensures you can stay up to date with the market.

By: hObbE

hObbE — Sun, 22 Feb 2009 21:24:26 +0000

Thanks :) Good luck with Unwell Mel I just saw it released on BFG.

To clarify on point 2. On indie projects you often have an “unlimited” amount of time. At least you think so :P

In my opinion having two unknowns (features and resources) in the equation is also a recipe for disaster. “Oh I got all the time in the world… so I can start working on these unnecessary features or over engineered tech”.

In this case I suggest you simply set a deadline when you want your game to be finished. Working iteratively it will be the best possible game on that time frame.

By: Jake Birkett

Jake Birkett — Sun, 22 Feb 2009 07:33:17 +0000

good tips hObbE, both applied to my last project and will be improved in the next one.

By: hObbE

hObbE — Sun, 22 Feb 2009 07:19:50 +0000

Well… when setting deadlines you have two major problems:

1. Time, the farther away the deadline is in the future the higher the risk of not meeting the deadline. Heck if you have a 1 year deadline set, you probably have changed the feature list many times, so the deadline is worthless (if it’s expressed as “these features at this time”).

Beware of people trying to do this, the don’t know the first thing about software development.

2. People trying to control all the parameters. The development team really have to have control over at least one parameter in the Resources – Features – Quality equation. Fiddling with quality is not a good idea, leaving Resources and Features. Resources are often fixed as in time and money. Leaving only Features. That is the actual developes need to be those responsible for saying what they can achieve at top quality given a certain amount of resources.

I personally only do iterative development, using 2 week iterations. I always have a plan for what I want to achieve in those 2 weeks. But if life happens to me, I toss features to keep the deadline. Keeping the deadline and delivering on time is vital to project success.

And remember; planning is everyting the plan is nothing…

my 2 cents

By: Lamonte | Free FPS Games

Lamonte | Free FPS Games — Sun, 22 Feb 2009 07:17:47 +0000

Thanks for the article :) honored. I get what you mean. Meeting a deadline is all about having the core system done instead of having bloated featured which could be added down the line. Yeah this idea pretty much exists on not just game development, but web applications and more.

By: Jake Birkett

Jake Birkett — Sun, 22 Feb 2009 05:05:19 +0000

Oh I like your 100m analogy btw.

By: Artie

Artie — Sun, 22 Feb 2009 03:28:20 +0000

There is another aspect of deadlines that make them a requirement. If you don’t have a deadline then your sense of urgency to finish things is lessened. Its a lot easier to say “lets just throw this in before we release”, “let me fix these last few bugs before we release”, or “I don’t like this one part, should we change it before we go llive”.

Having a deadline helps you make those decisions intellligently. Without the deadline there isn’t any reason to say no, but with a deadline you can determine just how important it is to do one of those things.

By: vigrid

vigrid — Sat, 21 Feb 2009 14:51:49 +0000

For software development, there is a simple equation that can be used as a rule of a thumb:

quality * number_of_features * speed_of_development = const

You can have more features, if you sacrifice the speed of development or quality. You can have better quality, if you decrease the number of features. You can deliver faster, if you have less features or settle for lower quality.