Always 1 month away from completion

Discussion in 'Indie Related Chat' started by bantamcitygames, Jul 29, 2004.

  1. bantamcitygames

    Administrator Original Member Indie Author Greenlit

    Joined:
    Jul 27, 2004
    Messages:
    1,731
    Likes Received:
    78
    (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?
     
  2. Mithril Studios

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    94
    Likes Received:
    0
    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 :(
     
  3. chanon

    Indie Author

    Joined:
    Jul 28, 2004
    Messages:
    468
    Likes Received:
    0
    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.
     
  4. chanon

    Indie Author

    Joined:
    Jul 28, 2004
    Messages:
    468
    Likes Received:
    0
    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 ..
     
  5. MattInglot

    Moderator Original Member

    Joined:
    Jul 26, 2004
    Messages:
    170
    Likes Received:
    0
    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.
     
  6. Diodor Bitan

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    251
    Likes Received:
    0
    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
     
  7. Sillysoft

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    831
    Likes Received:
    0
    "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.
     
  8. MiCo Games

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    38
    Likes Received:
    0
    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.
     
  9. Linusson

    Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    65
    Likes Received:
    0
    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!
     
  10. Reactor

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    1,637
    Likes Received:
    0
    A few things about what my brother and I did...

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

    [​IMG]

    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.
     
  11. MiCo Games

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    38
    Likes Received:
    0
    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.
     
  12. Linusson

    Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    65
    Likes Received:
    0
    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. ;)
     
  13. MiCo Games

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    38
    Likes Received:
    0
    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.
     
  14. Linusson

    Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    65
    Likes Received:
    0
    The same for me. But I still like to know when the game will be ready. ;)
     
  15. Jason Colman

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    79
    Likes Received:
    0
    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.
     
  16. Reactor

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    1,637
    Likes Received:
    0
    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.
     
  17. Jason Colman

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    79
    Likes Received:
    0
    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.
     
  18. Reactor

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    1,637
    Likes Received:
    0
    That's fair enough :) Keep at it... you'll get there, sooner or later. All passionate people do.
     
  19. Jason Colman

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    79
    Likes Received:
    0
    Thanks, it's nice to get a vote of confidence! :)
     
  20. bantamcitygames

    Administrator Original Member Indie Author Greenlit

    Joined:
    Jul 27, 2004
    Messages:
    1,731
    Likes Received:
    78
    (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 ;)
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer