Add support for ruleset-specific blueprints in editor timeline #29973
Conversation
OliBomby
changed the title
| [CanBeNull] | ||
| public virtual TimelineHitObjectBlueprint CreateTimelineBlueprintFor(HitObject hitObject) => new TimelineHitObjectBlueprint(hitObject); |
There was a problem hiding this comment.
If we're going to go and say that it's fine for the timeline to look differently on different rulesets, then I can already tell you that this API is too constrained and we'll need a higher-level primitive anyway to replace the entirety of the timeline.
Why, you ask? One of the most frequent pieces of feedback on scrolling rulesets (taiko and mania) are that scroll speed changes should be visible on the timeline. And osu!'s displays above hitobjects do not make sense there because that's not how speed changes work on those rulesets - they affect the entire playfield. So they should probably look closer to the red timing change markers.
So I think this sort of thing is too short-sighted and we'll have to tear it out sooner than later anyway. Not opposed to the idea, yet wholly opposed to this execution.
There was a problem hiding this comment.
This is valuable feedback.
Then we'll need to expand the API to allow showing additional things on the timeline apart from hit objects. I'm thinking such taiko/mania scroll speed changes would probably have to sit next to the TimelineTimingChangeDisplay in the drawable tree.
My question is to what degree do we want rulesets to replace the timeline? You said "replace the entirety of the timeline", but maybe thats overdoing it? I think all rulesets will still share a lot of elements of the timeline like the zoom behaviour, centre marker, timing change display, waveform, ticks, etc. Whatever implementation we go with, it should be easy to add these elements to your ruleset's timeline, so we don't end up with lots of code duplication.
There was a problem hiding this comment.
Whatever implementation we go with, it should be easy to add these elements to your ruleset's timeline, so we don't end up with lots of code duplication.
I mean obviously, yes - that said, composition over inheritance please. I don't want to see any BaseTimeline shaped monstrosities. Just have the required components readily available for reuse.
|
The above comment notwithstanding I'm gonna need @peppy cross-check on this, since I vividly remember him being vehemently opposed to the notion of per-ruleset deviations of any sort on the timeline, although I cannot find the paper trail for this. I think it must have been somewhere around when we started to implement this editor design. I think it could have been in stream twitch chat or something...? |
|
A couple of screenshot comparisons in the OP would help to explain what this is aiming to achieve. There may be better ways we can do this. I'm hesitant to make the timeline non-generic. |
I've added a few screenshots and edited images to show what I want to achieve with the timeline. |
|
Thanks. I think it's a valid direction as long as we make sure to keep the UX between rulesets as similar as we can. |
RFC. This PR allows rulesets to customize how hit objects are represented in the timeline without having to modify the hit object classes or create additional interfaces.
The need for this has been expressed multiple times already in #29441 and #21566
The API is a bit limited because it expects objects of type
TimelineHitObjectBlueprintwhich already defines all the layout and interactions. If more freedom is required, I thinkTimelineHitObjectBlueprintshould not define layout and instead the parts of it should be split into separate classes which could be composited instead.Some examples of what could be possible with ruleset-specific timelines:
IHasDisplayColourinterface can also be eliminated in favour of taiko specific timeline blueprints. Maybe even show strong hits.