Professional developers don’t just develop until things ‘feel’ good and then put the game out. That would be silly. Professional developers develop to certain milestones and then change development focus until everything is thoroughly tested and tweaked and polished and completed.
Here are some common milestones:
Alpha - the game is feature complete; there’s still some polish to be done and a considerable amount of bug fixing, but generally the game can be played. Focus shifts to wide testing, debugging, and adding small features.
Beta - the game is ‘complete’ but not quite finalized. You can play through the entire game. Bugs probably still exist, though Alpha should’ve cleared out the bulk. Focus is testing and debugging. No new features. Period.
Release Candidate - hopefully all the bugs are gone but not necessarily. Testing is narrow. Any fixes are kept as local as possible to avoid repercussions. Every build is a candidate to go final.
Lot Checking - you’ve declared the game ‘final’ and now it’s up to someone else to verify this such as a console manufacturer.
The definitions are a little transient between studios along with when the game should be ‘code complete’ and ‘content complete’, and this list excludes internal milestones which are a reality everywhere. But the general gist is there.
I’m of the opinion that even small studios should adhere to this paradigm for a number of reasons:
(1) It gives a good indicator of progress and allows for better estimates. If you can say your game is feature complete, you have a rough idea of how much longer is left in development. This idea may not be exact, but it’s a lot better than if features are still going in.
(2) It help avoids feature creep. It’s too easy, especially with smaller games, to go back and repeatedly add little touches to make things better. If you can be disciplined about declaring Alpha, you can pretty much set a stopping point for new features and focus on getting the game out.
(3) It reduces moving targets. You can’t do quality heavy debugging while new features are going in. The general rule is this: every feature is going to break something. If you’re still adding new features up until the end, you’re breaking something else up until the end, you just haven’t realized it yet.
(4) It manages cost, which goes hand-in-hand with reducing moving targets. Having a bug during Release Candidate or Lot Check is a Bad Thing. The fix necessitates a heavy amount of testing and verification before the game can be cleared to move on again. The goal then is to make sure that doesn’t happen, and being focused during your testing/debugging facilitates this.
(5) It creates a sense of urgency. Nobody likes beta testing. You want to get out of that as fast as humanly possible. Trust me. Release candidates are even worse.
(6) It sets aside time to really focus on polish. Alpha is a great time to add in those little tweaks that are necessary for real games but which you might forget if you go straight from normal development to release.
(7) It forces you to not polish sometimes. When you get into beta or RC, every change imposes risk and cost, and you have to be critical about which changes are necessary versus which are ideal. If your goal is to release a game on a schedule, sometimes you just have to ignore an issue that isn’t a deal-breaker.
I went through all of the phases for See the Light (it’s currently in “Lot Checking”, or as XBLIG calls it, “Peer Review”), and I think my game is better for it. It’s not a perfect game; there’s only so much I can do as a one-man-band with limited time, but it’s certainly cleaner and more polished and more bullet-proof than the large majority of my previous games. And if (big if) it makes it through Peer Review without any issues, I credit the end cycles for that.
You’ve got the fog effect going on.