forum

[Proposal] Catch the Beat ruleset draft (General)

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