Add ability to display autoplay cursor in editor

[minetoblend]

Depends on #35699 Closes #35486

Adds the ability to display the autoplay cursor in the osu-ruleset editor.

https://github.com/user-attachments/assets/ac593e3c-9936-44a9-a1b8-79c7694881ba

also, you should play the map used for the video, it's very fun.

[bdach]

@peppy would like your opinion on this feature proposal before I spend any review time on it

[peppy]

I'm not sure about this one. It feels like test play should be used for this. It's not something I can see anyone leaving enabled permanently, which makes it a bit of an annoying feature (even as a toggle) because you're going to constantly be needing to change it.

[minetoblend]

Before I go into the actual UX aspect of all this, I want to start off by saying that seeing the gameplay cursor simply makes using the editor more fun for me. I think fun is just as important of a thing to strive for as having efficient and intuitive workflows. I just enjoy looking at it while mapping.

I posted a video of this a while ago on twitter which gained quite some traction compared to most of my other posts, so I think it's fair to say that I'm not the only person who would like to see this.

It's not something I can see anyone leaving enabled permanently

That someone would be me. I've implemented the same feature in my own editor over a year ago and can't remember the last time I turned it off.

The value I personally get out of this is less about being able to actively analyze the cursor movement for specific patterns, because at that point u may as well just actually play the map. It's more about the constant exposure to it making the cursor movement something that stays in the back of my mind even when I'm not actively thinking about it.

which makes it a bit of an annoying feature (even as a toggle) because you're going to constantly be needing to change it.

Fwiw, I put the toggle in the toolbar next to the grid settings in osucad. The same place could be used in lazer too if putting it in the menu bar is that much of an annoyance.

Hotkeys are of course also a way of making it easier to toggle this. Aside from that, this feature is completely optional so people can simply choose not to use it.

It feels like test play should be used for this I've already touched upon this in #35486 a bit, but let me elaborate.

First off, I've actively used the autoplay feature in the editor maybe 5-10 times over the span over several years. It's just too awkward/cumbersome to actually try and build a workflow around for me. I do however regularly use the test play feature for, well, test playing; I'm strictly talking about the autoplay part here.

Occasionally I do actually use it more actively though, so let's explore a use-case and look at what trying to use test-play looks like for it:

Let's say I have a pattern and want to use the testplay screen to look at how the cursor movement changes when I make some adjustments.

https://github.com/user-attachments/assets/c118b43e-21e4-47cf-bf55-616df5a46563

Let's break this down into individual steps. To look at 2 different versions of this pattern with the test play feature I need to do the following:

• seek a decent amount backwards because I actually need to have enough time to activate the autoplay mod after the replay starts
• wait for the screen to load
• activate the autoplay mod by pressing tab
• watch the actual part I'm interested in
• exit back to the editor
• scroll back to what I was working on
• make adjustment to the beatmap
• scroll back again
• potentially deal with the "unsaved changes" dialog
  • I understand that the Player class has some limtations that causes this requirement, but having to override the map with a change I'm not sure if I want to keep yet is still kinda whack. This isn't git where you can just override files and restore the previous state down the line.
  • I also understand that you can just hit ctrl+s first, but this is the kinda thing you just forget about sometimes and then you're gonna get annoyed when the dialog pops up
• wait for the screen to load
• play the same game of "press tab key quick enough to activate autoplay before the pattern starts" again
• watch the actual part I care about again
• exit back to the editor
• seek back to the pattern in question
• hope that I haven't already forgotten what the replay on the first pattern looked like by now

Let's try again, but this time with the cursor visible in the compose screen.

https://github.com/user-attachments/assets/d3202968-9b64-4e91-aabe-ae6b06f41198

Here, the steps are the following

• seek to just before the pattern and hit play
• watch the part I'm interested in
• pause
• make adjustment to the beatmap
• seek back again
• watch it again

I hope you can see why I think that the mental overhead of using test play is just too much to consider it worthwhile.

[peppy]

The UX i imagined for the editor was to have the "test" play not transition to its own screen, but just hide the editor UI and leave the gameplay remaining. Which I think would also resolve all your issues, but is a bit more involved to make work well.

[peppy]

I can get behind this being a toggle bound to the Tab key by default, because the endgame implementation i mention above would also use the same binding. This could be a "first step in that direction".