Bay 12 Games Forum

I don't understand the new military screen at all. There are lists of dwarves where I can change them between white and green. What does that mean? Anyone understand the "positions" screen?

I hate to say this, but the new military screen is a new standard for confusing UIs in a game of confusing UIs.

thanks Teiwaz!
next question should I learn some C and C++? it seems that many of the examples and stuff that I can find for roguelikes is in them and as I have learned from this thread DF is in C++.

Don't bother with C, C++ will teach you everything C can do, and more. C can be a good stepping stone for C++, but C# will do just as well for that and will get you into an object-oriented way of thinking.

C++ is really, really powerful, but can be simply brutal. Absolutely learn it if your plans are to go into the industry as a programmer, but put it aside for now - C# will teach you most of what you need to learn about programming, and should last you a good long while. Go to C++ when you want to learn C++ - it can be a nightmare, especially if you're trying to get a working project out of it. Just getting something to compile can be a colossal pain in the butt, doubly so if you're trying to integrate other peoples' code to do the stuff you don't want to worry about (and I'm talking really low level stuff here, like polling the state of the keyboard or figuring out where the mouse is, or playing a sound that isn't a default windows beep, or loading an image into memory and displaying it on the screen).

There's a whole lot more to being a good programmer than knowing language X or Y. It's more about being able to figure out how to do things, being able to write easy-to-read, well commented, functional, efficient code, being able to squash bugs quickly and without causing new ones, and being able to familiarize yourself with a new codebase quickly, whatever the language. If you can do that, knowing the syntax and foibles of a particular language is secondary.

Movement flags could easily be a bitset, if the unit pathing has the appropriate flags it can use that link if not it can't. Ideally we can link directly to the map anyway. You have to specify some form of system to allow pathing under different conditions. Either that or have a whole node map for each set of movement types, which I imagine would be more space.

Why would you bother? Just get the information from the adjacent tile. You only need connectivity data for a simplified node network (pathing zones, TCZs, reference points) and there would be several orders of magnitude fewer nodes on the path network than there are tiles in the game, so memory wouldn't be an issue.

I don't think it's very realistic to expect players to set up pathfinding routes for their dwarves. The forum would just get flooded with people asking why their swarves aren't doing any jobs. This should be done proceedurally by the game. Storing the zones efficiently might be a problem, but generating them and figuring out when to update them would be trivial. (Dwarf fortress already does a simplified version of this with its connectivity map)

The flaw with pathing only from zone to zone is that some arbitrary goal needs to be put in each zone which results in a "choppy" path in which the agent unnecessarily moves to that goal point.  My plan is to use a zone tree to both confirm connectivity and to progressively whittle-down a to a series of connected zones which will form a 'corridor' through witch an A* search will be confined.  That prevents most wasted node expansions but still gives the optimum path.

Pathing to the arbitrary zone reference point is unnecessary. All you have to do is path into the zone. Depending on performance, you either path to the reference point, but stop as soon as you enter the zone and generate a path to the next one or you  generate a path to a "best guess" point which is nearest to you inside the target zone (and then generate a new path as soon as you enter the zone for whatever reason, in case your guess was wrong.) Obviously, which approach is more efficient depends on zone size.

You may not get a perfectly optimal path in all conditions (I expect most of the problems would exist outside) but in the normal environment of Dwarf Fortress - a series of rooms and corridors usually connected by only 1 or 2 tiles, which would generally be the boundary of a zone as they often have doors - there's not very much variation between a perfectly optimal path and one that works. (In fact, I'd bet there wouldn't be a difference at all in most cases.) In any case, we're dealing with a game with performance issues. Generating a path quickly and efficiently is *far* more important than generating the perfectly optimal path that saves a dwarf a tile or two of travel time.

While restricting the network over which you need to path will help, generating a complete path still means you're generating a LONG path, and also one that is likely to be discarded (the case of targeting something that is itself moving, like siegers going after a dwarf and having to regenerate their path every frame, for instance), and is therefore wasteful. Pathing between zones means that you only have to re-generate the path if the moving target is in the same or an adjacent zone as you, which means it's a short path by definition and therefore cheap. (If they're in a different zone, your path doesn't change. Even if the target moves to a new zone, you only have to regenerate the "high level" zone path, and even then, you just need to generate it from the second-last zone in your path, with a maximum path length of 2. Cheap!)

I couldn't find the current algorithm (is there one? Conversation seems to go in circles a lot) but anyway, an observation:

I think generating a complete path to your destination is a waste. You're too likely to have the path invalidated (by map changes, something getting in the way, Dwarf deciding he's thirsty and dropping his current task, etc.)

Generate zones (areas of limited size which are contiguous for the most limited movement type possible in them - i.e. a normal floor area would be part of a zone where the entire area is contiguous for a creature which can walk but not open doors, an area of water for one which can swim but not open doors, a tile with a door on it for creatures which can walk and open doors, etc) with connectivity links (not specific paths, just info that they zones are connected) to adjacent zones. Generate an initial path on this (comparatively very simple) zone network, and then just generate a path to reach the next adjacent zone as you need it.

You'll end up generating a lot more paths, but the cost will be diffused over time, (this doesn't seem so important in DF as in games that demand a smooth framerate - but caravans and sieges arriving can still cause huge, nasty hitches from the cost of the initial long pathfind for a bunch of new creatures entering the map all at once) and with relatively small zones the individual paths should be fairly trivial to solve. Additionally, as you know you are only pathing as far as the next adjacent zone, you can limit pathfinding to within your current zone - so in the worst case, of a failed pathfind, you'll only floodfill your current zone. (Though this should never happen if your connectivity info is good.) Shorter pathfinds also reduce the number of paths which are invalidated and have to be regenerated when the map changes (a map change would only affect creatures currently pathfinding in the same zone, and would only affect creatures pathfinding through the zone but not currently in it if the connectivity changes).

Also, I'd put aside multi-tile creatures for now. They're an edge-case, and even when they're there, there will generally be very few of them. It's not worth optimizing for this at the cost of a better algorithm for single-tile creatures. Not to mention the current lack of multi-tile creatures...

You guys have too much sympathy.

Toady contracted a communicable disease.
This implies he had contact with another human being.
Which implies he went outside.
That implies he wasn't working on the next release of Dwarf Fortress. For shame!

Let's just hope he learned his lesson about the terrible things that happen when you aren't working on the next DF version.

One of my Champion Hammerdwarves just gave birth WHILE fighting off a siege.