Player Movement Control Correction

[BenCheung0422]

Original: MinicraftPlus/minicraft-plus-revived#172 and MinicraftPlus/minicraft-plus-revived#199 (comment)

Background

In the original integral coordinate system, player movement is controlled by the 4 directions. Each one controls an addition or subtraction based on one axis, so for diagonal movement, 2 axes incremented as same as just both of them incremented respectively. By vector addition, the movement magnitude is in fact $\sqrt{2}$ but not just always 1, which is inconsistent. This system is also unfavorable for controller joysticks. It is quite inevitable for the original system, but with (Revamped Spatial System), it is now possible.

Details

To standardize the movement control logics for both keyboards and controllers, they would now control the direction of the same unit vector. Obviously, the controller's joystick would control the vector directly, though there could be advanced speed control by that, but that is another part. For keyboard, since theoretically 8 even directions with each separated by 45 degrees can be inputted, in addition to 0°, 90°, 180° and 270°, there would be 45°, 135°, 225° and 315°. The entire movement calculation process can be in polar coordinates, so the resultant deltas can be calculated by atan2.

It is the theory, but the code for keyboard could be verbose. The more universal way is to calculate the "averaged" direction by the set of directions. For each arrow/WASD key, a direction is inserted into the set; if either summed x or z component, the result would be directly used; else the new angle value is calculated by atan2 of the sum of Cartesian coordinates of the set, and x and z are recalculated by $\cos{\theta}$ and $\sin{\theta}$ respectively. This way, if the resultant angle is a multiple of right angle, the value can be sharp, since there would be no floating point error on the zero components.

The other part is player movement process ticking. The original speed is actually $\frac{1}{16}$ m/tick or 3.75 m/s, but a tile would no longer be divided into 16 units or pixels. While Minecraft walking speed is roughly 4.317 m/s, this might be enough. On the other hand, though inputs are captured by GLFW, it might not be a good idea to do game updates based on frame rates, but the constant ticking rate. So, the speed calculation could be more consistent. Suppose TPS is 20, the speed per tick could be 0.2 m/tick, so that it could be 4 m/s. In each game tick, the input is checked, so a movement can be made, and it could be somehow independent on frame rates.

See Also

• Rebalancing Game Ticking Rate #18
• Revamped World Spatial System #20