GML When NOT to turn on the physics system


When NOT to turn on the physics system

GM Version: GMS 1.x / 2.x
Target Platform: All
Download: N/A
Links: N/A
Summary: A summary of situations when the GMS physics system should be turned off.

This guide aims to document situations where the physics system should be turned off. If any of the following situations apply to you, you should handle movement manually. An appendix is included with a basic primer to manual movement.

Situation #1: You move things by setting positions directly instead of pushing and pulling.
The physics system is based on pushing and pulling instances with mass. If you are constantly setting the position, you are constantly breaking its continuity and violating its design.
The Manual's preface on the physics system said:
  • Try not to move instances from one point of the room to another in any way other than using the physics functions (ie: do not set the x/y coordinates manual). Although this can be done and in some circumstances it may be necessary, this is generally to be avoided due to the unpredictable results that it may have on the physics engine, especially when trying to resolve collisions.
It's fine to work on projects that move by setting the position, but you must not put a system designed not to do this in charge.

Situation #2: You are working on a project that isn't based on realistic Newtonian physics.
Just because things are moving, it doesn't mean you should use the physics system for it. Using the physics system implies a complete simulation of all linear and rotational dynamics, e.g. conservation of momentum, centre of gravity, action-reaction, etc. Examples of projects that should use the physics system include pool, pinball or the Angry Birds series. Anything not like these should be considered cartoon physics and have its movement handled manually.

Situation #3: You don't know what F=ma or J=mΔv is.
Using the physics system demands a firm understanding of classical mechanics, and the Manual has no time or business explaining the terms in detail. The two equations above are among the most basic that you should know ahead of time, being the definitions of force and impulse respectively. If you can't recognize or use these without getting help, you need to hit the books harder before you can call yourself ready to use it. Otherwise, everything you do with it would be a crap shoot, and that's no way to program.

Situation #4: You have yet to create your first game.
The physics system is designed with prior experience in mind, and filled with black boxes that only experienced eyes can see through. If you are creating your first game, you need to get face-on experience with manual movement to see how velocity and acceleration affects positioning. This puts you in a better position to apply, understand and appreciate the physics system's intricacies when the time comes to use it.

Situation #5: Your only exposure to the physics system is HeartBeast's RPG tutorial series or any others that manually set phy_position_x and phy_position_y.
The constant confusion brewed by these tutorials on the Q&A boards is why I wrote this article. You won't learn how to use the physics system properly with these, and you're bound to get even more muddled when traditional methods are offered to you around here. As a general rule, if a tutorial sets phy_position_x or phy_position_y twice or more, it is not done properly and not worth your time to watch.

Appendix: What if I need to handle movement manually? Quick primer for manual movement:
Movement is simply a step-by-step change in positioning. When the physics system is off, changing x and y is the way to achieve this. You can do this gradually for smooth movement, or jump directly to a new position for a sudden change.

Linear velocity and accleration

The most basic movement scheme is movement in a horizontal or vertical line at a constant rate. With built-in variables, set hspeed or vspeed. For manual handling, declare your own x- and y-velocity variables, then change x and y by those amounts every step:

// Initialize velocities
// As an example, this moves straight down
vx = 0;
vy = 4;
// Move
x += vx;
y += vy;
You can extend these by adding an acceleration, the rate of change in velocity. With built-in variables, set gravity and gravity_direction together. For manual handling, it does to velocity what velocity does to x and y.

// Initialize velocities and accleration
// As an example, this starts out moving to the top-right, then accelerates downwards
vx = 4;
vy = -4;
ax = 0;
ay = 0.05;
// Move
x += vx;
y += vy;
// Accelerate
vx += ax;
vy += ay;
Directional Movement

It is also possible to move based on a fixed speed with a direction instead of separate x and y components. With built-in variables, set direction and speed. With manual handling, you can use lengthdir_x() and lengthdir_y() to convert to an equivalent in x- and y-velocities.

//Initialize speed and direction
//5 per step north-east
spd = 5;
dir = 45;
x += lengthdir_x(spd, dir);
y += lengthdir_y(spd, dir);


In velocity-based movement, it is usually a good idea to also define maximum velocity that is used to truncate the length of velocity vector. But I guess infinite acceleration may also suit some types of games.


Thanks for the great write-up. I agree with pretty much every bit of this. I do have a question though. What do you think about using the physics system for random elements of the game but not really to run the entire thing?

For example, a twitch platformer game with some cloth attached to the main character. The cloth is ran by the physics system but just follows the player. I believe I've seen this in one of the platformer assets on the marketplace. I'm not really trying to debate the legitimacy of it. I'm just genuinely interested in what you think about this and if there are better ways to handle stuff like this. I've always really valued what you have to say on these forums. If I'm being completely honest I would actually really enjoy it if you started a YouTube channel.