[New][GdeLine] Slider tick must be visible for speed changes

posted
Total Posts
39
Topic Starter
Garven
New ruleguideline:

Sliders cannot be visually identical on screen but have large speed changes without having a slider tick visible, or the hit object density changes proportionally with the speed change to give a visual cue. This is to aid in the readability of your map.
Since our current guideline is pretty limited in scope, and we have pretty much been enforcing this proposition anyway, we may as well put it down to parchment. Basically sliders that have no visible ticks but are visually identical on the screen at the same time or close enough to still be an afterimage is not advisable due to them having no visual cue to a velocity change. You essentially have to memorize the map which goes against the sightreadability rule. This is a specific branch from that particular rule as a strong guideline.

A visual of what would be discouraged:



Slider 1 is at .5x speed, slider 2 is at 2x speed and slider 3 is at 1x speed. All are visually identical, but play completely differently with no visual cue.
Raging Bull
I just miss the old slider tick behavior.
RLC
While I get the idea, I don't really agree with this rule, and here's why.

Here's an example of two identical sliders with different speeds (I've seen a lot of people play this map, and none of them have misread the SV change):
https://osu.ppy.sh/b/268040&m=0 [LC] diff
02:46:171 (4,1) -

As said above, not a single person that I watched try this map hit a slider 100 or broke at that point.
Why might this be readable / intuitive? Perhaps because 02:46:464 (1) - is accompanied by a decreased on-screen note density; perhaps because both are short enough to not break on, but not short enough to trick the player into releasing early. Point is, first-try read/playability of sliders is not just a matter of ticks.

What does it mean for a map to be sightreadable?
Does the player need to 1) understand the timing of every object PERFECTLY on first run in order to qualify a map as sightreadable, or 2) only understand the timing to an extent such that the player has all the required knowledge to (theoretically) SS? The former would have some serious logical flaws--consider two sliders, no ticks on either, one at 1.00x and the other at 1.01x. While this is a strained example, under definition 1) of sightreadability, this might be unrankable, which doesn't really make sense.

Anyway, consider the example i linked above, and consider revising this :(
Ephemeral
In light of RLC's post, perhaps the rule could be adjusted to encompass simply requiring some form of identifier for speed changes, whether it be visual or aural. If sliderticks are not applicable, then musical cues or large changes in note density/structure must be present in order to justify the change.
Topic Starter
Garven
I can see where you're coming from with that RLC, but your second example for sight readability is a bit off compared to the wording I proposed as it's specifically targeting LARGE speed changes. Not an incremental one.

The LC map you linked was okay, but tick rate 2 is the proper tick rate anyway and would invalidate the need for a check since it would have the tick visible anyway.

Care to propose a different wording to encompass your examples? It took me long enough to figure the wording for my proposal. I am pretty horrid at being concise. q:
RLC

Garven wrote:

The LC map you linked was okay, but tick rate 2 is the proper tick rate anyway and would invalidate the need for a check since it would have the tick visible anyway.
True, TR2 may fit that particular song. Nevertheless, my point was the pattern is readable regardless of the tick rate.

To be honest, I can't really come up with any good way to tweak the wording. After so much playing and spectating, I've arrived at the uncomfortable conclusion that readability is a much less objective thing than I thought it would be. As my previous post (and Ephemeral's) hinted at, there's a large assortment of cues of all different kinds that play a role in how players read patterns.

(Visual) Tick count can show SV changes.
(Visual) Colorhaxing schemes can also communicate SV changes.
(Visual) Decreased object density suggests slower sliders.
(Visual) Increased object density suggests faster sliders.
(Visual) If you have a slider, and then an object that appears 1/1 after the slider, the player knows for certain that the slider must be rhythmically shorter than 1/1.
(Flow) Stacking on top of a slow slider's head can kill momentum and make a slowdown more obvious.
(Flow) Large jumps into faster sliders can build momentum and make them more obvious as well.
(Visual / Leniency) People have a greater tendency to "rush" to follow the path on visually longer sliders, so short slow sliders are easier to handle than long slow sliders.
(Leniency) A 1/4 kickslider followed by a 1/8 kickslider with 2.0x would be perfectly readable despite being visually identical, because of how players handle kicksliders.
(Aural) Softer music suggests slower SV.
(Aural) Louder music suggests faster SV.

etc. etc.

And this is just a list from the top of my head. As you can see, any rule that we can synthesize from these cues (and the countless others that I have not listed) would be inevitably flawed.
We've been handling SV readability on a case-by-case basis thus far, and from what I can tell, it seems to be working fine? The introduction of a new rule doesn't sound like it would expedite modding by much, if at all.
Topic Starter
Garven
The case-by-case basis comes to a head often though, frothing and filled with anger. Having a solid rule in place would be preferred so that we we don't have very wild variations on interpretation of the guideline. People push the limit way too far and pretty much invalidate the point of even having sliders when you have large velocity changes and no ticks. You don't have to even ply the slider. You just click the start and the end. The path means little except eye candy instead of the gameplay element of something that you should be following.

Let's see if we can condense your examples at least, because I feel that leaving things as they are will just lead to more unneeded heartache.

As an aside, I'd prefer to not have combo colors used just to show a gimmick of the map and have them be a representative of the phrase of the music instead.

So a lot of the visual examples can pretty much be summed up by "note density."

Flow is a little more tricky since there are a lot of different styles, and wording a hard line rule to encompass that is rather difficult. I think they would also factor into the note density aspect, though there are always outlying cases with this sort of thing.

The aural tends to not work very well in my experience, as usually if the song is suddenly going to get quiet, there is pretty much zero cue for the player that has never heard the song before to intuit that this will happen AND that the map will be translating that in a drastic manner in terms of pace.

So perhaps something along this line:

Sliders cannot be visually identical on screen but have large speed changes without having a slider tick visible, or the hit object density changes proportionally with the speed change to give a visual cue. This is to aid in the readability of your map.
pieguyn
there exist cases where a drastic speed change is visible without a tick and increasing tick rate would mess up a lot of the map, so putting a rule like this in would be completely counterproductive

I don't see a need to respond to anything specific as long as that holds true

seems like it'd work well as a guideline though 0.0
Topic Starter
Garven
Increasing tick rate doesn't mess a map up in most cases as most people actually have the tick rate too low. And if it does mess the map up, the rate is probably at a rate that is not applicable to this particular problem

There's already a guideline that does pretty much nothing regarding sliderspeed changes, thus the need for addressing it with this thread. Turning this into a guideline would be pointless.
pieguyn

Garven wrote:

Increasing tick rate doesn't mess a map up in most cases as most people actually have the tick rate too low. And if it does mess the map up, the rate is probably at a rate that is not applicable to this particular problem
plz not this whole tick rate debate again. = =

There's already a guideline that does pretty much nothing regarding sliderspeed changes, thus the need for addressing it with this thread. Turning this into a guideline would be pointless.
I even disagree with this

for people who aren't sure if their speed change is readable enough, they can go to check the guideline and see the idea of adding a tick to make it absolutely readable. but people who are more experienced don't need a guideline anyway and have their own intentions. putting this as a rule just gets in people's way, while putting this as a guideline brings a lot of benefit to the people who could actually need it
epocsodielaK
I can't agree more with RLC

As far as I know, few players read slider velocity change by the desity of slider tick, because it's hard to catch

I usually read the slider velocity by colorhaxing and the sliderball, and

- for sliders slow down suddenly, we may misread it at first, but usually they are long enough, so if it's tickrate 1, we have enough time to move cursor back. But for tickrate 2, before we can notice that the slider is of low speed, we get annoying combo break.

- the same situations happens to high speed sliders. In most case, more slider ticks just ruins the flow of the map rather than improve the readablity of the speed change to sliders
Oyatsu
New combo for every note-changing? :)
those
If you have to rely on a new combo to determine a slider's change in velocity, it's probably mapped wrong, so no that's not a solution.
Kodora
did stupid typo so half of post got deleted ;_;

You can never identify speed of next slider just by seeing new combo on it
Scorpiour
https://osu.ppy.sh/b/172193&m=0

< <

actually .. i wanna say, personally i prefer tick rate 2 to 1, but please consider that in some cases the reduced speed slider are used for peaceful part of music which volumn is pretty low, so the hitsound of tick rate 2 may break the sense of music.

in real mapping, i believe there are various way to emphasize the speed change, so it is a "case-by-case issue". That is, i would like to put it in guideline but not rule, and in special cases BAT could let it go.
D33d
There should be something in the overall experience to indicate speed changes. Combospam is some people's way of expressing sudden changes, but it's kind of bogus because it's not immediately clear that a speed change is being expressed.

If a speed change is subtle enough that it doesn't screw up many players, then it's not really a problem in the first place. If it isn't subtle, then there's a good chance that it will and if we go by something like Garven's example, changes in tick density will make speed changes at least remotely easier to anticipate.

Even rules can be broken in special cases, if the song/mapping really call for it, so people could still circumvent this if they have a strong enough case. Even if this isn't agreed on as a tick rule, I'm sure it can be agreed that having sliders of different speed, which look the goddamn same, are stupid. Perhaps that aspect could be incorporated instead?
Kodora

D33d wrote:

There should be something in the overall experience to indicate speed changes.
Can also this be a potential solution?
D33d

Kodora wrote:

D33d wrote:

There should be something in the overall experience to indicate speed changes.
Can also this be a potential solution?
Seems rather contrived to me. As elegant as the solution could be, it would also add more visual noise than is really necessary. When the speed changes are carried out well, player shouldn't need extraneous visual cues beyond ticks. To elaborate slightly, it'd be confusing to determine the difference between a speedup and a slowdown at a glance.
Zare
I'm pretty indifferent about this. While I get the idea, I also fully agree with RLC about Ticks not being the only thing that can imply a SV change.

Garven wrote:

As an aside, I'd prefer to not have combo colors used just to show a gimmick of the map and have them be a representative of the phrase of the music instead.
But it IS used that way. You can't just deny that by saying you'd rather see it done differently. Usage of combo colours has to fit in some way, but what way that is, is up to the mapper entirely.
Also keep in mind SV changes would not be used randomly but when something in the song, e.g. a new, stronger phrase suggests it. Often enough you would use NCs at such parts anyway. (Not always, of course, but yeah)
D33d
I think his point was more that colour indicators don't show speed changes that well. It is abuse of combo colours as well and is a pretty hamfisted way to deal with a basic problem.
show more
Please sign in to reply.

New reply