forum

[Proposal] Catch the Beat ruleset draft (General)

posted
Total Posts
74
show more
JBHyperion

Riari wrote:

Deif wrote:

  1. Redefinition of timing jump to borderline dash
Can we reword this? a borderline dash makes it seem like a note you'd find in a cup or or a salad that you'd dash for when you don't need to in that situation.

Suggestions on an alternative wording? "Timing jump" was just as vague :/

BoberOfDarkness wrote:

I can make overdose for dango but nobody likes CS8 :^)

Nobody likes CS8 because it's inherently unrankable, as it requires editing of the .osu to achieve. Any alterations to this rule are not up for debate, as made clear by the game developers.

xi-False wrote:

ZiRoX wrote:

There's no limit to how hard a map can be, as long as the song is calling for it. Anyone with common sense wouldn't make an Overdose for Dango Daikazoku, for example.
-Im not sure if you've played Odoru but, the spacing on that beatmap is Ridiculously hard. no one has FCed it yet in the CTB Community. but i know for a fact you can get an SS on it. im saying For Example, if i were to map "Odoru Mizushibuki"-Death Dance as it is right now, will it be rankable still?, with most of the jump being almost frame perfect.

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


ZiRoX wrote:

1/12 jumps are not unrankable by definition. I don't see a problem with that as long as they're used fine. Regarding Star Rating that's something we can't do anything about.
-true we cant change the star rating ourselves but in away we can. I believe if we were to allow High Star maps like 15 or 20 to be ranked. that will catch the attention of the people in charge of the Star system and maybe make them feel obligated to change it.

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.


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.
Zak
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.

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.
Sorceress

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.
xi-False

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.
xi-False

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 :(
Zak

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.
Topic Starter
Deif
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.
Drafura
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.
Kurokami
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."
Topic Starter
Deif

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.
Drafura
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.
Kurokami
@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.
Kitokofox
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.
JBHyperion

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)".
Kurokami

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.
Drafura

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.
Kurokami
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.
Topic Starter
Deif
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.
Topic Starter
Deif
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!
CelegaS
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?
Topic Starter
Deif

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.
ztrot
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.
BoberOfDarkness

ztrot wrote:

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.

I support this too but who cares
Haskorion
Why should animation support not be enabled?

They have been animatable since implementation.
Just check one of OsuMe65's recent skins where he has animated catchers: t/399690

Paste them into a beatmap and you will see that the animation plays.

EDIT: Or do you mean like beatmap side animation support as in being able to set a framerate?
Zak
I'm pretty sure there isn't any real animation supported for catchers, just being able to have 2 different catcher images for kiai time and failing, not actual animation.
Haskorion
This just means you didn't even try to animate the catcher.
The simplest way to check if something can be animated is just to temporarily add "-0" to any image. If it gets used it should be animatable.

I even made a video:

http://puu.sh/pja0J.mp4

As you can see the simple catcher changes colours in all states.
ztrot
yes but there will be more states added, if support and assets are created of course.
Loctav
As of today, this set of rules counts as amended. As of the big amount of changes, only beatmaps submitted past this amendment are going under this new set of rules. Every beatmap submitted prior this amendment will get treated and handled under the previous set of rules.

This legacy regulation expires in 6 months from today on. Everything that is not bubbled within the next 6 months will also be treated under the new ruleset then.

Adjustments to the ruleset, when we get the new catcher animations, can be done when we have them.
Monstrata
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.

---

fruit-drop-overlay.png is this element necessary? It's included in the fruits table on the wiki, but the additional notes say "If image is included, the scoreboard will not use it". Which kinda implies that the image doesn't need to be used. (Using "If" implies theres an option not to use it).

Also: Additionally, it is recommendable to use transparent elements for the overlays.

Move that to guideline. Anything that is "recommendable" isn't an objective rule. You'll confuse people into thinking transparent elements are necessary because its been placed under a "ruleset" instead of a "guideline".
Kurokami
fruit-drop-overlay can only be seen in-game. The scoreboard is using the fruit-drop.png. Yes, its necessary because if you happen to use a custom shape, the one from the standard skin will overlap it which looks really ugly.

Uhm, Guidelines are just as strong as Rules but they might be broken under special circumstances. We used "recommendable" because to use different color you need to know more than just basic skinning as using a wrong colored one might end up just being ugly again and hiding the glow of the Hypers. Which is obviously not recommended at all.

Also, this is already finalized. :c
Monstrata
Hmm, then the wiki should be reworded because right now it's giving an option not to include fruit-drop-overlay.

Guidelines aren't as strong as rules though. Ideally, they should be equal, and broken under special circumstances, but we know that's not realistic because of how people see guidelines. It's better to avoid confusion, but I guess keeping the "recommendable" is alright.

Also, finalized rules can still be amended, that's the purpose of this entire forum anyways xD. I wasn't looking to change anything tho honestly, just some wording on the wiki.
Kurokami

Monstrata wrote:

Also, finalized rules can still be amended, that's the purpose of this entire forum anyways xD. I wasn't looking to change anything tho honestly, just some wording on the wiki.
True, and that was not the point of my sentence. /o/

Hm, I did not have problem with that wording. That sentence means if you happen to include it, it won't be visible on the scoreboard just on the playfield, at least to me. But that might because I have experience with skinning.

Well, we made the quidelines in a way that it could only be broken in special cases. Which means, if you making your map in casual way, you should have no problem following it. It basically guides you into the right direction while you are following them. I personally think making them transparent is the easiest way to skin your map.

Well, for now I think the current ruleset is good. Considering that we had none in the past. I will try to experiment with other solutions until the next amendment.
Monstrata

Kurokami wrote:

That sentence means if you happen to include it, it won't be visible on the scoreboard just on the playfield, at least to me.
That implies it's not mandatory to include fruit-drop-overlay. If you can happen to include it, you can happen not to include it. Either clarify that fruit-drop-overlay.png is not a necessary element, or reword the wiki to better reflect that it's necessary, and you can't just "happen to use it/not use it".

I don't see anything that needs to be experimented on lol. You guys just didn't word the wiki in a way that fully supports the RC. Maybe the wiki hasn't been updated yet since the RC rule was finalized, and if so, then this is a good opportunity to make a quick change.
Haskorion
fruit-drop-overlay.png should not be optional. The default skin uses a transparent image and newer skins start to use it more frequently. To ensure correct display when playing with a custom skin the overlay is needed.
On a side note: the tables are originally based on my list with skinnable files when deadbeat asked for my opinion on how to restructure the skinning wiki pages. At that time it was a rather empty list, but was something he also had in mind.
Since I wasn't really active on the wiki at that point, a lot of smaller mistakes were made by others when copying the facts from my list and may have been misinterpreted.
Kurokami
I have a feeling that you both did not understand what am I saying. :c The RC of osu!catch clearly says that you must include all necessary element of a custom fruit which means you must add the overlays too in case of custom skin. Which means if your custom skin contains custom droplet you must add it's overlay as well. This is for beatmap sets.

On contrary none of these custom fruits will be visible on the scoreboard because that is already based on the players own skin and not using the custom one from the beatmap folder anyway. The skinnable file list is not wrong either because if your own skin has a fruit-drop-overlay that won't be used on the scoreboard because the fruit-drop do its job.
Monstrata
I see, thanks Haskorion. Seems the wiki has been edited now to fix this inconsistency. It was mainly just a concern I had when qualifying : https://osu.ppy.sh/s/461945 due to the custom skin.

@Kurokami - You've missed the point xP. But whatever, it's resolved~
Please sign in to reply.

New reply