Cataclysm-dda: Remove "moves" from displays in favor of seconds

[KorGgenT]

Is your feature request related to a problem? Please describe.

Moves are a really confusing thing to see as a player, because they aren't explicitly stated anywhere in the interface that 100 moves = 1 second.

Describe the solution you'd like

For places in the UI that use moves, convert it to seconds instead in some fashion. A majority of this can be fuzzed depending on context.

Describe alternatives you've considered

Continue to have moves in the interface.

[esotericist]

Before we can really do this, we're actually going to need to pin down time to be less variable.

At the moment, "moves" are not "fractions of a second", they are "fractions of the amount of move points you get in a turn", which is not necessarily 100; with certain traits (quick) or gameplay mods (speedydex) you can end up with a fair amount more than 100 per second.

I think an important first step is fixing movement points (for both survivors and monsters) to 100, and transition things that previously gave bonus move points instead to providing modifiers to movement point costs.

e.g. the 'quick' trait should provide a reduction in the cost while moving between tiles, rather than increasing your total movement points.

then we can ideally standardize how we approach those modifiers in various contexts, without runaway multiplicative effects.

related thought: speed penalties (from e.g. pain or possibly injuries) could also benefit from being multipliers instead of movement point adjustments.

[Robik81]

AFAIK Quick trait gives overal action speed bonus, not just movement speed bonus, same goes for other speed bonuses / penalties from pain etc.

It is a way to make character slower or faster in general, not just his / her movement. Changing speed related stuff to just movement is reducing of what the current engine is capable of, which is IMO not a good idea.

[esotericist]

AFAIK Quick trait gives overal action speed bonus, not just movement speed bonus, same goes for other speed bonuses / penalties from pain etc.

It is a way to make character slower or faster in general, not just his / her movement.

Yes, this is a problem. It makes time complicated to present to the player, and it means somehow a single trait manages to adjust literally everything a player does, which makes no sense.

It also has subtle balance implications when things interact, getting increasing magnitudes of benefit than intended.

Changing speed related stuff to just movement is reducing of what the current engine is capable of, which is IMO not a good idea.

That's not what I said. I said change things to adjust costs instead. I am in no way saying players won't be able to do non-movement things faster under certain circumstances.

Terminology clarification: I said movement points because what things like quick gives you are called movement points. That's the internal mechanism.

Cost multipliers can be for things other than movement, but the resource used is always "moves" / "move points" / "movement points".

[I-am-Erk]

Eso's change by no means reduces the engines capabilities. It enhances it quite a lot, allowing specific traits or attributes to adjust specific speeds of things instead of a flat "you're faster at everything now" way. Quick increases walk/run speed. Dex perhaps increases speed of getting things in and out of containers, for example. Perception increases aim speed. Etc etc

[Robik81]

Sure, if movement point cost really means any action cost, then it the only difference is that instead of speed (modified by traits, morale, pain, etc.) increasing / decreasing your 'movement point per second' (MPS) as it is now, would have to increase / reduce movement points cost (MC) on all actions.

I don't know if it is easily achievable, it depends on if all actions are calling some common function in action cost calculation where it could be modified for all of them in one place.

Though such change would not enhance the engine capabilities in itself (not by quite a lot, not by a little). You would still have to code specific cases, just like other traits do it.

[Robik81]

Also, if the goal of this is just to show in UI how long something took in seconds instead of 'moves', you can still calculate it by using formula without the need to change how speed currently works.

default speed = 1
speed = default speed * (sum of all speed modifiers, e.g. with Quickness 10%, it would be 1.1)
MC = move cost of an action
TC = time cost of an action (in seconds)

TC = MC * (1 - (speed-1)) / 100

[Tamiore]

UI already explicitly shows your current effective speed.
To get from MP to seconds you literally just need to divide MP cost of an action by this value.

[CoroNaut]

I've never thought of the game as moving in seconds, more like 'moves' and 'turns', and seconds were just a result of these. The current system would say you have say 33 'moves' until another turn ticks over in which case your 'turn' has ended and the rest of the world's zombies/npcs take their own turn. Once all of these turns are calculated, 1 second has passed. You can also increase/decrease the number of moves you have to give you a longer or shorter turn. I prefer the existing way because it just models turn-based game play and is easily understood, probably just poorly documented to the player.

Switching the user interface to use seconds feels wrong in that it is implying that the player does all their actions in terms of fractions of a second instead of doing all moves inside a single turn. Taking real time turn progression into account, how do you explain to the user that the world operates a 'turn' every 1 second, but they actually have 1.10 seconds because of their 'quick' nature or have speed given by bionics. That would be very confusing, but would make much more sense if the game was headed towards removing the turn-based nature and implementing real time turn progression as default. If this is the case, then it is an excellent idea to change UI. I would prefer keeping the already-existing UI.

Should probably make the help menu for movement explain this is more detail, as it is right now, this issue is barely explained in 1 sentence in there.

[I-am-Erk]

The problem is less one of math (it's easy enough to normalize to available movement points and translate from there to seconds) and more one of runaway multiplication, as Eso said. Whenever we adjust speed extremely coarsely through movement points, and also fine tune it through penalty reductions and things, we get broke combinations like Quick+Parkour, which spiral rapidly out of control. By categorizing speed boosts and not having anything that literally accelerates or decelerates time for the player (except the time dilation CBM, I guess), we dramatically reduce the chance of this.

Readily displaying things in seconds rather than moves is a bonus to that, but I don't think it's the main goal. Still, "moves" are very opaque to new users particularly in how they spill across turns and whatnot. Making them "seconds" is a change that is just as understandable to people used to the idea of moves, you just have to get used to moving the decimal place... But it's far more accessible to new users. I think it's a no-brainer change.

[Tamiore]

Perhaps I'm missing something, but what exactly is difficult or confusing about the current system — given that your current speed (in move points) is explicitly displayed in UI?
I'm pretty sure everyone can figure out how many turns an action (that requires X MP to perform) will take if your character generates Y MP per turn.

P. S. To state the obvious: character speed in actual combat is RARELY, if ever, exactly 100 MP per turn. Pain, debuffs, stimulants, traits, etc, etc — all that effects speed.

[I-am-Erk]

You're given a value in an unknowns unit, and expected to understand intuitively how it correlates to a number in another part of the screen amidst a field of other numbers, where it is labeled by a different name. This number could, without any impact on gameplay, be labeled in a real world unit that everyone already understands. I'm phenomenally impressed that this is even a matter of debate.

To state the obvious: character speed in actual combat is RARELY, if ever, exactly 100 MP per turn. Pain, debuffs, stimulants, traits, etc, etc — all that effects speed.

Yes, and given that almost nothing completely globally slows or speeds you like that, this is something that should be changed.

[Tamiore]

You're given a value in an unknowns unit, and expected to understand intuitively how it correlates to a number in another part of the screen amidst a field of other numbers, where it is labeled by a different name. This number could, without any impact on gameplay, be labeled in a real world unit that everyone already understands. I'm phenomenally impressed that this is even a matter of debate.

This is a matter of debate because instead of dynamically showing you current speed in MP in UI with static costs displayed for items, you will now have to DYNAMICALLY update all the items.
Let's say I examine a wooden spear on a nearby shelf with a quick character wearing heavy survivor suit.
What attack speed would it display under your proposed system?

Yes, and given that almost nothing completely globally slows or speeds you like that, this is something that should be changed

So would WOULD pain do, if it will not slow you down?

[I-am-Erk]

I didn't say it wouldn't slow you down. Slowing you down by dropping your movement points is pretty silly though, because it means being in pain makes literally everything you do take longer.

Really the whole thing should be more granular based on where your injuries are, but a global pain is mostly just likely to reduce your movement speed. Unless your hands are hurt, it's not going to change how long it takes you to get stuff out of your backpack, or eat a sandwich.

[I-am-Erk]

This is a matter of debate because instead of dynamically showing you current speed in MP in UI with static costs displayed for items, you will now have to DYNAMICALLY update all the items.
Let's say I examine a wooden spear on a nearby shelf with a quick character wearing heavy survivor suit. What attack speed would it display under your proposed system?

I think you're making issues out of non issues here. It would display the base attack speed, which would be a very useful item stat that could still be compared between items. If you had a modifier because something had slowed down your attacks, the item stats are not the place to show that. Personally I don't think that's something that should be player-facing information anyway, but if someone wanted it they could add a field for "your attack speed" that implemented all your current bonuses and penalties for your equipped weapon and listed them on your @ menu or something.

[Tamiore]

I didn't say it wouldn't slow you down. Slowing you down by dropping your movement points is pretty silly though, because it means being in pain makes literally everything you do take longer.

I fail to see why exactly pain should interfere with jogging more than with swinging machete.

It would display the base attack speed, which would be a very useful item stat that could still be compared between items.

Base attack speed in what units?
And how do I, as a player, turn that "base attack speed" into attacks per turn with my current character?

[I-am-Erk]

The base attack speed would, obviously, be given in seconds... The current base attack speed with the decimal moved a bit over.

As I said, personally I don't think it should be trivial to translate that to your character's current attack speed. It's not something you should be able to tell at a glance. However, it could be put in a forward facing location if someone disagreed with me... A candidate would be the interface spot vacated by the now useless speed stat.

"Pain" as a vague category doesn't slow your ability to swing a machete. Arm damage probably should, instead. Pain to most parts of the body aside from the arms tends to slow walking speed by limping, but even then, that should probably be specifically linked to leg and torso injuries, and specific injury effects. The idea of pain standing in for all ongoing damage effects is definitely not a sacred cow.