If you like this, you may also enjoy this Tarn Adams talk at NYU GameCenter's 2016 PRACTICE conference https://youtu.be/yDPb0jqRr3o
How Dwarf Fortress is built
21–30 of 407 posts
Re: How Dwarf Fortress is built
#22Making the item system polymorphic was ultimately a mistake, but that was a big one. Q: Why was this was a mistake? A: When you declare a class that’s a kind of item, it locks you into that structure much more tightly than if you just have member elements. It’s nice to be able to use virtual functions and that kind of thing, but the tradeoffs are just too much. I started using a “tool” item in the hierarchy, which st…
"Tool" is still a class, with perhaps very generic polymorphic methods (e.g. do_default_action() ). The problem is not polymorphism per se, but rather about having a deep class hierarchy aka lasagna code. My policy: OOP is like salt. Use little and that's great. I only allow a single inheritance layer, and ideally no inheritance at all.
Funny thing, it's just the object model in play that causes the problem. Something more similar to Smalltalk (or Objective-C) works pretty well for things this dynamical, though you do need to factor out the properties and messages reasonably well still.
The trouble is C++ and similar object models poor support for composition and implicitly penalizing uniform object structure.
(E.g. call multiple base methods in a subclass - pain ensues. Add virtual calls to the mix, it gets really iffy.)
Even Python and Ruby with explicit mixins but the old model get hairy.
Re: How Dwarf Fortress is built
#23Dwarf Fortress consumed hundreds of hours of my life in high school, I have so many fond memories of it. Every year or so I come back to it and I'm always surprised that they've managed to add another mechanic or feature that just makes the game feel even more like its own little universe. After enough time in the game there really is a moment like that scene in the Matrix - "I don't even see the ASCII anymore. All I see is dwarf, plump helmet, magnetite ore."
That said, I've always wondered if Dwarf Fortress would be a more smooth experience if it had more developers or was just open source (understandable that it's not though since it's basically Tad's passion project). The biggest headache was always the lack of multithreading, since your fortress really starts to chug once you pass maybe 150 dwarves or do anything exciting with fluids. Regardless, it's amazing what one developer with a great idea and an enthusiastic community has been able to do with the game.
Re: How Dwarf Fortress is built
#24Earlier quoted context omitted.
Is it? That's when git is simplest, having a single branch and never merging removes most of the complexities of git.
Sure, but it also removes most of the reason to use Git.
In my experience, most people use git as version control. Branching etc is very useful, but not necessary for a 1-person project.
Re: How Dwarf Fortress is built
#25Earlier quoted context omitted.
Is it? That's when git is simplest, having a single branch and never merging removes most of the complexities of git.
Sure, but it also removes most of the reason to use Git.
Don't underestimate all the useful information a complete git log contains, even for solo developers. You can look years back and find out exactly why a change was made.
Re: How Dwarf Fortress is built
#26Earlier quoted context omitted.
Is it? That's when git is simplest, having a single branch and never merging removes most of the complexities of git.
Sure, but it also removes most of the reason to use Git.
I invite you to try using Git as much as possible for two weeks. After a week I started using Git for branching out of my main branch to test several different ideas and then compare them at once with other developers - colleagues or friends. I think that moved the meetings and discussions with my teammates up a level.
Re: How Dwarf Fortress is built
#27Making the item system polymorphic was ultimately a mistake, but that was a big one. Q: Why was this was a mistake? A: When you declare a class that’s a kind of item, it locks you into that structure much more tightly than if you just have member elements. It’s nice to be able to use virtual functions and that kind of thing, but the tradeoffs are just too much. I started using a “tool” item in the hierarchy, which st…
"Tool" is still a class, with perhaps very generic polymorphic methods (e.g. do_default_action() ). The problem is not polymorphism per se, but rather about having a deep class hierarchy aka lasagna code. My policy: OOP is like salt. Use little and that's great. I only allow a single inheritance layer, and ideally no inheritance at all.
This is one of the things I like about Go. Just structs with methods. You can embed them but it seems to hedge against deep nesting and creates simple code
Re: How Dwarf Fortress is built
#28Making the item system polymorphic was ultimately a mistake, but that was a big one. Q: Why was this was a mistake? A: When you declare a class that’s a kind of item, it locks you into that structure much more tightly than if you just have member elements. It’s nice to be able to use virtual functions and that kind of thing, but the tradeoffs are just too much. I started using a “tool” item in the hierarchy, which st…
"Tool" is still a class, with perhaps very generic polymorphic methods (e.g. do_default_action() ). The problem is not polymorphism per se, but rather about having a deep class hierarchy aka lasagna code. My policy: OOP is like salt. Use little and that's great. I only allow a single inheritance layer, and ideally no inheritance at all.
> My policy: OOP is like salt. Use little and that's great. I only allow a single inheritance layer, and ideally no inheritance at all.
That's been my observation as well - there's no free lunch and DRY isn't free either, certainly not if you use inheritance chains to achieve it.
I'm starting to think that the only programming axiom that will survive in the end is KISS.
Re: How Dwarf Fortress is built
#29Earlier quoted context omitted.
Sure, but it also removes most of the reason to use Git.
In my experience, most people use git as version control. Branching etc is very useful, but not necessary for a 1-person project.
It is if you want to bug fix released items but keep steam rolling features for the next version.
Re: How Dwarf Fortress is built
#30To me what was most surprising about Dwarf Fortress, given the complexity, is that Tad didn’t use git or any other code repository until more recently.
Why would that be surprising? For a single programmer working alone Git is an incredibly complicated tool. P.S.: A lot of you are confusing "complicated" with "difficult".
Change history, if nothing else. That alone brings a ton of benefit, from being able to view earlier versions, to recovering from mistakes or lost code.
If you have a remote repo then, you can also have offsite backups. If you never branch, it's still massively worth it.