Extending flexibility of playlist system to better support spotlights evolving

[venix12]

This issue is proposal of implementation of basic spotlights sytems into the osu-web, I'm willing to work on that, putting a draft in here, open for improvements.

Basic infrastructure

• Add spotlights marker on spotlighted beatmapsets, and allow to filter by it (similar to how FA tags work). Those would be linked to URL from spotlights table mentioned below, or remain unclickable for legacy spotlights/charts implementations. (or just default to spotlights wiki article when no custom url is provided?)
  • Add support for adding spotlight label to beatmaps #8768
• Add seasons display and listing.
  • Add seasons infrastructure and basic display #9725

Ranking implementation

Following steps are required for full-scale seasonal ranking implementation, in order to fully supersede external calculation scripts:

• Add user seasonal total score calculation workflow.
  • Add user season score calculation workflow #11768
• Add seasonal leaderboard display to season show pages.
  • Add seasonal leaderboards #11804
• Add seasonal rank/division display to user profiles.

Some ideas (would be nice to have but not really high priority)

• Some form of "subscribtion" - a person could follow spotlights and get a notification when new lobbies open (are attached to spotlights season).

[peppy]

I think a lot of what is asked for here should potentially be added to the playlist system itself, ie. allowing any playlist to have an attached description, URL, etc.

Maybe we could also implement a "seasons" system where multiple playlists could be grouped together (implement the backend for spotlights but eventually let others use this?)

[nanaya]

The title says "Basic implementation" so is it a different system from existing lazer playlist's spotlight flag (which also already have leaderboard in osu-web)?

[peppy]

The goal here is to give spotlights more of an official presence as they expand in scope (ie. more users are interacting with the system). Making it visible on a beatmap's page (and potentially.. the beatmap listing as proposed), as well as allowing better linking of metadata so players can get more info on the spotlight/playlist they are playing on.

To get some context you can check the latest news post regarding the system usage (https://osu.ppy.sh/home/news/2022-02-15-beatmap-spotlights-season-5-winter-2022). At very least I'd want to see the ability for us to add descriptive text (maybe full markdown?) so spotlight ranking pages (and in-game display) could give users the same amount of detail as the news post. Or just link to the news post if that's simpler.

Basically it's very hard for a user to understand what spotlights are right now unless they follow news posts closely. Given that playlists/spotlights are an area I really hope to build on in the future expanding the general flexibility of the system seems like a good next step.

The admin panel part is lower priority (I'd like to see this as part of the playlist creation interface in-game to keep things in one place).

[nanaya]

So... extending current system and not a basic implementation? Can use a better issue title at least I think.

[venix12]

@peppy since I'm gonna work on the seasons thing now, i wanted to ask, should there be an interOp API endpoint or something to make assigning certain rooms to certain seasons (assuming the Season creation can go straight into database) a thing in the script you're working on? #8927 (comment)

The workflow could be pretty much:

1. a Season is created
2. script is hitting interOp endpoint along with season_id and room_id, which then proceeds:
   • Room is marked as spotlight
   • Room items (beatmaps) are marked with spotlights tag and reindexed

That kind of solution seems pretty handy to manage all this stuff.

The season thing could also be used later without the interop/reindexing endpoint stuff to group some of non-spotlights lobbies (as mentioned in #8736 (comment)).

[peppy]

Is the work you're planning to do at osu-web end? Or is it an external system? If it's being added osu-web end (which would be good, I think) then interop is not required as all of the pieces above are already supported via osu-web calls directly.

[venix12]

Thought you wanted to use it in an external script, that's why i suggested the interOp, did the stance change since and therefore i should make it a website UI thing instead?🤔(or am i misunderstanding something)

#8927 (comment)

If it makes more sense, we could implement this as an api endpoint and skip requiring the UI overhead. Or if it's something which is going to involve a manual switch from our end (ie. also flagging the playlists in lazer as spotlight), it can potentially be automated as part of that process.

[peppy]

Right, sounds good.

The easiest way for me is to expose an ASS command to perform the necessary ops. If you give me a list of the commands you'd like I can get them prepared (that was the plan for the indexing which i haven't got to). Is it just the mark-spotlight-and-index flow that needs addressing? I'm unsure of the database requirements you mention for seasons above.

[venix12]

ok so what i mentioned database-side is mostly explained in the opening post i believe, to put it simple way:

• Season table contains specific spotlights (and in future possibly not only spotlights) seasons, by which i just mean a group of playlists (as mentioned in Extending flexibility of playlist system to better support spotlights evolving #8736 (comment)) - to have a frontend display in the future
• SeasonRoom is just a pivot table so that you can assign rooms to specific seasons (maybe could just add season_id to Multiplayer\Room playlist items instead? (could work for spotlights, not sure if other purposes expect one playlist attached to max one season, would guess so?)

other than that, regarding the ASS commands, when the above is implemented, what i imagined it to be is:

• a command to create Season entry, with customizable name
• a command to assign specific Multiplayer\Room playlist to specific Season (and spotlight=true it), which would at the same time pull playlists items and set spotlight=true + queue reindex on them (probably the most complex/important one - that's what i expected an interOp endpoint for, can drop that part if it's possible for you to do on ASS side fully)
• probably a simple command to just set spoltight=true and queue reindex on single beatmapset (for pre-lazer spotlights era, can also be used before the seasons is a thing)

hopefully everything's clear now 🤔

[peppy]

The implementation with a Season table sounds best from a flexibility perspective.

I'll get to adding a command to do the management as soon as I find the bandwidth (right now making the changes manually is lower effort due to how rare the requests come in). But feel free to continue pushing forward with the surrounding implementation and I'll adapt as required.

[venix12]

ok, so just to clarify, should i go with season_id on Room or with separate SeasonRooms table to allow one-to-many relationship between rooms and seasons?

[peppy]

The second sounds better. Or if the list of rooms is decided at the start of the season and never changed, a CSV column could work fine too. Whatever is simpler.