Dwarf Fortress now on Steam with a graphical overhaul

[Alienman]

Dwarf has world simulation and history, Rimworld has nothing like that.

Does that do anything for gameplay though?

I think it does. If you play a world for a long time you put your mark in that history, everything you do gets recorded and who knows what legends will be told from your little dwarves or adventurers you have played. I have almost as fun as playing the game checking the legends after a game.

The simulated aspect of the world is just much more immersive to me at least.

 

[jcd]

Is CPU death still a problem?

 

[Alienman]

Is CPU death still a problem?

Not played for a while, but I assume so.

 

[dehimos]

CPU is always a problem. Large companies release specific products for cryptocurrencies but not for DF

 

[AgentFransis]

I'm serious, what even is it? And what happens later in the game?

The appeal breaks down into roughly these three categories:

1. Architecture and engineering. If you have the inclination the game allows you to design some really lovely and intricate fortresses. This can be anything from just coming up with pleasing floor plans to advanced features like floor mosaics from different colored stones, plumbing systems and waterfalls for water or magma etc. Then there are megaprojects like building massive above ground pyramids, cathedrals, statues whatever (these require extreme autism or special tools since the interface is very bad for this kind of building). Or special challenges like building your fort above/under the sea, inside a volcano etc. This also includes building arbitrarily sadistic defensive systems like floors that retract at the pull of a lever and drop enemies into a chasm or floods a room with water etc.

2. Survival. You can embark on a haunted glacier for example where nothing truly died and scarcely any resources and try to survive as long as possible until inevitably something goes wrong and things spiral into oblivion.

3. Emergent gameplay (aka funny shit happens). Look up any of the classic let's plays for examples including some good ones here on the dex.

 

[Catacombs]

CPU is always a problem. Large companies release specific products for cryptocurrencies but not for DF

Introducing the new Intel 11000K Z MtnDew™ Master Edition Dwarf Fortress™ Ready CPU

 

[Moaning_Clock]

Is it known when it will be released? It seemed like the brothers would need money so I thought it would be out faster.

 

[Catacombs]

Is it known when it will be released?

It'd be news if they announced a release date. For now, they're taking their sweet time and avoiding the question with "time is subjective."

 

[Moaning_Clock]

I would be happy about a release year

 

[Correct_Carlo]

Another 10 and maybe there will be graphene CPUs that will allow us to play DF with more than small embark and more than 200 dwarves without FPS death.

I don't understand technology. Why doesn't DF just use the GPU in addition to the CPU to process dwarf calculations?

 

[AgentFransis]

Another 10 and maybe there will be graphene CPUs that will allow us to play DF with more than small embark and more than 200 dwarves without FPS death.

I don't understand technology. Why doesn't DF just use the GPU in addition to the CPU to process dwarf calculations?

A GPU is a specialized processor designed to do calculations needed to draw pixels on the screen, in particular 3d stuff, very efficiently. That means that it's very good at doing stuff like matrix multiplications but is otherwise very limited in the operations it can perform and as such can't run a normal computer program. In recent years GPUs have indeed been used for tasks other than graphics but still only for very specific mathematical tasks that happen to be a good fit for what a GPU can do.

 

[Perkel]

Another 10 and maybe there will be graphene CPUs that will allow us to play DF with more than small embark and more than 200 dwarves without FPS death.

I don't understand technology. Why doesn't DF just use the GPU in addition to the CPU to process dwarf calculations?

Because DF isn't graphically demanding game. It is simulation aspect of game that hogs CPU power.

That being said there are a lot of algorithms that could fix a lot of performance in DF by using GPU power like case of pathfinding/temperature fields etc for which GPUs are pretty good.

Thing is that Tarn never took performance into account in his work and asked multiple times about it he said that it is for "future" or that he "isn't interested in it as long as it works"

For Tarn basically 20-50 dwarves is what he thinks about fortress dingy shithole mode and if you look at upgrades to game he is mostly focusing on adventure mode and world creation rather than fortress mode which most of people play.

Either way he changed a lot lately so maybe performance will go higher on his TODO list

 

[anvi]

I don't know programming or nothin but here's my opinion. Don't games like this (and most RTS...) use stupid amounts of CPU for no real advantage? Like in an RTS, say you select a bunch of units and then click somewhere far away, everyone expects the game to calculate that route instantly and you can see the CPU spike whenever you do it. If you do it with a huge enough stack of units then it can lockup the computer for a moment while it calculates... But if when you clicked a bunch of units to go somewhere, it just stopped them for a moment and then processed their route in a queue with other jobs, it would solve that completely. There was some game I saw once where you could see it process a waypoint and it processed from the end point towards you and from you towards the endpoint. So it was calculated in half the time because they met in the middle and the route was confirmed. Very clever. Also a lot of games assume they have to calculate everything per second, like if the game has money, gold, energy, or whatever and it is building up in a number per second. That takes a lot to compute! 100 buildings providing 11 energy per sec and then you spawn 150 new tanks that eat 8.7 energy per second, and they are all out there getting blown up and stuff and being calculated every second... It's a great endpoint but only if you can do it well. They can't do it well so they should process it every few seconds instead.

Also in some tower defense games they are sending waves of creatures at your guns to get slaughtered, and for a finale they spawn thousands at once and it always slows the game down. Instead of 1000 x 10hp zombies you can just send 1 huge zombie instead... It's the same thing, mostly. And smart games do it and some games don't.

tl-dr- I suspect most games are programmed like ass

 

[Blaza]

tl-dr- I suspect most games are programmed like ass

That is pretty true. So a lot of game calculations are tied to Frame Rate. That makes it easy for things to get instantly updated, and it means you get a consistent experience across all level of machine power. However this has other side effects like physics going haywire if the FPS hits like 300 or something like what happens with console game ports sometimes.

Like someone else said Tarn has said he is happy as long as it works, which is fine for some things but when you're doing something as massive as Dwarf Fortress you hit walls pretty quickly. Lots of solo devs take this approach because games juggle a shit ton of variables and sometimes you just want to finish working on a part of the game.

TLDR: Most game programmers are more like old school hackers (the original meaning of "someone who makes a computer do things") instead of Software Engineers who know the pros and cons of algorithms, etc. The goal is for something to "just work well enough"

 

[Perkel]

From what i know pathfinding is actually hard problem and to really get it working on GPU you need pretty fancy math skill. Planetary Anihilation devs made it this way which is why they can push ridiculous amount of units without any slowdowns.

That being said Tarn is MIT graduate with 2 years of post graduate work as scholar. He knows his math for sure or at least some form of it. He just sucks at coding and at the same time he is pretty good at making really complicated systems.

 

[Blaza]

From what i know pathfinding is actually hard problem and to really get it working on GPU you need pretty fancy math skill. Planetary Anihilation devs made it this way which is why they can push ridiculous amount of units without any slowdowns.

That being said Tarn is MIT graduate with 2 years of post graduate work as scholar. He knows his math for sure or at least some form of it. He just sucks at coding and at the same time he is pretty good at making really complicated systems.

I didn't know know he was an MIT grad, and in math at that. Huh. So I wonder if the performance issue is just due to having no multi threading, and Tarn doesn't want to go and refactor? From a quick search Dwarf Fortress started in 2002, and is written in C++. C++ didn't get multi-threading until C++ 11, which released in 2011. To add multi-threading he'd need to refactor 9 year old code. I can see the reluctance, I barely want to work with code I wrote last week.

 

[thesecret1]

That is pretty true. So a lot of game calculations are tied to Frame Rate. That makes it easy for things to get instantly updated, and it means you get a consistent experience across all level of machine power. However this has other side effects like physics going haywire if the FPS hits like 300 or something like what happens with console game ports sometimes.

Lol, that's a pretty old take. I dare say you won't find such issues in any serious studio, as tying logic to framerate is an amateur mistake that can usually be easily remedied though delta time (compute the time between previous frame and current one, and use that value to determine what exactly should have happened during said time. This way, you will have a consistent output regardless of FPS).

Like someone else said Tarn has said he is happy as long as it works, which is fine for some things but when you're doing something as massive as Dwarf Fortress you hit walls pretty quickly. Lots of solo devs take this approach because games juggle a shit ton of variables and sometimes you just want to finish working on a part of the game.

Eh, not necessarily, "so long as it works" is generally a frowned upon approach, you are expected to provide shit that performs reasonably well in addition to working. It's more of a cost-benefit calculation. This "highly optimized code, like in the old days" that people often hark back to is not so easy to achieve. You need to spend a shitload of time on making it so optimized, and you need to be quite experienced to achieve it (and experienced programmers cost a lot of money). Moreover, games in the old days were much simpler than today (not in terms of gameplay and design, but in terms of technology being used). A lot of abstracting is needed to get any work done (for example by using a proper game engine to make a game rather than literally programming the game from scratch), and each such abstraction carries some performance cost attached to it. In broad terms, the reason why "games are optimized like ass" is because getting that perfectly optimized wonder would prolong the game's development significantly, and cost a shitload more money.

 

[Correct_Carlo]

Maybe if it's a massive success on steam he can hire someone to do it.

 

[Blaza]

Lol, that's a pretty old take. I dare say you won't find such issues in any serious studio, as tying logic to framerate is an amateur mistake that can usually be easily remedied though delta time (compute the time between previous frame and current one, and use that value to determine what exactly should have happened during said time. This way, you will have a consistent output regardless of FPS).

I was unaware of delta time, I'm assuming engines and frameworks take this into account? Because the two I am pretty familiar with (Godot and Love2d) has _process() and love.update() functions that are referred to as being called "once per frame" in their documentation.

Eh, not necessarily, "so long as it works" is generally a frowned upon approach, you are expected to provide shit that performs reasonably well in addition to working. It's more of a cost-benefit calculation. This "highly optimized code, like in the old days" that people often hark back to is not so easy to achieve. You need to spend a shitload of time on making it so optimized, and you need to be quite experienced to achieve it (and experienced programmers cost a lot of money). Moreover, games in the old days were much simpler than today (not in terms of gameplay and design, but in terms of technology being used). A lot of abstracting is needed to get any work done (for example by using a proper game engine to make a game rather than literally programming the game from scratch), and each such abstraction carries some performance cost attached to it. In broad terms, the reason why "games are optimized like ass" is because getting that perfectly optimized wonder would prolong the game's development significantly, and cost a shitload more money.

For big studios, I understand the time crunch and abstraction portion for optimization purposes. I was referring more to smaller indie devs like Bay12/Tarn. Is Tarn getting any technical help from Kitfox or are they simply doing the art and making suggestions?

 

[dehimos]

I didn't know know he was an MIT grad, and in math at that. Huh. So I wonder if the performance issue is just due to having no multi threading, and Tarn doesn't want to go and refactor? From a quick search Dwarf Fortress started in 2002, and is written in C++. C++ didn't get multi-threading until C++ 11, which released in 2011. To add multi-threading he'd need to refactor 9 year old code. I can see the reluctance, I barely want to work with code I wrote last week.

Yep, DF isn't multicore. Toady has managed his code too long with a lot of changes.

For big studios, I understand the time crunch and abstraction portion for optimization purposes. I was referring more to smaller indie devs like Bay12/Tarn. Is Tarn getting any technical help from Kitfox or are they simply doing the art and making suggestions?

Bay12 is the only one. Kitfox help with music (I don't remember who) and artist (Meph, a famous modder for Masterwork Dwarf Fortress).

Spoiler

 

[Tacgnol]

CPU is always a problem. Large companies release specific products for cryptocurrencies but not for DF

It isn't processing power that's the issue with DF, but optimisation and design.

The game still has no significant multi-threading support, and Toady says he finds it too confusing to implement. Multi-threading would help a lot with DF as the game has a lot of things going on that could be offloaded.

It also doesn't help that Toady isn't a trained programmer and generally seems to work to a "if it compiles, it's good enough" style of development.

 

[axx]

Fps seems to fall if you deviate from compact fortress design. Pathfinding seems to be an issue.

 

[Tacgnol]

Fps seems to fall if you deviate from compact fortress design. Pathfinding seems to be an issue.

Pathfinding is a great example of something that multi-threading would be really useful for. Right now it's working on the same thread as everything else.

Doesn't matter in most games, but DF has vast areas with a ton of units to do.

 

[AgentFransis]

The game still has no significant multi-threading support, and Toady says he finds it too confusing to implement. Multi-threading would help a lot with DF as the game has a lot of things going on that could be offloaded.

It also doesn't help that Toady isn't a trained programmer and generally seems to work to a "if it compiles, it's good enough" style of development.

You people don't seem to understand. Multithreading is the necromancy of programming. It's alluring and easy to get in to but it's just as easy to lose your sanity and create an abomination. Experienced programmers don't tread lightly with this dark art. Parallelizing a behemoth like DF with 20 years worth of linear code assumptions is an epic herculean task that would take years and generate legions of hard to find bugs.

Also wtf is a trained programmer? There is no training for programmers worth a shit, the only thing that really matters is experience. Toady is a monk that spent decades on top of a mountain honing his craft and his kung fu is not to be underestimated.

 

[Tacgnol]

The game still has no significant multi-threading support, and Toady says he finds it too confusing to implement. Multi-threading would help a lot with DF as the game has a lot of things going on that could be offloaded.

It also doesn't help that Toady isn't a trained programmer and generally seems to work to a "if it compiles, it's good enough" style of development.

You people don't seem to understand. Multithreading is the necromancy of programming. It's alluring and easy to get in to but it's just as easy to lose your sanity and create an abomination. Experienced programmers don't tread lightly with this dark art. Parallelizing a behemoth like DF with 20 years worth of linear code assumptions is an epic herculean task that would take years and generate legions of hard to find bugs.

Also wtf is a trained programmer? There is no training for programmers worth a shit, the only thing that really matters is experience. Toady is a monk that spent decades on top of a mountain honing his craft and his kung fu is not to be underestimated.

Toady is a maths guy, that doesn't translate directly to being good at writing optimised code. Good algorithms, sure.

Also what experience? Toady has spent years working on his own codebase without any real idea of the technical debt and nightmare he was creating. Also a lot of formal training these days for coders is completely shit (and probably infested with woke nonsense) I agree, but in my day we learnt useful things. Try writing inefficient code when you have a 30 year ex-ministry of defence programmer criticising every line you've written.