16 ms·

One thing that amazes me about Dwarf Fortress is that the creator(s) don't use version control[1] (as of 2014, things may have changed): "I don't use version c

by umvi 8y ago

One thing that amazes me about Dwarf Fortress is that the creator(s) don't use version control[1] (as of 2014, things may have changed): "I don't use version control -- I didn't like the feeling of having the code get committed into a black box thingy with no immediate upside." I can't fathom how you can manage the complexity of a game like DF without a VCS. [1] https://www.reddit.com/r/IAmA/comments/1avszc/im_tarn_adams_of_bay_12_games_cocreator_of_dwarf/c919fo8 https://www.reddit.com/r/IAmA/comments/1avszc/im_tarn_adams_...

Pfhreak 8y ago
They almost certainly use some sort of version control, like all novice programmers do, right? -- copying files/directories, creating backups, etc. (MyProject02.old.bak.zip).
- felipemnoa 8y ago
  I'd be surprised if that is not the case. No way they could have gotten this far without at least this minimum level of version control.
- Buttons840 8y ago
  Ah yes: myproject.final.zip myproject.production.zip myproject.backup.zip myproject.backup2.zip myproject.shipped.zip
  - CydeWeys 8y ago
    myproject.final2.zip myproject.final3.zip myproject.final_for_real.zip Been there done that. I prefer git where it's all just meaningless hashes, or semver tags.
jandrese 8y ago
It makes a little sense. They aren't working with any kind of time limit, so if they break something they just work at it until it is fixed. There's no rolling back to the last good version. But yeah, this is undoubtedly a factor in the games rather glacial development rate.
ethbro 8y ago
No development team, no need for version control. I meta love DF for it's primitive development practices too. Guy decides to make a game with a block of stone and a chisel, development community calls him crazy and says games can't be made that way, but he keeps chiseling away.
- oftenwrong 8y ago
  This is like stone carving with a chisel, but striking the back of the chisel with your hand instead of using a hammer. A hammer adds a bit of complexity, but you will save yourself a significant amount of pain.
  - Macuyiko 8y ago
    Until you hit your hand with the hammer, then you can't use either the hammer or your hand any more (pedantic, I know, but meant in good spirit)
tom_ 8y ago
They take backups, name each folder based on the date, and what feature that was just completed (or just about to be started) that prompted the backup. I bet you a pound. This is what everybody that says they don't use version control does.
- chimeracoder 8y ago
  > They take backups, name each folder based on the date, and what feature that was just completed (or just about to be started) that prompted the backup. I bet you a pound. All they need to do is to compress those folders with zlib, and then they've reinvented git.
  - peheje 8y ago
    diff, branch, merge, blame, stash
  - a1369209993 8y ago
    That's what I do (for personal projects where I don't care about complex commit-graphs) and I do call it version control.
    - chucksmash 8y ago
      Justifications like "where I don't care about complex commit-graphs," of which there are a few in this thread, always sound like they're trying to hide confusion about the tool by making it sound overly complex. Nobody cares about complex commit-graphs! If you're just one person, you can work directly on master and just commit everything every time: git commit -am "I did some work" Don't try to follow gitflow or githubflow or whatever it is that's made you bail on real version control. But why play the copying folders monty game in 2019?
      - a1369209993 8y ago
        You don't seem to understand my previous comment. Tarballs are better. Complex commit-graphs are not a reason to avoid git for small projects, they are a reason why I can't avoid git for large projects. The revision history is complex or not regardless of what software I'm using to slog through it.
danielbarla 8y ago
Honestly, for personal projects where I'm the sole developer, I only use git nominally. I mean, it's there, and sure, I commit; but it's not like I'm spawning feature branches or anything like that. It's a rather linear set of commits, functionally almost equivalent to having a zip of the source every now and then. I'm sure many people are the same.
- stcredzero 8y ago
  Hear hear! That said, it's pretty damn useful to have a log of my changes. Commit often, and it's even more useful! IntelliJ IDEs have pretty nice ways of viewing the diffs over time per file, and many other tools exist for doing this. Super useful!
- zrobotics 8y ago
  Even for small personal projects, for me the real killer feature is commit messages. Otherwise, it's almost impossible to remember which numbered folder has the change I want, and looking through commit messages is often a good way to get back up to speed on a project I haven't touched in a while.
- LyndsySimon 8y ago
  Sort of. I've used git for so long and so deeply that it's ingrained in the way I think about code - I break things into atomic commits, and regularly traverse and edit the commits in the feature branch that I'm working on. That doesn't change when I'm working solo, nor do my commit message style rules. I find it very useful to be able to investigate the history of a piece of code, even as it moves across multiple files, and figure out what happened and why. That said, when I'm working on a team I generally don't care how many concurrent branches are being worked on - it's not a problem at all if the threaded view is n levels deep. When I'm working alone I tend to have a linear (single threaded) history, with tags for each release or deploy.
  - specialist 8y ago
    "I break things into atomic commits" This is something that I struggle with. And it sets me apart from the apparent majority of (younger) programmers. At best, once I've baked something enough that I'm satisfied, I can go back and break up the work. But then what's the point? From my perspective, the agile/scrum mindset (velocity!) leads to spamming the code base with poorly reasoned trivial changes, frequently just kicking the can down the road, happily accumulating technical debt like an accretion disk. Alas. I think the youngsters are more correct. Code bases are now so short lived that anything more than the bare minimum is just wasted effort. I miss the days of product development and burning CD-ROM gold masters and people at least tried to hammer nails straight. I know, I know, get off my lawn and all that.
stcredzero 8y ago
One thing that amazes me about Dwarf Fortress is that the creator(s) don't use version control[1] (as of 2014, things may have changed) A friend of mine, years ago, took the "daring, revolutionary" step of convincing NASA management to embrace version control. I also know of a European consulting firm which made a lot of money swooping in and saving a major Euro bank's problems due to lack of version control.
AdmiralAsshat 8y ago
Copy of Copy of Copy of DFSource.zip
rcxdude 8y ago
I think one problem is he doesn't, or at least it is managed through heroic effort as opposed to efficiently. Updates take longer and longer and have a longer period of 'everythings broken' as the game progresses. From all reports the code is a complete mess. It's an amazing piece of work, but it does seem like there is some wasted potential there (though I can believe that it may not be possible to harness that potential without giving up on the incredible ambition of the game, because this is the kind of thing that can only really be accomplished by someone who is completely unreasonable).
Sargos 8y ago
Tarn isn't known for being a good developer. He's just very dedicated :) In fact it's pretty well known that Dwarf Fortress has a horrible code base and it would be a huge project to bring it up to a good standard.
- umvi 8y ago
  Well they say hard work beats talent when talent doesn't work hard... DF is definitely an admirable and awe-inspiring project, regardless of the beauty of its innards
- ilaksh 8y ago
  Maybe he just said he wasn't the greatest developer and that the code wasn't well organized. That's called modesty and honesty. In this era of self-promotion some people actually can't recognize those things. But I think its very obvious that he is a good programmer. His work is literally legendary.
  - SquareWheel 8y ago
    I feel the same way about Notch. He was being modest when being critical of his own code. Besides, Minecraft was little more than a weekend project when he started. The whole idea is to move fast when prototyping game ideas. It's unfortunate that people latched on and the "Notch is a bad coder" meme took off. I imagine the same is true with Tarn.
  - rizzin 8y ago
    >But I think its very obvious that he is a good programmer. His work is literally legendary. "His work", as in, the game he made. Game development is a multi-faceted beast. It is quite possible that while game design is awesome, technical implementation is a mess even if it reaches the goals. I have heard DF being praised for having so many things to do, for being able to create wild stories, etc, but never for technical excellence.
- AnIdiotOnTheNet 8y ago
  Good devs get shit done. Feel however you want about the cleanliness of your code vs that of others, but Tarn created something that will be recognized for its significance to gaming culture for the foreseeable future.
tareqak 8y ago
Tarn Adams did however release the RAWs of the games to the public domain. As a personal project, I wrote a script to take the different zipped releases, extract the RAWs, and layer them into a git repository while attributing everything to Adams' handle Toady One. I separated the script I used to create it, and the layered RAWs into two separate repos. It's not up to date, but here it is: https://github.com/tareqak/df_raws_helper https://github.com/tareqak/df_raws_helper https://github.com/tareqak/df_raws https://github.com/tareqak/df_raws
honkycat 8y ago
Dwarf Fortress is a popular game, but it's progress has been stalled for years. One of its big issues is performance. For an ascii game. If anything, it is an example of how saying "Eh, screw it." can stall your progress
- Smithalicious 8y ago
  What do you mean by "stalled for years"? I haven't played in a while but according to the website[0] the last development progress wasn't even a month ago. [0]http://www.bay12games.com/dwarves/ http://www.bay12games.com/dwarves/
- npunt 8y ago
  DF does massively complicated and computationally expensive simulations. It eats CPUs alive. How it shows those results (ascii, tile pack, etc) has nothing to do with it - it isn't GPU-bound the way just about every other game is, because it's as much a simulation as a game.
daemin 8y ago
I think as long as you have a system for versioning the source code you are working on you will be fine. It's just that it will be a little more manual a process to perform (hence you might do it less often), but if it's a stable process then it should suffice. Configuration Management isn't just about keeping your source in source control software / server somewhere, it's also about the tools, dependencies, and other artefacts that you need to build and distribute the software. How many people take great care for the version control system but forget everything else?

by umvi 8y ago

Pfhreak 8y ago

They almost certainly use some sort of version control, like all novice programmers do, right? -- copying files/directories, creating backups, etc. (MyProject02.old.bak.zip).

felipemnoa 8y ago
I'd be surprised if that is not the case. No way they could have gotten this far without at least this minimum level of version control.
Buttons840 8y ago
Ah yes: myproject.final.zip myproject.production.zip myproject.backup.zip myproject.backup2.zip myproject.shipped.zip
- CydeWeys 8y ago
  myproject.final2.zip myproject.final3.zip myproject.final_for_real.zip Been there done that. I prefer git where it's all just meaningless hashes, or semver tags.

jandrese 8y ago

It makes a little sense. They aren't working with any kind of time limit, so if they break something they just work at it until it is fixed. There's no rolling back to the last good version. But yeah, this is undoubtedly a factor in the games rather glacial development rate.

ethbro 8y ago

No development team, no need for version control. I meta love DF for it's primitive development practices too. Guy decides to make a game with a block of stone and a chisel, development community calls him crazy and says games can't be made that way, but he keeps chiseling away.

oftenwrong 8y ago
This is like stone carving with a chisel, but striking the back of the chisel with your hand instead of using a hammer. A hammer adds a bit of complexity, but you will save yourself a significant amount of pain.
- Macuyiko 8y ago
  Until you hit your hand with the hammer, then you can't use either the hammer or your hand any more (pedantic, I know, but meant in good spirit)

tom_ 8y ago

They take backups, name each folder based on the date, and what feature that was just completed (or just about to be started) that prompted the backup. I bet you a pound. This is what everybody that says they don't use version control does.

chimeracoder 8y ago
> They take backups, name each folder based on the date, and what feature that was just completed (or just about to be started) that prompted the backup. I bet you a pound. All they need to do is to compress those folders with zlib, and then they've reinvented git.
- peheje 8y ago
  diff, branch, merge, blame, stash
- a1369209993 8y ago
  That's what I do (for personal projects where I don't care about complex commit-graphs) and I do call it version control.
  - chucksmash 8y ago
    Justifications like "where I don't care about complex commit-graphs," of which there are a few in this thread, always sound like they're trying to hide confusion about the tool by making it sound overly complex. Nobody cares about complex commit-graphs! If you're just one person, you can work directly on master and just commit everything every time: git commit -am "I did some work" Don't try to follow gitflow or githubflow or whatever it is that's made you bail on real version control. But why play the copying folders monty game in 2019?
    - a1369209993 8y ago
      You don't seem to understand my previous comment. Tarballs are better. Complex commit-graphs are not a reason to avoid git for small projects, they are a reason why I can't avoid git for large projects. The revision history is complex or not regardless of what software I'm using to slog through it.

danielbarla 8y ago

Honestly, for personal projects where I'm the sole developer, I only use git nominally. I mean, it's there, and sure, I commit; but it's not like I'm spawning feature branches or anything like that. It's a rather linear set of commits, functionally almost equivalent to having a zip of the source every now and then. I'm sure many people are the same.

stcredzero 8y ago
Hear hear! That said, it's pretty damn useful to have a log of my changes. Commit often, and it's even more useful! IntelliJ IDEs have pretty nice ways of viewing the diffs over time per file, and many other tools exist for doing this. Super useful!
zrobotics 8y ago
Even for small personal projects, for me the real killer feature is commit messages. Otherwise, it's almost impossible to remember which numbered folder has the change I want, and looking through commit messages is often a good way to get back up to speed on a project I haven't touched in a while.
LyndsySimon 8y ago
Sort of. I've used git for so long and so deeply that it's ingrained in the way I think about code - I break things into atomic commits, and regularly traverse and edit the commits in the feature branch that I'm working on. That doesn't change when I'm working solo, nor do my commit message style rules. I find it very useful to be able to investigate the history of a piece of code, even as it moves across multiple files, and figure out what happened and why. That said, when I'm working on a team I generally don't care how many concurrent branches are being worked on - it's not a problem at all if the threaded view is n levels deep. When I'm working alone I tend to have a linear (single threaded) history, with tags for each release or deploy.
- specialist 8y ago
  "I break things into atomic commits" This is something that I struggle with. And it sets me apart from the apparent majority of (younger) programmers. At best, once I've baked something enough that I'm satisfied, I can go back and break up the work. But then what's the point? From my perspective, the agile/scrum mindset (velocity!) leads to spamming the code base with poorly reasoned trivial changes, frequently just kicking the can down the road, happily accumulating technical debt like an accretion disk. Alas. I think the youngsters are more correct. Code bases are now so short lived that anything more than the bare minimum is just wasted effort. I miss the days of product development and burning CD-ROM gold masters and people at least tried to hammer nails straight. I know, I know, get off my lawn and all that.

stcredzero 8y ago

One thing that amazes me about Dwarf Fortress is that the creator(s) don't use version control[1] (as of 2014, things may have changed) A friend of mine, years ago, took the "daring, revolutionary" step of convincing NASA management to embrace version control. I also know of a European consulting firm which made a lot of money swooping in and saving a major Euro bank's problems due to lack of version control.

AdmiralAsshat 8y ago

Copy of Copy of Copy of DFSource.zip

rcxdude 8y ago

I think one problem is he doesn't, or at least it is managed through heroic effort as opposed to efficiently. Updates take longer and longer and have a longer period of 'everythings broken' as the game progresses. From all reports the code is a complete mess. It's an amazing piece of work, but it does seem like there is some wasted potential there (though I can believe that it may not be possible to harness that potential without giving up on the incredible ambition of the game, because this is the kind of thing that can only really be accomplished by someone who is completely unreasonable).

Sargos 8y ago

Tarn isn't known for being a good developer. He's just very dedicated :) In fact it's pretty well known that Dwarf Fortress has a horrible code base and it would be a huge project to bring it up to a good standard.

umvi 8y ago
Well they say hard work beats talent when talent doesn't work hard... DF is definitely an admirable and awe-inspiring project, regardless of the beauty of its innards
ilaksh 8y ago
Maybe he just said he wasn't the greatest developer and that the code wasn't well organized. That's called modesty and honesty. In this era of self-promotion some people actually can't recognize those things. But I think its very obvious that he is a good programmer. His work is literally legendary.
- SquareWheel 8y ago
  I feel the same way about Notch. He was being modest when being critical of his own code. Besides, Minecraft was little more than a weekend project when he started. The whole idea is to move fast when prototyping game ideas. It's unfortunate that people latched on and the "Notch is a bad coder" meme took off. I imagine the same is true with Tarn.
- rizzin 8y ago
  >But I think its very obvious that he is a good programmer. His work is literally legendary. "His work", as in, the game he made. Game development is a multi-faceted beast. It is quite possible that while game design is awesome, technical implementation is a mess even if it reaches the goals. I have heard DF being praised for having so many things to do, for being able to create wild stories, etc, but never for technical excellence.
AnIdiotOnTheNet 8y ago
Good devs get shit done. Feel however you want about the cleanliness of your code vs that of others, but Tarn created something that will be recognized for its significance to gaming culture for the foreseeable future.

tareqak 8y ago

Tarn Adams did however release the RAWs of the games to the public domain. As a personal project, I wrote a script to take the different zipped releases, extract the RAWs, and layer them into a git repository while attributing everything to Adams' handle Toady One. I separated the script I used to create it, and the layered RAWs into two separate repos. It's not up to date, but here it is: https://github.com/tareqak/df_raws_helper https://github.com/tareqak/df_raws_helper https://github.com/tareqak/df_raws https://github.com/tareqak/df_raws

honkycat 8y ago

Dwarf Fortress is a popular game, but it's progress has been stalled for years. One of its big issues is performance. For an ascii game. If anything, it is an example of how saying "Eh, screw it." can stall your progress

Smithalicious 8y ago
What do you mean by "stalled for years"? I haven't played in a while but according to the website[0] the last development progress wasn't even a month ago. [0]http://www.bay12games.com/dwarves/ http://www.bay12games.com/dwarves/
npunt 8y ago
DF does massively complicated and computationally expensive simulations. It eats CPUs alive. How it shows those results (ascii, tile pack, etc) has nothing to do with it - it isn't GPU-bound the way just about every other game is, because it's as much a simulation as a game.

daemin 8y ago

I think as long as you have a system for versioning the source code you are working on you will be fine. It's just that it will be a little more manual a process to perform (hence you might do it less often), but if it's a stable process then it should suffice. Configuration Management isn't just about keeping your source in source control software / server somewhere, it's also about the tools, dependencies, and other artefacts that you need to build and distribute the software. How many people take great care for the version control system but forget everything else?