Movement is not precise enough.
Koruyo
AUT Join Date: 2009-06-06 Member: 67724Members, Reinforced - Shadow
AUT Join Date: 2009-06-06 Member: 67724Members, Reinforced - Shadow
Sometimes Its hard to hide behind stuff or shoot trough little holes because of this...
The only way too move a bit smoothly is to strafe while moving backwards, or forwards so i am suggestion a walk key for every lifeform + marine.
<a href="http://www.youtube.com/watch?v=i0u7KIZFdb4" target="_blank">http://www.youtube.com/watch?v=i0u7KIZFdb4</a>
Im just tabing left and right fast n short... see how far it moves + i show you the backward sidestrafe. Sure its not a big problem if you are alone on a server, but in combat sometimes its a difference between life and death. (you make a sidestrafe but it moved you too far showing your half body to your enemy.
The only way too move a bit smoothly is to strafe while moving backwards, or forwards so i am suggestion a walk key for every lifeform + marine.
<a href="http://www.youtube.com/watch?v=i0u7KIZFdb4" target="_blank">http://www.youtube.com/watch?v=i0u7KIZFdb4</a>
Im just tabing left and right fast n short... see how far it moves + i show you the backward sidestrafe. Sure its not a big problem if you are alone on a server, but in combat sometimes its a difference between life and death. (you make a sidestrafe but it moved you too far showing your half body to your enemy.
Comments
Aliens are basically always run, hold the modifier key to walk and the Marines are always walk hold the modifier key to run.
Skulks are the only lifeform with a walk key.
They said theyve been studying ns1 tf2 to get the 'feel' right.
So it is tied to one of the major deficiencies of the engine in its current state. Mouse lag, same thing. That's why it doesn't feel quite right.
This is an ok feature if the vents are orifices in the DI and you are pushed out of a sphincter of sorts but that a metal frame should push one like that makes no sense to me.
also, speaking of vents, as marine I jumped into some vents to only get stuck in them, and wasn't able to get out either.
I've adjusted this in the next patch, let me know if it's still not right.
I'd suggest some slight exponential accelleration, so short quick movements are more precise (cover less distance) while the overall speed of the character remains the same when movement keys are pressed/held for longer durations.
60 seconds in mspaint (exaggerated, not to scale):
<img src="http://img515.imageshack.us/img515/3218/ns2exponentialspeedincr.png" border="0" class="linked-image" />
"speed" = movement speed
"time" = how long the move key is pressed
blue line = ???
red line = proposed acceleration curve
might be useful to graph distance vs time as well
Blue line is the current velocity curve.
Red line is the proposed velocity curve.
Horizontal line just represents max speed.
Time is time held down.
Just gotta integrate velocity for distance I believe. Not quite sure what the equation for proposed acceleration is though.
You could just have acceleration change constantly with time:
e.g.
vmax = 1, treachmax = 1
... current acceleration
k = vmax/treachmax
a = k
v = k*t
s = 1/2*k*t^2
k = 1/1 = 1
for t = 0.5
a = 1
v = 1*0.5 = 0.5
s = 1/2*1*(0.5)^2 = 0.125
... proposed (not exponential) acceleration
k = 2*vmax/(treachmax^2)
a = k*t
v = 1/2*k*t^2
s = 1/6*k*t^3
k = 2*1/(1)^2 = 2
for t = 0.5
a = 2*0.5
v = 1/2*2*0.5^2 = 0.25
s = 1/6*2*0.5^2 = 0.08333
a is acceleration, v is velocity (speed), s is displacement (distance)
Oh, I thought you instantly hit max speed as soon as you move in a direction, thats what it looks like from the vid posted.
For example, the Lerk walk acceleration is 115, while its walk max speed is 2.8; this means it takes 0.02435 seconds to reach max speed.
By comparison, a marine's run acceleration is 200, max run speed of 5; so 0.025 seconds to reach max run speed. A marine's sprint acceleration is 300, max sprint speed of 6.25; so 0.02083 seconds to reach max sprint speed from rest.
All about the same. All very, very quick.
To illustrate the benefit of variable-acceleration:
<img src="http://img258.imageshack.us/img258/7391/ns2proposedspeedincreas.png" border="0" class="linked-image" />
As you can see, the variable-acceleration velocity curve for tmax=0.5 is lower than even the constant-acceleration velocity curve for tmax=1, for most of the duration. Basically what this means is you could have a shorter time to reach max speed, but still maintain more control over the lower time periods.
Movement latency is the devil.
If tuned right and in a game without <input latency>, choosing how briefly you want to press the key would determine how precise your movement is.
A quick tap gives you a tiny movement and slightly firmer tap results in a substantial movement difference... so I would GUESS that engine takes into account the time the key is depressed for and uses that in a velocity based increase in momentum, there is also a de-acellerate phase as the player doesn't stop immediatetly after releasing the key.
Not so much of an opinion as a impression from my experience testing movement in TF 2 as a comparison ( doubt many would argue that TF 2 has bad movement ? ).
TF2 doesn't have BAD movement, but it's really not where the game shines.
NS, however, is all about movement.
Here are some design goals for good movement:
1) No latency. This also means no significant charge-up acceleration phase like you're a big truck.
2) Good interaction between deceleration and opposite direction key presses.
For example, this means if you're strafing right and add strafe left, it creates a different velocity curve than if you just let go of strafe right and tap left, and if you just let go of strafe right. For instance, you could quick stop if you hold both, but slowly decelerate if you just let go of strafe right.
3) Interaction with view direction. Simply, this means forward, backwards, and strafing all have different properties. But it can also be more advanced like in the popular competitive fps games, with features of air accel, etc. NS1 had "air accel" even on the ground, because if you turn left as you strafe left, you get a speed boost.
Creating a good movement control scheme involves making a grid of all possible combinations of key presses and timings, and making sure you're using every box in the grid for a certain purpose.
I'm not sure if the engine is currently holding the game back in this regard, as there seem to be some issues with input latency and responsiveness of the actual engine, even mouselook lags. So that should obviously be addressed.
In the friction function, it basically does this:
if(speed < stopspeed) then
speed = stopspeed
end
Makes the player stop "fast" when going under some speed
The movement was very good in ns1 but its a beta, so i hope they will fix it, special the movement and the fade teleportation, its very hard not end in walls...same with lerk.
Would be good if jump or alt = let the lerk hover
In the friction function, it basically does this:
if(speed < stopspeed) then
speed = stopspeed
end
Makes the player stop "fast" when going under some speed<!--QuoteEnd--></div><!--QuoteEEnd-->
I know this is already in NS's code. I believe it's <0.2.
*Oh wait, never mind. it's different. Instead it's: If speed < 0.2, then speed = 0.
Anyway, NS doesn't use force and momentum at all; only velocity, and sometimes it uses acceleration. Masses are in, but I've never seen it used. It could be that the movement code is placeholder, but I doubt it. Manipulating velocity is a lot quicker anyway, even if it is less versatile.
I'm not really sure what juice is suggesting, making it work more like a racing game? Pressing a direction works as the acceleration, pressing the opposite direction works as a brake?
What zex said: "all we're really saying with these graphs is that tapping the move key should result in small movements, and holding it down should result in large movements. The overall time it takes to reach maximum speed while holding down "W" doesn't need to change in order to accomplish this."
is pretty much all right, except that 0.025 seconds is clearly TOO quick to reach max speed (if you want any kind of control over the acceleration time), so that still does need to change.
Whatever other advantages you might attribute to it, constant acceleration is the most natural looking; that's a decent approximation of what happens in nature with everything from people, falling objects and cars when they are well below their top speed. As top speed is approached, acceleration smoothly drops off toward zero.
With constant acceleration you can turn in a narrow, circular arc in a predictable and intuitive way(going around in a circle is constant acceleration perpendicular to your direction of motion). With exponential acceleration nothing much will appear to happen at first; you're introducing an unwanted delay in turning corners at full speed. If you try to fix this by an ugly hack, such as having constant accleration when moving at higher speeds, then you need to adjust the speed for the movement of the ground below you if you ever introduce trains, moving platforms or conveyor of some sort.
If you are running at half speed, say, and you briefly let go of your button and then decide to run again, with constant acceleration you just continue, with exponential acceleration nothing much appears to be happening at first as you maintain your lackluster speed, and then a sudden burst up to top speed.
<!--quoteo(post=1825627:date=Jan 20 2011, 01:42 AM:name=zex)--><div class='quotetop'>QUOTE (zex @ Jan 20 2011, 01:42 AM) <a href="index.php?act=findpost&pid=1825627"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->[...]is that you can maintain precise control for small movements without nerfing overall accelleration time as badly as 1 second, which is ridiculous (50x slower??)<!--QuoteEnd--></div><!--QuoteEEnd-->
I think exponential acceleration will make fine control even worse. Constant accleration means that the distance covered when running in a straight line increases as a parabolic function in time; parabolas already have the sought after feature of increasing slowly at first, faster at later times.
If acceleration is an exponential function you will accelerate very slowly at first, seemingly not budging a smegging inch, then all of a sudden lurch forward.
Here are some plots. They are normalized so that after time 1 you have speed 1(in arbitrary units of time and distance).
<img src="http://img545.imageshack.us/img545/1940/constantaccel.png" border="0" class="linked-image" />
A(t) = 1 when t < 1; 0 otherwise.
<img src="http://img200.imageshack.us/img200/2939/linearaccel.png" border="0" class="linked-image" />
A(t) = 2t when t <1; 0 otherwise.
<img src="http://img441.imageshack.us/img441/3087/exponentialaccel.png" border="0" class="linked-image" />
A(t) = e^5t/N when t < 1; 0 otherwise. N is just a constant for normalizing acceleration so that the area under the curve is 1.
<img src="http://img96.imageshack.us/img96/4186/exponentialaccel2.png" border="0" class="linked-image" />
A(t) = e^10t/N when t < 1; 0 otherwise. N is just a constant for normalizing acceleration so that the area under the curve is 1.
In the time it takes to accelerate to full speed, some distance will have been traveled. At one quarter of that time some fraction of this distance has been traveled(i.e. s(0.25)/s(1)):
Constant: 6.3%
Linear: 1.6%
Exponential(k = 5): 0.87%
Exponential(k = 10): 0.039%
Same thing for half the time taken to accelerate to full speed(i.e. s(0.5)/s(1)):
Constant: 25%
Linear: 13%
Exponential(k = 5): 6.1%
Exponential(k = 10): 0.65%
Are you using matlab? Maybe you could upload the project files and pm me the link?