How Dwarf Fortress is built

> Even when Tarn decided: "Hmm, maybe making some money for a product I am proud of and work extremely hard on" when he decided to add the Steam version, it has been a long load to make it there.

Not quite. It's health concerns.

Quoting https://www.polygon.com/features/2019/3/14/18264569/dwarf-fo... :

"Not long ago, he explains, Zach had a cancer scare. Even with a good insurance plan, the costs to tease things out were high. When Adams looked at his own plan he was shocked.

“We were looking at the health care prices,” Adams says. “If it had been me — we grew up in the same town, right; we have all the same doctors and everything — I would have been wiped out.”

“It’s just scary,” Adams says, referring to the health care system. “The whole thing. So that was on our minds. But also, the whole crowdfunding environment has been a little bumpy, just in terms of how Patreon changes. [...] That’s just how it is in games in general. People just feel kind of a little squeezed right now.”

And so the brothers at Bay 12 are doing something they thought they’d never do. Nearly 16 years into the project, they’ve pulled the trigger on a plan to make a proper commercial release. But how they’re planning to do it is the remarkable part."

FPS issues is what eventually killed dwarf fortress for me. If you want to do anything interesting be prepared to watch the game slow to a crawl.

That and construction of anything being a nightmare as your dwarfs will get stuck in every conceivable way trying to build even a simple wall more than a meter high.

That said, I have spent hundreds of hours on the game with some great stories to tell so overall I can't complain too much.

>because of an unspoken, undetectable limitation.

It is certainly not. It's a well-known limitation.

And it's not even specific to Dwarf Fortress: with most "simulation" games you really can't have your cake and eat it too.

Some games sidestep it with "make-believe" simulation, where they reduce simulation resolution to arrive at something plausible, but not necessarily correct.

But that's not what people are playing DF for. I like my pinkies damn well simulated.

Absolutely agree. The single master branch, commit when you feel like it workflow is very simple, and still miles better than just copying files in the file system.

Probably, but also that will always be true “one afternoon of X will make things better” but if it’s working for somebody I’m not going to tell somebody their workflow is wrong.

I've noticed that people tend to have varying differences in their mental map of organization. If you view a codebase as largely monolithic with only a few states such as previous/backup, current, and future/editing, the addition of version control may not help workflow. Editing is always a rolling-release model, be it backwards or forwards (at least that's what I interpret from "there is kind of an active molten core that I have a much better working knowledge of" in the article. If version control were introduced, you would now be tasked to actively divert workflow to the versioning software, such as when reverting commits, etc. You don't create a repo for trivial objects, such as a simple shell script you write for your personal desktop, so it's easy to see this applied to scale, especially with a single-person codebase like DF. For the script example, a file will typically have undo/revert history in an editor, which itself is a limited form of version control. So there obviously has to be some form of version control used by the author other than file copying, albeit not as explicit as git. I think it's unfair to call it a mistake unless you're directly affected. In the 20 years of (solo?) development of DF, do you not suppose a rational person would adopt versioning were a lack thereof impacting them noticeably? So obviously it's a non-issue as far as scope of the codebase goes.

If nothing else to see and learn from your own history. Imagine a rich 20 year history of commits. Even if it was all the most basic system with just branches and commits and merges. I am still a source control simpleton after 20 years, but having a few branches using git is rather trivial.

I managed code in version control long before Git, and before DF existed in 2002 we had decent and sometimes great tools (ClearCase?). Still, I personally do not care how other people work. Different strokes for different folks, etc.

But the other side of the argument is that the game is amazingly complex, and this level of complexity may not be possible if you add in a 2nd developer - their vision would conflict, or compromises given early on that prevents future complexity to be added.

AKA, a 20 year project with 1 developer could take more than 20 years with two (to reach the same level of complexity)!

therapist seems like an important one, iirc they showed a similar interface in a steam version demo. Without it, jobs and aptitudes of all different dwarfs are all over the place and woe to you if you forget the key combo because by the time you figure it out you probably forgot the friggn guys name

This is a third party mod. You shouldn't need a third party mod to get the main gameplay experience.

Note that Dwarf Fortress is not open source.

This was the tool that finally made DF playable for me, with it I was able to get into the game enough to enjoy myself and realize what everyone was going on about :)

They should have called it "Dwarf Shrink"!

That is what I have been told. I have tried both and I ended up getting a lot of enjoyment out of rimworld while in DF I spent several hours studying the getting started wiki and still didn't really feel like I understood what was going on.

Would be amazing to see all this work that went in to DF exposed to a wider audience with some kind of UI improvements.

Rimworld is nowhere near as deep as dwarf fortress, but it's a game many more people actually manage to play.

They are both interesting.

As someone who has played neither game, can you please explain why?

To be fair this is basically just a texture pack, which is already something you can use. The real problem is the highly consistent UI design, differing in things as simple as if you have to use a keyboard or mouse to navigate a list.

Toady is understandably disinterested in putting time into that element of the game, and I think he had a bad experience the last time he 'outsourced' it.

I'm super hype on this. I've managed to play DF a bit successfully thanks to Dwarf Therapist, but I'm really excited to come back and play again with the UX overhaul.

This is exactly what I was looking for, thanks!

Still interesting to watch, thank you.

It's actually a repost of the same article from earlier in the year as the editors note points out.

Plenty of games were made using plain C and even Assembler.

What is really needed are not objects in a OOP sense, but a way to make a mutable, composite data type. Else you would have to pass tens of arguments to even simplest of functions.