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

As part of the Ranking Criteria's reconstruction, the United Beat-Knights of Ranking Criteria have been discussing subsections (such as timing, metadata, skinning, etc.) with the experts of each field. I'm here to announce what kind of rules and guidelines we agreed upon for the Storyboarding subsection in this draft. Notice this is not the final result, as we need the feedback of the community first before getting it officially bumped into the wiki!

Frequently Asked Questions

(read this in all cases before posting)
  1. Is it necessary to read the entire draft before commenting or asking questions?
    -> Yes, else you may complain about/mention things that are not related to this draft or are actually already present here.
  2. Is this the entire new Ranking Criteria? I feel like this is missing a lot of things...
    -> This is not the entire Ranking Criteria. This draft aims to be the rules and guidelines that end up under the Storyboarding header.

Before posting, please think through if what you want to add belongs in any game-mode specific drafts of the Ranking Criteria or should be part of another subsection of the general Ranking Criteria. Thanks!

The proposal starts with the glossary.

Glossary



Common terms


Storyboarding
  1. Storyboard Image: This refers to the image in the song folder that the storyboard uses.
  2. Sprite: An object in a storyboard representing an image, or a series of images.
  3. Time: A millisecond representation of a timeline position. This representation is seen within the design section of the editor.
  4. Command: These affect a sprite in various ways. Some examples of commands are Move, Scale, Fade and Rotate. Each of these have a starttime and endtime.
  5. Axis Specific Command: A command which only applies to one specified spatial axis, for example MoveX and MoveY.
  6. Active: From the first start time to the last end time of commands in the object.
  7. Rendered: Often referring to an on-screen sprite that is not completely faded out.
  8. osu!pixel: The smallest dimension of the design tab. Seen in the top right corner of the editor screen, e.g. x: 104; y: 88.

Storyboarding


Rules

All rules are exactly that: RULES. They are NOT guidelines and may NOT be broken under ANY circumstance.

  1. Storyboard images must not exceed a width of 1920 pixels and a height of 1200 pixels. The storyboard editor works based on osu!pixels with an internal maximum width of 854 pixels and a height of 480 pixels. If you are using an image bigger than that, you may need to scale accordingly.
  2. Maps that contain repetitive strobes, pulsing images, or rapid changes in contrast, brightness or color in the storyboard must use an epilepsy warning. If the warning interferes with gameplay, audio lead-in must be made longer. Strobing effects at 3 Hz and below are unlikely to cause concern. When in doubt, add the warning and confirm its necessity during the modding process.
  3. The beatmap must not throw parsing errors upon loading. This means the parser cannot read part of the storyboard instructions.


Guidelines

Guidelines may be violated under exceptional circumstances. These exceptional circumstances must be warranted by an exhaustive explanation as of why the guideline has been violated and why not violating it will interfere with the overall quality of the creation.

  1. Consider leaving a one pixel border of transparency around storyboard images of rotated sprites for interpolation to work properly. osu! does not utilize anti-aliasing around images, and as such this becomes very noticeable if the edges are visible and the sprite is rotated.
  2. Avoid any noticeable performance issues as much as possible. Even being optimized, having consistent frame rates is crucial for the playing experience of the map. Test play the map during the modding process to confirm this.
  3. Refrain from usage of storyboard sound samples in ways that are easily confused with hitsounds during gameplay. This goes against the concept of audible feedback, as the sound samples will play independently of any input from the player.
  4. Avoid illogical, conflicting and obsolete commands. Commands of the same type whose intervals overlap, have their ending time before their start time or are bound to impossible to reach triggers, are either not working as intended or obsolete, and should either be removed or adjusted to work as intended.
  5. Widescreen support should be turned on if the mapset contains a widescreen storyboard. Alternatively, if the storyboard is designed for 4:3 resolutions, widescreen support should be turned off. This setting will not affect anything within the beatmap without a storyboard being present.
  6. Make sure the storyboard is optimized as much as possible, within practical means.
    1. Avoid having sprites, or the background of the map, completely visually obstructed while rendered. Fading these out when otherwise not visible is preferable for the sake of performance. To fade out the background of the map, turn the same background image into a sprite, with “Background” or “0” as second parameter, and fade accordingly.
    2. Avoid sprites being partially off-screen or visually obstructed for the entire time they are used. In these cases the respective parts of the images should be cut unless this is necessary for an effect within the storyboard.
    3. Avoid unnecessary transparency around storyboard images. For the sake of performance, images should be cropped as much as possible for their desired effects.
    4. Use loops for commands that repeat themselves many times, unless this goes against what is visually intended. Using the loop command will often reduce the line count considerably, which in turn reduces file size.
    5. Avoid using two axis specific commands when the same effect can be achieved with one regular command instead. Using one command instead of two will mean less overall file size.
    6. Use whichever image file format takes up the least file size whilst maintaining reasonable quality. Png format often takes up more file size for larger images due to the lossless compression method, unlike jpg.
    7. Avoid any duplicate image files. Having two instances of the exact same image adds unnecessary file size.
    8. Refrain from having multiple sprites active while not rendered. Active sprites will still process commands regardless of whether they are visible or not. Should this be the case for longer periods of time, instantiate new sprites instead, for when visibility is regained.
    9. When using many commands of the same type on a sprite, try leaving at least 16 ms between their start times. 60 commands per second is often more than enough for any sprite to make smooth transitions on an average setup. This is for the sake of reducing file size and loading times.
    10. Fade out sprites activated from triggers after usage. Triggers will activate from their first possible command and stay active until the end of the map, which is why fading these out when done is preferable.


Make sure to read the entire draft! It will be up to discussion for two weeks and close on the 17th of April!
posted
Hi,

As one of the United Beat-Knights who helped in revising the new storyboarding ruleset, I would like to share a few thoughts in our goals when it came to drafting a new set of rules for storyboarding.

The current ruleset for storyboarding is, to be frank, extremely outdated. Very little of it has changed over the years (and take it from me, the fossil here at osu!), yet storyboarding as a medium has evolved so heavily. When the original rules were proposed and made for storyboarding, they did not even imagine what could be possible today. Therefore, one main goal we wanted to achieve in the new storyboarding ruleset is the consideration of performance that's better reflective of what can be done now.

You may be looking at the draft and be wondering, for instance, where SB Load would be. We felt that this metric no longer accurately portrays the kinds of performance problems storyboards may encompass. For instance, a storyboard can render thousands of small 1x1 particles that produce an SB Load far below 5.0x, yet, with a density of commands being applied to them, can horrendously cause performance issues, particularly dropped frames and additional lag.

This is why we hope that these new guidelines can help promote optimization, good practices, and make disabling a storyboard due to lag a rarity if it all. :)

Thanks for reading, and I hope that the new ruleset will help encourage even more amazing storyboards in the near future.
posted
ok
posted
Storyboard images must not exceed a width of 1920 pixels and a height of 1200 pixels. The storyboard editor works based on osu! pixels with an internal maximum width of 854 pixels and a height of 480 pixels. If you are using an image bigger than that, you may need to scale accordingly.
So there's no dimension restriction anymore for vertical and horizontal scrolling images, as long as they're at range 1920xA and Bx1200?
Also, shouldn't there any guidelines or explaination regarding storyboard sounds sample? since there's a line on the bottom of .osb, unless it's not in use anymore
//Storyboard Sound Samples
posted

Mako Sakata wrote:

So there's no dimension restriction anymore for vertical and horizontal scrolling images, as long as they're at range 1920xA and Bx1200?
There's no reason to restict vertical and horizontal images in any way. Adding more restrictions wouldn't make sense as it would be unfair in comparison with other storyboard elements.

Mako Sakata wrote:

Also, shouldn't there any guidelines or explaination regarding storyboard sounds sample? since there's a line on the bottom of .osb, unless it's not in use anymore
//Storyboard Sound Samples
It's still in use, but the only relation to the storyboard here is that it's in the .osb file, so I don't believe it should be handled in the storyboarding section. And personally, I think that the current guideline regarding storyboard hitsounds is covering enough. Simply - Don't use it in a way it could make a confusing impression in the map. The current guideline could be reworded though, it's way too long and sounds quite rejective towards storyboard hitsounds.
posted
uhm
the whole thing about active sprites is quite shady for me

Active: From the first start time to the last end time of commands in the object. Triggers will activate from their first possible command and stay active until the end of the map, which is why fading these out when done is preferable.
I interpret this as "fade your triggers out bro". Shouldnt the second sentence be a guideline on its own? Is a bit misplaced in the glossary imo.

Refrain from having multiple sprites active while not rendered. Active sprites will still process commands regardless of whether they are visible or not. Having many active sprites faded out for longer periods of time may cause performance issues.
This took me a couple of minutes to understand in conjunction with the one mentioned previously because it boils down to "fade active things out but avoid doing so".
It could help the clarity to include a negative example or using a positive wording instead like "If you repeat an effect in your storyboard create new sprites each time in order to avoid the initial ones staying between the effects".
If I understood it correctly at least which im still unsure of.
posted

Endaris wrote:

This took me a couple of minutes to understand in conjunction with the one mentioned previously because it boils down to "fade active things out but avoid doing so".
It could help the clarity to include a negative example or using a positive wording instead like "If you repeat an effect in your storyboard create new sprites each time in order to avoid the initial ones staying between the effects".
If I understood it correctly at least which im still unsure of.
This is referring to off-screen objects and objects that are not visible but still have commands applied to them. Because the commands are still processed. Reading the glossary should make it clear.

The wording of Active in the glossary indeed contains some irrelevance and is a bit unclear.
posted
Define what an osu! pixel is, and be more stringent regarding epilepsy warning thresholds. I don't remember the exact interval off hand, but anything under 4hz strobing (4 strobes per second) is EXTREMELY unlikely to cause epileptic symptoms in photosensitive epileptics and shouldn't require a warning.
posted

Ephemeral wrote:

Define what an osu! pixel is, and be more stringent regarding epilepsy warning thresholds. I don't remember the exact interval off hand, but anything under 4hz strobing (4 strobes per second) is EXTREMELY unlikely to cause epileptic symptoms in photosensitive epileptics and shouldn't require a warning.
About the epilepsy warning, we might inform about the dangerous frequencies, but even just contrastive patterns and colour combinations can cause an epileptic seizure, so relying on strobing frequency is not always the best way.
posted
i think we have a definition for osu pixels lying around somewhere (i believe the term was supposed to debut in like the last 3 drafts but somehow wasn't necessary ever) + the definition of an osu pixel is actually like right in the rule so uh okay

as far as i've read into that whole epilepsy thing the really dangerous area starts at 10 hz strobes / flashing or just general color contrasting chaos on your screen
the things that supposedly trigger it aren't limited to one factor and vary widely from person to person and so do the lowest numbers that supposedly cause them so accurately defining the generally dangerous area is easier said than done

if you have any ideas how to accuratly draw a line where ~it's too much~, sure, though i think staying relatively vague in this case is safer for the aforementioned reasons
posted
yeh ok
posted
Changelog

  1. Removals:
    1. Glossary:
      1. Deleted the sentence "Triggers will activate from their first possible command and stay active until the end of the map, which is why fading these out when done is preferable." because it was causing more confusion than anything and semi-relevant
    2. Rules:
      1. replaced flashing colors with something more precise
    3. Guidelines:
      1. Removed the sentence "Having many active sprites faded out for longer periods of time may cause performance issues."
  2. Additions:
    1. Glossary:
      1. added osu!pixel: The smallest dimension of the design tab. Seen in the top right corner of the editor screen, e.g. x: 104; y: 88.
    2. Rules:
      1. "flashing colors" was replaced with "rapid changes in contrast, brightness or color"
      2. added the sentence "Strobing effects at 3hz and below are unlikely to cause concern."
    3. Guidelines:
      1. added Refrain from usage of storyboard sound samples in ways that are easily confused with hitsounds during gameplay. This goes against the concept of audible feedback, as the sound samples will play independently of any input from the player.
      2. replaced "Having many active sprites faded out for longer periods of time may cause performance issues." with "Should this be the case for longer periods of time, instantiate new sprites instead, for when visibility is regained."
      3. added Fade out sprites activated from triggers after usage. Triggers will activate from their first possible command and stay active until the end of the map, which is why fading these out when done is preferable.


We have discussed large scrolling images again but reached the consensus that keeping the limit up at 1920x1200 includes all practical uses
discussion time is 7 days as the changes to the draft aren't major in the slightest so yeah.
posted
Hello there~ yf_bmp asked me to take a look at this draft and I'd like to throw some of my opinions.

  1. At the very beginning, I think an additional rule should be added is "Widescreen Support should be turned on while using a widescreen storyboard." Though it's something we all know by default, I guess it'll be better if this stays in the RC.
  2. Another thing should stay in the Ranking Criteria is that there should be no broken or conflict commands in a storyboard. Because this could result in some technical problems in osu. Though in some occations this won't give big problems and osu! won't tell an error, this could destroy the original ideas and effects by the storyboarder.
  3. I don't know how to describe this one because of my poor english. ;w; In the first line of every sprite command, something like this:
    Sprite,Background,Centre,"xxx.png",320,240
    You should avoid using decimals on the axis of the sprite or it'll cause technical errors in osu.
  4. The next one is that "Avoid duplicate images", this mostly happen with the storyboards with split lyrics. Take this one as example.
    It can get optimized if the duplicated lyrics are processed.


That's all I can think of so far, hope it helps!
posted
we are going to consider the above post and then reopen
posted
Changelog

  1. Additions:

    1. Rules:

      1. The beatmap must not throw parsing errors upon loading. This means the parser cannot read part of the storyboard instructions.
    2. Guidelines:

      1. Avoid illogical, conflicting and obsolete commands. Commands of the same type whose intervals overlap, have their ending time before their start time or are bound to impossible to reach triggers, are either not working as intended or obsolete, and should either be removed or adjusted to work as intended.

      2. Widescreen support should be turned on if the mapset contains a widescreen storyboard. Alternatively, if the storyboard is designed for 4:3 resolutions, widescreen support should be turned off. This setting will not affect anything within the beatmap without a storyboard being present.

      3. Avoid sprites being partially off-screen or visually obstructed for the entire time they are used. In these cases the respective parts of the images should be cut unless this is necessary for an effect within the storyboard.

      4. Avoid any duplicate image files. Having two instances of the exact same image adds unnecessary file size.
  2. Changes:

    1. Guidelines:

      1. To fade out the background of the map, turn the same background image into a sprite, with "Background" or "0" as second parameter, and fade accordingly.


We did some testing after Yumeno Himiko's reply, after which the things mentioned have been applied, along with other additions. Since these changes are unlikely to be disagreed upon, discussion time is 7 days; closing at the 17th of April.
posted
well ok that was a lot of feedback indeed so i'll bubble this wording then
posted
Appending drafts at incredibly slow speeds!

This draft has been amended to the General section of the Ranking Criteria and can be found here!

As this whole thing involves a lot of changes, the usual 6 month ruling applies:
  1. maps that are submitted from this post onward will be handled according to the new criteria.
  2. maps that were already submitted may be handled according to the old criteria for the coming 6 months.


Once 6 months have passed, all maps will have to comply with this ruleset regardless of submission status!
posted
thread moved because finalized amendment
Please sign in to reply.