I just want to say that Dwarf Fortress is a great game, maybe one of the greatest I have ever played - and Toady, for making it, one of the best game designers. I’ve been playing around with it, on and off, for about six months or so now. The depth of the generated worlds is amazing, the complexity is amazing, the way anything can happen, the way any series of events might unfold is amazing. The creative freedom of the game is amazing. I really think the fundamental ideas behind the game and the game mechanics are extraordinary.
Unfortunately, great ideas are crippled by a bad implementation. That’s no slight on Toady: Dwarf Fortress is a very large project, and he’s only one person – and furthermore, he’s one person without the education, training, or experience to work on really large software projects. He’s a hobbyist coder, if DF is any indication, and he’s done some extraordinary things…as a hobbyist coder. And certainly some of his experience has come in handy – as I thought, he does have a math background, and I’m sure that was invaluable for certain aspects of DF.
What makes me say the implementation is bad? Well, I don’t think I’ll be saying anything that hasn’t said here before. The interface is tremendously horrible, unworkable. The performance is god-awful – and while yes, Dwarf Fortress could never run efficiently on a desktop from 1999, given what it’s simulating, I am quite sure there is room for a tenfold improvement, especially in some corner cases, like running over frozen oceans in Adventure Mode. And finally, the game is overrun with dozens of very annoying bugs – the beekeeping problems, for example, or the full bucket problems.
The community has addressed these issues to some degree with mods, utilities like Dwarf Therapist and DF Hack, and complex workarounds posted on these forums (when you can find them, anyway.) But these basically amount to putting a band-aid on an axe wound. The game is nigh-unplayable without them. That’s, quite frankly, absurd. As an aside here, for the benefit of the forum members here, it would be an enormous help if there were FAQ topics stickied at the top of each board, rather than telling people “you would know this if you would just search the forums.” Assuming that a newbie figures out exactly what he should be searching for, he then has to go through dozens or hundreds of threads that mention it, some in passing and some in detail, until he finally finds one that is actually relevant.
There’s really only one thing Toady could really do to fix these problems: get other developers to work on DF. Since he (quite commendably) doesn’t charge for DF (which I also believe gets him many more users), hiring more developers is out, because there’s not enough money. The only other viable way of getting more help is by open sourcing DF.
Yes, I know, this has been brought up before. But as far as I could tell in the few threads I actually found on the subject, the arguments against it were bafflingly ignorant. They seemed to amount to:
1. DF is Toady’s baby, and he want to retain full control over it.
2. DF is Toady’s source of income, and open sourcing it would take that away.
3. Too many cooks spoil the broth.
4. There would be 100000000 forks of DF.
All of these are fallacious, but 1 and 3 are especially so. There is nothing about open sourcing DF that would cause Toady to lose his artistic or any other control over DF. The organizational structure of an open-source project depends entirely on its goals. Some projects do operate by consensus and committee, but most open-source projects rely on a single benevolent dictator who has full control of what is accepted into the codebase. If there’s not a single benevolent dictator, there usually is at least a hierarchy of dictators all appointed by the Head Dictator. It is actually quite common for code submissions to be rejected – if you don’t conform to the style or standards, then you can expect to be rejected, or if you implement all on your own some feature that the dictators didn’t ask for and aren’t interested in. Indeed, it’s baffling that anyone could think they operate otherwise – how could any project be successful if they just anyone submit code? It would be a complete disaster.
Which is where the “two many cooks spoil the broth” comes in – some even add Brooks’ dictum that adding programmers to a late project makes it later (these people have never actually read his book.) Some of the most successful software in the world is open source, such as the Linux kernel, GNU environment, various BSDs, the core that Mac OS X runs on, Mozilla Firefox, Google Chrome, the Apache webserver that virtually every website runs on (except Bay12 – it runs the open source nginx), and thousands and thousands of other projects, including, for example, the forum software this board uses. The Android operating system on smartphones and the Kindle Fire is open source and based on Linux. Most likely the very program used to compile Dwarf Fortress is LLVM or gcc, which are open source. You are pretty well guaranteed that you are running some open source program on your computer, and some is much, much more complex than Dwarf Fortress. Adding developers did not make any of these projects later; in fact, many of them have regular release schedules. Firefox, for example, releases every six weeks.
I am not an open source partisan – I’d be very hesitant before going open source myself, because my income also comes from my work. But open source projects can and do make money. Red Hat makes billions of dollars off of Linux. Mozilla makes hundreds of millions of dollars off Firefox. More to the point, though, Toady’s income comes from donations. It’s hard to see how that would be affected by open sourcing it: the leader, figurehead, founder, and designer will always be Toady. While forks are very uncommon because of the work needed to maintain them, people will always come to Bay12 for THE Dwarf Fortress made by THE Toady, just as people go to Mozilla to download Firefox when a couple of forks do exist. And they will donate to Toady, because the game is greater – and if open sourced, would be even better. I have seen some say that the contributors would expect a share of the donations, but that’d be pretty bizarre, since it doesn’t work that way anywhere else and is never even stated upfront because it’s bloody obvious that they aren’t getting any.
I can understand Toady’s feeling that this is his baby and a piece of art that he is determined to loose into the world. But he will never be able to finish it to his – or anyone’s – satisfaction alone. That might be hard to admit, and I honestly don’t expect him to take this advice, even if he does ever read it, because he comes across as a little stubborn. If that’s how he really feels about DF though, then he should feel doubly obligated to accept, even invite, help. Simply put, software engineering isn’t Toady’s forte, and that’s already clear this early in development. One gets the sense just by playing of tightly coupled and poorly architected design, even disregarding poor algorithmic choices. This will only get worse and worse over time. The amount of bugs Toady has on his plate to fix will increase exponentially, and he will have the choice of continuing to implement features and thus generating an exponential amount of more bugs (and even worse performance) or spending entire frustrating years tracking down and fixing bugs, which will often just create (or reveal) further bugs. Indeed, if one is going to go by Brooks, then you’re also going to have to accept that DF will at some point (probably now) need a total rewrite.
Frankly, the community doesn’t seem to be serving Toady well in this regard, where a lot of them seem to defend everything and profess knowledge where they have none. The best example seems to be the implementation of multithreading in DF. I ran across tons of threads where this was derided as not realistic, necessary, and too hard. That’s jaw-droppingly wrong. Processor cores are not going to get much faster – and by the way, clock speed alone is not a good indication of actual speed at all, as I have seen some say when recommending that players buy processors with fewer but faster cores. One of 2.8ghz cores in my Core i7 is much, much faster than , for example, a 3.8gbz Pentium 4. But as this is not the place for an in-depth explanation of processor architecture, I’ll just say that single core speed is going to stay basically static while the number of cores is going to increase. But more importantly, multithreading produces fantastic performance improvements even in single core processors. That’s why essentially every single application on your computer is multithreaded – except, of course, Dwarf Fortress – and has been before dual core processors were a gleam in anyone’s eye. Most important, perhaps, is not so much the raw performance increase but the perceived increase in responsiveness that the user gets when, for example, the UI is offloaded onto another thread. There is nothing difficult about multithreading: everyone does it. And while nobody serious is really going to say that n threads gives you an n increase in performance, it is quite drastic, especially in applications such as DF which can be highly parallelized (and yes, it can – might even be interesting to see how much can be offloaded to the GPU.)
Personally, I think it’s really disappointing that things turned out this way, because DF has so much potential. As a personal project, I’m going to decompile DF and see what I can do. Decompilers aren’t magic – comments, other documentation, variable names, how the software is modularized, etc. – are all stripped out in the process of compilation, so it’ll be a lot of work and drudgery, but maybe it’ll be interesting, especially when I get to the point where I can fix things or (I suppose) add to them. It would be clearly wrong for me to publicly distribute it in either source or binary form, so it’ll never be more than an experiment, but that’s also sadly all DF will ever be if Toady doesn’t step up and get over his personal hesitation. Yes, great projects and works of art require a single vision. But they also take a lot of engineering, architecting, and many, many hands, and Toady simply isn’t a software engineer.