Bay 12 Games Forum

would give them a completely unrrealistic time saving advantage from what it should be very minor.

No. it would give them a 20% time savings. Half an hour off of what would otherwise be a 2.5 hour long trip.
Versus in real life, also a 20% time savings. Half a minute off of what would otherwise be a 2.5 minute long trip, or whatever.

Sorry, still not seeing the problem you have with this. 20% speed boost has the exact same affect on gameplay regardless of the SI units involved and also regardless of the distance traveled... I simply don't understand your objection. Physics does not know how long you intend to travel for -- it applies instantly from your first step to your last.

In their regular work days it wouldn't save them any real time. So in the way dwarf mode passes the time( one day for every couple of clicks), making them go faster wouldn't be justifiable to me.

So then don't build short paved roads in your forts... what's that have to do with the suggestion for the game? You're just talking about individual fort strategies, which the suggestion does not contradict.

Yes, clearly pretty much ANY feature in the  game will be considered important by some people and not by others, strategically, based on specific fort circumstances. That's actually a hallmark of a good suggestion, not a bad one. Something everybody would always have to do would be less fun and less interesting, and more busywork.

(Also time compression has nothing to do with this -- whatever way walking is being abstracted now, it would be with this, too, so actual number of ticks to move 10 tiles will still be 20% less over 20% less effortful terrain. Method of abstraction used doesn't matter, since it cancels out of both sides of the equation.)

You could say that pathing from a to b without a road takes 20% more effort. So maybe the dwarf gets a bit more tired by having to use some extra energy to go through it, but not enough to make a difference, since they just don't go around running at full speed everywhere and its such a short distance.

I'm confused why you think that running = fixed effort, but you think walking = fixed speed? It seems much more likely that BOTH are fixed effort: walking is usually at the local max efficiency point for that terrain, and running is at the maximum physical fitness allowance for your body.

And even if you COULD physically possibly walk across scrubland as quickly as pavement, that doesn't mean you will, because you'd have to adopt a weird, less-than-locally-efficient gait for one of those two surfaces for your speed to remain fixed, which would be wasteful. When expending equal effort, you'll walk more slowly on the scrubland, because you have to spend more energy watching for bumps and moving more steadily and lifting your feet a bit higher to clear uneven obstacles, etc.

The pathfinding algorithm would have to be updated to take terrain into account, which could slow things down a bit.

I don't think so. Pathfinding uses a map of costs already. Adding terrain adjustments would be a one time very small delay (like probably 1/3 of a second) when you first make your map, and then would just be there and be as fast as normal, since it's still looking up costs like before. As you change the terrain, there'd also be a brief microsecond to adjust to that new road right as it's built, but imperceptible.

This basic concept could probably be simplified and perhaps even made more realistic by keeping track of general variety of experience, period. Not bothering to keep track of experience with every single species (tons of bloated memory and detail).

For example, you could store the most recent species / individual fought or sparred with only, and every time the individual changes, you get 1 variety point, every time the species changes you get 10, or something. Build up 255, and you're maxxed out, good enough

Then to apply the value, if whatever you're fighting now is different than the last thing you fought on file, you get a penalty to your skills if your experience variety is < 255, proportionally.



Sort of like, "learn a few languages, new ones come easy" "Fight with a few different people/species, new adaptability comes easy"

This is nice and all, but I don't think it really fixes the main problem, which has less to do with understanding the categories and more to do with them being organized crazily such that I still can't remember where track stops are in the menus after years of using them...

So yeah, this AND overhauling the menus, perhaps.

humans have no issue electing the descendants of goblin slaves into leadership positions. Race just isn't an issue in DF.

Your conclusion simply does not lead from your premise. Yes, a FEW random goblins that earned their trust after years and years with the civ, are sometimes granted citizenship and then have a chance of being elected purely because they are historical figures that the game tracks unlike large chunks of the rest of the civs population, so they are disproportionately represented. Basically a coding bug that they then get elected more often. Really they're just equals.

So what? What we can conclude from that is that "racial minorities that have proven themselves aren't an issue in DF." NOT "Race isn't an issue in DF." A stranger goblin is still a creature that you would be stupid not to fear by default, with no other information.

ETA: And let's cut out arguing about humanity and what we've done, please. It's completely irrelevant here.

That's not the discussion. Nobody is arguing that on Earth, monotheistic religions started more wars and spread more rapidly and have been gradually gaining popularity, etc.

The discussion is whether that was a coin flip situation (next simulated world might have the opposite happen), or whether it is an inevitable result from the fundamental nature of religions (such that it would be in every simulated world).

Evidence of both types of things having happened on earth in more obscure examples points to it being happenstance. No evidence of anything else ever happening points to it being inevitable.