Always 1 month away from completion

[BantamCityGames]

(Formerly BrewKnowC at Dexterity Forums)
*Warning: ranting may follow*

Is anyone else working at this part time, always chugging along as fast as free time permits, but always still a couple feet short of the light at the end of the tunnel? If you ask me at any time during my game development, "How long until its done?"... I almost always answer, "about a month". A month later the same question comes up with exactly the same answer.

I haven't figured out what the problem is.

I think it may be one of two things: either I keep adding features to the game that weren't in the original design, or I am a very bad judge at how long it takes me to complete something. The last 6 months of ToW was always only a month away from being done.

This brings me to my ultimate question:
Do successful game developers a) add new features to the gameplay as they are working on the project, b) do they finish the project as designed and then add the new features in, or c) do they update the design as new ideas come into play and then work on the project that follows the design at that point?

[Mithril Studios]

What you are describing is pretty common, at least in the business side of development. I regularly heard the phrase "It's 80% done..."

As to your questions, I'm not a successful game developer yet, so I can't answer them :(

[chanon]

I'm feeling just like you right now, except the answer is always "3 months" :D

I'm also not successful yet, so sorry I can't comment.

[chanon]

Well, even though I feel like you, I'll try giving some advice ...

Anyways, I think you should try to lock down your design soon. To me it sounds like you're in the final stages already, so you should have a pretty good idea of what works/what doesn't in your game. Lock down the design, list everything that's left that you need to do, estimate time for each of those things, plan time to finish it all, and stick to the plan.

And when you list everything that's left, you really need to list everything, or else new things will keep popping-up in areas that you didn't think about.

Well that's what I'm trying to do anyways ..

[MattInglot]

CustomBar was almost done since January 2003 (dev start summer 2002). A year and a half later it is out. :) I'll probably write a post-mortem one of these days and it'll involve examining the reasons for this in more detail. Continously adding features was a big thing, but so was completely reinventing parts of the application multiple times. Then there was under-estimating how much time it takes to test, write documentation, clean things up, put up a website, setup an order system, and so on.

I think the only way to come even close to meeting your original expectations for time is to come up with a very thorough plan that details every feature and realistically takes into account all the non-programming details of the project as well (getting art, creating site, testing, etc). I did a small contract project earlier this year and completed a commercial app in just two months. This was still past the original expected deadline, but the project's efficiency and the accuracy of milestones increased as the specifications that my client provided grew more and more detailed. When you know exactly what you are up against you have a shot at making a realistic assessment of the situation, as well as the benefit of minimizing time lost due to unexpected additions or changes having to be made in the program (which as we all know not only involves adding code, but possibly significantly altering already written code). With much less time being wasted coding in the dark, the app was finished far sooner and was of higher quality than if the specifications had remained vague.

[Diodor Bitan]

It used to be "one week" for me, but indeed it is more like one month now :)

I'm not sure there's really something wrong with this. If the "carrot on a stick" system works for horses why not for us as well? Just pick a game you are 100% sure you can finish, and go get that carrot. :D

[Sillysoft]

"It's better done than perfect"

Write down a list of everything that NEEDS to be done. Then go through that list and think about what actually NEEDS to be done and cross everything else off. Then set yourself a deadline to release it.

Then all you have to do is hit the deadline :D

The 1.0 release of my game was really bad. It even had a few show-stopper bugs in it. However once it was actually out there it was much easier to tell what I should be spending my time on right now. Over time it got better and better, and now it is selling quite nicely.

[MiCo Games]

In my experience, the best thing to do is describe to yourself, in some form, what the game will look like and play like when it is done. This could be in the form of scribbles on a scrap or paper or a full design doc, depending on which you find most useful.

At this point keep as many features as you can get away with off that list. Add them to a second list if you want to, so as not to forget about them, but if it is a feature that is not essential for the game, don't put it on the list.

Then, develop the game so that it meets that list. Don't bother about adding any of the features from the second list, save them for the sequel, the expansionpack or your next game. Focus on getting the essentials done, the things that the game would not be playable without.

When all of them are in place, you should have a product that can be released as it is. It might not be your ideal product, but it is a complete product, and you can at this point choose to release it in the state it is in, or add some of the features from that second list if you think they will boost the sales enough to be worth it.

Or, release the game as is and start working on an expansion pack or a sequel that use those extra features that didn't make it in for v 1.0.

[Linusson]

1. Write down everything that MUST be in the game for release.
2. Write down everything that you most probably WANT in the game
3. Write down everything that would be FUN to have in the game.

Estimate the time for 1 & 2. If you have problems with time estimation. Get yourself a timer and write down how long everything you do takes, even when you check email and surf the web, maybe you'll waste less time too. ;)
One good thing with writing down every thing is that you will notice how many hours per week you really get something done with your game.

After your estimation is done, calculate how many hours you can work every week. Don't forget to include time for testing and bug fixing.

If you get any time over for things from list number 3, that's great.
If you estimation failed and you didn't have enough time to do every point even on list number 2 (I take for granted that you at least will be done with number 1) then I guess you'll have to make a 1.01 version later on. :)

Good luck!

[Reactor]

A few things about what my brother and I did...

We created an Excel plan file, based on one outlined on Joelonsoftware.com.

http://img66.exs.cx/img66/4858/Pic1.jpg

In the plan, we decided on how many hours a day we thought we'd work, and how many days a week. For myself, I wanted to work five days week, at about five hours a day (my brother went for 6/6, because five wasn't enough for him to finish along with me). Then, we outlined the tasks to be done, and set time estimations. We made everything fit a hourly schedule. As we completed the tasks (not listed here, because we like keeping things secret :)) we marked off the hours completed. The excel file did the rest, calculating how much longer our development would take.

So far, things have held fairly true. We've had the cut the odd feature here and there, and simplify a few areas that we underestimated, time-wise. Many large companies do this, and it's a better practice than trying to get everything perfectly estimated. The thing is- you need to be serious about it. If you're behind time, and you need to be finished by a certain date, you need to cut something to get it done in time. If you have no time limits, then you need to make sure you're not adding features for no good reason, or doing something else that will prolong your development.

I guess that's why a plan of some sort can help. Just so you know, we're obviously working full-time on this. I'm not sure how well it would work for part-timers, but even if you go for an hour a day, it'll still help you work out a time by which you should be done. If you notice that an hour a day means you'll be finished in 3009, you might want to try for more hours :) So in that respect, a plan can be a big help!

The kinds of tasks we listed were as detailed as we could get them. So, you don't add a task like 'graphics', or 'sound'. Smaller programming and graphical tasks should be added, or even down to (as we did) time to talk to each other about gameplay elements.

[MiCo Games]

Linusson, that is a proven model for retail game development, and no doubt it could work for indies as well. But the problem with that model, in my opinion, is that you do your time estimate, and then you end up spending at leat that amount of time, which is fine if you are paid by a publisher for that period of time. But I think that for indies, it is better to get everything from list 1 done as soon as possible, and then get the game out. Keeping a tight focus and not letting oneself get sidetracked is a really good way of making progress, but if you've allocated a certain time to complete the task, you'll most likely use up all of that time, even of the goal could have been reached faster.

From my experience of the retail industry, where the "required features/whishlist features and careful estimates" approach is used, it is very rare that features from list 2 get in. Features from list 3 usually get cut during pre-production anyway... And even so, lots of companies fail getting all of the stuff in list 1 done on time.

[Linusson]

Linusson, that is a proven model for retail game development, and no doubt it could work for indies as well. But the problem with that model, in my opinion, is that you do your time estimate, and then you end up spending at leat that amount of time
Didn't now that, haven't been there. But I thought that most people underestimate their time and end ups with to little time to do everything. But maybe all the retail studios takes their estimated time and multiply with 10. ;)

[MiCo Games]

They do, and then the publisher divides it by twenty :D

My point is that, at least for me, it is more important to get it done as fast as possible than to know how long it is going to take.

[Linusson]

My point is that, at least for me, it is more important to get it done as fast as possible than to know how long it is going to take.
The same for me. But I still like to know when the game will be ready. ;)

[Jason Colman]

This thread really rings true for me. I was convinced I would finish a release on Monday (I am working on an updated version of my game). But I just couldn't do it :mad: I find this constant battle against the clock very stressful.

[Reactor]

Unless there's a publisher breathing down your neck, or you need to make a sale to feed your starving family, who are eating rotten food from dustbins on the street, you don't have much to be stressed about.

[Jason Colman]

Dear Reactor, don't get me wrong - I feel that I have been exceptionally fortunate in my life, and I did not want to come over as saying "poor me". But stress is a subjective thing, and I do feel it! I think the core reason is that I very strongly want my (embryonic) business to succeed.

[Reactor]

That's fair enough :) Keep at it... you'll get there, sooner or later. All passionate people do.

[Jason Colman]

Thanks, it's nice to get a vote of confidence! :)

[BantamCityGames]

(Formerly BrewKnowC on Dexterity Forums)

I guess for me it gets to the point where I'm halfway done with a game and think, "wow, this gameplay isn't even remotely as fun as it looked on paper". Then I continually change things until it is. I made a java checkers game for a college project a few years ago and we wrote up a design doc and coded it with very few sidetracks... and before we knew it, it was done. I think this was because checkers is a known game with known gameplay. Its just hard for me to stick to an original design doc when the game is not as fun as it seemed on paper. I guess thats what makes me closer to the amateur spectrum than the professional ;)

[Jason Colman]

That's crazy talk! Improving the game play must surely be the best thing you can do! I say burn that design doc! :)

[svero]

All my games are shipped and done with a huge todo list still on the table. I try very hard to limit additional features to the very best ideas. My goal generally is to get the basic game done. Have a clear clear idea of how that looks and what it is and then put any addtions off to the side until I'm done the minimal ship-able game. Then time permitting I add new features.

- S

[Linusson]

All my games are shipped and done with a huge todo list still on the table. I try very hard to limit additional features to the very best ideas. My goal generally is to get the basic game done. Have a clear clear idea of how that looks and what it is and then put any addtions off to the side until I'm done the minimal ship-able game. Then time permitting I add new features.
We have done pretty much the same with our games.

[Coyote]

Its just hard for me to stick to an original design doc when the game is not as fun as it seemed on paper.
Heh - that's my problem with comprehensive design documents - they tend to be inflexible, and you just can't design fun on paper.

My problem is as much related to starting a new business as anything else - I'm finding I'm spending a lot of time dealing with all kinds of additional issues like working on the website, promoting the upcoming game, researching means of distribution and e-commerce, and managing the other folks contributing to the project. Hopefully this will speed up for future projects, but right now it's definitely impacting the game's schedule.

The other things you need to watch out for:

The 80/20 Rule
This was mentioned earlier... "80% of the job takes 20% of the time... the remaining 20% of the job takes 80% of the time." This screws people up all the time, because the 'fast' 80% is mostly found in the early stages of the project. So you think it's half done, but you are really only about 12% of the way there. Being able to gauge exactly how far you have left to go and what's left to be done takes a lot of experience and practice.

Fighting feature creep
I've probably failed in this one on Void War (wwwl.voidwar.com), but I'm not considering it a bad thing (yet). What you need to do is figure the cost of developing a feature. Not just the cost of your donated, free time... but the opportunity cost of not having it out the door and selling it early, the cost of having a new potential source of bugs, and the opportunity cost of not being able to work on your NEXT best-selling title (or the sequel) because you are busy with these new features. Consider the cost of your team, if you have one, losing morale because the game is still not done.

Now consider - will the features you are considering adding worth the cost? Will they sell THAT many more copies to justify the additional expense? Breaking everything down to an estimated dollars-and-cents value makes it a fairly straightforward business decision. If you assume adding 10 more levels will add $1000 (in donated time, lost revenues, etc) to the cost of the game, will it sell $1000 worth of more product? If so, you've got enough bang-for-the-buck to justify it. If not, bag it.

Usually the biggest values you can add to the game is POLISH and CHROME, not actual content. Sad but true, but people are attracted to pretty and shiny. However, being an indie, you do have some luxury of doing some things "just because it's right." That would be me doing both multiplayer and single-player for Void War. Stupid business decision, but it's what I wanted to do, dang it... and who knows? Maybe it will help put Void War on the map.

Just remember... you can always do an expansion / sequel / update, and add those features that didn't make it last time. In that way, every game is still a work in progress.

[Bluecat]

The other thing to remember is that it is allright to scrap something that isn't working.

A lot of developers get all worked up and passionate about their great game feature and become blinded to the fact that it doesn't add to the quality of the game. In some cases, the feature actually doesn't work and reduces the enjoyment of the game. In these cases it would be better just to remove the feature entirely. Just look at Blizzard. They canned an entire game (Warcraft Adventures (?)) because it wasn't living up to their standard of fun. I consider (the old) Blizzard to have made some of the most fun games I have played and replayed. As far as I know they were ruthless when it came to chopping out features that didn't make the grade. I'm of the opinion that this was one of their keys to success.

[Chris Evans]

Just remember... you can always do an expansion / sequel / update, and add those features that didn't make it last time. In that way, every game is still a work in progress.

I hear this mentioned a lot around here and I agree with it to an extent.

However, there's some things you can only take advantage of with your initial release. Game reviews are one of them. The majority of sites and just about all magazines will only review your game once. Further updates to your game will only get a small news blurb if you're lucky.

So I think it's important to have the key features of your game in place when you send out your game to reviewers since in many cases they're a one shot deal. A positive review even on a medium sized site or magazine can give your sales a big boost. It can also increase awareness and word of mouth. It's the best form of free advertising.

With download sites not being what they used to be, I think game reviews have a higher importance these days.

[GBGames]

That's a good point. I remember when I ran my own game review site (it was geared towards QBasic games), there was one guy who kept resubmitting his game after I reviewed it. So I would oblige and update the review. Then he would resubmit again. After the third time, I basically let him know that I had other games to review so I couldn't keep doing this.

Perhaps if you can even plan any updates, you could let the reviewers know about it. They may mention potential multiplayer or other options in the review. Of course, this behooves you to actually DO the updates rather than consider them optional.

[Coyote]

I didn't mean to imply that you can release a piece of crap and try to improve on it later, of course. You DO need a solid game out of the starting gate.

But do you really need 50 levels on your initial release? Or can you do 30 for the initial release, and then do 20 more after your game has proven itself and your players are hungry for more? Maybe those are the levels where you can use this keen new gameplay element that was too expensive to bother with prior to release? Do you really think that a 'timed triple-death domination' gameplay mode on top of your three existing gameplay modes will really make a difference on release, or is this something that might be better in a (free or premium) expansion?

You definitely don't want to hold anything back that would really impact the sales of the game. But you don't want to spend an extra month working in a new feature that's only going to have marginal impact on your customer's initial reaction to the game, either.

[Sparky]

We're not behind because we've added any features (added very little that wasn't in the original design), but that we totally underestimated how much time it would take to do what we planned. Especially developing and learning how to use our tools. $#@!&*! tools!

[BantamCityGames]

(formerly BrewknowC on Dexterity Forums)

Ok, after reading everyone's posts I just decided I'm going to set a strict deadline for sept 30th, 2004 for release of my current game. Any features or extra graphics that will stand in the way of that deadline will be cut. And further more, since I just announced it to everyone here, I expect you all to hold me to it ;)

Thanks Everyone.

[Coyote]

You'll probably want to set some internal milestones between then and now - you've probably already done that, but hey - it doesn't hurt to be reminded, I guess. Being able to measure your progress to your goal is pretty important.

[^cyer]

Hi to all the people here,

I think it is NOT good to not make your deadline to long if it is possible.

For example you set your date to the September 30, but ask yourself if it can be done a little earlier. For example September 5. This will "force" you to push harder and eventually you will shorten development cycle. Sometimes the hard way is better and shorter.

cyer

[Linusson]

Congratulations you're no longer 1 month from completion, it's almost 2 now. :D

[Chris Evans]

Setting a firm release date definitely helps you to focus.

With my game, "Pow Pow's Great Adventure", not only is the release date listed on our website, but several gaming sites that ran news articles on our game also mentioned our release date of September. Not to mention, a couple of newspaper and magazine editors are expecting to receive review copies around that time.

Having such a visible release date helps me focus on the necessary features to meet that goal and I'm less tempted to add or waste time on unnecessary fluff.

[Sillysoft]

Sounds like a good deadline. I also find it helpful to create internal mini-deadlines on a week by week basis. Things like 'finish this feature by friday'. They can then act as signposts along the way to completion. If you start missing them consistently then you know something is going wrong.

Anyways, keep us updated on your progress.

[^cyer]

As i said short time deadlines are cool, hehe for those who post their release dates to various www sites and public - good idea, but then better deliver the game or the waiting masses of people will hate you :)

[Mark Fassett]

I've avoided posting dates as much as possible precisely because I seem to miss any date I set for myself. Something always gets in the way - and it doesn't have to be related to the game. It doesn't mean I don't have dates. I just think posting them is not always the best practice if you're not a full time developer, or if significant portions of your time are spent on things other than development. It's also difficult to complete things on time when people you are working with don't deliver what they promise by the date they promise it. No. No public dates for me until I'm finished with the full version and working on the demo.

[Chris Evans]

Well I am working full-time on the game, but yes posting a release date is a double edged sword.

It motivates you to hit the date, but if you still end up missing the date substantially then your reputation may suffer.

However, delays are extremely common in the software business, so it's not the end of the world if your game slips by a few weeks. Though if a few weeks turn into months, then you may have a problem on your hand. Still, if your product ends up being worth the wait, people tend to forget about the delays or at least forgive them.

[Tom Cain]

You might consider making a prioritized features list to go along with your deadline. It helps to be able to tell how things are progressing as you approach the deadline, checking items off as you go. If "Game Done" is the only goal on your list, I can tell you from experience that it is much harder to make sure you meet the deadline.

Also, if you are prone to feature creep like I am, a prioritized feature list helps when you need to stop adding things and release the software. You don't have to think a lot about the decision because the important things have already been checked off your list.

[BongPig]

Lets not forget that its not all about game features.
Features are easy enough to list and tick off, but gameplay/feel is a bit more difficult.

We had both our games feature complete way before we released the game. It was our bloody playtester who stopped us!

Other features can be calculated. I know how long it takes me to make something. Same with my coder. We may get it slightly wrong, but were always close enough.

But how can we say : "get gameplay and feel of game perfect by October 12th"

Its impossible to know how long it takes to tune. Impossible, and completely different for every game. No amount of experience will give me that knowledge.

Generally, I dont feel many games ( indie and retail ) tune properly by a long way. Just because the game character now moves when you press the cursor keys, thats not the end of it. You cant tick off the 'chracter now moves' feature in the list before he/she/it moves perfectly. Speed, weight, inertia & dynamics need to be spot on.

Can I ask, how many of you use gametesters who have nothing to do with the actual development?

[princec]

I do, frequently. I use the Dad Test. If your dad (or anyone else's) can play it and likes it, it's passed the test.

Cas :)

[stan]

I've got at least one playtester who's not part of the dev team... He and his wife were quite helpful, especially for testing the different AI levels.

[BongPig]

Its these people who should be telling you whether something is finished or not.
The developer him/herself is in no position to tell whether something is done yet! :)

[Chris Evans]

Not necessarily.

Even when you playtest, you'll always have a group of people who say, "Hey, it will be cool if you add this feature!!!" or "The game locked when I jumped on the block 37 times and then ran backwards and mashing all the keys down on the keyboard".

If you have playtesters, they will always have suggestions and they will always find bugs (if they are worth their salt). At some point, you the developer has to say, "This game is finished!"

Though I see your overall point Bongpig, I'm fortunate enough to have a nice group of hardcore gamers who playtest my game. Playtesting certainly shouldn't be skipped to hit a release date, however I would be wary of letting playtesters completely set your release date because then you may never finish your game.

[wazoo]

They can send a man to the moon, but they still haven't bottled the chemicals in your brain that "recharge" themselves while you sleep. Where are our priorities?!

The day they invent those, is the day we start complaining that we ONLY have 24 hours to work...:)

Remember "Time is an illusion. Lunch time doubly so."

Said the wise Ford Prefect.

[BongPig]

Chris, im with you completely. I think we all agree that when it comes to features, a line needs to be drawn.
Its the feel of a game that cant be nailed down. If my tester told me our game still didnt feel right because of A,B & C, thats something I cant let go, regardless of deadlines. Luckily we have a tester who really knows how to communicate a problem to me and our coder.

Its a priceless thing to get comments from our testers like : 'the horizontal inertia is a little loose', rather than, 'it feels crap. Dunno why exactly, it just does'.