As a Roblox developer, it is currently too hard to create diagonal movement using the GroundController when the AccelerationTime and DecelerationTime differ a lot.
The way that a GroundController currently chooses if it should use AccelerationTime or DecelerationTime seems inconsistent and/or unnatural. This can be noticed when using a GroundController with a very low AccelerationTime and a very high DecelerationTime. In the video below I created a model with a single Part that is controlled by a ControllerManager.
- AccelerationTime is set to 0.05
- DecelerationTime is set to 1
In the video you can see me trying to accelerate diagonally, but because I (purposefully) press the WASD keys just slightly out-of-sync, the object suddenly accelerates very slowly to the diagonal movement vector. Only if I press the two keys within a single frame of each other does the object immediately accelerate diagonally.
It took me a while to figure out why character movement in my game felt ‘off’ until I started looking into it more. I even considered filing this as a bug report at first, but I believe this behavior - although awkward - is actually expected behavior.
That brings me to this feature request. I would like either better control over when the engine decides that a controller is ‘decelerating’, or improved decision making which solves the highlighted issue where diagonal movement requires the user to time their keypresses very accurately.
Currently I have to use the following code to work around this issue:
local GroundController = Controller:WaitForChild("GroundController")
local defaultDeceleration = GroundController.DecelerationTime
GroundController.DecelerationTime = GroundController.AccelerationTime
Controller:GetPropertyChangedSignal("MovingDirection"):Connect(
function()
if Controller.MovingDirection.Magnitude > 0 then
GroundController.DecelerationTime = GroundController.AccelerationTime
else
GroundController.DecelerationTime = defaultDeceleration
end
end
)
This way the character is always considered to be accelerating until they completely stop moving.
Although the code itself is not very complex, requiring the understanding of why movement ‘feels weird’ and that this would solve the above problem does add unwanted friction to an otherwise very intuitive feature.