Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rucksackjack]

I love Dwarf Fortress, but I often find it hard to play one fortress for very long because of how dramatically the framerate drops after a few migrant waves. Does anyone know for sure how best to mitigate this drop? I've heard that one should use wide halls, avoid chokepoints, etc., but it also seems that overly open areas can have a detrimental effect. What about the relative positioning of different parts of the fortress, of stairs, etc.? Can anyone give me some general fortress design tips that will help keep my framerate from being totally wrecked?

[Jimmy]

I use a spiral method with ramps to reduce path lag. It's designed to simulate the burrows method of fortress design, with a central area for a stockpile, space surrounding it for workshops, and a residential and dining area off the side.

Basically, to reduce pathing lag I ensure every public access corridor is 3 tiles wide, with a high traffic designation in the centre. This reduces the amount of dodging your dwarves do when travelling in similar or opposite directions. 2x2 also works, but I prefer 3x3 myself.

However, it's also important that you have fast close access for your dwarves to food and drink, sleeping quarters and their workshops. Nothing beats planning your fortress layout before you dig. Also disabling hauling on a majority of your population when reaching the hundreds can reduce lag after trading with the caravan or a goblin siege.

[Greiger]

Setting a double line of restricted traffic blocking the entrance to the fort seems to help a bit.  It apparently keeps them from checking pathing outside when they don't need to go outside.

It has the negative effect of reducing your fps more if some end up having to go outside though, as they all check the entire underground for a way to get to their destination before checking outside.

A 100% high traffic path from the meeting areas to barracks and the dining room also seems to help also if you have a large number of idlers.  I think it causes your idlers to only check pathing in the high traffic areas during their daily lives.

[Granite26]

Setting a double line of restricted traffic blocking the entrance to the fort seems to help a bit.  It apparently keeps them from checking pathing outside when they don't need to go outside.

It has the negative effect of reducing your fps more if some end up having to go outside though, as they all check the entire underground for a way to get to their destination before checking outside.

Seems like doing the same for your mineral mining would do the same

[Skorpion]

What DF really needs are one-way systems.

Also, does D13 improve framerate versus D11?

[Elvin]

Thanks Greiger, this has improved my average framerate by ~10. ( I didn't really need it, i'm still at 60, but it all helps  )

[Thexor]

The big concern in pathfinding isn't getting to your destination, it's all the detours that the algorithm takes en route. So, to optimize pathfinding (assuming a heuristic system similar to A* - I seem to remember reading that Toady doesn't use A* directly):

* Ensure that major paths are straight lines through high-traffic areas.
* Avoid dead ends. If you have a workshop with only one entrance, the algorithm may enter the shop and explore every nook before backtracking out.
* Avoid the outdoors! Indoors, the walls help narrow the algorithm's search - outdoors, it can fan out over a wider area. This is especially important if there are bottlenecks out there, like a single bridge over a major river - the algorithm could cover huge chunks of the world before finding the bridge!
* When forced to go outdoors, remember the first point. Linear, high-traffic paths will take the least time. If you really want to be careful, consider a high-traffic route surrounded by restricted zones to keep the pathfinding contained. (Just don't expect your dwarves to path outside this range without difficulty!)
* Don't block paths! Locking a door is the obvious one - if a door is suddenly locked, the dwarves that were going through it have to re-compute. The game will also have to re-compute its connectivity map (which remembers which areas are connected - otherwise, an impossible path would first search the entire map before failing!), and the connectivity map is a pain to update.
* Keep workshop objects readily available. When a dwarf is in a workshop, he first finds the 'nearest' item - this algorithm expands out in a radius. If a Mason needs a stone, and the nearest stone is 7 tiles away, the game will search every tile within a 6-tile sphere first. That's a function of distance cubed. Sure, it happens less often, which is why this isn't the single biggest FPS drain... but it's worth optimizing, especially if you've got multiple high-efficiency dwarves working hard - they'll drain all the nearby resources quickly, and they'll force a lot of these inefficient searches later on.


Hopefully I haven't made any obvious mistakes here.

[Granite26]

Just that the Z axis isn't considered in distance to objects... A stone in the same square 10 levels down with the stairs on the other side of the map will still come back as closer than a stone two squares away.  Distance is raw, not pathfound

[Martin]

* Avoid dead ends. If you have a workshop with only one entrance, the algorithm may enter the shop and explore every nook before backtracking out.

Actually, this is wrong if he's using A* without nodes and caching.

If your workshop has 2 entrances, than any pathing that hits one door will still hit every corner of the room, then hit the 2nd door, and then proceed to path.

Assuming Toady is pathing from both ends (which I hope to hell he is) and the destination is in a dead-end room, then most dead-end rooms probably won't get touched as the end-point path will quickly work its way out of the workshop and into the main fortress flow. If it does work this way, you could speed things up quite a bit by putting a restricted traffic marker on every room entrance that is a dead-end. The end-point path will plow right through that with nowhere else to go but the start-point path will avoid all such rooms and mainly navigate the hallways looking for the intersection with the end-point path.

which remembers which areas are connected - otherwise, an impossible path would first search the entire map before failing!

I don't think the game remembers which areas are connected. I think it calculates on the fly. If it remembered, it'd be fairly trivial to cache path costs between connected areas and this whole thing would be a moot point. We'd be discussing how to optimize the node tree rather than how to reduce path costs.

[Martin]

Just that the Z axis isn't considered in distance to objects... A stone in the same square 10 levels down with the stairs on the other side of the map will still come back as closer than a stone two squares away.  Distance is raw, not pathfound

Well, that depends.

If you are building a wall, the distances are pathfound. Go look at the list presented of materials and look at the distance to something who's path you can increase by raising a bridge or locking a door. Then ask for the list again and you'll get a different distance.

If the dwarf is performing a job and selecting the material then distances are raw, but are you sure they don't include the z distance as an equal peer to x,y? That is, the object 10 levels down would be the same distance as one 10 tiles north? I seem to recall my masons clearing out a 3D diamond shape.

[dragon0421]

An untested idea I just had is you could forbid all of the stone in your fort except the stone you need to use. This might reduce the number of objects scanned when selecting a stone.

[Teldin]

I've always found the easiest way to reduce FPS is just to embark on a smaller location. Even on very big forts I can get a persistently high FPS by embarking on a 3x3 or 2x2. It also goes MUCH faster if you embark somewhere without a lot of variation, like a glacier or a desert.

[Slogo]

Yeah I think that dwarves will consider z on the same priority as x and y but it's raw so a stone 1 level up is closer than one 2 tiles away even if you have to go 40 tiles to hit the stairs up.

I'm guessing the general rule of thumb is anything that's done while game is paused calculates distanced based on path while anything done during live play will calculate based on pure distance.

[Granite26]

which remembers which areas are connected - otherwise, an impossible path would first search the entire map before failing!

I don't think the game remembers which areas are connected. I think it calculates on the fly. If it remembered, it'd be fairly trivial to cache path costs between connected areas and this whole thing would be a moot point. We'd be discussing how to optimize the node tree rather than how to reduce path costs.

This is wrong... The game maintains a connectivity map so that it knows what paths are possible before it starts.

That's the problem with flying creatures: the algorithm may not know two points are accessible through the air (even though it'll still pathfind through the air)

Yeah I think that dwarves will consider z on the same priority as x and y but it's raw so a stone 1 level up is closer than one 2 tiles away even if you have to go 40 tiles to hit the stairs up.

I'm guessing the general rule of thumb is anything that's done while game is paused calculates distanced based on path while anything done during live play will calculate based on pure distance.

That sounds like a very sound theory

[Skorpion]

The big concern in pathfinding isn't getting to your destination, it's all the detours that the algorithm takes en route. So, to optimize pathfinding (assuming a heuristic system similar to A* - I seem to remember reading that Toady doesn't use A* directly):

* Ensure that major paths are straight lines through high-traffic areas.
* Avoid dead ends. If you have a workshop with only one entrance, the algorithm may enter the shop and explore every nook before backtracking out.
* Avoid the outdoors! Indoors, the walls help narrow the algorithm's search - outdoors, it can fan out over a wider area. This is especially important if there are bottlenecks out there, like a single bridge over a major river - the algorithm could cover huge chunks of the world before finding the bridge!
* When forced to go outdoors, remember the first point. Linear, high-traffic paths will take the least time. If you really want to be careful, consider a high-traffic route surrounded by restricted zones to keep the pathfinding contained. (Just don't expect your dwarves to path outside this range without difficulty!)
* Don't block paths! Locking a door is the obvious one - if a door is suddenly locked, the dwarves that were going through it have to re-compute. The game will also have to re-compute its connectivity map (which remembers which areas are connected - otherwise, an impossible path would first search the entire map before failing!), and the connectivity map is a pain to update.
* Keep workshop objects readily available. When a dwarf is in a workshop, he first finds the 'nearest' item - this algorithm expands out in a radius. If a Mason needs a stone, and the nearest stone is 7 tiles away, the game will search every tile within a 6-tile sphere first. That's a function of distance cubed. Sure, it happens less often, which is why this isn't the single biggest FPS drain... but it's worth optimizing, especially if you've got multiple high-efficiency dwarves working hard - they'll drain all the nearby resources quickly, and they'll force a lot of these inefficient searches later on.
Hopefully I haven't made any obvious mistakes here.

I salute you! Following these instructions gave me a whole two FPS back!
Now up to a solid 22/23.