Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Bishop36]

Well, we're not likely to have much option as they aren't going to get changed.

You could always not play a game that obviously is completely broken and will remain so for years to come.

[Hydra]

more frequent releases mean more frequent save compat breaks, something that apparently Toady wants to avoid.

I think most people can handle compatibility 'breaks' every few months and so. Also: compatibility breaks are much more likely if you modify stuff everywhere instead of focussing on just certain aspect. If you'd focus on just military for example (and this is just my outsider p.o.v.) you could just make the 'break' relatively minor as in that for example your fort would still be read into your new version but all military stuff would be reset (no squads, no barracks, no waypoints) so that you would just have to redo those in your current fort.

Anyway, I'm not suggesting he brings out a new version every week (although I am hoping on a nice bugfix release soon, my current fort doesn't have a functioning military and is completely covered in blood ), but every month / 2 months would be nice. My forts typically don't last that long. And if you're attached to a certain fort, you can always keep that version around as well. It's not like it takes a lot fo space on your harddrive

[Kazindir]

Honestly, Toady could invent cold fusion and people on this forum would complain it was too noisy.

[Shurikane]

Well, that's pretty much true of any game, really (I mean, check out the comments over Left 4 Dead 2's latest patch.)

[keratacon]

I do think that the web page could indicate that 0.31 is at this time a buggy experimental build, and that 40d is the more stable version that all the tutorials are about.

I've only been playing for about a week, and things have been *MUCH* easier since someone tipped me off to the older release.

[beorn080]

more frequent releases mean more frequent save compat breaks, something that apparently Toady wants to avoid.

I think most people can handle compatibility 'breaks' every few months and so. Also: compatibility breaks are much more likely if you modify stuff everywhere instead of focussing on just certain aspect. If you'd focus on just military for example (and this is just my outsider p.o.v.) you could just make the 'break' relatively minor as in that for example your fort would still be read into your new version but all military stuff would be reset (no squads, no barracks, no waypoints) so that you would just have to redo those in your current fort.

Anyway, I'm not suggesting he brings out a new version every week (although I am hoping on a nice bugfix release soon, my current fort doesn't have a functioning military and is completely covered in blood ), but every month / 2 months would be nice. My forts typically don't last that long. And if you're attached to a certain fort, you can always keep that version around as well. It's not like it takes a lot fo space on your harddrive

Sorry, you have NO CLUE about the file structure he uses to save. Trying to keep save compat save a few items would cause FAR more headaches then just wiping out all the saves once a year and starting over.

[MaDeR Levap]

Remember, Toady waited so long because each update if he did it individually, would break save compatibility each time.

Unfortunately for you, I do not care about save compatibility. Especially in alpha stage game. And yes, this term apply here (sorry Apolloin).

This would lead to the fans being annoyed because each time there is a new release with stuff from .31, they have to start a brand new fortress.

Wut? Do new version of DF search for older versions on disk and wipe them out or what?

Which would you rather have, the current .31, or having to create a brand new world each time Toady releases a new version with one of the updates that came in .31?

Already answered. Play your old verson of DF for old fortresses.

[Apolloin]

Honestly, Toady could invent cold fusion and people on this forum would complain it was too noisy.

Only if the powerplant interface ignored your instructions to generate power, the process itself generated as much deadly radiation as it did clean, safe, power and it tended to go into a cascade reaction that was unstoppable until the next patch came out.

[Apolloin]

Well, we're not likely to have much option as they aren't going to get changed.

You could always not play a game that obviously is completely broken and will remain so for years to come.

You could always take a reading comprehension class so that you can understand people's posts before you comment on them, too. I didn't say it was completely broken and I didn't say it will remain completely broken for years to come. I said that the military interface was completely broken and I said that Dwarf Fortress won't be finished for as long as Toady has work he wants to do on it and we keep paying him to do that work.

However, due to my inability to get my head around setting up and administrating a working military I *have* stopped playing it, at the moment.

[Apolloin]

. 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.

[Nexii Malthus]

Thank you Apolloin, you put my dislikes of the Alpha/Beta tags for indie game development in a way that would taken me far too long to explain.

It is best for Toady just to say it is very unfinished, bugs are to be expected and that is actively worked on, that is all really.

[qwertyuiopas]

That huge wall talking about milestones(yes, I did read it all) seems to be directed at a recent FPS perspective. Lighting. Networking. Scripting. "Environments" associated with lighting, not levels or maps or anything.

Now, to classify DF by that, the closest that can be reached is that the Concept is never quite finished, but constantly evolving, the pre-production was Armok 1, Production is between-release development, and the released alphas are alpha compared to the then-current state of the Concept, or at least the properly extrapolated bits.

Beta is when the Concept needs little further refinement, and thus the alphas will end, Release is when all of the original goals have been met and Toady starts to contemplate improvements to be added for the end of the second development cycle, renewing the ammount of work remaining for stage one.



In short, Toady's release cycle is what you get if you turn the standard procedural cycle into a multithreaded paralell one. Ironically, he manages to also change a team of hundreds into one man with occasinal collaboration with his brother, and the generally insider-only concept of major development into an open community-driven feedback system.

He inverted the structure, and it worked just as well with fewer developers. He found(ed) the future of video game design.

[Urist McDepravity]

Stages of Development:

Does Stardock count as big developer?
Their Elemental beta definitely does not match your criterias. Same for their overall 'stages of development'.
Each studio has its own workflow, its useless to try to fit whole industry into some canon.

[Rollory]

Each studio has its own workflow, its useless to try to fit whole industry into some canon.

You don't actually know what you're talking about, do you?

Software development is a known process.  There are improvements to the process being found and implemented over time, but most of the obvious ways of doing things have been tried, and many of the better methods have been found.  To the extent that different studios have their own take on the process, it is hardly ever fundamental differences in methodology.  This is why people can hop from one company to another and be doing useful things inside a couple days.

Alternatively, there is another reason studios might do things differently from tried and true software development methods, which is bad management.  It is far too common. 

[G-Flex]

In short, Toady's release cycle is what you get if you turn the standard procedural cycle into a multithreaded paralell one. Ironically, he manages to also change a team of hundreds into one man with occasinal collaboration with his brother, and the generally insider-only concept of major development into an open community-driven feedback system.

Wait, what? I get the feeling you're just saying a lot of buzzwords here.

Toady's release cycle is what you get if you turn the standard procedural cycle into a multithreaded paralell one.

This is senseless. If anything, he's done the exact opposite. A development house with multiple team members works in parallel; you have multiple people working on different things at the same time. Toady does the opposite; he's only one man, so the process isn't parallel at all. This isn't to say he should do it differently, but he's not doing whatever it is you just said.

Ironically, he manages to also change a team of hundreds into one man with occasinal collaboration with his brother

Sort of. Keep in mind that he's spent years on this project already. There is a definite trade-off in the amount of time spent versus how many people are working. The fact that Toady works alone is one reason we all joke about v1.0 being so far off into the future. Yeah, it's how he works best, but it's not the sort of magical cure-all you seem to think it is.


He hasn't discovered "the" future of game development. His methods require an outstanding amount of dedication and patience in order to function whatsoever, and wouldn't be applicable to most projects or most developers. He's a good example of how to figure out how to get a project done and persistently work at it despite the costs; this doesn't mean his development model is the next big thing. He found out what works for him and took a big risk doing it, and that's where the value is.