forum

[Proposal] osu!standard ruleset draft (General)

posted
Total Posts
106
show more
Sieg
Both slider border and body colors must be manually set or not set. Setting only one may conflict with a user’s custom skin choices.
Can you please elaborate this?
Mao

Sieg wrote:

Both slider border and body colors must be manually set or not set. Setting only one may conflict with a user’s custom skin choices.
Can you please elaborate this?
I think it's meant that if you set for example a red sliderborder and a user has a red slidertrack in their own skin the sliderborder won't be visible anymore thus skinning both is mandatory if you skin one.
Topic Starter
Myxo

Sieg wrote:

Both slider border and body colors must be manually set or not set. Setting only one may conflict with a user’s custom skin choices.
Can you please elaborate this?
When a user set one of those in their skin (or both) and a mapper sets only one of them, they might end up being the same color.

It's a bit unfortunate that it's not possible to force the slidertrack taking the color of the combo colors automatically, like it is in the default skin. We will do our best to make the devs implement this, and then we can remove this rule. But for now, we want to ensure maximum compatibility with player's skins.
abraker

Desperate-kun wrote:

Quote:
Every slider must have a clear and visible path to follow from start to end.
Ohhhh I was thinking that in terms of visibility. Like for example, a slider fully in view has a visible path from start to end, but not necessarily has the velocity or consistent velocity which can indicate the time the path starts and the time the path ends.
Topic Starter
Myxo

abraker wrote:

Desperate-kun wrote:

Quote:
Every slider must have a clear and visible path to follow from start to end.
Ohhhh I was thinking that in terms of visibility. Like for example, a slider fully in view has a visible path from start to end, but not necessarily has the velocity or consistent velocity which can indicate the time the path starts and the time the path ends.
No, this one is for preventing burai and hold sliders like explained after the bold text.
Sieg

Desperate-kun wrote:

It's a bit unfortunate that it's not possible to force the slidertrack taking the color of the combo colors automatically, like it is in the default skin. We will do our best to make the devs implement this, and then we can remove this rule. But for now, we want to ensure maximum compatibility with player's skins.
So if you use custom slider skin element in your map you must set sliderborder, if you have sliderborder set you must set sliderbody? This means sliderbody cannot use combo colors and forced to a single color until feature for this will be implemented by the devs, right?
Topic Starter
Myxo

Sieg wrote:

Desperate-kun wrote:

It's a bit unfortunate that it's not possible to force the slidertrack taking the color of the combo colors automatically, like it is in the default skin. We will do our best to make the devs implement this, and then we can remove this rule. But for now, we want to ensure maximum compatibility with player's skins.
So if you use custom slider skin element in your map you must set sliderborder, if you have sliderborder set you must set sliderbody? This means sliderbody cannot use combo colors and forced to a single color until feature for this will be implemented by the devs, right?
Unfortunately, yes. If someone doesn't find a workaround for this (which I highly doubt will happen).
quaternary
You might want to add a guideline about using custom numbers in your beatmap skin.

If the player has a HitCircleOverlap or ScoreOverlap value set in their skin.ini and uses the beatmap skin, osu! will use the player's Overlap settings with the beatmap skin's numbers, which, more often than not, just makes a mess...
Wafu

quaternary wrote:

You might want to add a guideline about using custom numbers in your beatmap skin.

If the player has a HitCircleOverlap or ScoreOverlap value set in their skin.ini and uses the beatmap skin, osu! will use the player's Overlap settings with the beatmap skin's numbers, which, more often than not, just makes a mess...
We consulted this and we cannot do this right now. We have no ability to change required values in .osu file for making these work completely, once that is possible, we'll bring the rule. We are aware this causes an issue, but for now, it's only fixable via forcing the default skin (which changes way too many things, if we basically want to change one value). There's one guideline requiring default skin as preferred too, so I agree it doesn't make sense to stay. I planned to create a feature request for this so that we can complete the skinning rules.
Sieg

Desperate-kun wrote:

Sieg wrote:

So if you use custom slider skin element in your map you must set sliderborder, if you have sliderborder set you must set sliderbody? This means sliderbody cannot use combo colors and forced to a single color until feature for this will be implemented by the devs, right?
Unfortunately, yes. If someone doesn't find a workaround for this (which I highly doubt will happen).
uh, alright, but this is such a huge limiting in skining to cover just a few edgy cases that may occur
Topic Starter
Myxo

Sieg wrote:

uh, alright, but this is such a huge limiting in skining to cover just a few edgy cases that may occur
will discuss this again
grumd
copy pasting this
not sure what was fixed already
1. there is a typo.

Avoid excessive composition differences in similar sections of a song. The basic spacing and rhythm should similar, while patterning can vary. This is to ensure players do not get confused when playing the same rhythm twice.

> should BE similar

2.
Avoid beginning ¼ sliders on unsupported blue ticks. Often white/red ticks should be prioritized even if the same sound sample is used for blue ticks. If there is a distinctly important sound on the blue tick, however, beginning a ¼ slider there can be acceptable.

probably would want to emphasize that blue tick sound should be more distinct than red/white to start a slider there

3.
Spinners should be used when they fit the music. They usually fit during held notes, changes in intensity, or transitions between sections. This is to ensure score differences among perfect plays on the leaderboard.

3rd sentence refers to 1st so its better like this

Spinners should be used when they fit the music. This is to ensure score differences among perfect plays on the leaderboard. They usually fit during held notes, changes in intensity, or transitions between sections.

4.
Avoid following multiple layers of the song if it is unclear what rhythm is prioritizing. Players should be able to discern what part of the song is being followed.

probably should add that this mostly applies to lower diffs
Kibbleru
looks good so far, i can already see the unnecessary limitations before have been removed.
Koiyuki
i think custom combo color have to be used, which can be added to the rule 2 in general.

also it seems changing .osu file is not banned, from my side we can allow some of the changing by .osu file like sv, str, lr and some of the slider go through the timing section(red line)......

other seems fine.
Topic Starter
Myxo

grumd wrote:

copy pasting this
not sure what was fixed already
1. there is a typo.

Avoid excessive composition differences in similar sections of a song. The basic spacing and rhythm should similar, while patterning can vary. This is to ensure players do not get confused when playing the same rhythm twice.

> should BE similar
Already fixed.

grumd wrote:

2.
Avoid beginning ¼ sliders on unsupported blue ticks. Often white/red ticks should be prioritized even if the same sound sample is used for blue ticks. If there is a distinctly important sound on the blue tick, however, beginning a ¼ slider there can be acceptable.

probably would want to emphasize that blue tick sound should be more distinct than red/white to start a slider there

3.
Spinners should be used when they fit the music. They usually fit during held notes, changes in intensity, or transitions between sections. This is to ensure score differences among perfect plays on the leaderboard.

3rd sentence refers to 1st so its better like this

Spinners should be used when they fit the music. This is to ensure score differences among perfect plays on the leaderboard. They usually fit during held notes, changes in intensity, or transitions between sections.

4.
Avoid following multiple layers of the song if it is unclear what rhythm is prioritizing. Players should be able to discern what part of the song is being followed.

probably should add that this mostly applies to lower diffs
Will discuss.
Although I disagree that 4. should mostly apply to lower diffs, because it's bad to follow 'everything' in Insane too. Mostly it leads to 1/2 or 1/4 spam without recognizable rhythm.

Koiyuki wrote:

i think custom combo color have to be used, which can be added to the rule 2 in general.

also it seems changing .osu file is not banned, from my side we can allow some of the changing by .osu file like sv, str, lr and some of the slider go through the timing section(red line)......

other seems fine.
Each map must use at least two different custom combo colors unless the default skin is forced.
is already here... I don't really understand what you want to say regarding colors.

Changing .osu files is still banned like before, because it is part of the all-mode Ranking Crieria. This one here is only std-specific.
Koiyuki

Desperate-kun wrote:

Each map must use at least two different custom combo colors unless the default skin is forced.
is already here... I don't really understand what you want to say regarding colors.

Changing .osu files is still banned like before, because it is part of the all-mode Ranking Crieria. This one here is only std-specific.
eh that's a misreading, because i met a map which doesnt set any combo color, also unforced default skin, and get bubbled.

for std rule, i remember that charles445 mentioned that the stack leniency can be set as 0 by changing .osu file, also it's rankable. So I think we should mention it in std rule.
Topic Starter
Myxo

Koiyuki wrote:

Desperate-kun wrote:

Each map must use at least two different custom combo colors unless the default skin is forced.
is already here... I don't really understand what you want to say regarding colors.

Changing .osu files is still banned like before, because it is part of the all-mode Ranking Crieria. This one here is only std-specific.
eh that's a misreading, because i met a map which doesnt set any combo color, also unforced default skin, and get bubbled.
Yeah, because currently that is allowed. When this RC will be ammended it won't be allowed anymore.

Koiyuki wrote:

for std rule, i remember that charles445 mentioned that the stack leniency can be set as 0 by changing .osu file, also it's rankable. So I think we should mention it in std rule.
It will still be included in the all-mode RC though, except if we decide to do otherwise when we will discuss that topic. For now this won't be added here as that rule is still covered by the general RC.
grumd
Changing .osu files is still banned like before, because it is part of the all-mode Ranking Crieria. This one here is only std-specific.
This is wrong.

Do not manually edit anything in an .osu file that cannot be changed through the Editor.
There's an important part there.
Topic Starter
Myxo

grumd wrote:

Changing .osu files is still banned like before, because it is part of the all-mode Ranking Crieria. This one here is only std-specific.
This is wrong.

Do not manually edit anything in an .osu file that cannot be changed through the Editor.
There's an important part there.
That's what I meant, my sentence structure was a bit weird. I meant the same aspects about .osu editing like before are banned, because of the all-mode Criteria.
Haruto
Do not manually edit anything in an .osu file that cannot be changed through the Editor.
Does adding Skinning stuff like, colours of sliderborder and slidertrackoverride is still considered as manual editing through the .osu file? and does it will still allowed if the new RC applies?
Topic Starter
Myxo

Haruto wrote:

Do not manually edit anything in an .osu file that cannot be changed through the Editor.
Does adding Skinning stuff like, colours of sliderborder and slidertrackoverride is still considered as manual editing through the .osu file? and does it will still allowed if the new RC applies?
The all-mode Ranking Criteria will be updated later, which will cover this issue, too. The RC is incredibly outdated.
Obviously, editing sliderborder and slidertrackoverride will NEVER be unrankable, because it's necessary.
Haruto

Desperate-kun wrote:

Haruto wrote:

Does adding Skinning stuff like, colours of sliderborder and slidertrackoverride is still considered as manual editing through the .osu file? and does it will still allowed if the new RC applies?
The all-mode Ranking Criteria will be updated later, which will cover this issue, too. The RC is incredibly outdated.
Obviously, editing sliderborder and slidertrackoverride will NEVER be unrankable, because it's necessary.
Oh i understand then. I Thought they will come as unrankable if the map dont have any custom skin files lol.
Okoratu
Just my own notes made public about the things we should have to address in a revision anyways based on the input from several sides so far (+my own thoughts after hearing a few things):

Desperate-kun wrote:

All repeat arrows on sliders must be visible, excluding short repeating sliders. In those cases, only the first repeat has to be visible, since the other repeats are expected. Test play your map to confirm if repeat arrows are visible.
Should get a sentence explaining why this even is a requirement

Desperate-kun wrote:

All circles and slider heads should be snapped to distinct sounds in the music. Adding objects where there is no musical cue to justify them can result in confusing patterns and unfitting rhythms.
Instead of calling it confusing this should probably say something among the lines of inventing objects that contradict what the song offers goes against the basic intention of a rhythm game that follows a song

Desperate-kun wrote:

Avoid overlapping objects with other elements of the default skin. This includes elements such as the HP-bar, combocounter, progressbar or the score meter.
while it is already kind of hinting that it probalby only means skinnable elements i feel like this should include a list of things that are involved here, otherwise nobody knows how and what to check for in which resolutions whatsoever because it's a tad too vague

Desperate-kun wrote:

Avoid using high tick rates combined with low slider velocity. Receiving feedback from slider ticks that are not visible can be uncomfortable.
Would rather say that hearing ticking and not seeing anything that causes it is similar to storyboarded samples playing in the middle of something

Desperate-kun wrote:

Buzz sliders must have appropriate delay before the next note. 1/8 and 1/16 sliders should be followed by a 1/4 gap, whereas 1/12 sliders should be followed by a 1/6 gap. This ensures that the hit-window between objects is playable.
Guideline wording would suggest must -> should

Desperate-kun wrote:

Avoid excessive composition differences in similar sections of a song. The basic spacing and rhythm should be similar, while patterning can vary. This is to ensure players do not get confused when playing the same rhythm twice.
should rather say section and back this up that a composition of objects based on a song should not be vastly different if a repeated section is played as a more logical argument because most of the times this does not confuse players, it just does not make much sense from a game design perspective

Desperate-kun wrote:

Try to spread your object placement evenly across the playfield. Objects cluttered in one region of the screen can be uncomfortable to play when there isn’t clear intent behind their placement.
similar approach to getting rid of "uncomfortable": the composing area is an entire screen so it should be used for keeping placement balanced, unless the idea is to clearly do otherwise. If you randomly end up just being in the same place you could argue that you mapped yourself into circles and should attempt to balance your placement given that you have a ton of space left out.

also get rid of contraction "isn’t" -> is not
those
Objects on or ending on nothing in the music is still wrong, even if the popular opinion doesn't agree. If you're allowed to put stuff where there isn't anything, why bother creating a rule set at all?

Setting a slider end to volume 0 is a band-aid solution to the problem. If there's nothing in the music, the player has to hold for an arbitrarily long time. It no longer becomes a skill to play sliders when you have to guess when it will end (1/4 to the next beat? 1/6? 3/8?). Having a slider end on a beat in the music eliminates this ambiguity. Furthermore, the only reason these sliders of arbitrary length exist is because the game for some reason does not allow an object to play at another object's end. If there's nowhere in the music for you to end the slider before the next time you want to click, the correct solution is to not use a slider at all.
Endaris
Well, there exist hold sounds that fade out - theyre not fit to use a circle but there's no distinct end. I'm thinking of the ending slider of MiddleIsland Aldo [Angelhoney] and similar usage cases here.
If there's a context you can put the sliderend into I certainly agree with you but I think trivialising sliderendusage isn't the way to go.
Topic Starter
Myxo

those wrote:

Objects on or ending on nothing in the music is still wrong, even if the popular opinion doesn't agree. If you're allowed to put stuff where there isn't anything, why bother creating a rule set at all?
When mapping you follow a certain dominant layer, and you want to emphasize that layer as much as possible depending on your way of using rhythms. Extended sliders that end on nothing can be used if a hold note needs to be emphasized but the beat the note ends on also needs to be clickable, because it is probably as strong or stronger than other clickable beats in the map.
There are also cases where 1/6 can be simplified as 1/4, for example, or similar things that may require putting even clickable objects on nothing to improve the readability and playability of a map. After all, osu! maps aren't just about following the song, they are also made to be played.

After all, we should aim to follow the songs as close as possible, but there also needs to be proper emphasis and the maps need to be playable, which may require mapping on nothing at some point. Mapping on nothing is basically only allowed if it makes the map feel more related to the song, rather than how you assume less related.

those wrote:

Setting a slider end to volume 0 is a band-aid solution to the problem. If there's nothing in the music, the player has to hold for an arbitrarily long time. It no longer becomes a skill to play sliders when you have to guess when it will end (1/4 to the next beat? 1/6? 3/8?). Having a slider end on a beat in the music eliminates this ambiguity. Furthermore, the only reason these sliders of arbitrary length exist is because the game for some reason does not allow an object to play at another object's end. If there's nowhere in the music for you to end the slider before the next time you want to click, the correct solution is to not use a slider at all.
What Endaris said. Also, certain hitsounds can sound noisy in calm songs, in which case they can be muted. Slider ends don't necessarily need to give feedback to the player as they are not strict with the timing of releasing the key.
those

Desperate-kun wrote:

but there also needs to be proper emphasis and the maps need to be playable, which may require mapping on nothing at some point
What you need to realize is that not all music is meant to be mapped. If a song is to be mapped it should be done according to what's in the music. Otherwise, you can just create something over a blank audio file and come up with some reason that somehow satisfies someone. Mapping on nothing is a lazy excuse for not wanting to think about how to actually make the objects fit or align with the music. This applies to both objects and end of objects.
Okoratu
It really isnt since mapping is interpreting a song, and if you have an unclearly ending and prolonged sound you really shouldnt be forced to just use a circle because there isnt a distinct sound to snap things to.

It doesnt go against mapping to the song either, because if the song calls for a held /prolonged note and you enforce something shorter because there isnt any clear sound to end that on then you are actually ignoring the song by being for disallowing that. For the objects starting on nothing or being against simplifying snapping for the sake of keeping rhythm 100% accurate you support disregarding that osu is also a game and as such meant to be played and your example of mapping over a blank mp3 is rather extreme

However i think we can address what you called arbitrary usage of 1/4 or 1/6 or whatever extends as a guideline in a revision
those
Lemme call you out on this one first: not mapping everything (as you describe as "simplifying snapping") is a skill and nobody should be against that at all.

However, putting things in the map that isn't in the music suggests that you aren't able to come up with rhythms that are present and instead, have to throw in your own rhythms just because you want it mapped a certain way. Refer back to the idea of laziness, etc.

Regarding slider ends: the idea is simple; you cannot simply go by the fact that you don't click the end of the slider. There is a reason why sliders have a distinct length and not just an arbitrary length or a length that fades into nothing - and that reason is that the end of the slider is to be mapped to something in the music. The biggest clue of why this is true is because the game was programmed with ends of sliders and spinners playing a hitsound. If there isn't a place for you to end the slider at a beat in the music, you should be considering (a) maybe there is a different way to map it, or (b) maybe this song isn't meant to be mapped, and not (c) maybe I'll just settle and use the "next best thing" [but is still wrong].

Arbitrariness is no fun. It's not a skill having to guess when sliders should end, and it's not a legitimate punishment for losing score/accuracy just because you held for a few milliseconds less than what was required.

Instead of settling, however, we should look at ways to allow objects to be placed on the end of objects. After all, that is what the essence of sliders that end on nothing is, right? Not being able to hold the beat until the next clickable point so you arbitrarily end it some time before the next beat. It makes absolutely zero sense, and has made zero sense for the past four years.
Endaris
But didn't you say yourself that sliderends are only used in this poor way due to the following mismatch?

those wrote:

Furthermore, the only reason these sliders of arbitrary length exist is because the game for some reason does not allow an object to play at another object's end.
Such sliders exist because there are consecutive sounds that definitely ask for a slider and the sounds are equal in importance so that it would be poor to highlight some over the others by giving them heads instead of tails.
It is a band-aid indeed and it is poor in its own way but I think floating sliderends with low hitsound volume can be justified due to their better expression of the head(=the important stuff) in comparison to the alternatives. I agree that it's not cool but as long as peppy sticks to "no 2 objects at the same time" there isn't a 100% satisfying solution to this from a mapping perspective imo. Enforcing the one suboptimal solution over the other suboptimal solution via RC doesn't look like a valid approach to me.
Wafu

those wrote:

Regarding slider ends: the idea is simple; you cannot simply go by the fact that you don't click the end of the slider. There is a reason why sliders have a distinct length and not just an arbitrary length or a length that fades into nothing - and that reason is that the end of the slider is to be mapped to something in the music. The biggest clue of why this is true is because the game was programmed with ends of sliders and spinners playing a hitsound. If there isn't a place for you to end the slider at a beat in the music, you should be considering (a) maybe there is a different way to map it, or (b) maybe this song isn't meant to be mapped, and not (c) maybe I'll just settle and use the "next best thing" [but is still wrong].
We are aware that your reasons for not using extended sliders are somewhat valid, but that still doesn't mean our reasons are invalid, if you basically don't claim anything against them.

"There is a reason why sliders have a distinct length and not just an arbitrary length or a length that fades into nothing - and that reason is that the end of the slider is to be mapped to something in the music." - I don't see why'd this be an argument. Sticking to the "original" and "authentic" purpose of the slider is cool, but doesn't mean that everyone needs to be conservative about it. Sliders also have a sliding sound so I could say that it's only supposed to be used for the long sounds and disallow it for drums. Yes, you can mute the sliderslide making it 100% viable for these sounds and it's a practise used by most of mappers. This also ruins point of sliders, but people aren't conservative about it and accept that it could also be used this way abusing something. That means muting end of a slider is not much different from muting its sliding sound, it's exactly the same kind of "abusing" the original intention.

"If there isn't a place for you to end the slider at a beat in the music, you should be considering (a) maybe there is a different way to map it, or (b) maybe this song isn't meant to be mapped, and not (c) maybe I'll just settle and use the "next best thing" [but is still wrong]." - If there isn't a place to end the slider, then you put it on the place where it feels natural. I'll bring an example from real life, if playing any instrument (for simplification, let's consider a piano), if there are very short sounds, you just simply "click" them, you barely hold the key. However, if there is a long sound you'll hold the piano key for a long time, but you need to put your finger off at some point which is not defined by beats and it's usually approximately before playing another note. This is a thing that every musician is going to experience, so it's very relevant to music. Holding a slider with muted end and releasing a while before next note is none different from how the instrument is in reality played.

What I want to say here is that not all of your points are incorrect, most of them have some meaning, but assuming that it is incorrect just for the sake of authenticity (coming from how sliders are programmed) is a bit off if it plays just the same as real instruments. Of course I am against them to some point, if there is no long sound that requires a hold, then ending on nothing feels very weird, but if you hear the long sound, it's absolutely fine to "hold it" as you'd do with any instrument. You don't need to guess when the slider ends, sliders don't require that much of accuracy and you can usually detect it easily by the length of the slider and speed.
those
There's a fundamental difference between the scoring of music and the way it is mapped, especially between the length of a note and the length of a slider. A player's interpretation only comes into play when he can decide without penalty the duration a tone should be held. In classical music for example, tenuto markings tell the player to hold the note for its "full value", and do not tell the player to hold for precisely x amount of beats, whereas in an osu! map, it tells the player to hold for precisely x beats, but there is no way to be precise except by having musical cues. Not mapping to the music (that is, ending in nothing) does not allow any form of precision and is punishable by slider 100s and even broken combos. With respect to held tones, the mapper doesn't say to the player "hold for as long as you can before the next object", but instead, he says "hold for x length, but I may or may not give you any musical cues."

At the very least, we're understanding each other's points. My argument is that just because a quarter beat before the next object has been the popular way to do it, it doesn't make it any less arbitrary and any more natural. If there is a way to accurately depict the length of a slider by beats in the music, it should be taken. If this requires the mapper to not use a slider, then that's the way it should be. In other words, only use a slider to represent a held tone if you can end it on a beat present in the music. Otherwise, reconsider general slider usage in the entire section or the entire map.
Endaris
Uh well.
Whether a sound warrants it to have a hold-sound with a dead sliderend is highly dependant on the individual case and I think we're indeed discussing on a level that adresses what the Code of Conduct calls "intersubjective issues".
Fact is, those sliders aren't a problem in terms of playability because as you mentioned, the slider accurately depicts for how long it has to be held. Unless there are random bpm-changes like in a rubato-section the sliderend will always be well in time and not disturb the flow of the music. Even though it ends "on nothing" it still ends "in time".
It's a different kind of approach that has its focus on other elements than yours. I think every mapper has to decide himself what is more important (to him) in individual cases:
a) an accurate expression of the soundfeeling through the active tapping and hold experience
b) sticking strictly to the present sound resources

I think b) is the more logic approach indeed as it is a very general concept that should be applied pretty much all the time but experience has shown (me at least) that an appropriate stylistic choice that ignores this concept can yield enough gain in expression to make up for the loss.
One should be able to provide good reasons to break with it but I hope that's common sense.
Monstrata
Regarding the slider-end discussion:

If you've ever played the piano, you'll often encounter notes that you have to hold and release. Same idea with a guitar strum, or just holding a note on a woodwind instrument. There is a clear beginning, but an unclear end, as the sound fades away rather than stopping. Mapping stuff like this to slider-ends fits pretty well because the release of the piano key, or the release of a held note when playing say a flute or clarinet, mimic the releasing of your mouse/keyboard key.

It's true that the game programs a hitsound to be played at the end of a slider, but slider-end hitsounding doesn't actually give feedback to the player. It's known as "passive" hitsounding because the hitsound feedback you get doesn't actually correspond with when you release on the slider-end or when your cursor touches the slider-end. The hitsound from slider-end will occur exactly when the slider is supposed to end. In that respect, the slider-end hitsound doesn't actually tell you if your timing is slightly early or late, just where its supposed to be.

Slider-end hitsounding is not strong enough of an argument to say that every slider-end should be mapped to something in the music. Rather, i think the release mechanic is quite different from the clicking mechanic, and should be allowed to be mapped to nothing. When you release a note on an instrument, you still perform an action, even if that action results in absence of a sound.
those
I guess the question is, how can you possibly choose the correct place to end the slider if the end of the held tone is unclear? Having to accept that the end is in an arbitrary place is an unfortunate conclusion.

Additionally, a map should cater to the greatest number of players possible. Hit sounding for Taiko converts, for example, requires the samples to use the right names. For mania, ends of sliders are counted towards play accuracy. I'm sure I'm not the only one unwilling to accept that this is a standard that the cannot reach, but from the looks of it, it's almost as if we don't care enough at all.
blissfulyoshi

Desperate-kun wrote:

Effective Slider Velocity: Equals Base Slider Velocity of the difficulty multiplied with the current inherited point.
Isn't the use of the word effective here a bit misleading? When using the word effective, I usually think of a property that is cross comparable across all mediums. Since actual SV, is a multiplier of BPM, I always judged effective slider velocity as the BPM * SV * inherited timing section multiplier. If it is just SV * inherited timing section multiplier, then I still just call that SV, since you can never judge the actual sv, off the base SV alone.
Okoratu
The problem with that was that people think of SV as the base setting in the editor. We just used an additional word for it to avoid confusion with this and to get people to read the definition this is talking about.

If you think effective is misleading, what would be less misleading given the concern we have using just SV for it.

As for those's concern i still think having a guideline that captures the most common uses for these into sth "that should be done 99% of the time when handling these unless you have a really good reason to do otherwise" would solve the problem of it being arbitrary. As in: if we define how to handle these sliders unless you have a good reason to not handle them like this would give a lot of people a good basis to work with. Sliderends are and as far as i know will stay lenient in terms of hitwindows or even the requirement to release a button so standardising their length while allowing other lengths provided there is exhaustive explanation for it

Also maps are designed for standard and for nomod playing, catering to convert players should not really be any objective for mapping standard due to how different the gamemodes are. For example mania converts wont ever have notes during LNs because that mechanic is completely disallowed, taiko converts are made based on hitsounding and most taiko maps arent made around consistent hitsounding but more for consistent patterning while layering instruments in the song which would sound pretty weird considering default hitsounds in standard. Most lower difficulty converts for either mode arent even really working for proper lower difficulties in these two modes (i heard catch works the best among those 3) so all in all while catering to the biggest audience possible would be cool i dont think converts should be considered for the rankability of an osu! Mode beatmap
phaZ

those wrote:

I guess the question is, how can you possibly choose the correct place to end the slider if the end of the held tone is unclear? Having to accept that the end is in an arbitrary place is an unfortunate conclusion.
thats like making a rule how to map music in generall. it feels like your dictating how a map has to be like.
if all mapping would be done automatically by a programm that would be something to think about but in my opinon that really should be open for eachs own interpretation of the song "how long" would fit, if you see the problem there.

sry if im leading this off-topic..
BounceBabe
Alright here I go: I'd like to propose a standard rule in regards to adding two additional difficulties with fixed names for a balanced mapset spread that MAY be included in a mapset. I will analyse, evaluate and provide an alternative solution to the current star rating and difficulty naming for an even mapset spread. I'd also like to discuss their characteristics that will be provided as a guideline for mapping each difficulty. Furthermore, I want to suggest having a fixed set of difficulties as base for this game that have to be playable by average players AND experienced ones.

These are the current and commonly chosen difficulty names: Easy - Normal - Hard - Insane - Extra
These are my suggestion for an even mapset to provide easier to understand and reasonable difficulty names: Easy - Normal - Intermediate/Medium - Hard - Advanced - Insane - Extra

Of what is currently suggested as "Advanced" should be a standard allowed difficulty that is called "Medium" instead. First of all, it would fit to the rest of the difficulty names that already exist. Advanced is commonly used in relation to Beginner - Intermediate and then Advanced difficulty names. Hence, it's rated higher than an "Intermediate/Medium". The option of using Advanced would come after Intermediate which could be interpreted as Medium, whereas Advanced can be interpreted as Hard.

Furthermore I'd like to have a discussion about strict rules regarding the built of each difficulty that informs mappers how they must look like and which mapping characteristics it may include. This includes the allowed star rating that has to be used for each difficulty.

RC wrote:

The difficulties in the mapset must be in a consecutive order. Easy or Normal can be skipped if the gap in the star rating spread allows it. The order can be seen in the chart below. If your mapset has two difficulties, one of them cannot be an Insane or Expert. The lowest difficulty must be below 2.0 stars. The difficulty spread is determined by the map's star rating. A map falls under a certain difficulty when having a specific star rating:
Below 1.50: Easy
1.50-2.25: Normal
2.25-3.75: Hard
3.75-5.25: Insane
Above 5.25: Expert
Source: https://osu.ppy.sh/wiki/Ranking_Criteria#Mapset

Star rating gaps between each difficulty:
E - N: 0.75
N - H: 1.5
H - I: 1.5

Introducing one new difficulty between Normal - Hard will erase the 1.5 star gap and even out the star ratings from Easy - Hard but it will leave the gap between Hard - Insane. Including just one completely new difficulties for a standard mapset would mean having to adjust the star rating between Normal - Medium, Medium - Hard AND Hard - Insane by 0.75 or 1 stars to even the star spread. By modifying this already existing rule and applying my suggestion according to the ratings for just one difficulty between Normal and Hard, the star rating will be as followed:

Below 1.50: Easy
1.50-2.25: Normal
2.25-3 : Medium
3-3.75: Hard
3.75-5.25: Insane
Above 5.25: Expert

The maximum star rating for each difficulty would gradually increase by 0.75 stars without the Advanced difficulty that fills the gap between Hard and Insane. 0.75 stars seems rather low compared to how big the gap is between Hard - Insane. With another difficulty between Hard and Insane, the star rating would have to be modified in order to provide an evenly calculated mapset spread. Adding an Advanced difficulty for the gap between Hard and Insane would be reasonable because it has been included in a couple of mapsets I've seen, just in a wrong way.

Lately I've seen a couple of mapsets that had a "Light Insane" included in the spread. I'd like to point out why "Light Insane" does not suit as a difficulty name and suggest an alternative to use.

First of all, "Light Insane" would make mappers justify having a "Light" Easy, Normal, Hard, Insane, Extra. Which is nonsense. Instead, I'd like to propose to have a completely new difficulty introduced that fills the gap between Hard and Insane with an even star rating as listed above, and also related to the other already existing names without causing confusion. This will give the mappers a justified name that they can use 100%.

The general mapping characteristics, this excluded various mapping styles and difficulty settings for Hard, Insane and Extra are;
Hard: consistent, spacing, small streams and small jumps.
Insane: more vividly used spacing inconsistencies, longer streams and farther jumps.
Extra: extraordinary jumps, intense and long streams and also reasonable spacing inconsistencies that are comprehensible enough for gameplay.

Some analytics: A "Light Insane" would be a mixture between Hard and Insane. This means that a "Light Insane" should consist of jumps, streams and spacing inconsistencies. The spread would be Easy - Normal - Medium - Hard - "Light Insane" - Insane - Extra. This makes the mapset spread uneven, as it will make Hard the middle piece of the mapset spread, while Medium should serve as this middle piece if the suggestion would be applied. The gap between Medium and Insane would be filled with a Hard. The gap between Hard and Extra already is Insane. Given that, if there would be a "Light Insane" allowed as difficulty, it would mean that there has to be a difficulty added between EACH other already existing difficulty. This would make a mapset spread consisting of Easy - Normal - Hard - Light Insane - Insane - Extra, extremely uneven, since the harder difficulties Hard - Light Insane - Insane - Extra would outweigh the Easy and Normal by far.

I do propose to forbid naming a difficulty between Hard and Insane "Light Insane" in the future and introducing a new rule for the following reasons, in addition to the analysis above that add a fixed naming policy for a difficulty that is between Hard and Insane:

  1. Light Insane would serve as a difficulty that i between Hard and Insane. It's not a difficulty that is close to Insane but far from Hard, right? Otherwise it would be "Hard-Insane". This makes "Light" unjustified.
  2. "Light Insane" does not make sense as it's own difficulty because the mapping characteristics would vary only a tiny bit from Hard to Insane and the preferred mapping characteristics used, like the name says, would be from Hard. Which again, makes a "Light Insane" as gap filler between Hard and Insane not justified.
  3. The star rating and mapset spread would be uneven once a Medium difficulty is added. There would have to be a difficulty added that fills the gap between Hard and Insane. But a "Light Insane" will outweigh the spread, because see point 1.
  4. Additionally, adding too many gap filling difficulties would make the gaps between the star ratings smaller and smaller each time another difficulty gets added. With too many added, the mapset spread will only have minimal differences that are hardly discernible.
Introducing an Advanced difficulty in addition to the Medium, would mean to modify and adjust the star rating again. This would make the spread even and make the star rating as followed:

Below 1.50: Easy
1.50-2.25: Normal
2.25-3 : Medium
3-3.75: Hard
3.75-4.5: Advanced
4.5-5.25: Insane
Above 5.25: Expert

Since the rules are not set yet and the purpose of this thread is to develop new rules that will be applied in the future, this spread would be perfectly reasonable and easy to follow for anyone. It will definitely add a change to the already existing Insanes as the star rating would have to be harshly modified in order to grant an even spread, but it would be comprehensible enough for everyone to understand.

I also would like to support my reasons with the fact that Easy - Insane should be playable for an average player, who would be slowly increasing their knowledge of gameplay and skill with each difficulty, while Extra + is for very experienced players above the average. The base game (Easy - Insane difficulties) HAS to be playable for everyone in order for the game to be balanced and not be dominated by experienced players. Thus, lowering the minimum star rating for Insane is justified. An even spread will also provide a gradual increase of knowledge about the gameplay and help the player to gain more experience with each difficulty successfully passed.

There already is another suggestion of adding Extreme and Ultra to the existing Extra as additional difficulty increase. When agreeing to my reason that Easy - Insane HAS to be playable for the average player, anything above Insane should have an according rating rule as well. I do propose to adjust the star rating for this as well, in order for it not to get out of hand so that mappers have a guideline/rule they can follow for naming their difficulties.

Any suggestion mentioned can be discussed and I'm willing to alter my suggestion accordingly to the majority of matching suggestions provided. To me, the suggestions mentioned are perfectly reasonable, though.

I do sincerely hope to be able to discuss and elaborate this further with upcoming posts that follow in order for this community to have a new, positive and reasonable change in regards to mapping, mapset spread and star rating. Thanks for reading.
Bonsai
holy moly hey there BounceBabe

This post exists to remind Oko to replace every instance of the word 'repeat' (in relation with sliders doing the Cha Cha Cha) with 'reverse'.
show more
Please sign in to reply.

New reply