simple machines forum

Sword of Moonlight => Archive (pre 2023) => Beginner and other Nonsense => Topic started by: Holey Moley on June 07, 2015, 10:37:20 PM

Title: Turn rate must change. But how?
Post by: Holey Moley on June 07, 2015, 10:37:20 PM
In the light of a vastly improving control scheme, I have to admit that I don't know what to do about the turning rate, I just know that as is it isn't ready for prime-time.

In SOM_SYS you have three numbers for the movement speeds. I don't have any doubt about these, in fact I don't think they should even really be part of SOM_SYS. I'm pretty sure all games want these numbers to be 4.5, 1.5, and 90. If players don't like those figures then they should probably turn to the options.

I've been using 70 for a while, but it's kind of sluggish, especially when looking up/down it doesn't feel like a natural speed to do that. 90 feels much better, and 90 seems ideal for cornering when walking through a building with square hallways. 90 also feels more responsive with the mouse, although I'd never recommend actually playing with the mouse.

1.5 and 4.5 are based on comfortable speeds for people and feel most natural. If the character gains speed I can only imagine increasing the 4.5 number according to the speed stat when sprinting.


What I'm trying to say so far is we pretty much know the basics, where to start from. The problems arise though when you begin to dash, and what then should happen to the turn rate? SOM's classical behavior is to scale the turn rate by the dash/walk ratio. At 90*3 this gets really floaty, and even at 70*3 it is unwieldy.


If I knew how to proceed I'd just do it, but I don't, so I'm putting this up for discussion.


Some things to keep in mind...

A) Fast turning works while walking or dashing, and can pretty much fulfill any need to turn quickly. So ramping up the turn rate like this mainly just makes it so you can circle a monster while going from a walk to a dash without adjusting the turning rate (eg. with the analog stick)

B) In general the turn rate needs to be the same on both axes so they move together in a circle. Looking up and down faster just because you are running to me doesn't make a lot of sense. Plus this rule is naturally broken when fast turning in a way that I think is excusable.

C) I don't mind keeping the turn rate fixed really, except it is kind of cool to tap the Action/Dash button to be able to do a quick look. On the other hand you can also do a quick turn this way, but I find the proper fast-turn combo to work better for this. Since it's generally fun to tap to quick dash while fighting monsters it's probably a good idea to fall back on the standard dash/walk formula so your circle isn't broken...

That suggests that if you are not tapping (you are holding) then maybe the turn speed up should bleed out. It feels weightier to turn at the regular rate while running. Again if you need to cut you can fast-turn.


My general thought on this has always been that probably the turn speeds should just be a preference. Almost all games have such a preference, including Dark Souls. But barring not having a way to do that from inside the game at this time. Maybe it would be better to adopt a different policy. There are already extensions for adjusting these settings via multipliers.


I have lots of questions, like with do_dash and do_walk the speeds are modified independent of the dashing button acceleration from 0 to 750ms. Should the turn rate be based on that? 750 is another number, that I'm finding actually feels best around 375, or half 750. This is the amount of time it takes to tell a tap from a hold.

If the turn rate bleeds out after holding, should it bleed all the way out? Or end up slightly/somewhat faster? I don't have any answers, so I'm inclined to fall back on whatever seems like the simplest approach until there is more data. That's usually worked out for the best in the past/feels best at SOM's current level of sophistication.


PS: I say both quick-turn/dash and fast-turn here. Fast-turn I think is common parlance for a special move designed to make a 180 degree turn, or to just turn fast enough so you can do that in an instant. By quick-turn I mean just regular turning while tapping dash. Since tapping dash automatically accelerates to full dash speed and then immediately comes back down, during that time the turn rate speeds up to.
Title: Re: Turn rate must change. But how?
Post by: Holey Moley on June 09, 2015, 01:19:47 AM
I've been thinking about the quick-turns/look. I thought about suppressing the short duck when the d-pad is not doing anything so that you wouldn't duck when quick-looking up/down, since that feels unnatural, like very uneconomical movement to say the least.

I think that could have been interesting, and could have added more noise to the movement to make it feel more life like. But the real problem with that scheme is the standing jump would loose its effect, which is a very important selling point.

So what I arrived at as a compromise is to suppress the duck when looking upward, since ducking even to activate things that are up higher is weird, while it looks cool generally for things at/below eye level.

The problem with that is you can't effectively do a standing jump then while looking up. It feels kind of strange to do that anyway, so it's not a big loss. Except what if you wanted to jump up to grab something like a ledge? Well the standing jump isn't very good for that as is anyway, since it goes straight up and down. It's mainly for fun like when a giant makes an earth wave that you can time a jump over it, or even jump over a sweeping attack. It hurts to sit and take those helplessly in the ice area in KF3...

So I'm always looking for synergy. What I'm thinking is to jump for a ledge you need to look up at it and hold the Action/Dash button. That means you can't begin running, or begin crouching while looking up. And it means that you have manual control over this kind of a jump. It will be a little odd because nothing will happen while you are holding the button down, but at the same time something is happening... because you are not crouching or running.

When you let go you look forward and then back up as you jump for it. That should all happen automatically after you let go. If you want to cancel the jump you can look down (dead-ahead) and let go. Mimicking the look down it does before jumping. When you look down to cancel the look will refuse to go any lower than straight forward, and that can double then as a way to recenter the vertical looking angle without any extra added buttons (edited: admittedly I never use this, and things generally probably look better off-center, and I think a lot of the allure of being able to auto-center is to do it fast in a pinch, which is totally lost here, but if you just want to recalibrate I guess it would be useful. I've often thought center should be relative to the lay of the land where you are at, but that's kind of hard to program, but would be very interesting to have that at some point)

Strikeout: on second thought I think it's actually good practice to learn to be proficient/automatic-really with the vertical look axis, and it also promotes a kind of kinesthetic form of motor immersion that would be missed out on (although that could be a useful accessibility feature for people with physical complications)


None of this really affects the turn-rate, but it is keeping with the quick-turn model, and improves it. When quick-looking down you duck a little, but this doesn't feel so strange, because you need to step back/drop your head to look all the way down anyway. With the duck suppressed while looking up things look better. There is no suppression when looking to the side if not looking up, that feels then like a dramatic pivot. If you want suppression while looking side to side without pivoting, well fast-turn works perfect for that!


As for the turn-rate problem, my intuition is to apply the same bleed-out to walking turn rate that is applied when crouching to all instances where the Action/Dash button are held down, and to make the fast-turn rate fixed at just what feels natural for instant turning, so that its speed is separate from SOM_SYS's turn rate setting.

I'm inclined to NOT introduce an extension for this change, like do_turn for instance, and just roll it into do_dash instead. Crouching isn't dashing, but it works the same way button wise, so it kind of is. Or IOW it will almost be an assumption that if you are using do_dash you are using a quite high dashing speed, and so the turn rates while dashing will probably be ridiculous anyway if the original formula is applied to running/sneaking.

And not only that, but you need a slower turn rate while sneaking. Slower than the old dashing rate anyway, the walking turn rate would probably be just right.
Title: Re: Turn rate must change. But how?
Post by: Holey Moley on June 09, 2015, 10:04:22 PM
EDITED: Re-reading this (the above post) today, it occurred to me that fast-turn does pivot. So I tried it and learned that the pivot's sign had become flipped in the latest build. So instead of ducking it goes up. I will probably silently upload a patch after posting this.

I think the fast-turn pivot will just be suppressed when you are not moving, the same way the stepping motion is, until you've turned far enough around that you have to begin shuffling your feet, and then probably then it should duck (in a way suggesting a pivot)
Title: Re: Turn rate must change. But how?
Post by: Holey Moley on June 25, 2015, 08:53:57 AM
I think I've come to my senses.

About looking up, I think it's just going to have to duck down when dashing. It will have to be like a dramatic evasion as if a monster is flying just overhead. I think to make it seem less funny you will stay ducked down somehow until you look back down. Looking down may do the same.

My rationale for this is mainly that I want to maintain a one-to-one correspondence between button presses, et cetera and animations. So the idea to aim jumps while looking upward broke that rule. I think this is important above all else. So now I think at some point jumps will be aimed while looking upward, but they will duck down just like a regular standing jump. Probably aiming an upward jump while running will work as well.


PS: Another rationale for this is I think with VR headsets there's going to be a strong free-look component, so you will be able to look up as fast as you actually do so, like with your neck. So at that point the vertical look axis on the thumbstick might have nothing else to do anyway (that is it should still trigger the all-the-way up/down states, which literally bending your neck should not be able to)
Title: Re: Turn rate must change. But how?
Post by: Holey Moley on December 25, 2015, 04:04:32 PM
I first posted this in "Random News" but realized there was a topic about this more or less already. Albeit 6mos old. This is something I've long been meaning to afford consideration. The dash-turn speeds have for a while made me uncomfortable. I'm glad a resolution has been reached.

I did some unexpected work on SOM today, Xmas Morning; I was up all night (I will be like Weekend at Berny's for the family gathering/lunch later)

It occurred to me that turning at full speed while crouching is fairly absurd. Also just smoothly panning is too. I tried exaggerating the wobbling effect that simulates shuffling feet after turning too far to be simply turning your neck, but I decided to leave that alone, and focus on the speed dilemma for now.

In the end I settled on reducing the turning rate by 25% when crouching/turning in a way that would require leg movement. It can't really go any lower than this or it becomes too noticeable that the looking up/down speed is still at 100% and I cannot justify slowing that down, and it feels very awkward if you notice that you seemingly can only look up and down. After SOM is fully down with VR glasses, I intend to totally free up the look axes, and maybe make that what the mouse uses, and have the mouse buttons turn left/right (meaning you'd have to use Shift/Space to play with)


But more interestingly I became unsettled by the ambiguity of doing a dash-turn versus turning while crouching down. If meaning to crouch the extra acceleration is awkward or not necessarily desirable.

So I tried not having the accelerated turn at all. I know King's Field 3 has no such acceleration, and I haven't tested 2 or Shadow Tower. But the acceleration I found was especially missed when wanting to quickly look up/down, and "dodging" felt sluggish without it. Plus in theory without it if you dash while circling a monster you'll drift off center...

So what I ended up doing was cutting the acceleration for turning in half. This is in addition to eliminating it completely after the initial burst of energy, so that running is not too unwieldy.

This halving is not done unless do_dash is in play, and neither is the 25% slowdown when crouching.

Considering that I strongly recommend 3x dashing speed. (Really I wish SOM_SYS didn't even have those settings at this point.) Speeding up by 200% is a bit extreme. So halving that is 100% speed up, which is still quite speedy. It's enough to look up/down quickly. And still feels functional as a 90 degree turn to quick look. Better to undershoot that than overshoot it.

All and all this feels much better, and I feel like I am in control of where I am looking when dodging, where as before it felt like whiplash/almost turning in on yourself.


As for the aforementioned ambiguity. It still exists. But it's more believable and much less noticeable at this speed. Plus crouching while turning is not something players are likely going to be doing in an actual play session. More likely is jumping while turning, which doesn't really suffer from the acceleration.

To make this work the shuffling is suppressed when crouching down [ie. the actual act of crouching, versus being crouched; the English language was clearly never intended to describe abstract video game concepts] so that the 25% doesn't eat into jumping. It does slightly if you've been turning for a while and then jump, but it's not noticeable, and will not affect the jumping distance, only slightly the intended direction. Although this can depend on the tap vs. hold timeout settings. It isn't an exact science, but it feels much better now.

I'm not going to upload a patch just for this. It's just a positive development I felt like sharing. It will be in the next patch or release.

Strikeout: never mind. I just discovered a major bug that will require a patch. It's a classic write max() when you mean min() bug.