Print

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

[dyze]

i would be grateful for some kind of 'noob' game play mode, where everything happens a lot slower. to this day, i still use a very low pop-cap, since it just seems to spiral out of control otherwise.
a noob mode where immigrants came at lower numbers, and maybe less 'useless' dwarves (soapmakers etc), gem-makers and other 'advanced' workers could start to immigrate once the player had built up the general base of farms, workshops etc.

[Angellus]

People have complained about lag once you get a lot of dwarves; I'm seeing it now with around 100 little guys.  I read in an interview that you're using an A* algorithm for pathfinding, since you can't lay down "cheater paths" that other devs might do on maps that are not dynamic.  If the amount of cpu that's being used for A* is a significant factor in the lag, this could help:

Could you implement something similar to how ants navigate?  Basically, the way it works is that ants leave a pheremone trail behind them (that gradually fades) depending on what task they are on, and they follow these trails also depending on their task.

For example, an ant is on "forage"; it leaves the hill, and is leaving behind "forage" scent.  It randomly wanders until it finds food.  Once it does, it follows the gradient of decreasing "forage" pheremone back to the hill, only this time it's leaving behind "food" scent.  When it reaches the hill, the other ants can detect the food trail and follow it back.  They all do the same thing, so the more traffic, the heavier the scent.  Once the food is gone, the scent gradually evaporates.

Now, the dwarves in DF are not as dumb as ants - they know where they need to go, using A*, but you could have them leave behind the virtual "scent" that subsequent dwarves could follow to simplify the A* search they need to perform.  You could also have a number of "pathfinder" dwarves that don't follow the trails but do use the straight A* path in order to "update" trails in cases where changes in the environment has opened up new trails or closed off old ones.  You would have lots of virtual "pheremone trails" all over the map that would act as highways for common dwarf tasks.

I do not think this will help much with decreasing lag, though I do not know much of programming. It would though, make everything more realistic. A dwarf does not know whether the door it came trough would be closed once it has reached its destination, they now seem to magically know this.

[CynicalRyan]

I do not think this will help much with decreasing lag, though I do not know much of programming. It would though, make everything more realistic. A dwarf does not know whether the door it came trough would be closed once it has reached its destination, they now seem to magically know this.

Actually, it would. At the cost of DF using more RAM, though.

Let me explain by way of example:
Pathing is like writing a book.

Currently, every time a dwarf goes somewhere, a new book is written, containing the instructions where to go. At worst, every dwarf that goes to the same tile (think picking up the gifts the goblins left after their last siege), gets his own book of instruction.

Now, instead of writing a new book for everything, Dwarf Fortress stuffs books in a library. That way, the game can simply look up the book, and give it to the dwarf, instead of writing a new one.

This is obviously faster, even though it isn't as customizable as a personal book for every dwarf.

However, you could store lots of books, and discard the ones that are least used, before storage space runs out.

And if you turn books into an ecyclopedia of paths dwarfs take, the game can look up the encyclopedia (the ant trails: A specific area, for example the one where you fell the most trees, gather the most sand, fish the most fish, etc.), then the game only has to calculate the end of the path, since the dwarfs are already close to where they actually need to be.

It's quite possible that dwarfs won't use the most efficient path anymore, but that is sooo rarely needed, anyway, that I wouldn't be too concerned.

On another note, I've noticed that grass tiles that get pathed often (i.e. lots of dwarfs running around) "lose" the grass, creating a dirt path of sorts. That could be used to calculate common path ways already, I guess.

[PTTG??]

...
This is obviously faster, even though it isn't as customizable as a personal book for every dwarf.
...

Not at all; the game has to find which "book" is the correct one to give. In order to do this, it has to, basically, write a new book. At the very least, your idea would require cashing a connection from every point to every other point, and recalculate this whenever the map changes- an absurdity.

[peterix]

One thing: I have little patience for micromanagement. Let me suggest a solution.

DF really needs to employ dependency trees for managing labor. Let's say I order the dwarwes to build a road out of green glass blocks. I don't have any yet. I don't even have a glass furnace and there's no sand gathering spot designated. The game (in my head) goes through all the pre-requisites for making roads out of green glass blocks and tries to make them. It fails (and announces that it failed) - there's no glass furnace, bags, fuel and no designated glassmaker. I then go to the jobs screen, where my order for building the road is listed as 'blocked'. I can view it's details - a list of prerequisites.
From this list, I can
* order dwarves to build those buildings (select 'glass furnace needed', map apperas, I put it where I want it, cancelling or placing the building returns me to the requirements list)
* assign the glassmaking profession to a dwarf (select 'glassmaker needed', *enter*, list of dwarves appears - on the left their names, on the right their professions. I select a dwarf and press *enter*,)
* same thing with the sand gathering spot and fuel. When there's no sand, it lists 'find sand', etc.
* I have no bags! The game list this as a prerequisite. I can order some bags made from the list. If it can't be done, it's added to the list and processed the same way as the build road order.
* Noble mandates go here - essentialy, nobles order the dwarves to make stuff just like you. You can't cancel their mandates, just look them up and do what's needed. If all the requirements are met, dwarves make stuff for the nobles without player intervention.
* Complex orders - like 'keep alcohol stocks at 500', etc.

Now I can go and tell dwarves to build my nice glass tower (put designations all over the place) and just watch them gather sand, make glass blocks and build walls wihout any intervention or mucking with every task. My attention is only needed when there's a real problem. I don't have to tell them to brew alcohol all the time, they do it themselves. I focus on designing glass towers, military tactics, high-level planning and digging (digging is fun and requires a brain).

The annoncement list - entries should be linked to what caused them and I should be able to see it ... Going to the list, selecting a 'Horrors! Demons in the deep!' line and hitting *enter* should show me the demon. Same with all the other announcements.

Graphics separation - don't reuse same graphics for different things if possible. A nice raw file with all the fixed game objects and graphics assigned to them would be fine. This would go nice with themes. A theme coul be something like a linux package - it would contain all the images and the file which links them to game objects (like [GRAPHIC:CREATURE:SPIDER_CAVE_GIANT:LIVING:spidey.png] [GRAPHIC:CREATURE:SPIDER_CAVE_GIANT:DEAD:ded_spidey.png]).

Also the path caching already mentioned here. Using waypoints and caching should speed things up a lot.

The in-game manual: it needs a major overhaul, linkage to the rest of the game.

* peterix cancels writing wall of text, too tired.

[CynicalRyan]

...
This is obviously faster, even though it isn't as customizable as a personal book for every dwarf.
...

Not at all; the game has to find which "book" is the correct one to give. In order to do this, it has to, basically, write a new book. At the very least, your idea would require cashing a connection from every point to every other point, and recalculate this whenever the map changes- an absurdity.

Hash table. This is, basically, a solved problem in computer science. And a look up in RAM is faster than calculating the whole path again and again and again and again and again and again.

Nor do you have to cache every possible route. Just the most used routes. That should speed up pathing quite a bit, since you don't have to calculate the path from workshop to stockpile every single time.

[G-Flex]

I think I've read that the problem with caching routes is that the map in DF changes damn near constantly.

Say the game caches a path from point A to point B. If anything on the map changes, like water entering or leaving an area to some degree, or dwarves moving around, or any architectural changes or other dangerous terrain problems, it has to calculate the entire path again anyway, since in such a case, the cached path may be inaccessible, or more difficult to traverse (and thus not necessarily the best anymore), or another path may have come up which is simply better. And considering how often this stuff, especially fluids, move around...

[CynicalRyan]

I think I've read that the problem with caching routes is that the map in DF changes damn near constantly.

Say the game caches a path from point A to point B. If anything on the map changes, like water entering or leaving an area to some degree, or dwarves moving around, or any architectural changes or other dangerous terrain problems, it has to calculate the entire path again anyway, since in such a case, the cached path may be inaccessible, or more difficult to traverse (and thus not necessarily the best anymore), or another path may have come up which is simply better. And considering how often this stuff, especially fluids, move around...

So you do a check every 5 seconds if the paths are still valid. If they aren't, they are discarded, and the game builds a new list of paths.

Besides, the game actually knows what happens on the map. What's more difficult to handle is user input, but compared to the speed of the average CPU out there, we are slower than molasses in what we do.

For example, when siting a building, during the pause mode where there is no pathing, and while you designate the the needed material, paths can be recalculated that either touch the area, or cover the fortress.

The lag results from too much happening at once. If you shift the work around a bit, that can help a lot already.

The question is, however, how difficult all of this is to implement, while keeping DF modular enough for the anticipated growth of the program.

[G-Flex]

I think I've read that the problem with caching routes is that the map in DF changes damn near constantly.

Say the game caches a path from point A to point B. If anything on the map changes, like water entering or leaving an area to some degree, or dwarves moving around, or any architectural changes or other dangerous terrain problems, it has to calculate the entire path again anyway, since in such a case, the cached path may be inaccessible, or more difficult to traverse (and thus not necessarily the best anymore), or another path may have come up which is simply better. And considering how often this stuff, especially fluids, move around...

So you do a check every 5 seconds if the paths are still valid. If they aren't, they are discarded, and the game builds a new list of paths.

And if somebody has to path to a now-invalidate-but-still-considered-valid path during that five-second-interval, then what happens?

[Andir]

I think I've read that the problem with caching routes is that the map in DF changes damn near constantly.

Say the game caches a path from point A to point B. If anything on the map changes, like water entering or leaving an area to some degree, or dwarves moving around, or any architectural changes or other dangerous terrain problems, it has to calculate the entire path again anyway, since in such a case, the cached path may be inaccessible, or more difficult to traverse (and thus not necessarily the best anymore), or another path may have come up which is simply better. And considering how often this stuff, especially fluids, move around...

So you do a check every 5 seconds if the paths are still valid. If they aren't, they are discarded, and the game builds a new list of paths.

And if somebody has to path to a now-invalidate-but-still-considered-valid path during that five-second-interval, then what happens? 

They hit a wall where a wall wasn't before and they check for a new path.

[Neruz]

I think I've read that the problem with caching routes is that the map in DF changes damn near constantly.

Say the game caches a path from point A to point B. If anything on the map changes, like water entering or leaving an area to some degree, or dwarves moving around, or any architectural changes or other dangerous terrain problems, it has to calculate the entire path again anyway, since in such a case, the cached path may be inaccessible, or more difficult to traverse (and thus not necessarily the best anymore), or another path may have come up which is simply better. And considering how often this stuff, especially fluids, move around...

So you do a check every 5 seconds if the paths are still valid. If they aren't, they are discarded, and the game builds a new list of paths.

And if somebody has to path to a now-invalidate-but-still-considered-valid path during that five-second-interval, then what happens?

They do that anyway; Dorfs pick a path at a given point and then follow that path until they hit an obstacle, at which point they recalculate. This can be seen in the goblin repeater room.

[Aquillion]

They do that anyway; Dorfs pick a path at a given point and then follow that path until they hit an obstacle, at which point they recalculate. This can be seen in the goblin repeater room.

That is actually not quite right.  They don't recalculate the whole path -- they recalculate how they can get to the next available step on their old path.  The difference may seem small but can cause catastrophic results.

I discovered this, for instance, when I had a long, complicated snaking trap corridor with an easy access channel that lets you bypass the twisty corridor, which I opened for my dwarves when the place was otherwise sealed off.  If a dwarf is approaching the long, twisty corridor, I can forbid the long-twisty-corridor door, and then open the easy access corridor.  The dwarf will walk up to the now forbidden door, pause for a second to think, and then you know what he does?

He walks all the way around in through the easy access corridor, but then immediately walks into the long twisted corridor from the wrong direction until he gets to the door from the other side, then immediately turns around and goes through the whole long twisty corridor instead, wasting a huge amount of time.

[Jetman123]

An in game tutorial would help immensely when you can get around with it and would easily help rope in new players. If you want to keep the players, generally having some good in-game help goes a long way.

A better organization of the build menu would certainly help (putting the workshops at the top, for instance), as well as an explanation of some of the error messages players might get upon trying to build furniture.

"Bed - needs a bed (Constructable from Carpenter's Workshop)"

[varkarrus]

It's too slow paced for me.

I have not ever kept a fort until my first ambush even. Thieves, yes, but not ambushes.

[Mechanoid]

It's too slow paced for me.

This.

Dwarf Fortress needs a "fast forward" button. 2x, 4x, and 8x speeds.