4
\$\begingroup\$

I am writing a simple 2D game in Rust, having access to the following dependencies:

The genre is Metroidvania, the game features a single map Super Mario style, where the player can only move backwards and forwards and jump (and throw attacks). Modern games, such as Hollow Knight just to give an example, allow the player the same type of movements and they are very smooth.

I have never developed a game with these features, and from my first attempts now it looks like developing these smooth movements is harder than I thought it would be.

I have thought of several alternatives in order to move the player, but I am not sure which of these approaches is the best one or if there are others that are even better:

  • Do not rely on the physics engine at all and implement the movements just by changing the position of the graphics (shapes/sprites...). I personally didn't try this one because it sounds like a lot of work that does not guarantee good results.
  • Implement the movements by setting the velocity of the player through the physics engine.
  • Implement the movements by applying a force to the player through the physics engine.

I guess the answer would also depend on how to handle the user inputs properly and link them to the player movements, since they are very strictly related to each other.

\$\endgroup\$

2 Answers 2

1
\$\begingroup\$

You should use forces to play nice with your physics engine, but you've got to be careful about how to apply them.

One point I'd like to make is that if you do use forces, you should do so to servo to a desired velocity, rather than applying a constant force. What the player expects in a platformer that their character will move at a constant velocity in the direction they desire (maybe with very slight delays). They don't expect the character to get faster and faster. They also don't expect the character to have a lot of inertia when stopping.

So, each time you get input from the player, interpet it as a desired velocity. Compare this to your current velocity, and apply a correcting force proportional to the difference between the two. You can then adjust how "smooth" the change in velocity is by filtering or clamping the forces.

\$\endgroup\$
2
  • \$\begingroup\$ what does to servo mean? (not English native speaker, and dictionary not very clear in this context : wordreference.com/definition/servo) \$\endgroup\$
    – Pac0
    Commented Sep 18, 2020 at 8:12
  • \$\begingroup\$ it means to attempt to match. \$\endgroup\$
    – mklingen
    Commented Sep 21, 2020 at 12:36
0
\$\begingroup\$

Unfortunately, smooth and responsive are kind of opposites on a spectrum.

For the smoothest control, you set force, which leads to acceleration, which leads to velocity change which leads to position change.

Setting forces will also be a lot friendlier to your physics engine. If you start setting positions or velocities, the physics engine will get confused. At the very least, you'll be very prone to setting the objects into a colliding state.

This indirect steering via forces, will make feel the control less responsive to the player, though.

If the player presses JUMP, he wants to jump now, and not wait for acceleration to play out.

But if you go for maximum realism, forces are the way to go. And you do have the option to use very high forces too, to hide the inertia of your game objects.

In conclusion, it kind of depends on your game genre. A game like PONG would definitely require setting of positions for optimum responsiveness. A racing game should only use forces, otherwise the physics will look very fake.

\$\endgroup\$
1
  • \$\begingroup\$ If the player presses JUMP, he wants to jump now, and not wait for acceleration to play out. It doesn't work in every game, but "hold the jump button to charge your jump" tends to works as an acceptable compromise. At least for games where you want fine control over your jump height, which for physics-oriented games is usually the type of control a player wants. \$\endgroup\$
    – Flater
    Commented Jun 17, 2019 at 14:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .