forum

Gradually Fluctuating Slider Velocity

posted
Total Posts
33
This is a feature request. Feature requests can be voted up by supporters.
Current Priority: +30
Topic Starter
Exa
So this has been in my head for quite a while, so I went ahead and made a post about it.

As the title implies; I would like to request the addition of a new mechanic regarding the slider's velocity:

When the player interacts with a slider, he does so by tapping on it's head. From that point on, all he has to do is follow the slider-ball that appears while it travels with a fixed velocity across the slider's body. The feature I am suggesting, makes it possible for the slider-ball's velocity to gradually decrease and/or increase from the point of tapping, to a certain point across the slider's body.

Gradual decrease


The red point represents the slider-ball's starting point.
The bluepoint represents the slider-ball's ending point.
The black point does not represent the slider's end point, but a simple fixed point, being roughly at 3/4 distance from the slider's starting point to the ending point. It could also be on the slider-ball's end point.
The arrow represents the distance which the slide-ball has to travel until it reaches it's final velocity. That distance being from the red, to the black point.

This is an example of the slider's velocity gradually decreasing. The narrower the arrow gets, the lower the slider velocity becomes until it reaches it's final velocity (black point).

Graph:


X axis represents the slider's body. Start being at 0.0 and end being at 2.0
Y axis represents the slider's velocity. Maximum being at 2.0 and minimum being at 0.5

Gradual increase


The red point represents the slider-ball's starting point.
The bluepoint represents the slider-ball's ending point.
The black point does not represent the slider's end point, but a simple fixed point, being roughly at 3/4 distance from the slider's starting point to the ending point. It could also be on the slider-ball's end point.
The arrow represents the distance which the slide-ball has to travel until it reaches it's final velocity. That distance being from the red, to the black point.

This is an example of the slider's velocity gradually increasing. The wider the arrow gets, the higher the slider velocity becomes until it reaches it's final velocity (black point).

Graph:


X axis represents the slider's body. Start being at 0.0 and end being at 2.0
Y axis represents the slider's velocity. Maximum being at 2.0 and minimum being at 0.5

The mapper shall be able to determine how fast the arrow "widens" or "narrows" to determine how fast or slow the slider velocity fluctuates.
The arrow must always start (either way) at the slider's starting point to avoid starting the fluctuation mid-body.
There shall only be only one arrow, meaning only one fluctuation for each slider.
The black point can be moved across the slider's body do determine where the fluctuation ends.
There are limits to how fast/how slow the slider velocity can get and these are the same as how fast or how slow the slider velocity can get on the timing panel in the editor.
This is a very advanced mechanic and shall be used with extreme caution and only by experienced enough mappers.

The only visible element during gameplay shall be the "arrow". The 3 points are merely used for the sake of understanding the concept behind this.

Surely these should not be the actual graphical elements, I am just bad at working on editing programs.
Bara-
Can be nice
Might be very confusing though
I'd really like to see this
Kibbleru
interesting. would be kinda troll but interesting
mijkolsmith

Exa wrote:

So this has been in my head for quite a while, so I went ahead and made a post about it.

As the title implies; I would like to request the addition of a new mechanic regarding the slider's velocity:

When the player interacts with a slider, he does so by tapping on it's head. From that point on, all he has to do is follow the slider-ball that appears while it travels with a fixed velocity across the slider's body. The feature I am suggesting, makes it possible for the slider-ball's velocity to gradually decrease and/or increase from the point of tapping, to a certain point across the slider's body.

Gradual decrease


The red point represents the slider-ball's starting point.
The bluepoint represents the slider-ball's ending point.
The black point does not represent the slider's end point, but a simple fixed point, being roughly at 3/4 distance from the slider's starting point to the ending point. It could also be on the slider-ball's end point.
The arrow represents the distance which the slide-ball has to travel until it reaches it's final velocity. That distance being from the red, to the blue point.

This is an example of the slider's velocity gradually decreasing. The narrower the arrow gets, the lower the slider velocity becomes until it reaches it's final velocity (black point).

Graph:


X axis represents the slider's body. Start being at 0.0 and end being at 2.0
Y axis represents the slider's velocity. Maximum being at 2.0 and minimum being at 0.5

Gradual increase


The red point represents the slider-ball's starting point.
The bluepoint represents the slider-ball's ending point.
The black point does not represent the slider's end point, but a simple fixed point, being roughly at 3/4 distance from the slider's starting point to the ending point. It could also be on the slider-ball's end point.
The arrow represents the distance which the slide-ball has to travel until it reaches it's final velocity. That distance being from the red, to the blue point.

This is an example of the slider's velocity gradually increasing. The wider the arrow gets, the higher the slider velocity becomes until it reaches it's final velocity (black point).

Graph:


X axis represents the slider's body. Start being at 0.0 and end being at 2.0
Y axis represents the slider's velocity. Maximum being at 2.0 and minimum being at 0.5

The mapper shall be able to determine how fast the arrow "widens" or "narrows" to determine how fast or slow the slider velocity fluctuates.
The arrow must always start (either way) at the slider's starting point to avoid starting the fluctuation mid-body.
There shall only be only one arrow, meaning only one fluctuation for each slider.
The black point can be moved across the slider's body do determine where the fluctuation ends.
There are limits to how fast/how slow the slider velocity can get and these are the same as how fast or how slow the slider velocity can get on the timing panel in the editor.
This is a very advanced mechanic and shall be used with extreme caution and only by experienced enough mappers.

The only visible element during gameplay shall be the "arrow". The 3 points are merely used for the sake of understanding the concept behind this.

Surely these should not be the actual graphical elements, I am just bad with working on editing programs.
This topic title got me like damn, sounds like something cool though.
WingSilent
That's a good idea and you have my full support.
Rilene
ayy

Must have this.

Supporting with my star that never existed.
silmarilen
i think this would hurt readability too much. you can already change the speed at which a person has to move their cursor without doing that by giving the sliders funny shapes or compressing them (like this or this).
abraker
I remember there was some request on revamping SV editing, but couldn't find it.
Topic Starter
Exa

silmarilen wrote:

i think this would hurt readability too much. you can already change the speed at which a person has to move their cursor without doing that by giving the sliders funny shapes or compressing them (like this or this).
I can't see this be used in small sliders, so readability should not be that much of a problem; especially when applied nicely.

Also why not avoid ugly and unreliable slider shapes like these and have an actual way of changing the slider velocity mid-body? (2nd looks kinda cool though but that's not the point)
Karuta-_old_1

Exa wrote:

silmarilen wrote:

i think this would hurt readability too much. you can already change the speed at which a person has to move their cursor without doing that by giving the sliders funny shapes or compressing them (like this or this).
I can't see this be used in small sliders, so readability should not be that much of a problem; especially when applied nicely.

Also why not avoid ugly and unreliable slider shapes like these and have an actual way of changing the slider velocity mid-body? (2nd looks kinda cool though but that's not the point)
what silmarilen is trying to point out is

when you play the map without taking note of when the slider's velocity will change (i.e. usually it is not readable unless you can read the mapper's mind)

while altering the slider actually achieves the same result without affecting how a player reads

I don't see the need to add this in, sliders are already difficult as it is
Rilene
This might be useful for creating perfect accelerating/decelerating streams, instead of doing them manually which imperfectness in the streams exists.
Topic Starter
Exa

Karuta- wrote:

what silmarilen is trying to point out is

when you play the map without taking note of when the slider's velocity will change (i.e. usually it is not readable unless you can read the mapper's mind)

while altering the slider actually achieves the same result without affecting how a player reads

I don't see the need to add this in, sliders are already difficult as it is
How difficult something is, is a personal and subjective matter. I did say this is an extremely advanced mechanic because it affects the flow's stability. That doesn't mean that this wouldn't be possible to be used responsibly.
Full Tablet
If this gets implemented, I think there should be a new visual indication of the speed changes (since, as it is proposed, you would have to guess that the slider has speed changes).

Doing a velocity change of this sort by squiggling the slider is a bit more readable, since you can notice the slider shape and estimate how it will move. Even with that visual indication, sliders like that are quite limited in ranked maps, mainly because of the difficulty of sight-reading them.
Topic Starter
Exa

Full Tablet wrote:

If this gets implemented, I think there should be a new visual indication of the speed changes (since, as it is proposed, you would have to guess that the slider has speed changes).

Doing a velocity change of this sort by squiggling the slider is a bit more readable, since you can notice the slider shape and estimate how it will move. Even with that visual indication, sliders like that are quite limited in ranked maps, mainly because of the difficulty of sight-reading them.

Exa wrote:

The only visible element during gameplay shall be the "arrow". The 3 points are merely used for the sake of understanding the concept behind this.

Surely these should not be the actual graphical elements, I am just bad at working on editing programs.
I also explained how the player will be able to determine the speed change according to how wide and long the arrow is.
abraker
Bump, bumpity, bump
Vuelo Eluko
this would throw a monkey wrench in everyones reading as we have all learned that slider velocities don't change during a slider, unless it's one of those really awkward squiggly sliders or something that completely gives itself away the moment it appears anyway.

I can't agree with fundamental gameplay changes at this point.. I really think it's too late. Adding decimal AR/OD/HP/CS was fine, but this is much more than that.
abraker
This will work if mapped properly. I see this making sense with certian sounds. I wanted to make a bent slider with it speeding up to a drop after the bent, but no such feature exists. Or imagine a slider slowing down as the song transistions to a calmer state. I imagine these things will need to be consistant so that they are predictable, because imo, those things need to be felt and not read. Have a little more imagination and worry less about troll maps.

And what's so mind boggling about this changing the game? At worst, this has less of an impact on gameplay than making sliders fadout in HD because this is adding to the game and not changing an already established thing.
Vuelo Eluko
well that and the decimal things only impact reading not execution and reading
IDK. i guess it could work if implemented well and carefully
Yauxo
Ive had the same idea for a long time and I'd really love to see this (especially if the gimmick category gets to be a thing)
ReaverX
I definitely agree with this, and came here because I wanted to see if this idea was pitched yet. The name I had for it was Slider-Boost. Simply by using an arrow, and perhaps a line, you can tell the player exactly where the speed-up is happening - and it doesn't even have to be a gradual increase, it can be a set amount. Think of a song where the beat drops/melody really kicks in, and you've got a good spot for a slider-boost. That said, you can also have some fun with the gradual increasing/decreasing velocity too.

Definite bump!
lilynya
.
Yui Fujiwara
I know it's past the point, but I was mapping (Wow, no way) and I came across a point that this would work. In my eyes away ways.

So, I'm using the mp3 from Kroytz' xi - Ascension To Heaven map and at 00:20:242 - 00:22:642 and then from 00:22:642 - 00:23:842

Obviously, the timing measurements are half, when comparing the first set of times to the second, but the bigger thing I want to note, of which is why I posted this topic in the first place, is to note the music's mood change at 00:20:242 - 00:22:642 and then from 00:22:642 - 00:23:842 which then leads to the the build up to the main part of the song literally a measure and a half later after 00:23:842

I'm guessing that this still isn't an idea valid for osu! right now or ever, but I wanted to make my cause for posting this topic, to have an example that makes sense.
I noted this on my own topic page thingy. Bara told me to come here. This is only an example of what Exa is talking about.
Jude

Aeii wrote:

ReaverX wrote:

Think of a song where the beat drops/melody really kicks in, and you've got a good spot for a slider-boost.

Can't you just use 2 sliders?

This sound really abusable and confusing to read, and ruins the minimal gameplay of osu.

No thanks.
thats what i think. ive seen rhythm changes by using one slow slider then it goes fast. we cant know how much a slider is going to change velocity and its just confusing
rawrneru
I was this close to requesting this. Damn you for stealing my idea :^)
Yui Fujiwara

Rachneru wrote:

I was this close to requesting this. Damn you for stealing my idea :^)
ay dude, happened to me. that's why I posted my example here.
Yui Fujiwara

Jude wrote:

thats what i think. ive seen rhythm changes by using one slow slider then it goes fast. we cant know how much a slider is going to change velocity and its just confusing
Slider ticks. Less density means slower velocity. higher density means higher velocity.
Upskirt
This wouldn't work because people read what they expect or predict.

But it could be cool to see.
Rilene

Venzire wrote:

This wouldn't work because people read what they expect or predict.
Of course there should be a indicator for this.
Caput Mortuum
Tbh, ppl already requested hold objects and 2 keys note. They both also needs an indicator, and I don't think having 5 (6 if you include spinner) different kind of objects is very fun. Especially in sightread
Upskirt

Eraser wrote:

Tbh, ppl already requested hold objects and 2 keys note. They both also needs an indicator, and I don't think having 5 (6 if you include spinner) different kind of objects is very fun. Especially in sightread
I agree with Eraser. Players already need to follow the general shape of the slider and increasing the amount of objects on the screen would be a hindrance to play even if it was a small one. The change isn't necessary although it as a sweet idea.

Further more, how would this viable in other mods such as hidden? You said there would need to be an indicator for the linear increase in slider velocity so how would it work in hidden? It doesn't seem viable if the idea is to hide notes in the play field.

As it is already, many people do not like sudden SV changes so it would have to be a very niche application.
abraker
For those talking about indicators, a slow increase wouldn't need an indicator since it's one you would be able to react to. Faster changes, however, would benefit from an indicator. I am thinking of having the indicator be something like a color change in slider body or border. Another indicator might be tick density.
Yui Fujiwara

Venzire wrote:

This wouldn't work because people read what they expect or predict.

But it could be cool to see.
Playing shouldn't be about prediction unless someone has played a given map multiple times.
Yui Fujiwara
Can I also note to some posters, myself included, that this is just an idea. Because someone states something doesn't mean that it needs to be bashed on.

From a base, there is bound to be things that come from that base.

Ideas, simply ideas.
Please sign in to reply.

New reply