Live data from Hacker News

How Dwarf Fortress is built

stackoverflow.blog

211–220 of 407 posts

Re: How Dwarf Fortress is built

#211
post #2

I read everything about this game I can get my hands on. I don’t fully understand why I find dwarf fortress so intriguing. It’s such a pure passion project… that actually made it.

I am the same. I also started to play a few times, but not knowing the mechanics and not having enough time/motivation to learn them in detail is frustrating. But there’s a nice alternative: https://youtube.com/c/kruggsmash Watching someone else play Dwarf Fortress can be surprisingly entertaining. Just start one of his series from the start.

My favorite gaming youtuber.

They are somewhat similar with Tarn, also a pure passion project that made it, with all the hand drawn pictures and down to earth approach.

Re: How Dwarf Fortress is built

#212

Earlier quoted context omitted.

That's very interesting, because I had observed exactly the same when I tried to implement a rogue-like in Java some years ago. For example, I had to decide whether there should be different subclasses for spell books, the different weapon types (e.g bows vs swords), drinks, etc. or just one big Item class. Closely related to that, another decision I had to make was whether object or character properties should be im…

Mattias Johansson uses basically this example in his argument for composition over inheritance. You have humans, robots, and dogs all fitting into your nice class hierarchy. But now you need a robot dog that breaks everything. https://www.youtube.com/watch?v=wfMtDGfHWpA I think inheritance makes the most sense when your problem domain has been known for decades - like airline reservations. But for new blue sky projec…

> You have humans, robots, and dogs all fitting into your nice class hierarchy. But now you need a robot dog that breaks everything.

I like the way you put that. Though humans and dogs are 85% similar at a DNA level, so makes sense for them to inherit from a common parent. And my guess is robots and robot dogs would be ~85% similar at a building block level, so dog would inherit from robot.

I think go easy on levels of inheritance but have really strong root classes that most things inherit from.

Re: How Dwarf Fortress is built

#213

Df is just like OpenTTD. Both are like Chess, easy to start, fun to play casually but it takes years to master. Great games, complex if you want to and a time sink if you don't keep an eye on it. Have had many hundreds of fun hours in both games

I agree with the spirit of your post, but Dwarf Fortress and Easy to Start do not fit in the same sentence in my opinion. I mean, the game is legendary for it's arcane user interface and the vast number of things that can go wrong even for experts. Dwarf Fortress is something like vim, where usually on the first interaction people don't even know how to start the game, let alone do anything in it. Chess is easy to st…

When I first started playing DF it took me all day reading the wiki...

Next week was spent on trying to survive the first winter...

As a 15 years vim user though - vim has a much more gradual but also much higher learning curve, I'm still learning new tricks in vim on a weekly basis.

Re: How Dwarf Fortress is built

#215
post #28

Earlier quoted context omitted.

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

A few weeks ago some commenter here said they ascribe to WET - Write Everything Twice. Basically worry about abstraction when you get to number three. And what an acronym given the context!

I've also heard "We Enjoy Typing"

Re: How Dwarf Fortress is built

#216

Earlier quoted context omitted.

"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

Then how would you model composing behaviors in Go. Say for example I have a representation of Food and a representation of Animal. I then want an ability that will "animate" things, so I can animate Food to give it the behaviors of Animal.

I'm not being critical either, I'm seriously curious how somebody would implement this behavior in Go. Like you say, just struct with methods is a very appealing mental model since you have fewer moving parts, but how does it deal with a scenario like this which is very common in game dev?

Re: How Dwarf Fortress is built

#217

Earlier quoted context omitted.

I am the same. I also started to play a few times, but not knowing the mechanics and not having enough time/motivation to learn them in detail is frustrating. But there’s a nice alternative: https://youtube.com/c/kruggsmash Watching someone else play Dwarf Fortress can be surprisingly entertaining. Just start one of his series from the start.

My favorite gaming youtuber. They are somewhat similar with Tarn, also a pure passion project that made it, with all the hand drawn pictures and down to earth approach.

I agree. That’s why both get a bit from me on Patreon.

Re: How Dwarf Fortress is built

#219

Earlier quoted context omitted.

> For games that want this level of complex interaction between components, entity component systems are the way to go. Entity component systems are still in a half-baked state, with everyone rolling their own slightly different conceptual model. They're solving a problem, but not solving it well. One promising direction is getting rid of entities. Components need to link to entities and other components anyway, so o…

I think this is more of a language paradigm problem. Game programming is very much tied up in C++ and C# for historical and performance reasons, ECS is a way to try and graft what is entirely natural in a more value-based language into OOP mechanics and C++/C# type systems. ECS is so common and easy in lisps that it doesn't even warrant its own name.

Rust game engines are all based on ECS too.

Re: How Dwarf Fortress is built

#220
post #33

> What’s your favorite bug and what caused it? > A: It’s probably boring for me to say, but I just can’t beat the drunken cat bug... That was the one where the cats were showing up dead all over the tavern floor, and it turned out they were ingesting spilled alcohol when they cleaned their paws. I think that bug explains very well just how deeply complex Dwarf Fortress really is. Drinks can be spilled. Some drinks ha…

Other amusing DF bugs: Dwarfs trying to clean their inner organs (dwarf wounded, doctor closes the wound, dirt stay inside) Undying children in the moat water (for years... just swimming there...) Killer carps (there was a long time during which carps were really overpowered because constant swimming was buffing them up really good, dwarfs getting close to water sources were eaten by carps) Catplosions (Tarn loves ca…

Catplosions (Tarn loves cats, cats reproduce, too many cats kills DF performance)

This was a particularly insidious one because the usual strategy of culling excess livestock doesn't work out when applied to dwarfs' pets (pets can't be designated for slaughter, and other means of making pets die will make their owners upset). With most animals, you can avoid the pet adoption issue by just not marking them as available for adoption, so you wouldn't have to worry about a dogsplosion, sheepsplosion, etc. Cats do not become pets through that system. Instead, a cat adopts a dwarf.

Post reply on HN