1. osu! forums
  2. osu!
  3. Development
  4. Ranking Criteria
  5. Finalized/Denied Amendments
show more
posted

JBHyperion wrote:

Suggestions on an alternative wording? "Timing jump" was just as vague :/
Maybe "Borderline Hyperdash" or how about "Near Hyperdash". As Riari said, "Borderline Dash" sounds like a jump where the distance is far apart enough you almost need to dash but actually don't.
posted

Zak wrote:

The only 2 things I really wish to respond to are the argument for "Impossible maps" and difficulty names.

First off, impossible maps should and likely never be rankable, nothing in any game should be 100% unachievable, that's just silly, and I'm fairly certain the game developers have no desire to allow anything that no one is able to do. This does not mean you can't make extremely hard maps, but you're going to have one hell of a rough time getting them ranked, but should you choose try, then good luck.
Impossible Maps are just a Phares im using, I don't want Maps that are literally impossible to be ranked. Also how come maps that are Extremely hard, are of greater challenge to get ranked. Is it due to people just not mapping them correctly?

Zak wrote:

And no, we do not need to be more flexible with difficulty names, as many people took advantage of it in the past to make difficulty names that made literally no sense for the sole purpose of being funny, not creativity, you still have plenty of freedom with the names, so there's not really any real creativity being disallowed.
True truueee.
posted

JBHyperion wrote:

Odoru is a convert map. It is not a specific. It is not intended to be played in this game mode. Further discussion using this as an example is likely to misguide us. CtB criteria should be based on what we want to see in specifics, not converts
-I'm not sure how to put this but, i guess what I'm trying to say is even though it's a convert map, I would still like the CTB Ranking Criteria to be able to follow the spacing rules and difficulty jumps of Odoru not necessarily meaning i want to follow the rules of the osu-standard ranking critieria. I'm using "Odoru Mizushibuki"-Death Dance as an example of Difficulty. because the spacing of notes CS:size and Slider speed is what makes Odoru hard. maybe a better example would be Blastix by: CLSW



JBHyperion wrote:

Deliberately breaking something to prove how broken it is isn't a solution. You wouldn't beat someone up to demonstrate that violence is wrong. Also, as has been mentioned the Star Rating system is flawed and easily manipulated with the right knowledge. Prevention is better than cure here.
Good point xD
Do you think we can change that in the future perhaps?!


JBHyperion wrote:

ZiRoX wrote:

Slider jumps are based on a gameplay element that doesn't exist in CtB: slider leniency. In standard you don't have to release a slider perfectly in time, while in CtB you're required to catch that sliderend as not doing so will break the combo.
-Is this unrankable then im not sure.

It's irrelevant, as ZiRoX explained. Sliderjumps do not exist in CtB, so discussing their rankability is a moot point.
Ok I've never used slider jumps. RIP Slider Jumps :(
posted

xi-False wrote:

Impossible Maps are just a Phares im using, I don't want Maps that are literally impossible to be ranked. Also how come maps that are Extremely hard, are of greater challenge to get ranked. Is it due to people just not mapping them correctly?
That is part of the reason, another is the fact we just don't have anything CLOSE to the hardest we can actually have in ranked yet at all and several people wish for us to just jump straight to things that would end up being like 8+*, and that's just not the right way to go about it, we should make some sort of progression going further and further up as the community grows and evolves more, which also leads to another problem: the size of the community. We have so few modders/mappers as it is and even fewer that are actually qualified enough to actually deem those maps as ready and no one wants to just rank some 8* map just because only a few people went through and said it was acceptable, you generally want a lot more mods on any map and with something hard you usually want more than normal simply because you want to make sure it retains it's difficulty while still being fun instead of well... being difficult just to be difficult.
posted
Something that came to my mind while looking for skinning sets, taken from https://osu.ppy.sh/wiki/Skinning_Catch_the_Beat and https://docs.google.com/spreadsheets/d/ ... 1815373882 is the usage of the element "lighting.png", which appears on kiai times at the bottom of the screen following the path that the fruits would take while dropping.

That element also seems to be part of the skinnable elements of the catcher, but its usage is optional. A guideline in the Skinning section about this topic wouldn't hurt:

  1. Custom catchers can additionally include the element "lighting.png" to complete the skin set. This element is however optional to add and should only be used in non-osu! beatmaps.
Wording can be improved though :p

Also, self-reminder for the next meeting: I was told the definition of "borderline dashes" can be improved since it's currently not 100% clear.
posted
Would like to see as a rule :

Using a shitload of spinners in a short period of time in order to manipulate spinner density should be banned from rankings as it consumes a big amount of ressources (memory and cpu). (You know what I mean try to rephrase this one :p)

-------------

Also there's a global rule wich make no sense in CtB:

A maximum of three slider velocities should be used (including 1x). For example, you could have a single map using 0.6x, 0.8x, and 1x; or 0.75x, 1x, and 1.5x; etc. If more than three slider velocities are used, then they should make sense and be intuitive. If slider velocity changes are able to be merged (e.g. close values like 0.8x and 0.7x) while still flowing/working correctly, then they should be.

In CtB you can get 14 different slider speed just by angling your sliders with only one SV used all map long. Actually this guideline should be std specific so it probably deserves another topic.

-------------

About the amount of fruits in the plate:

I remember the case with sliders having a big amount of returns. Maybe in the guideline description you can explain that those sliders should be cut to create a new combo within the slider itself. This will not change the result in term of gameplay. Another option should be to remove them and map something else because they are ugly and uninterresting to play but heh.
posted
We talked about the spinners first and since there is a global rule which forbids two hitobject at the same time there is no need to include it here as well. As for the consecutive spinners, well, it won't hurt including it as it makes no sense since even the plate won't be empty by dividing it.

About the slider velocity rule, the global part of the RC is on the way with the changes as well (I hope). There is no need to worry about it now, just ignore it.

As for the sliders, maybe we can make a rule "Do not have more than 4 repeat on a slider, because its not interesting to play and generates repetitive movement."
posted

Kurokami wrote:

As for the sliders, maybe we can make a rule "Do not have more than 4 repeat on a slider, because its not interesting to play and generates repetitive movement."
I disagree with such a rule. Don't forget kicksliders are an important element that can be used in difficulties probably from Platter on.
posted
The main idea for the slider returns is about avoiding too much fruits in the plate (more than making nice patterns). For example you have a 15 returns slider (16 fruits in total) but the guideline limits you to 8 fruits in the plate you should create instead 2 sliders of 7 returns with new combos, one on top of the other one, the only difference is that the plate will empty midway to fit with the guideline.

It's more a mapping technique but it could be useful to new mappers to have a tip on how to easily get a rankable slider without affecting the gameplay, and at the same time save explanations by modders.

Could be worded to something like :
[...] If you feel to map a slider having more than the difficulty fruit limit in the plate due to a huge amount of returns, you should split it to tiny sliders having an allowed amount of fruits and new combos in order to empty the plate during the slider.

Kurokami wrote:

We talked about the spinners first and since there is a global rule which forbids two hitobject at the same time there is no need to include it here as well. As for the consecutive spinners, well, it won't hurt including it as it makes no sense since even the plate won't be empty by dividing it.
Yes, I was talking about consecutive spinners. Hitobjects overlap are autobanned by the general rule indeed.
posted
@Deif I did not talk about kick sliders. That is for 1/2, 1/1s. Anything above should be fine since there is no movement at all.
posted
Okay, time to do a rundown of our current revision.

Deif wrote:

Gameplay

  1. Fruit: A large object represented by a hitcircle, slider head, tail or repeat.
  2. Drop: A medium-sized object represented by a slider tick.
  3. Droplet: A small object representing a slider body. Missing these will reduce your accuracy, but unlike the above, will not result in a combo break.
  4. Banana: An object found during spinners. These award bonus points, but do not contribute to accuracy and are not required to obtain max combo.
  5. Jump: A spacing between two objects that requires the use of dash to catch both.
  6. Hyperjump: A more exaggerated spacing which cannot be caught by normal dashing. During play, hyperdash will be triggered between the two objects, characterised by a coloured outline on the first object.
  7. Borderline dash: A spacing between two objects which requires dash between the opposing borders of the two objects to catch both. The spacing is not quite large enough to create a hyperjump.
  8. Trigger distance: The minimum spacing between two objects at which a hyperdash is generated between them.
[/notice]
What about the Wiggle sliders that kick back and forth? Not sure if that's important enough to mention, but it's always there so why not.

Deif wrote:

Rules

  1. Your map must theoretically be possible to SS. This means it must be possible to catch absolutely all fruits, including droplets.
  2. Borderline dashes must not be used in direct conjunction with hyperjumps. This is because such patterns require especially precise movement and force an unreasonable restriction on accuracy required to catch them.
  3. Each map must use at least two different combo colors which must not blend in with the map's background/storyboard/video. This is so hit objects are always visible to the player.
What happened to our rule of spinners being too close to regular fruits? I also propose that Guidelines and Rules be merged into one category. they are both the same in any case.

Deif wrote:

Skinning



Rules

  1. Custom catchers mustbe included in both v1 and v2 skin format. This is to ensure correct display on all skins. The required filenames are "fruit-ryuuta.png" (v1), "fruit-catcher-idle.png", "fruit-catcher-kiai.png" and "fruit-catcher-fail.png" (v2).
  2. Custom fruits must include all necessary elements and be colored in a scale of grey colors. This is to ensure that your images are clearly defined and of acceptable quality. The needed elements can be found in the osu! wiki https://osu.ppy.sh/wiki/Skinning_Catch_the_Beat#Fruits. Additionally, it is recommendable to use transparent elements for the overlays.

See the draft of the difficulty-specific ruleset here: https://osu.ppy.sh/forum/t/435598
I additionally think that fruit skin elements should be regulated in a way that they don't "lie" about their hitbox (too big or too small) as I have seen a few skins that have fruits bigger than the actual hit boxes, and it can be frustrating to the player. also, somewhere in here, there's a typo of "mustbe"

Drafura wrote:

Would like to see as a rule :

Using a shitload of spinners in a short period of time in order to manipulate spinner density should be banned from rankings as it consumes a big amount of ressources (memory and cpu). (You know what I mean try to rephrase this one :p)
Agreed, as well as the spamming of other mapping elements that provide "Free combos" ... Not like it'll happen, but it's good to close ends.

Drafura wrote:

Also there's a global rule wich make no sense in CtB:

A maximum of three slider velocities should be used (including 1x). For example, you could have a single map using 0.6x, 0.8x, and 1x; or 0.75x, 1x, and 1.5x; etc. If more than three slider velocities are used, then they should make sense and be intuitive. If slider velocity changes are able to be merged (e.g. close values like 0.8x and 0.7x) while still flowing/working correctly, then they should be.
I can agree with this, too. I also want to point out t/245521 so we can expand on this and create a slider speed limit so we don't outrun our catcher with sliders.
posted

Kitokofox wrote:

What happened to our rule of spinners being too close to regular fruits? I also propose that Guidelines and Rules be merged into one category. they are both the same in any case.
This is incorporated in the difficulty-specific ranking criteria - t/435598 - Basically each difficulty will now have it's own "rule" on how much time must be left between spinners and objects.

Rules must not be broken under any circumstance. Guidelines may be broken under certain conditions. I feel it's very important that we keep this distinction of what should "never be done", and what "may work in certain situations, but should be avoided generally unless you really know what you're doing (and have good reason to do so)".
posted

Kitokofox wrote:

Okay, time to do a rundown of our current revision.

Drafura wrote:

Also there's a global rule wich make no sense in CtB:

A maximum of three slider velocities should be used (including 1x). For example, you could have a single map using 0.6x, 0.8x, and 1x; or 0.75x, 1x, and 1.5x; etc. If more than three slider velocities are used, then they should make sense and be intuitive. If slider velocity changes are able to be merged (e.g. close values like 0.8x and 0.7x) while still flowing/working correctly, then they should be.
I can agree with this, too. I also want to point out https://osu.ppy.sh/forum/t/245521 so we can expand on this and create a slider speed limit so we don't outrun our catcher with sliders.

Kurokami wrote:

About the slider velocity rule, the global part of the RC is on the way with the changes as well (I hope). There is no need to worry about it now, just ignore it.
posted

Kitokofox wrote:

create a slider speed limit so we don't outrun our catcher with sliders.
I don't think SV limit is a good thing. Technicaly you can put any SV and map a slider without any movement. However the way the sliders are mapped is the point wich needs limits (using droplet hyperdashes for example as discussed before).

Adding a limit to SV is too restrictive in term of map design and mapping creativity. I experimented many times working with slider shapes in CtB and when you want to get more control on how droplets are generated having a high SV helps a lot. Even making the same droplet shape generation for two similar sliders is pretty hard at low SV.

I think there's a lot of potentially fun patterns to make with high SV wich have never been mapped before.
posted
Thank you for your feedback guys. We'll check every suggestion and deliberate in a short period of time if the changes are viable or not.
posted
After the last meeting with the rest of the members, these are the changes that were took into consideration and were approved. Check out the OP for them:
  1. Borderline Dashes were renamed to "Edge Dashes" and the definition was reworked.
  2. Added a rule about the allowed size of the skinning elements.
  3. Added a guideline to have additional skin elements added.

Most of the other suggestions belonged to the general ranking criteria, which affects all game modes whatsoever. There's no need to add them to the Catch the Beat ruleset to avoid double information.

As a reminder: This will be the last 2-week period to recieve feedback from the community. After locking the thread on the 29th May at 23:59 UTC the ruleset will be discussed one more time with the last recieved comments and ammended by the osu! staff afterwards.
posted
Alright, the time is up! Thanks everybody for the effort in this proposal. I hope to see it amended soon, but we need to wait until the high staff approves it.

As there was no further feedback, it's safe to proceed to the next step towards the final approval!
posted
In General -> Rules
"Borderline dashes must not be used in direct conjunction with hyperjumps. This is because such patterns require especially precise movement and force an unreasonable restriction on accuracy required to catch them."
It's Edge Dash now :D

"Hyperdashes should not be used when the destination of the hyperjump is located near the left or right border of the play field. This creates an uncomfortable movement as the catcher is forcibly stopped upon reaching the border of the playfield. Try to leave at least 16 osupixels of space between the end point of the hyperjump and the border of the play field, respectively at x:16 or x:496 at most."
This kind of stream is okay then?
posted

CelegaS wrote:

In General -> Rules
"Borderline dashes must not be used in direct conjunction with hyperjumps. This is because such patterns require especially precise movement and force an unreasonable restriction on accuracy required to catch them."
It's Edge Dash now :D
Nice catch! It's fixed now.

CelegaS wrote:

"Hyperdashes should not be used when the destination of the hyperjump is located near the left or right border of the play field. This creates an uncomfortable movement as the catcher is forcibly stopped upon reaching the border of the playfield. Try to leave at least 16 osupixels of space between the end point of the hyperjump and the border of the play field, respectively at x:16 or x:496 at most."
This kind of stream is okay then?
That kind of stream is still okay. Since hyperdashes will lead the catcher to the middle point of the next note and there's no hyperdash or sharp movement in there, it should be safe enough to play.
posted
After reviewing this set of rules everything looks good to go! Mind you the catcher skin v2 rules will have to be amended once animation support is enabled. More file names will be required but that is only if you want your catcher animated, so that can be amended at a later time. Looks good I support this proposal as well.
show more
Please sign in to reply.