How Dwarf Fortress is built
stackoverflow.blog
stackoverflow.blog
All of that is possible manually, but it is doing version control by hand. There are plenty of great tools out there to simplify that process. And if you start automating your manual custom process, you just end up at your own version control system that is something additional you have to mantain.
* Ability to roll back to some older state. often I have dismissed some solution only to later realize that I need it again, or parts of it. If I have ever committed it, it's still around. Even if it is an orphan commit now, or in the extreme case, if it was once in the staging area you can still recover it later, at least until garbage collection has deleted it.
But whatever rocks your boat I guess.
That can help a lot with understanding code bases: people seldom comment their code properly, so any context you can get is good.
(In my opinion, really good code can often answer 'what' and 'how' without comments, but it has a hard time answer 'why', and an almost impossible task of answering 'why not'? Ie 'why not' this alternative approach?
Whether the answer to that one is "we tried it and it didn't work" or "we didn't think of it, you are a genius for bringing it up" or something else can be important.)
And what the Mikado Method teaches us is that when a refactoring gets out of hand, there’s a much smaller refactor hiding inside it waiting to get out. Erosion history is both a blessing and a curse here, but generally there are bits you can salvage without falling into Sunk Cost.
In fact, right now the main DF developers are working with a partner studio to put a better UX on DF to sell on Steam. I bet an industry standard version control would be extremely helpful right about now.
Creativity is a fickle thing, and it's unlikely that steps X,Y,Z would produce the same inspiration as A,B,C.
I agree that modern version control would offer benefits, but maybe in moving to git Tarn would decide to sha1 everything internally, which would have some ultimate impact on the game that results.
That workflow/tools is not something they advertise, are proud of, or concentrate on. We know about it from a random interview only, so I don't see a reason to count that as part of the DF-as-art.
I believe it's a balance. You don't want to spend your life just adjusting your IDE settings to the point that you never work on your actual project. But you shouldn't completely neglect anything that could improve your life with little effort.
I confess I'm guilty of "procrastination by configuration". I probably spent a year of my total career life just messing with my settings or getting the perfect git or vim configfiles.
If he goes online he has to worry about someone hacking his account, if he keeps it at home we're back to what is his backup strategy, what does his redundancy model look like, and that's just not losing anything he already has. Next he needs to git's enough to be effective. Not that it's hard but if you've never used any sccm before it can be intimidating, and all of it takes time.
It may just be easier to say later, later, later because you don't want to take however long it'll be to move and you're thinking of all the lost development time. Of course if he ever really needs it (house fire, tornado, hurricane) the price will the seem quite cheap.
In the meantime I'd at least find a way to backup off-site even if it's scp'ing passworded zip files to an Azure VM.
Chances are it didn't work for the developer. I've been in places where people were versioning by folder, and pretending it was fine, because they didn't want to learn how to do it properly. They'd come up will all manner of excuses that git/svn/hg/etc had already dealt with. "It's easier to just copy paste", "It's a waste of my time to spend time on a VCS", "What if we both change the same file". I've heard them all, and when I look back at the colleagues who said this, they produced a lot less than they ought to have. Not just because of version control, it's one among several software red flags (never commenting anything, not having tests, not making an effort to make things work on other people's machines, etc).
I'm not going to say anything bad about the DF guy, this seems like a strange foible, but in general not using version control is a major red flag that someone is actually a bit of a novice who is low on productivity.
Version control is the big one, because if you're productive you tend to write a lot of code, and you'll tend to have hit the same issues that everyone has when they're writing a lot of stuff.
Sure, not using version control in an environment where collaboration is to be expected (like in teams/companies where you work with others), I'd agree with you. But that's not Dwarf Fortress, it's just a single person doing the work. Obviously Tarn is not "low on productivity" or "a bit of a novice" since he have done something many of us will never do in our entire life, create entertainment that will forever live in some peoples memories. Just because he's not using Git, doesn't mean it's a red flag, since using Git would basically give him zero benefits and just add more to learn for again, zero benefits.
Git != Github
Just using git on a local machine is nothing like this, unless there's something large I'm missing.
You could also use git-send-email to make a mailing "list" with just yourself, and that way make it much easier to move between machines as you work. Or if you don't trust your email hosting provider, self host gitea or sourcehut (or have the option to later).
Finally, you also get the ability to better organize development with branches.
I don't even know git that well and came up with that off the top of my head.
If I remember right, svn used to be a bit more involved than eg git for just starting tracking of a local project. I think you used to need to set up a (local) server etc?
They seemed to have fixed that, so the barrier to entry is lower than it used to be.
Almost any version control is better than manual mucking around with files.
Git is probably the better investment, if you are new to version control systems; if even just because everyone else uses it these days.
But svn would work ok-ish, too. And you can always convert your history later, if necessary.
In fact, the only reason I use git instead of subversion is that I am required to do so.
Most people use git as subversion anyway, and when they mess the local development, re-create the local development.
No one wants to take a PhD in git command line flags.
* Syntax - in svn different commands use different conventions on how to use revision
* In svn moving directories breaks "subdirectory as branch" abstraction. I.e. there are no actual branches. Only files and versions of them.
* "Svn up" can fail, leaving working copy in broken, unpredictable state. This breaks abstraction, revealing that svn is little but copying files around. Git forces you to save your work and only then merge. That doesn't fail even when it fails to merge cleanly.
* ahem. All branches in SVN are copies of an existing tree at a particular revision. Call it a branch or whatever you want. But if you make a copy of your main development tree, you make a branch and you can work on it in the same fashion as if it was git. Merge it back to trunk when done or continue your work and sync with trunk or other branches. The principle is the same.
* Failing “svn up” is an unexpected technical problem that occurs due to problems with the server or network. The problem should never happen in normal cases.
It even handles running multiple instances of git commands at the same time rather well.
https://edoras.sdsu.edu/doc/svn-book-html-chunk/svn.ref.svn....
Two styles of revisions is super confusing to users like me. Git confuses me a bit, but not in command syntax. Hope this illustration helps to see what I mean.
Yep that's why i still use bitkeeper....and it's great :)
In the case of not using a VCS system "sub-optimal" means he's making his own life difficult for no gain. It is difficult to see that it is anything other than a mistake - a 20 year old project with 700k lines of code is going to benefit from version control. The only saving grace is that Dwarf Fortress development predates git so at least there is a good excuse for how it happened this way, but it is still a mistake.
We all make mistakes though, so the world will continue to turn if Tarn sticks to it.
As far as other opensource go to solutions, CVS and SVN, branching in them was nontrivial. Many folks preferred zipped folders to using CVS/SVN.
For further discussion, keep in mind that thanks to competition from git etc, modern svn is substantially more bearable than it used to be before distributed version control systems became popular.
My first SCM was RCS and have used most of them since then.
Even with all this experience I rather just redo my local devenv than take a PhD degree in git implementation to fix repo state.
https://www.astro.princeton.edu/~rhl/cvs-branches.html
Looks like you had a lousy IT.
You have to wonder why, twenty five years ago, the sysadmin didn't just synch the entire network to the cloud through his iPhone. That, of course, would just show how none of was is your lived experience.
'course there is. While Linus didn't bother, there are people who rebuilt the Linux history from the tarballs, and you can `graft` the historical sequence and the "real" one to get something of a continuous history from 0.01 to today.
It's a lot of work though, old archives often contains partial garbage data (many of the rebuilt linux history incorrectly attribute various historical commits to 2007)
So after the first release, for every release delete all the files in the folder except the .git folder and copy the next set of source files in and commit.
Doesn't account for branches, but seems like this would work and could be done quickly with some shell script.
As a bonus, it is something that has to run on three different operating systems, and the source code for each has been kept separately, and synced manually every now and then.
Granted, it was only like a dozen or so releases and not 20 years worth of development like DF, but that's just a matter of scale, not of principle. :)
But the real simple stuff usually starts out in my misc scripts folder. But that's more for filesystem organisation, not because creating a git repo has any (mental) overhead.
> 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?
If they never got around to learning about version control, it's totally imaginable that they are sort-of rational, and that version control would have improved their lives.
Not sure. I use git at work, but I would never use it for my solo projects. It just doesn't add anything I need, but it takes mental effort to manage it.
But the particular advantages of a single-developer project are worth pointing out; I do think you can "get away" with a lot of... things that would be messiness on a multi-developer project, but aren't on a single developer project when they match whatever predilections of the single developer. There are real "organizational" costs to adding more developers, with the biggest spike at adding a second. There are also obviously disadvantages and limitations to having only one developer. (in this case, not even only one developer "at a time", literally only one developer over the lifetime of a project that's lasted longer than most still-alive software projects!)
AKA, a 20 year project with 1 developer could take more than 20 years with two (to reach the same level of complexity)!
I agree that there are advantages to a single developer project that I don't see talked about a lot.
Very very well said.
I love Tarn and I think there is some wisdom in the way he develops, and he is clearly brilliant.
But I look at the state of Dwarf Fortress now, and Dwarf Fortress 5 years ago, and I do not see a huge amount of additional features and design space that has been explored.
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.
The game still has FPS death when fortresses get to a certain, actually relatively modest, size. This is a big deal, it means people cannot dig in as deep as they want with their fortresses. Imagine if your Skyrim game choked to death after investing months into a character because of an unspoken, undetectable limitation.
It is an impressive project, but the lesson I always take from his talks is: "Take your time. Build it right. Someday you may have to make a new GUI front-end, and I don't want that to take multiple people multiple years to accomplish."
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.
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.
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."
P.S. I say this as an [enthusiastic Nethack player](https://alt.org/nethack/player-stats.php?player=superjoe) :-)
I also got the impression that low level interventions may not be usefully realizable in the codebase.
Note that Dwarf Fortress is not open source.
Why? As long as everyone is aware of the mod, what is the practical difference?
Note that dwarf fortress is free as in beer
"Shouldn't" as in: the developers of dwarf fortress should be ashamed?
Or "shouldn't" as in: the guy who uses mods is not purist enough?
Or something else?
Since dwarf fortress is free as in beer, I wouldn't complain too much.
I've played dwarf fortress a bit about a decade or so ago, and had fun. But I didn't stick with it. For me, the main benefit was in all the other games, like RimWorld, that dwarf fortress inspired.
It's not officially endorsed by the creator of the game. It's not mentioned on the download page or the "links" page.
The game is clearly missing something - a gap is being filled by Dwarf Therapist, and it would be a better game, accessible to more people, if the game just had a better UX built-in.
I'm not saying something whacky. The dev team has the exact same opinion as me and that's why they're putting a bunch of effort into the UX for the steam version.
A newer game Rimworld takes most of the core ideas from dwarf fortress but packages it up in a nice gui with help text so you can learn to play in the game rather than with a wiki.
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.
*except maybe space station 13
In my play experience SS13 wins out in terms of funny stories and variety, mainly because the speed of development is so much faster (especially on big servers like tg), it being multiplayer and there existing many spin-off forks from the usual space station gameplay.
How about "lisp taught me"?
English teachers can hate all they like, but I will not swap the final two punctuation marks!
Rimworld has systems, but they are generally pretty simple. Dwarf Fortress allows some insane interactions between agents that are all organic
The problem with DF is, it's hardly accessible. This is why so many people hope for the Steam version. It's often more fun to read people stories playing the game compared to playing it yourself.
DF offers you the illusion of a living world, that is writing it's own history.
Dwarfs discovering some kind of creature living on a mountain edge. They gain interest in it. Throwing stuff at it, talking about it, giving this creature a funny name. Later on your mason will carve stories on your walls in your castle and somewhere in the story, maybe, he will write about this creature.
It's these little things that make DF fun.
Would be amazing to see all this work that went in to DF exposed to a wider audience with some kind of UI improvements.
They are both interesting.
I realise this is somewhat of a vague question. I've never played DF (or any video/pc games) but I find descriptions of it's development fascinating, and would like to learn more about how the creator actually designed and evolved this game.
Original discussion: https://news.ycombinator.com/item?id=27996684
Factorio can already entertain me for hundreds of hours, but even factorio can become a bit boring once you built a large base.
I'm really looking forward the UI revamp that will be sold on steam.
Hopefully more people will stop that trend of OOP everything, and learn a little more about what we really want to do with our data
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.
Is this some new standard ? Should I start adding he/him just in case I offend someone by not being explicite with something that is rather obvious in 99% of cases?
Normalizing putting our pronouns next to our names seems like a good way to approach this, without needing to explicitly ask others, or make them correct you, which seems nice, as it is pretty much effortless to do.
I wouldn't call it weird, just something that takes getting a bit of used to, but addresses shortcomings in the language. Much like how the Mrs. and Ms. thing is not obvious by looking at someone and therefore needs to be pointed out.
Dr Clifton is using (he/him) when he has no reason for doing this. Of course You can try to explain this as solidarity but for me it threads dangerously close to some kind of strange conformity to woke culture (I still don't understand why this is the minority that was granted this kind of political power - there are lots of other minorities that could also use this kind of recognition).
One possible reason in my eyes is indeed what you're hinting at - normalization of doing this and thus solidarity in a way, at least that'd be my best guess.
I find it odd that many websites out there feel like they should ask me for my gender when that has nothing to do with the services that they'll offer me, most likely being some advertising/data mining scheme or just a data point that's ingrained in our culture that they think they're deserving of. Similarly, i don't see why pronouns are that different.
It's just that in non-online mediums you can attempt to figure those out based on how people present themselves, at least sometimes, should they be relevant, however that's not always possible online, hence being asked to point those out. Of course, if the aforementioned AFAB friends want to use masculine pronouns, people around them presenting theirs, even when they're the "default" ones makes it easier for them to not feel awkward about their self expression.
On the opposite end, might as well use gender neutral pronouns for everyone, if that doesn't matter that much, even though that most likely won't be done either because of information loss. Some languages out there have even more pronouns and feminine/masculine forms of words - languages and social aspects are sometimes curious and puzzling. Oh, also Japanese honorifics are as interesting as they are overcomplicated, cool stuff.
> I still don't understand why this is the minority that was granted this kind of political power - there are lots of other minorities that could also use this kind of recognition.
This may or may not have something to do with the fact that it's relatively easy to do and doesn't take large amounts of effort to be nice to someone in that regard. The whole Git master to main branch thing and master/slave to leader/follower and whitelist/blacklist to allowlist/denylist thing probably took more effort than that. Sometimes these newer terms actually make more sense than the older ones, though.
As for other minorities that could use recognition - sure! I don't get up in the morning and think: "Hmm, today i'd like to be kind to LGBTQIA+ people, but i'll only care about racial issues on Wednesday." There's no reason not to be nice to most people, it's not like our capacity to do that is so limited for it to be hard.
Now, admittedly, i don't agree with everything that's happened in the world, like how Richard Stallman was cancelled over some claims that to me read like expressions of him not being entirely neurotypical and perhaps caring only for the facts (which isn't wrong) whilst lacking social tact (which isn't good, but also probably not deserving of the scale of backlash).
But for the things that seem like they might make sense and aren't actively making the world a worse place, i guess i can get with the times and be supportive of them.
Weird fact: DF doesn’t have version control, except for ‘mkdir’ and ‘cp’.
I don't think he'd just sell it.