The Ranking Criteria: From Elite Beat Agents to Particle Visualizer¶

When storyboards were first introduced into osu!, they were intended to mimic the background animations of the Ouendan and Elite Beat Agents games: basic slideshows of images, simplistic pass/fail visuals, and a narrative from start to finish. And yet, as osu! continuously grew, more tools became available for development, and innovators pushed the boundaries of storyboarding far more than its original intentions.

We went from this... (Storyboard is Elite Beat Agents’ You’re The Inspiration).

To this. By golly. (Storyboard is Damnae’s Far East Nightbird).

In this sense, the concerns for storyboards have shifted greatly as well. What initially were concerns about strobing and a multitude of large images being loaded at one time, have now shifted into ones that simply push osu!’s game engine with a sea of sprites coordinating together into something utterly unreal.

Wrecking computer and game performance, to a beatmap near you! (Storyboard is Exile-‘s world.execute(me)).

As of the last revised date for this article, new efforts to promote performance-friendly storyboards in an era of particle generation have been brought up here. As such, the ranking criteria has now changed to allow a storyboarder more freedom in rendering sprites, but also to be a responsible creator that won’t highly detract gameplay performance whilst creating art.

This chapter is devoted to creating and improving a storyboard for performance, from problems and solutions to general principles in ensuring a storyboard that isn’t something relegated to Cinema mod.

SB Load¶

• SB Load will no longer be a metric for ranking criteria

• More accurate guidelines that SB Load can help suggest to you are good though

  • Hidden objects, partially off-screen, obstructed, etc.

SB Load is a simple metric that is determined by how many rendered sprites occupy the 4:3 viewport. A sprite background occupying the 4:3 playfield of 640x480 would simply be an SB Load of 1.0x, as a background occupying a widescreen storyboard of 854x480 is of 1.33x. The metric is a sum of all rendered sprites at the current point in time. For instance, a series of four sprite backgrounds cascaded over each other results in an SB Load of 4.0x.

Performance Optimization¶

• Too many particles/sprites at one time
• Too many commands in a short period of time

• Sprites are rendered for too long in a map (this adds up)

  • OSB uses variables (upon loading the map)
  • the OSB file has to make inefficient runs converting a variable into
  • commands, however it does save space

• storybrew renders sprites more efficiently than osu! does, so playtesting needs to be done on osu!

  • Example: Command count
  • Too many commands, osu! may not read every command

File Size Optimiazation¶

• Beatmaps have a 30mb limit, or a 100mb for marathons
• Large storyboards often take time loading on osu!, etc.
• Often, a storyboard past 10MB etc is going to begin demonstrating performance drawbacks
• A good storyboarder should ensure that they don’t needlessly waste filesize

Performance & File Size Solutions¶

Solutions:

• Use less sprites

• Interpolate less

  • Keyframes in Storybrew

• Use storyboarded loops
• Despawn sprites after they’re used

• Sprite pools

  • Drawback: Slightly worse performance (a longer rendered sprite)

• yf_bmp’s storyboard optimizer
• Round up numbers, you don’t need to be that precise. The savings will add up.

• Get rid of needless transparencies, scale down an image if you could

  • Work on a smaller, lower quality image for certain things

Coding Optimization¶

• While coding for storyboarding has standard practices, the biggest differences are that...

  • You are not necessarily writing maintainable code

    • Though reusasble effects can help for producing future storyboards

  • Major optimization practices are not as important with storyboarding

    • Often in production-level software engineering, some optimizations include minute things such as memory management or

    very specific algorithms that solve certain problems

    • You may not need this, especially if they take far more time to implement than necessary

• These concerns are more founded when you’re scaling upwards and are using many commands

• When making an effect, you may consider

  • What is a good working solution for the effect?
  • What can I do to improve it or make it more reusable?

• Nested For-loops

  • Big O

• Infinite loops

  • While / Do-while loops

    • Example: Randomly generate [____]. If it’s not successful, do it again until it’s successful.

  • Be careful about making confusing booleans that seem like they may not end

Less Algorithm, More Code Quirks¶

These practices should not necessarily be used unless your code is already considerably slow, and the bottlenecks such as O() algorithms may have been taken care of. Likely for storyboarding cases they are not important, but for knowledge’s sake. <3

• For loops > Foreach loops
• StringBuilder > String for concatenation

• LINQ Queries

  • LINQ queries are efficient code but because they work on an IEnmuerable extensive interface, they may be slower
  • If it’s too slow, you may want to opt for a better way of reorganizing a list you’re managing to a smaller list or algorithm
  • Or it may be possible to simply implement some searches yourself, for better or worse
  • There is no need to use LINQ queries for small or trivial numeric operations