I realize that there is no One Size Fits All answer here...

But, lets say I can complete a full game in about 3 weeks (commercial quality). The only problem is, I rarely do. I have completed about 3 games in my 2 years of development. My most recent one definately the best.

How do you keep going? Do you plan? What?

I've recently become a big fan of what I call "Circular Zen". Examples:
I keep going on my projects by the simple process of Not Stopping.
"Human nature" is what humans do. If a human does it, it was human nature to do it.
I do what I do because it's what I do.
Nothing is "unnatural" because everything is a part of Nature.
Et cetera.


On the other hand...I do plan. But, again, to me, that's part of the project. So of course I plan. :)

Never forget: 3 games in 2 years, and you have now outproduced Valve Software. ;)

-David (who wonders what he's been drinking lately)

A commercial-quality game in three weeks? Wow. I'd have to assume you are basically enhancing an existing engine with which you were already incredibly familiar with, and adding in new content. Still seems like an awfully short time. I am not even positive I could feel comfortable with only allocating less than three weeks to testing alone. But again: tried-and-true technology, straightforward title... maybe you can :)

As an indie, I've not yet completed my first game (working part-time on it). However, when I was doing it as a pro, I completed a commercial-quality (budget) game in about 3 months with a team of 4. We killed ourselves doing it. And we completed several other titles (some of which went on to sell over a million copies).

I kinda echo David's comment: You just DO it. Yeah, maybe you go over schedule (I know I have...), but you just have to focus on getting the job done.

I plan regularly. I'm not a fan of GIGANTIC PLANS. I think they are counterproductive. But when you start, you need to have a general idea of where you are going, and how you are going to get there. Set your target dates, and try and figure out what tasks you'll need to complete to meet your target dates. Double your estimates at this point, because you are probably forgetting nearly half the work you are going to need to do.

Then break each stage down into smaller plans. We recently had a big demo we had to put out, so I broke down what EXACTLY needed to be done for the demo. I had an overall guide of all the tasks I needed to get done (and it did change) for the development effort, and then I also tried to break out "daily tasks" that needed doing. So I planned constantly, but I didn't devote a gigantic amount of time to doing it.

Well, bug fixing and all is not counted in that, that usually takes months :-D.

And, I meant more sellable quality, then commercial quality. I don't mean like 300,000$ particle effects, and 20,000$ 3d models.

Also, that is 3 weeks of 4 hours minimum of WORKING time. I do Dexterity's plan of recording all things I have done, and I just keep working until I have at least 4 hours of time actually getting work done.

Originally posted by maxdgaming
Well, bug fixing and all is not counted in that, that usually takes months :-D.

And, I meant more sellable quality, then commercial quality. I don't mean like 300,000$ particle effects, and 20,000$ 3d models.

Also, that is 3 weeks of 4 hours minimum of WORKING time. I do Dexterity's plan of recording all things I have done, and I just keep working until I have at least 4 hours of time actually getting work done.


I don't see any link to the games you made? Is there anything available?

The way I do it is, I guess, a milestone-based approach, and (just like Coyote) by not having gigantic plans.

I've decided on the type of game I want to do, and also jotted down the key features, the selling points of the game.

Next, I sit down and ask myself "Now, what would be the one thing I could add that would make the most difference?"

This could be anything, depending on how far into the project I am. If I had nothing done at all, the biggest thing would probably be to get just something, anything, on screen. Or it could be adding animation support, or a specific gameplay feature etc. The point is, it should be big enough to make an impact, but small enough for me to easily visualize how I would do it.

Then it is pretty easy. My next milestone is simply to do that one thing. I work on it until it works, until it is testable in the game. I don't polish it until it is perfect, I work on it just long enough for it to meet the requirements. Polish could be added at the end of the project, by going through all parts of the code again, and choose to make the improvements that would make the most difference.

If I reach the milestone faster than expected, I don't spend that extra time polishing the current feature, I move straight on to the next. Because at this point, polishing that feature would not make the biggest difference to the product. Adding something else would. And if it takes longer to finish than I had expected, I don't switch to anything else, I don't start cutting stuff away, I just keep working at it... becuase at that point, it's still the one thing that makes the biggest difference.

By working this way, I get constant progress in the areas that count, which also helps keeping me motivated. I never feel that the project is standing still.

I never consider any part of my code to be finished. I always expect to go back and improve or rework it, if it ever becomes the thing that would make the biggest difference for the project if it were improved.

Originally posted by Yuriy
I don't see any link to the games you made? Is there anything available?

Not quite yet, I am just finishing up level design on one of my almost completed projects (like I said, I never finish anything worthwhile)... Give me a week, and you will see it.


And, as you complete the game, what do you do about the '1' thing that makes the most difference? Do you go the '1' bug that needs the fixing the most?

I follow a regimen of "bugs first, features second". If I have a bug, I focus on fixing it right now instead of adding new features.

If you let bugs fester, you'll either forget about them entirely, or at the very least lose the ability to fix them efficiently. Fix a bug as soon as you see it and you'll be happier in the end...

I agree, bugs should be given top priority. If I'm working on adding a new feature, I don't consider it to be done until it runs in the game without bugs (regardless of whether it is bugs that are related to the feature at hand or not).

Sometimes (often?) adding a feature can introduce bugs, sometimes adding a feature allows you to find bugs that was always there, but not visible. So I don't consider a milestone to be reached until ALL bugs are gone.

Performance is a different thing though... I usually only aim for reasonable performance when I first add a feature. It is more important for me to get more features in and working without bugs than to have a fewer features run at full speed with all bells and whistles.

Chrome can be added later, and if it for some reason turns out it can't, the gameplay doesn't suffer. And there's probably some other area where you can add chrome to make up for it :-)

Originally posted by EpicBoy
I follow a regimen of "bugs first, features second". If I have a bug, I focus on fixing it right now instead of adding new features.

If you let bugs fester, you'll either forget about them entirely, or at the very least lose the ability to fix them efficiently. Fix a bug as soon as you see it and you'll be happier in the end...


Hmm, although I am the one asking for the help here... I like my way (for me) better...

I keep a list of bugs.. and at the end of each day, I fix as many of them as I can. The rest of the day I work, so the game is still improving, but at the very end, I will spend -say an hour- fixing bugs....

It seems too work, although I am having trouble finding bugs now :D I know they are there... just cant find 'em. How I know... I am not sur.e

It is tempting to just rush ahead and add stuff to the game. I know I feel like doing so from time to time. However, I don't think it is a good idea at all. If you know you have bugs in the code you have already written, it can be dangerous to continue to build on that foundation. And more importantly, it gives you a false picture of how far along you actually are. With bugs in the code, there's no way of estimating how much longer there is to go before you can release. Without bugs, you can release whenever you feel like it - you just won't have all the features ;-)

The thing is, it is easy to say that "yeah, I know that bug, im sure it is because of X, or possible Y, that's no problem, I'll sort that later". But then you discover that it was actually Z that was causing the problem, and fixing that means you have to rewrite part of the code, which will cause other parts to be changed as well, and so on. And for every change like that there is the possibility of more bugs being added.

Originally posted by maxdgaming
How do you keep going? Do you plan? What?

An interesting quote that was emailed to me yesterday:

There is no voodoo to how to get unstuck. It's about taking actions every day in a sensible way with a little bit of creativity and invention. -- Keith Yamashita, Principal, Stone Yamashita Partners

The way to keep going is to keep going. Baby steps at first will build momentum and soon you'll realise that an entire day has gone by.

IMHO, planning is essential. Being able to scratch a completed task off the plan is great for my motivation.

Cheers!
Carl

I'm not quite so focused on maintaining my game in a "zero bug" state. I tend to follow the evolutionary prototype development methodology, which means I end up throwing away and rewriting entire modules. This makes some bugs just "go away" as I iterate. But the conventional "waterfall" approach of addressing bugs near the end of the development cycle is totally screwed up and destructive to your project. You are sacrificing shortened overall development time, and maybe even the success of your project, for the sake of faster short-term visibile progress.

What I did during mid-development (the most frustrating and slow stage) was to arrange my tasks so that I 'rewarded' myself with a really fun task only AFTER I completed two other, more painful tasks (like bug fixes, or a less-than-thrilling feature addition / change). Now I'm rapidly approaching a 'feature complete' beta, and so I've just about out of fun tasks. But I have a nearly-complete, very playable game, and seeing the light at the end of the tunnel growing large is a reward in itself.