Signifier for slider velocity change

[smileyhead]

Describe the new feature: Something I think was missing even from stable is a signifier for slider velocity change in standard and mania. If you haven't played a map before, you have no way of knowing if suddenly a slider (or the whole playfield in mania) is going to become faster or slower.
Also, I'm not sure the taiko approach would be the best (even though it could technically be compatible with mania's layout too), since it can make the playfield feel cluttered and confusing with all the hit objects coming in at once with different speeds.

Proposal designs of the feature: I was thinking of maybe arrows inside the slider. They are sense if the slider is quicker than the previous one and sparse if it's slower. They also go at the same speed as the slider ball will.
In mania (and taiko if you agree with me that it could be improved), they would be next to the track, approaching the judgement line at the point where the track will speed up, following the same principles.

EDIT: Made concept more osuey.

[bdach]

Maybe to go with the triangle theming of the game overall, the same triangle particle effects from hit circles can be used on slider bodies, moving along the slider with the appropriate speed? On mania/taiko you could have those floating on the sides of the playfield itself.

Could become too cluttered visually though, would have to see how that'd look. (And it'd obviously not be easy, too.)

[Snowmander]

I would also like an indicator, but I fear that the proposed design might be too eye grabbing. The ability to react to a note comes from detecting moving elements (hitcircles appearing, approach circles closing in, and slider expanding) and non-crucial elements shouldn't divert a player's focus too much.

Instead of moving arrows, I want to suggest a static diagram such as a bunny for speeding up and a turtle for speeding down.

Here's where I got the idea from:

https://youtu.be/6LAupbx_0QY?t=303

[smileyhead]

Instead of moving arrows, I want to suggest a static diagram such as a bunny for speeding up and a turtle for speeding down.

Hmm, that's not a bad idea, especially as we already have similar icons in the hit error bar, but I'm not sure as to their placement, since I doubt it's an option to interfere with the combo number and just icons wouldn't be able to display the speed at which the slider ball is going to go.

[LanTenDragon]

Throwing out another idea:

Repurpose this dev build warning bar, give it sliding animation or blinking animation, red for speed up, blue for slow down. Idea came from Cytus 2 https://youtu.be/0POctmRMMQU?t=46

icons wouldn't be able to display the speed at which the slider ball is going to go

I'd argue that players only need to know that there is an impending SV change, then muscle memory would kick in?

[LanTenDragon]

Another thing to consider (for the future implementer) is how to handle edge cases of maps, where entire sections of maps are just crazy high and sudden SV changes.

Example maps are https://youtu.be/yzwtnWQhEW4?t=73 and quite a lot of Aspire Maps (Hellblinde - Solace Of Oblivion comes to mind)

In this case, SV signifier could be turned off otherwise it would stay on screen all the time.

[smileyhead]

Repurpose this dev build warning bar, give it sliding animation or blinking animation, red for speed up, blue for slow down. Idea came from Cytus 2

In Cytus 2, that bar is the judgement line. There is no such thing in standard (and in other game modes it's static). A moving line scanning across the screen would be way too large a signifier for something like this and just having it at the bottom of the screen (aka relying of the player's peripheral vision to notice it) is just bad design.

I'd argue that players only need to know that there is an impending SV change, then muscle memory would kick in?

SV is a spectrum. You can't rely on muscle memory if all the information you get is it getting faster or slower.

Another thing to consider (for the future implementer) is how to handle edge cases of maps, where entire sections of maps are just crazy high and sudden SV changes.

I'd imagine it would be a skinnable element and thus could be hidden by map creators, if desired.

[MightyHelper]

Couldn't we implement a slider sub-tick that would be only visual and would appear 3 to 2 times ( depending on time signature) between the slider ticks?
Maybe make them a bit smaller and darker so they are not confused and, since the player knows the bpm they can just see and "expect" the slider to take x s of time between slider sub-ticks.
The problem with this is if the BPM and SV change at the same time. Then, good luck.

[MitsukaiDokuro]

I would put a hue shift in my skin - blue for slower velocity, red for faster velocity. Though the default skin might visualize it with icons or a moving track, as suggested.

See Redshift, Blueshift

[hostilew]

I would suggest first make slider ticks fade in instantly with sliders. currently they only fade in after sliders are finished fading in, and slider ticks are the only good indicator of how fast a slider is. Then if that isn't enough of a new cue, then I would suggest a moving gradient on sliderborders. Subtle but would communicate an exact speed.

[bdach]

slider ticks are the only good indicator of how fast a slider is

are they? that depends both on the slider velocity and tick rate of the map, doesn't it?

[hostilew]

sorry I don't mean out of all possibilities, but I just mean out of what's ingame already, I would rephrase that to say they're the easiest thing I think to change.

[mk56-spn]

i mean while this seems cool and all i think making slider snake in match slider speed would be a much better option for indicating slider speed ahead of time

[Emrik-North]

I really want to be able to sightread sliders better (even the best players can get slow-slidered or fast-slidered on sightread), but the suggestion in the OP is too cluttered to read in a very fast map. Same with having the snake-in speed match the sv, since on AR10 you don't have a chance to read that. Here's my suggestion:

Have the filler colour inside the sliders be wider or thinner depending on the sv. This, or something like it, I think would be much easier to read fast, without cluttering up the playing field too much.

Example slow slider:

Example fast slider:

[bdach]

This won't work well for people who may have slider snaking enabled, since the slider body is not immediately fully visible in that case.

[Emrik-North]

Yeah, but it can be a toggle. I'd prefer to play with snake-in disabled, so that I would be able to immediately see the thickness of the sv indicator.

[BDSuther]

This is something I've wanted for a long time. I really dislike going through a first play of a map only to drop combo because someone decided putting a similar length slider with 1/2 or less SV was a good idea (or 2x or more SV).

I think a 3-point gradient skinnable colours for the slider body or background would be a great idea. The colours would represent [slow, most common, fast] slider velocities where 'most common' would be the normal expected colour for sliders as it is now in-game. If the map has one SV it would use the 'most common' colour always. If there are two SV, the 'most common' colour is used for the most used SV and the slow or fast colour is used for the 2nd SV. If they are equal, it could be a configured to use 'most common' and either slow or fast as the other colour per the player's preference.

With multiple SV you would then need to use the gradient values much like MitsukaiDokuro's redshift, blueshift suggestion.

[smileyhead]

Using just colours doesn't account for colour-blindness, though.

[BDSuther]

It would if you can pick the colours you want to use via your skin. Even greyscale would work.