Bay 12 Games Forum

@eerr : I think not. Because in most roguelike game, there is a "goal", and numeric representation are here to tell you how much of this you've done.
Here, there is no goal. So how to measure anything ?
The only thing you can measure is your skill evolution.

Roguelikes have scores. It's actually kind of an important part of the Roguelike experience to have scores? Nethack has a score, Angband has a score, and you can't get more Roguelike than those. Even if you look at modern stuff, Noita, Slay the Spire, the Binding of Isaac all have score.

...But all those games are actually structured like a roguelike, while DF adventure mode is kinda more wearing the skin of one, at least for now. But, like, Minecraft is much the same way, and also has a score. So I guess my point is, ain't nothing wrong with a score, necessarily.

Asking more technical rather than game content related questions:

1. Given the recent tooling changes around how you build DF (eg version control, multiple branches) what do you think has changed in the way you think about development thanks to this new tooling? What has it enabled in your mind that you previously thought might be too difficult to tackle?

2. Follow up on the tooling, what other interesting tools or patterns have you considered or looked into? what about unit tests? fuzz testing? c++20 concepts?

I've used C++20 concepts semi-recently but GCC generally has a few problems with certain C++20 features, especially if we want to let people run the game on older Linux distros (we're incompatible with Ubuntu 18, which is actually kind of a disaster). I've written things with views on reflex then had to replace them with other stuff a few times already, haha.

There is a way, it's simple enough to mod in that I used it to test modding in music.

Temperature in the thermodynamic sense is usually defined as the derivative of energy wrt entropy, i.e. "how much energy changes if you increase the entropy". In this sense, absolute zero is much more intuitively impossible: there's an actual division by zero, since the units are in energy/entropy, which you can represent as, say, (boltzmann constant)*joules/nat.

Thermodynamic beta is the inverse of temperature, entropy/change-in-energy, often represented in gigabytes per nanojoule, and this, too, is pretty obviously impossible to reach absolute zero in--here, absolute zero is at infinity, and the "zero" on the scale is "infinite temperature".

So, how it ought to work is that syndromes have an "adjusted level" which is multiplied by severity, then divided by 100, and then it adds 1 to all that, and if that's below 100 it just doesn't do the effect. How adjusted_level is calculated is:

1. Start with the current syndrome concentration (I think this is usually 10000, by default? A lot of syndromes have explicit set-to-10000 lines just in case in the vanilla raws)
2. Calculate dilution factor as DISEASE_RESISTANCE * SYNDROME_DILUTION_FACTOR/100 (only used for dwarves and alcohol right now, but important to point out)

2. If the symptom is RESISTABLE, multiply the dilution factor by min(500, exposure count*10+100)/100 (apparently RESISTABLE refers to immunity from repeat exposure? I didn't know this either?)

3. Multiply the dilution factor by min(500, exposure count*10+100)/100

4. If SIZE_DILUTES, multiply dilution factor by body size/100

5. Do... the equation in this graph. Where adjusted_level was L_0, it is now L_1. As you can see, in practice these means that a dilution level of 5000 makes it 1% as strong, of 0 makes it 2x as strong, and 2500 is the halfway point between these.

6. Set the level to 1, if it's lower.

7. If there's a PEAK, multiply so you get a linear ramp-up to PEAK from START, if before PEAK; if after PEAK and no ABRUPT_END, do a similar linear interpolation.

Quick test with king cobra on a human got me an adjusted_level of 990, which sent the pain to "urgent care required" levels immediately, so I suspect it's an issue with PEAK calculations; this syndrome has a PEAK, and an early one, so it gets strong quickly.

[SYNDROME]
[SYN_NAME:king cobra bite]
[SYN_AFFECTED_CLASS:GENERAL_POISON]
[SYN_IMMUNE_CREATURE:KING_COBRA:ALL]
[SYN_INJECTED]
[CE_PAIN:SEV:75:PROB:100:RESISTABLE:SIZE_DILUTES:LOCALIZED:VASCULAR_ONLY:START:10:PEAK:50:END:1200]
[CE_DIZZINESS:SEV:50:PROB:100:RESISTABLE:SIZE_DILUTES:START:30:PEAK:100:END:1200]
[CE_DROWSINESS:SEV:50:PROB:100:RESISTABLE:SIZE_DILUTES:START:30:PEAK:100:END:1200]
[CE_PARALYSIS:SEV:100:PROB:100:RESISTABLE:SIZE_DILUTES:START:60:PEAK:100:END:1200]

How hard would it be to make the motion graphics of DF more smooth, interpolating the movement of creature sprites between squares instead of jumping discreetly from one position to the next? Rimworld style, basically.

The problems here are mostly that:

1. Movement can be interrupted
2. Movement is often faster than the game's frames per second; I like to play the game at 1000 FPS, and at that speed, units move ~1.6 tiles per frame, meaning that ~60% of the time you'll see dwarves move two tiles in a frame

The only really reasonable way to do it is to do a lerp of the sprite's position offset between their current and target destinations based on how far they are into their movement, which, yeah, doable, but might result in really weird visuals, snapbacks and things.

The problem is at least partially because it's being treated as a wall, which requires flood filling to separate the map into accessible bits, the "unreachable" part there, which is itself a major cause of FPS loss (if you have FPs drops due to liquids, this is what's causing it).

Quote from: darkhog on December 10, 2023, 05:10:20 pm

So one of the biggest FPS death causes is pathfinding

Nope.

Yeah, fair response, but the primary cause of fort FPS issues is still... number of creatures. So the title question's a valid one. And the answer is basically just "yes", straight-up.

Still, if there's a hard limit on the number of creatures on the map at once, there's a less of a possibility that any of those things happen. It would be reasonably high to not affect the gameplay too much, but also low enough to improve the things.

Also another thing would be to limit how often creatures could repath, the lower FPS (as percentage of max FPS), the tighter the limit. IMO having a creature, including a megabeastm stuck is preferable to unplayable FPS.

Yeah, this is something I've sorta-kinda considered. Making your units who are stuck in a tree explicitly try to climb around instead of just path failing and posting to the errorlog about it is a sort of "step one" of this, there's a flag in there now that makes this happen and adding more "chill out with the panic pathing" stuff might just generally be a good idea. While slow FPS reduction over time isn't a pathfinding problem, sudden drops to the single digits usually is. The thread I made there was using "FPS death" to mean the general complaint of "slow, inevitable decline in game speed", which pathfinding is not really a party in at all.