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:

I just miss the old slider tick behavior.

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

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.

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:

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.

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.

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

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.

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

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

New combo for every note-changing?

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.

did stupid typo so half of post got deleted ;_;

You can never identify speed of next slider just by seeing new combo on it

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.

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?

D33d wrote:

There should be something in the overall experience to indicate speed changes.

Can also this be a potential solution?

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.

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)

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.

It seems the general consensus on the matter is that this would be better suited as a guideline. Would people support the current amendment expressed as a guideline rather than a rule in its current form?

Yeah, that would work. If the guideline is broken, the mapper would have to get enough players to play it and say the SV change is appropriate and readable in the context of the whole map.

Guideline wrote:

Sliders cannot be visually identical to other sliders on screen when their slider speed is largely different and there aren't slider tick visible if there are no acceptable cues, visual or musical. The acceptability of the cues must be tested by a group of people.

That's more generic as guideline
you can add a list of cues examples at the end, if you want.

Sorry, neglected this thread a bit.

I have edited the first post to reflect the general thoughts of the thread to move this to a guideline with an emphasis on having visual cues, be it slider ticks or a change in note density. This will still discourage disproportionate speed changes while preserving several styles of mapping. The main aim is to discourage drastic speed changes, so wording change propositions to reflect that sentiment would be appreciated.

As for individual responses:

This discussion seems to have died rather suddenly.

How about a simpler wording like this?

Kytoxid wrote:

This discussion seems to have died rather suddenly.

How about a simpler wording like this?

Slider speed changes should have corresponding cues. These cues may include changes in the music, changes in note density, or visible slider ticks.

Nice & simple, supporting this.

Kytoxid wrote:

This discussion seems to have died rather suddenly.

How about a simpler wording like this?

Slider speed changes should have corresponding cues. These cues may include changes in the music, changes in note density, or visible slider ticks.

Support, though I wish we could just say "Don't be retarded" and be done with it D:

Kytoxid wrote:

This discussion seems to have died rather suddenly.

How about a simpler wording like this?

Slider speed changes should have corresponding cues. These cues may include changes in the music, changes in note density, or visible slider ticks.

Good idea, and I think that combo colors are also included

Not necessarily. New combos mark the start of a new phrase. If you have to use a new combo to show velocity change, you're doing something wrong.

Just quoting my old post:

Kodora wrote:

You can never identify speed of next slider just by seeing new combo on it

A "change in the music" isn't a cue you can read until you're already on it and is overly broad anyway. The other two I agree with.

Ekaru wrote:

Kytoxid wrote:

This discussion seems to have died rather suddenly.

How about a simpler wording like this?

Slider speed changes should have corresponding cues. These cues may include changes in the music, changes in note density, or visible slider ticks.

Support, though I wish we could just say "Don't be retarded" and be done with it D:

Just remember that this is the osu! community.

I second Garven's statement about what a "change in the music" actually is. There should be something visual to indicate the change. If you're not sure that the visual cues are obvious enough and that the speed change can't be followed on the fly, then don't use it. Yes, it's that simple and yes, you mappers should discard a feature if it isn't proven to work, instead of becoming attached to them in the name of artistic vision.

Beatmaps are made to translate the abstract (the music) into the literal (a game level which can be read and felt). This applies to every aspect of a beatmap's visuals.

I added a bit about expecting the speed change before you land on the slider. I'm reluctant to remove music changes completely because there are definitely times when the music will be able to provide prior warning. For example, many songs will have a build up prior to entering a chorus; as a player, I can definitely use that to anticipate an SV increase once I enter the chorus itself, even in the absence of visual cues.

As long as you guys are strict about stupid bullshit then I'm fine with this. ^_^

Ekaru, that kind of language isn't helpful at all. Try to be at least a little constructive - explain what you mean. What is bad for you may be great for others. I just wanted to get some wording into the RC so that it will have a little bit a guidance towards fairness when it comes to sudden large slide speed changes, and this is the result. q:

@Kyto: That'll do then. As stated above, I wish there was mention of larger speed changes since that was the original intent of this thread.

I'm not sure that a simple slider tick to show that the sliders speed has changed will be enough indicate that it has. I think a half a second (or a time equivalent to that of a approach circle) outline glow to a slider to indicate it has changed would be more noticeable

RatedNC17 wrote:

I'm not sure that a simple slider tick to show that the sliders speed has changed will be enough indicate that it has. I think a half a second (or a time equivalent to that of a approach circle) outline glow to a slider to indicate it has changed would be more noticeable

That's why other part of proposed rule is exist:

Kytoxid wrote:

Slider speed changes should have corresponding prior cues. These cues may include changes in the music, changes in note density[u], or visible slider ticks, and should allow for the speed change to be expected before the slider begins.

Yes, new slider tick behaviour makes SV changes much harder to read since sliderticks appears just too fast to read them (it especially hurts on very fast maps). Most important thing - SV changes should have corresponding cues to allow people play them properly in first attempt without any problems, without looking in map in editor mode etc.

As i said before, support!

Alright, I'm going to bubble the new guideline under this wording. I added a bit at the end to explain why we have this rule.

I'll leave it open to discussion for a few more days; if no one has issues with it, it'll be added to the RC.

Added to ranking criteria.