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!
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.
Storyboarding
Rules
All rules are exactly that: RULES. They are NOT guidelines and may NOT be broken under ANY circumstance.
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.
Make sure to read the entire draft! It will be up to discussion for two weeks and close on the 17th of April!
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)- 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. - 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.
The proposal starts with the glossary.
Glossary
Common terms
Storyboarding
- Storyboard Image: This refers to the image in the song folder that the storyboard uses.
- Sprite: An object in a storyboard representing an image, or a series of images.
- Time: A millisecond representation of a timeline position. This representation is seen within the design section of the editor.
- 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.
- Axis Specific Command: A command which only applies to one specified spatial axis, for example MoveX and MoveY.
- Active: From the first start time to the last end time of commands in the object.
- Rendered: Often referring to an on-screen sprite that is not completely faded out.
- 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.
- 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.
- 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.
- The beatmap must not throw parsing errors upon loading. This means the parser cannot read part of the storyboard instructions.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Make sure the storyboard is optimized as much as possible, within practical means.
- 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.
- 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.
- Avoid unnecessary transparency around storyboard images. For the sake of performance, images should be cropped as much as possible for their desired effects.
- 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.
- 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.
- 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.
- Avoid any duplicate image files. Having two instances of the exact same image adds unnecessary file size.
- 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.
- 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.
- 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.
- 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.
Make sure to read the entire draft! It will be up to discussion for two weeks and close on the 17th of April!
