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

371–380 of 407 posts

Re: How Dwarf Fortress is built

#371

Post by markus_zhang »

akira2501 wrote: post #208
markus_zhang wrote: post #36

IMO that's one of the best ways a single programmer can spend his career. No weird requirements, no deadlines, no nothing, nada. Just one's passion and a product. Whether it is successful is irrelevant. Kudos Mr. Adams for making the achievement and moves gaming history. Going back to the interview, I found this line (and the logic attached) interesting: >Making the item system polymorphic was ultimately a mistake, b…

> No weird requirements, no deadlines, no nothing, nada Well.. until you accidentally create a broken release, that is. That's _real_ sweat.

It can happen in the jobs with weird requirements and deadlines though.

I do think there is a huge hazard of working for oneself that is not getting paid and may literally starve. The guy who made HolyC comes in mind but he also has mental issues.

Re: How Dwarf Fortress is built

#372

Post by strogonoff »

pjmlp wrote: post #370
strogonoff wrote: post #366

Earlier quoted context omitted.

You don’t have to use map() if you don’t like it; and you’re free to pick a functional implementation from Ramda or somewhere else and use that instead, React really couldn’t care less.

What is typeof(function)?

Could you try writing a few sentences instead of three words to make a proper counterpoint? My point was that React core can be used (and sometimes forces you to use itself) in a functional manner without DOM or the browser, counter to what you have claimed; the ball’s in your court.

Re: How Dwarf Fortress is built

#373

Post by ratww »

zwaps wrote: post #285
ratww wrote: post #271

Earlier quoted context omitted.

> One promising direction is getting rid of entities. > > Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components You are essentially describing ECS here. In ECS, entities are nothing but a "handle" without any additional data, normally just an integer used to link common components together.

What op links actually describes a different issue than what is in the post. What I got from the article, instead, is the following: If entities could be IDs to which components are connected, or containers holding components. Either case has disadvantages. If entities hold components, then iterating over components means iterating over entities, which slows down all systems. A rare type of component still degrades w…

> 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 destroys the caching benefits of data-oriented design. Having a memory pool don't automatically give optimal cache usage, only if you have very little data.

Most modern ECS frameworks solve the issues you mention by allowing systems that "query" more than one component at a time, not requiring a lookup. For example:

    system().each([](auto p, auto v) {
        p.x += v.x;
        p.y += v.y;
    });
This is supported by lots of mainstream ECS libraries already. It doesn't require lookups inside the System's hot loop, doesn't require random memory access via pointers, and also doesn't require managing/cleaning up those pointers.

The nice thing about keeping Entities as opaque handlers is that a "System Iterator" is able to abstract away the issues mentioned and implementation becomes a mere detail. An ECS library could even use the implementation the GitHub wiki link suggested, since ECS is currently abstract enough to allow it, because of the opaque handlers.

Re: How Dwarf Fortress is built

#374

Post by SkyBelow »

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.

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 works best?

Re: How Dwarf Fortress is built

#375

Post by ascagnel_ »

b0rsuk wrote: post #313
setr wrote: post #260

Earlier quoted context omitted.

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

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 notably more interactive than the more static worlds of fast-paced, action-first, twitchy shooters of the era (Quake, Half-Life, Unreal, etc).

Re: How Dwarf Fortress is built

#378

Post by uDontKnowMe »

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…

Thanks for that great series! It reminded me a lot of this demo for O'Doyle Rules, a Clojure rules engine library, wherein the author demos a dungeon crawler style video game written top to bottom using only the rules engine for logic https://youtu.be/XONRaJJAhpA?t=1577

He also goes on to show a text editor written entirely in the rules engine (which he uses to develop the game in), really cool stuff!

Re: How Dwarf Fortress is built

#379

Post by [deleted] »

strogonoff wrote: post #372
pjmlp wrote: post #370

Earlier quoted context omitted.

What is typeof(function)?

Could you try writing a few sentences instead of three words to make a proper counterpoint? My point was that React core can be used (and sometimes forces you to use itself) in a functional manner without DOM or the browser, counter to what you have claimed; the ball’s in your court.

[deleted]

Re: How Dwarf Fortress is built

#380

Post by 100011_100001 »

Octopodes wrote: post #60
100011_100001 wrote: post #35

This is a little bit of a hijack but if I wanted to start coding games as a side project, where would I start? Which platform? Mobile, PC, console? Any good introductions on the subject of solo game development? I know I can google this, but I trust HN users more than the Google algo.

Check out this itch page for some suggestions: https://itch.io/jam/game-off-2020 Scroll down to the " Help—I’ve never created a game before!" section and there are some suggestions like Phaser or Godot.

Thanks, this is a good starting point.
Post reply on HN