. Especially in alpha stage game. And yes, this term apply here (sorry Apolloin).
Stages of Development:
1. Concept - This is mostly done on paper by the Game Designers and representatives of the other disciplines.
2. Pre-Production - This is where the team ramps up a little to begin creating the full Design Documentation and the Concept Artwork is put together. Pre-Production ends with the creation of the Proof of Concept which creates testbed simulations to prove that the risks represented by the Unique Selling Points, the spec for the Game Engine and the High Level Design document are manageable.
3. Production - Here the main grunt-work of game creation is done. The various systems are put together, the game engine is completed and the low level designs for the levels/environments/gameplay are fleshed out into demonstrable pieces. Most of the evolution that the project will go through between Proof of Concept and Release happens during this phase. Eventually you create a Pre-Alpha demo that hopefully shows that most of the Tech and Gameplay challenges have been surmounted, that the gameplay is fun and that the project is ready to move into the endphase.
4. Alpha - Any part of the game that is shown before this point is referred to as Pre-Alpha. These demos show up most often at Leipzig, whatever the thing that replaced E3 is called now and other such venues. Alpha code is basically the final technology, but it is allowable for some effects to be placeholder, for environments to not be fully lit and other such sundry enchancements. Alpha code generally still needs to be optimised to make it run more efficiently within the target hardware platform spec, the gameplay is typically not polished or even complete and sound effects, voice acting and cutscenes may all be absent.
5. Beta - When the project reaches the Beta milestone it contains pretty much all the assets that will ever go into it. The gameplay is largely finalised, although tweaks to the scripting and the final balancing remain to be done. Graphics should also be finished by this point, although it's not unusual for final lighting passes to take place after this point, or for some of the graphical effects to be tweaked. Game Engine coding should be complete, but networking code and optimisation of the game engine are still being worked on. The focus from this point is optimisation and bug fixing.
6. Release - When the project reaches the Release milestone it is because the Producer for the Publisher and the Producer/Lead Tester for the Developer have come to an agreement that all the bugs that are going to be fixed are fixed. I'd like to say that it means there are no bugs to be fixed, but many bugs that are detected are marked 'Works as Designed', 'Cannot Reproduce' or 'Will not Fix'. Typically 'Works as Designed' bugs are disagreements as to functionality between Testers and Programmers/Designers, 'Cannot Reproduce' bugs are weird little reality artefacts that reproduce on such a long timeline that it is not economic for a Programmer to change/test/replicate cycle them. 'Will not Fix' bugs are bugs that are very difficult to fix without breaking the entire game apart, or bugs which require an inordinate amount of man hours to fix compared to their impact on the game.
Essentially, the timeline to release is plotted and the bugs are prioritised into A's (Show Stoppers) B's (Less Critical but Important) C's (Preferential Fixes) and D's (Improvements to SubOptimal Implementations). At a set point, quite early, D's are no longer addressed. When the time to release is less than the amount of time taken to fix all A's and B's, then C's are dropped. When the release deadline is near, then B's are no longer addressed. Most publishers, these days, will delay release if a Show Stopper bug is still in evidence, unless they feel that it can be put in a Zero-Day patch in the 2 months it takes a game to go from being completed to arriving on store shelves.
Now, the integral thing about these milestones is that they were all linked to Milestone Payments between Publishers and Developers, back in the days that there were Developers who weren't owned by Publishers. (I know, some still exist but they are much rarer) The idea was that if you didn't do the work agreed on by the time specified, you didn't get paid until you DID. A milestone was officially reached when the Producers for the Publisher and Developer agreed that they were. Successfully meeting a milestone was usually a cause for much celebration at a Development Studio since it meant nobody had to ask "Do you want fries with that?" or go back to working at a bank for awhile.
When the big Publishers bought up most of the indie Developers, they still used Producers that reported to the head office and they still used milestones to determine whether progress needs had been met, but a lot of the fear of an impending milestone eased, as the employees were all salaried and got paid, regardless. That's a story for another time, but the point is that since the Milestone system worked as well as any other that had been tried and since most of the Industry is familiar with it, it still gets used to this day. In other words, it still requires an Internal and External Producer to agree the milestone has been met.
Dwarf Fortress does not have an external producer. Internally, production tasks are done by Toady who is also the Art Head, AI Programming Head, Effects Programming Head, Game Engine Programming Head, Lead Designer, Lead Tester, Concept Artist Head and Development Director. In other words, the concept of milestones are valueless since Toady plans them, Toady does all the work on them and Toady is sole arbiter of when they have been achieved. That's one of the reasons I've been saying that they really oughtn't to be used in reference to this project.
Now, my wall of text is done. Apologies, but I really think we need to change the way we think about Dwarf Fortress, an indie project that is, if anything, still in the Production phase.