Hacker News Reader

Comment by umvi | Hacker News Reader

A great example of not getting bogged down in analysis paralysis. Adams chose and continues to choose "sub-optimal" technologies for developing and running DF. Heck, last I checked he is still manually doing version control with folders and flash drives. As he states in the article, he is infinitely more interested in the design side than the technology side. The takeaway is that he is motivated to make his vision a reality and ships regardless of the tech choices. An imperfect project that ships is better than a perfect one that doesn't.

View on HN

I always take the opposite view of the development of Dwarf Fortress. I think it is a shame how much the game has stagnated, and it is frustrating when the creator brags about not bothering to use version control.

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

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.

But your pinky doesn't have to be simulated every frame, right?

That entirely depends on your objectives; pragmatically, of course there are worthwhile optimizations to be made, from _my_ perspective, but my idea of optimization is not Tarn's.

I've followed DF since 2010. Tarn treats his game more like a hobby than a business. Of course, that is his prerogative, and maybe his objective.

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

Over the entire development of DF an afternoon or two to try out git or similar would have been a drop in the bucket. There's a lot of (useful!) ground between using flash drives and trying out a hot new version control workflow every week.

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.

But, who cares? If this worked for the developer, what's wrong?

Prevents collaboration with others, ability to rollback to a specific release to test a bug, partially developing multiple ideas.

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.

* Free sync across multiple devices

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

Also the ability to see when what feature of the code was introduced.

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

There is barely a week that goes by that I don’t start off with a good idea but halfway through I realize I’ve taken a wrong turn or bitten off the wrong chunk first. If it weren’t for git or more frequently Jetbrain’s local history, my output would be lower quality.

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.

Seems like the some of the best work is done in thinking during menial tasks moreso than during actual coding time!

Nothing until a catastrophe causes lost work, or if they wanted to collaborate with someone else.

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.

I don’t doubt that the lack of VC is causing that project’s delayed release. It was announced nearly three years ago.

It depends whether the process is part of the art itself, or just the result. If someone wants to be the excel artist (https://www.spoon-tamago.com/2013/05/28/tatsuo-horiuchi-exce...), that's cool even if other tools would give them more possibilities. But in this case, the 80s development style is neither part of the art, nor is it better in any way at all, so people keep pointing out that this decision is just objectively worse than doing the absolute minimum of modern version control.

I get your point, but it's also not entirely accurate to say the workflow and tools aren't part of the art.

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.

> not entirely accurate to say the workflow and tools aren't part of the art.

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 think you're talking about the artistic _product_, and the ethernet bridge is talking about artistic _process_. Like, you don't care what kind of paintbrush a painter uses, but it matters a lot to them.

git blame so the developer can remember why they did something 15 years ago.

He should care. The effort to learn git would have saved him time. Time he could have used to improve DF or to sleep, whatever. But instead he's still moving folders around.

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.

I think you may be overestimating the amount of time and effort it takes to move folders on a modern computer.

I don't disagree he needs a source code control system. But it's his intellectual property and right now he has some protection through redundancy. At least I certainly hope he keeps some USB sticks with a friend because if not one house fire and his livelyhood is gone.

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.

> But, who cares? If this worked for the developer, what's wrong?

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.

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

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.

You forgot to mention the "click on this one specific checkbox or your source code is now leaked to the entire internet forever" part. So actually, not that simple and potentially much much worse.

Git doesn't require an internet connection. With git you can keep doing backups the same way and store the git repository in flash drives, Dropbox, Amazon Glacier, or anywhere you want. The main difference here is that you don't need one folder per version anymore.

> You forgot to mention the "click on this one specific checkbox or your source code is now leaked to the entire internet forever" part.

Git != Github

Just using git on a local machine is nothing like this, unless there's something large I'm missing.

This is just "copying to a flash drive" with extra steps.

Except you also get a better history (assuming you write good commit messages), and it's all in the same folder.

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.

Git has no checkboxes. It is purely command line. Are you talking about Github or Gitlab? I know Gitlab used to have this bug where you could easily accidentally give everyone access to all your repos.

No fully true, there is gitk and git-gui (both part of the full-git-package)...but yeah no "publish to internet" checkbox there ;)

So you mean svn?

Yes, svn would support this use case.

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.

Subversion doesn't need a local server, a directory for the repo will do.

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.

Maybe people are wired differently but I have always thought that git is way more intuitive than Subversion and I was more productive after 1 week of git than I previously had been after 1 year of using Subversion. I am sure Subversion has improved since then, but so has git.

It would be really interesting to learn what git users think is less intuitive in Subversion than in git.

Quite a lot.

* 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. Revision is always a revision in SVN. It’s rN and all commands accept it.

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

To be honest, Git is pretty good about dealing with 'unexpected technical problems'.

It even handles running multiple instances of git commands at the same time rather well.

First point: Here is an official svn doc with lots of mentioning of @revision

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.

Maybe a more up to date version of the doc will help: https://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs...

The xkcd carton is still quite up to date.

>No one wants to take a PhD in git command line flags.

Yep that's why i still use bitkeeper....and it's great :)

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.

Normally lauding a "sub-optimal" tech means the optimal tech isn't a fit for the problem space or the cost of adoption is higher than the benefits. Something like Tarn doing everything in C/C++ which is arguably good and arguably bad but works. It is unclear that switching languages would be a net win or loss.

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.

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.

ClearCase was expensive, unless you pirated 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.

Linus Torvalds famously preferred tarballs over CVS.

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.

What is so hard about creating a branch in CVS and SVN?

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.

You don't remember when your CVS admin would send out the email announcing the repo would be frozen for the next 48 hours so a branch could be created for the golden master? I don't know why it was such an onerous task but the disruption creating a branch would cause was significant given you would only commit every few weeks when all your changes were ready. Compared to modern VCSes it was like having no VCS at all.

But SVN had cheap and quick branching.

No, because creating a CVS branch was relatively easy.

https://www.astro.princeton.edu/~rhl/cvs-branches.html

Looks like you had a lousy IT.

You know what happened when you did that one simple command that every sysadmin hates? It copies all of the thousands of files containing all the millions of lines of production code from spinning rust-coated glass to spinning rust-coated glass on system that run at hundreds of megahertz. If anyone accidentally checks in a change between when the copy starts and when it ends, the entire source history going back years gets horribly and irretrievably corrupted and you need to spend a couple of days restoring everything from backup, which is inevitably rust-coated mylar tape to rust-coated spinning glass disks, rebuilding indexes as you go. That is assuming the restore from backup actually works, which is rarely if ever tested and you know full well even if it is tested that's the day you experience not one but multiple disk failures probably because of all the intense activity. Meanwhile you lost your slot at the manufacturing facility in Taiwan because your golden master wasn't delivered in the brief window required and they have already retooled the line for another customer. Maybe you can recover from the financial loss, or maybe your sysadmin just takes the reasonable precaution of freezing access to the CVS repo for the days the branch takes to create, and schedules it over a weekend to minimize downtime.

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.

Really lousy IT.

Maybe at one point ClearCase could have been considered state of the art, but that ship has long sailed. I used it professionally from 2004-2013, and it was awful. Branching was slow. Well, everything was slow. It was way too easy to miss new (view private) files. Non trivial merges were atrocious. We were begging to migrate to svn...

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.

Well there must be 20 years worth of backups. I wonder whether there is a way to turn 20 years of zip files storing different versions into a git repository, using the dates of the zip files, the dates of the files inside and perhaps the name of the zip files. Bonus points for detecting branches.

> I wonder whether there is a way to turn 20 years of zip files storing different versions into a git repository, using the dates of the zip files, the dates of the files inside and perhaps the name of the zip files.

'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)

Yes, PostgreSQL did this when they switched from CVS to git. They used that as an oportunity to prrpend the history woth the contents of some ancient tarballs that they had.

Assuming there is a folder for each release, all you would have to do is commit the first release then each subsequent release.

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.

I did exactly that at work, when I inherited maintainership of a legacy internal software program, which until then has been developed with the same "version control" approach as DF - a folder/zipfile per release or per feature branch.

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

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.

I understand your example, but as a counterpoint: I do keep simple scripts in version control, too.

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.

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

I use it for my solo projects as well, but my commit messages (and history manageent in general) is much better when I'm writing for other people.

I'd be cautious to take a 20-year project with only a single developer the entire time as an example for other projects that are not that.

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!)

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)!

Right, my point was meant to be that some things are indeed possible with a single developer that aren't with a team and that adding more developers adds organizational challenges. (But there are of course other things not possible with a single developer).

I agree that there are advantages to a single developer project that I don't see talked about a lot.

“ An imperfect project that ships is better than a perfect one that doesn't”

Very very well said.

I see the opposite. DF is stagnant as hell and other games have eaten it’s lunch by building and iterating at light speed compared to the comparative snails pace of DF.

Using git as a single developer takes tens of minutes to understand at most. It is hugely helpful over time to see what changed and why. The fact that he isn't doing this is a net negative.

infinitely better*

Reply on news.ycombinator.com