OFFICIAL Physics In GameMaker Studio 2 - Part 1

rmanthorp

GameMaker Staff
Admin
GameMaker Dev.
Hey! We're back again with another series of remastered GMS2 tech blogs.
This 4 part series covers Physics! Check it out:

Today's tech blog takes form of a mini-tutorial, where we will be making a small physics simulation and at the same time we'll discuss some of the issues that people come up against when transitioning from the "traditional" GameMaker Studio 2 approach to movement and collisions to the physics approach.

INTRODUCTION
Even the most advanced users can be confused when using GameMaker Studio 2 physics for the first time, so we'll start this tutorial with probably the most important piece of advice we can give... Forget everything you know about how GameMaker Studio 2 deals with collisions and movement! Why? Well, when you enable physics in a room, you are changing how everything will interact at a very basic level within GameMaker, and this makes the built in variables like speed and direction obsolete. However, it does enable a whole bunch of specific physics variables which can be used instead.

The other major change that happens when you enable physics is that collisions will be handled automatically for you. With "traditional" GameMaker collisions you would have a Collision Event and then have some code or action in there to deal with what happens, but - with the physics enabled - the collisions will be resolved by GameMaker automatically, with bounce angles and velocities etc... being calculated and applied for you.

So, with that warning out of the way, lets move on and get started making a simple physics simulation... You'll need to make a new GML project in GameMaker Studio 2 and open the Room Editor before continuing.
https://www.yoyogames.com/blog/69/physics-in-gamemaker-studio-2-part-1
 

curato

Member
I must say, Yoyo has definitely increased the quantity and quality of their blog entries lately.
 

GMWolf

aka fel666
Very good post.
Is there a good way to get just the collision detection part of box2D in GM?
 

DBenji

Member
Thank goodness. Was beginning to think YYG might abandon box2D because (apparently) so few use it. It's actually quite difficult trying to find information about how to use it properly on the forums and there also seems to be somewhat of a stigma against it - which is a real shame because GM's box2D offers way more performance-wise (when you're trying to simulate things like ropes for example) than creating your own physics calculations and running them every frame.
 

FrostyCat

Redemption Seeker
Thank goodness. Was beginning to think YYG might abandon box2D because (apparently) so few use it. It's actually quite difficult trying to find information about how to use it properly on the forums and there also seems to be somewhat of a stigma against it - which is a real shame because GM's box2D offers way more performance-wise (when you're trying to simulate things like ropes for example) than creating your own physics calculations and running them every frame.
There has never been any stigma in the GMC against using Box2D, just a lot of ignorance in its best practices and also in basic physics theory in general.

What there should be stigma against is improper usage of Box2D that constantly sets phy_position_x and phy_position_y HeartBeast-style.
 

DBenji

Member
There has never been any stigma in the GMC against using Box2D...
"Never" is a strong word. That would mean I need only find one occurrence to technically disprove your statement. But perhaps I'm confusing "stigma" with the tendency of veterans to discourage newbies from the using the system - which is still surprising considering how Unity devs encourage the use of rigidbody2ds and physics2d.raycasting to any newcomers.

Regardless, I feel there has been a lack of resources on how to use GM's box2D properly. For instance, I've seen a couple members suggest using collision-checking functions like place_meeting with physics objects (instead of physics_test_overlap) is perfectly fine and useful, but the docs are completely silent on whether or not this is good practice.
 

FrostyCat

Redemption Seeker
"Never" is a strong word. That would mean I need only find one occurrence to technically disprove your statement. But perhaps I'm confusing "stigma" with the tendency of veterans to discourage newbies from the using the system - which is still surprising considering how Unity devs encourage the use of rigidbody2ds and physics2d.raycasting to any newcomers.

Regardless, I feel there has been a lack of resources on how to use GM's box2D properly. For instance, I've seen a couple members suggest using collision-checking functions like place_meeting with physics objects (instead of physics_test_overlap) is perfectly fine and useful, but the docs are completely silent on whether or not this is good practice.
You're completely mischaracterizing the reason why veterans make the discouraging posts.

We don't have an issue with rookies using Box2D if they do it properly in an informed manner, and only on games that benefit from lifelike physics as opposed to cartoon physics (e.g. pinball, Angry Birds). The issue is that too many rookies start using Box2D with no theoretical background in physics nor desire to at least learn the basic terms. To make matters worse, their first exposure to Box2D is too often the defective "jump with phy_position_x and phy_position_y as though physics is off" technique from HeartBeast's RPG tutorial. It's easier to tell off these people than to hold their hand.

With more formal, technically sound coverage of the physics system, perhaps the rookies will turn to better instructors and not have to be told off by Q&A responders for misusing Box2D in contexts where it has no place.
 
Top