How Dwarf Fortress is built • Hacker News Board

Re: How Dwarf Fortress is built

#401

Post by b0rsuk » Sat, Jul 31, 2021, 10:44 AM UTC

ascagnel_ wrote: post #375

b0rsuk wrote: post #313

Earlier quoted context omitted.

Your reply is somewhat self-contradictory. If games are interactive simulations by nature, why is DF so unusual? There is a trend to call many modern games "immersive sims" and somehow they don't produce such stories. In my opinion game developers have mostly stopped trying to simulate things. The focus is on clothes, rigid crafting systems, skill trees, storyline, cutscenes, vehicles, item collection. It's sandboxes…

> There is a trend to call many modern games "immersive sims" and somehow they don't produce such stories. For what it's worth, "immersive sim" is more a sub-genre of first-person action game (games with a heavy focus on world-building, player choice, and stealth, heavily inspired by the games Thief and Deus Ex) than a descriptor. It fit better when it was first introduced in the early aughts, when those games were n…

I absolutely agree with this, but it's an unpopular opinion that draws fire. Actual ambitious simulations are rare which is why they stand out. Rain World is one of my favorites. Rimworld is ok but the creator openly admits he doesn't want to go as deep as DF.

Re: How Dwarf Fortress is built

#402

Post by ratww » Sat, Jul 31, 2021, 11:11 AM UTC

zwaps wrote: post #399

ratww wrote: post #373

Earlier quoted context omitted.

> Author proposes to use a graph structure between components, getting rid of entities-component duality. Proposes to use pointers which allows calling into any component and process then all required components. This is far from ideal, and is equivalent to a very naive implementation of ECS. Having the user have to use pointers is not ergonomic, and the random access of secondary components via those pointers destro…

Good to know. Just to be clear, I was not endorsing the article. As mentioned, I have doubts about using a graph structure of pointers for related reasons, most of all because I think handling relational paths will amount to more overhead than any ECS structure. Nevertheless, I wanted to highlight that the quoted article clearly states that the proposal is not an ECS and is in fact superior to it.

> Good to know. Just to be clear, I was not endorsing the article. As mentioned, I have doubts about using a graph structure of pointers for related reasons, most of all because I think handling relational paths will amount to more overhead than any ECS structure.

Got it! Yeah, I totally agree with you.

Re: How Dwarf Fortress is built

#403

Post by bombcar » Sat, Jul 31, 2021, 1:06 PM UTC

skeaker wrote: post #397

bombcar wrote: post #246

Earlier quoted context omitted.

There exists at least one Dwarf Fortress done in Tarn’s model - it seems there exist zero done via any other method. He perfected a Patreon-style support system before Patreon was really a thing, and he keeps plugging away at it, keeping people interested. (Dirty secret - he’s found ways to let people access parts of the code he doesn’t care about such as the sound or SDL)

Your comment is true in a literal sense, but there are other games with very similar mind-boggling complexity that exist and thrive thanks to being open source. SS13 and CDDA jump to mind.

I think those take a different kind of person as a leader - the “Tarn + bro” person would need to be better at delegating and management of others vs implementation of his design himself.

Often if you have an idea but aren’t doing the low level implementation it’s harder to understand why something should change vs doing it yourself - in the latter case you just change the implementation and the design at the same time.

Re: How Dwarf Fortress is built

#404

Post by dilap » Sat, Jul 31, 2021, 1:21 PM UTC

blacktriangle wrote: post #393

dilap wrote: post #240

Earlier quoted context omitted.

Go has interfaces, but not inheritence. I'm slightly confused about what you're trying to describe, but maybe it's something like this? https://play.golang.org/p/smPyWvBvWWp We can make both Food and Animal statisfy the "Animateable" interface. Go also has a syntactic shortcut which is similar to inheritence, but more explicit. If you include a field in a struct without any name, it is considered "embedded", and you…

Thanks very much for the reply. Here's more of a clarifying example: The idea I was going with Animateable was not animation (poor wording on my part), but effictively giving the properties of a creature to a thing, ie magically animating it. So I have an ability in-game that lets me turn anything into a creature, thus merging the Creature interface with whatever other interface this has. From what I'm getting from y…

So caveat, I've never actually used an ECS system, but I've read about the pattern, and I would say it definitely seems better suited to the kind of situation you're describing than interfaces (or inheritence).

(I would say interfaces/inheritence are useful for simple high level abstraction of basic concepts with multiple implementations (here's an interface for a compression algorithm, or a RNG, or whatever), not so useful for trying to model complex game-world relationships. And to me, the useful part is the interface, whereas inheritence mixes in two unrelated concepts: implemementation-sharing and interface.)

But you don't need either of those for ECS, right?

If I understand it correctly, ECS at its core is basically an optimization of the struct-of-arrays datastructure. E.g., something like this is a super-basic ECS:

  struct World {
    Comp1[] Comp1
    bool[] HasComp1
    Comp2[] Comp2
    bool[] HasComp2
    ...
    int NumEntities // all arrays have this length
  }

I'm a big fan in general of struct-of-arrays vs collection-disparate-structs-with-pointers. Besides being way faster, it tends to make code clearer, too. ECS seems like a more efficient and convenient evolution of that pattern.

At least from what I've read. No real experience. Take with 13 grains of salt. :-)

P.S. If you feel like it, I'd be happy to explore some concrete code (you first!). It's always very interesting to me to try to explore all possible ways to express some concept in code.

Re: How Dwarf Fortress is built

#405

Post by philipov » Sat, Jul 31, 2021, 8:58 PM UTC

db48x wrote: post #154

MikeTheGreat wrote: post #128

Earlier quoted context omitted.

My experiences with cats (at least in my own life) is that cats prefer not walk into an area with a sticky floor if they can avoid it. Clearly there's a bug here where the cat will keep wandering around on the sticky floor, and then keep consuming the alcohol off it's paws. The obvious fix is to add a feature wherein different creatures have preferences about where they go next, and then use that to have the cats avo…

Good suggestion. It would occasionally be nice if the _dwarves_ would avoid stepping in things and tracking it all over the place. The only reason that the cats were in the tavern in the first place is that pets follow their owner* around.

The * refers to the fact that cats are the owners, and dwarves are their pets. A truly accurate understanding of how cats work.

Re: How Dwarf Fortress is built

#406

Post by curtainsforus » Mon, Aug 02, 2021, 9:13 AM UTC

outworlder wrote: post #153

minsc__and__boo wrote: post #115

Earlier quoted context omitted.

I've put in probably over a thousand hours on it, and have played it over the years as new releases come out. I've gotten to the point where I usually hit FPS death (too large a fortress that it overloads the CPU) even on the harder starts and with dfhack to help. The draw for me was the steep learning curve that rewards you with logical complexity when you finally understand it. The lore that your fortress generates…

For me, the reason I have stopped playing is that I have issues managing migrants. There are just too many dwarves to care for. Even DF Therapist doesn't (or didn't?) really help micromanaging jobs. It becomes tedious quickly. I remember seeing something about auto-allocating jobs, but it didn't work for me.

That's why many players had methods for 'taking care of' migrants

Re: How Dwarf Fortress is built

#407

Post by markus_zhang » Tue, Aug 10, 2021, 3:09 PM UTC

SkyBelow wrote: post #374

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.

This is something I've struggled with in the past as well. I have a player, NPCs, enemies, and wild animals. Should they have any class hierarchy at all? If my code matches the game world, what happens when I was to add golems and let mages turn castle's into entities that act just like an NPC would? Should my class design be so tightly coupled with the elements of my world? I don't think so but what alternative work…

Can you create a base class for all living things and derive from there? The base class owns a bunch of common components such as HP, Animation, Sound, etc, and each subclass has components that are specific for itself (for example, you cannot "Use" a player, but should be able to "Use" a wild animal, so here goes a component for that action).