Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Dwarf Fortress is built

stackoverflow.blog

Post reply on HN
Print view View original

251–260 of 407 posts

Re: How Dwarf Fortress is built

#251

Post by dgb23 »

blacktriangle wrote: post #216
mountainriver wrote: post #27

Earlier quoted context omitted.

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 sinc…

https://en.m.wikipedia.org/wiki/Structural_type_system

By structural typing. It’s a form of satisfying an interface by composition.

Re: How Dwarf Fortress is built

#252

Post by dgb23 »

blacktriangle wrote: post #196
truetraveller wrote: post #11

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.

Another good rule for OOP: Objects are fine, object graphs are a killer. Graphs are what get you into "all I wanted was a banana" territory. Objects should either be atomic, agrigated by simpler structures like maps and arrays, or if you absolutely must have objects pointing to objects, be sure that they form a tree and not a graph such that each object need only know about the things below them which can be encapsul…

I guess the exception would be when you’re modeling a graph.

Re: How Dwarf Fortress is built

#253

Post by mgsouth »

blacktriangle wrote: post #216
mountainriver wrote: post #27

Earlier quoted context omitted.

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 sinc…

Go uses duck typing. "Interfaces," such as Food or Animal, declare sets of functions that must be implemented in order to qualify as an object of that type. So a "Food" thing might need to implement "beInjested()" and "spoil()", and Animal "run()" and "die()". If, for type "Chicken", there are "beInjested(Chicken)", "spoil(Chicken)", "run(Chicken)", and "die(Chicken)", then a Chicken can be used anywhere a Food or Animal is wanted.

edit: You cannot, however, explicitly declare that a "Chicken" is supposed to be a Food and/or an Animal. And you can't directly inherit implementations; to make Chicken directly use a generic function you need to do something like implement "baseSpoil(Food)", and then have the body of "spoil(Chicken)" explicitly call "baseSpoil(self)".

As mentioned in another reply, there is a shortcut. You can declare that the Chicken structure includes (anonymous) Food and Animal fields. Then, if you call "spoil(myChicken)", Go will automatically replace it with "spoil(myChicken.Food)".

Re: How Dwarf Fortress is built

#254

Post by SilverRed »

jandeboevrie wrote: post #18

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

This seems to be the opposite of what people have described in the past. With the start being incredibly hard as you basically need to follow a wiki page step by step to work it out. But after a bit you can find a method that pretty much makes the game unlosable so you have to start implementing your own restrictions and artificial difficulties.

Re: How Dwarf Fortress is built

#256

Post by lmm »

truetraveller wrote: post #11
hprotagonist wrote: post #3

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

Nah, the problem is OOP polymorphism that conflates too many separate things. If you have a language that can actually express "implements this interface", "has this member", and "delegates this interface to this member", then you don't need traditional "extends" inheritance at all; sometimes you want to do the exact equivalent (and you can), but most of the time you want to do something narrower.

Re: How Dwarf Fortress is built

#257

Post by a1369209993 »

kd0amg wrote: post #220
devenvdev wrote: post #206

Earlier quoted context omitted.

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 availabl…

Note that the obvious strategy of not having any cats at all doesn't work well because cats are the most/only easily-available HUNTS_VERMIN creature, so you need some around to protect your food stockpiles.

A somewhat effective solution is to use male cats for stockpile protection, and keep female cats caged (which IIRC stops both adoption and breeding) and only let one out at time (cage any resulting (female) kittens immediately). There's not (yet) any simulation of evolutionary pressure to adopt a owner quickly, so you can just prefer kittens that do so for the next breeder when the current one dies of old age.

Gelding (neutering) the male cats also works, but is less sustainable if you don't have a reliable source of replacement cats from migrants or trade caravans for when the current ones die of old age. Spaying is not supported AFAIK.

You can also just remove the ADOPTS_OWNER token via raws editing.

Re: How Dwarf Fortress is built

#258

Post by dgb23 »

Gene_Parmesan wrote: post #191
tralarpa wrote: post #130

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…

Definitely components are the way to go. These have gotten very well known recently in the game dev world thanks to entity component systems, which is what I would call "heavy components," but you can also do "light components." Meaning, you don't need to organize your entire system around an ECS in order to take advantage of some of their benefits. They make changing behavior dynamically extremely simple. Instead of…

Database modeling comes to mind, especially EAV.

Re: How Dwarf Fortress is built

#259

Post by TKZZ »

In case anyone is interested in trying out DF, I recommend using the "Lazy Newb Pack". It provides a nifty GUI that lets you use different texture packs and change some settings that can improve enjoyment (cap population, remove aquifers, etc.)

http://www.bay12forums.com/smf/index.php?topic=126076.0

Re: How Dwarf Fortress is built

#260

Post by setr »

reidjs wrote: 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.

Games are interactive simulations, by nature.

DF is an honest attempt at simulating things thoroughly.

Therefore, DF is an honest attempt at making a thorough game.

Very few games can make such a claim

Post reply on HN