forum

[Proposal] Catch the Beat ruleset draft (General)

posted
Total Posts
74
show more
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