Trying to set up a resource friendly destructible physics terrain...

Yavga

Member
Hello Community,

I am making a game for Game Maker Studio 2 and I learned a bit about the physics in-depth already,

I had an idea for a game but I’m stuck at something maybe on of you have a solution for.

My game is a physics platformer where the physics are an absolute must for me because of the way the interaction with the environment works so far.

(swinging ropes, using momentum, picking up object and throwing them) the physics make my game a lot more fun to control.

Now I am about to enter a new phase

I am about to create a grid of small blocks/triangles that you are able to chip away with a pickaxe, a mining element. But regretably Game Maker Studio isn’t really able to handle a lot of physics objects at once, now I saw this game Glitch Witchesand the way the terrain functions is exactly what I need, I tinkered a bit with the source code to try out the limits of the game and magically it can handle A LOT at once. Something I couldn’t manage on myself so far.

Regretably I don’t even begin to understand how this code works (I can to a certain extend make an educated guess) and Google only gives me a lot of information through some (sometimes dated) Box2D tutorials that are on a level I can only hope to fathom one day.

Is there any tutorial out there that can help this beginner out in order to create his own resource friendly physics terrain system in GMS2 or does anyone possibly know/have a source or asset that I can learn from?

I would greatly appreciate any kind of help or pointers, I don’t have a background in programming but I am trying to learn what I can on my own.

Encosed is a video that shows what I am trying to make, except these “mineable blocks” take up ALOT of resources, adding about 50 more of these will get the FPS under 60. (now at about 120)

https://www.liveleak.com/view?t=9fBx9_1553605315
 

Yavga

Member
I tried implementing this in a large grid:
https://marketplace.yoyogames.com/assets/2411/breakable-physics-wall-or-box

But the problem is apparant the moment I start adding more of these blocks,
I conclude Gamemaker is not supposed to to be used this way (a lot of collision objects in a physics world at once)

So what else? When I try to dive into this through Google it tells me a few options but these are so advanced I do not know where I should begin to learn.

There’s triangulation which apparantly is able to slice a lot of polygons together into a mesh of triangles, than I should be able to address the individual fixtures in this mesh in order to delete them on contact?
This way I would circumvent the problem of the object count?
...Does that sound correct? Any pointers at all would be ace.
 

Juju

Member
Glitch Witches takes advantage of Box2D's physics system. If you want "realistic" physics in GameMaker then that's your best choice.

GW treats terrain as meshes made from many, many triangles. The process of breaking down a shape into a collection of triangles is called "triangulation", and GW creates terrain by triangulating sprites. Each mesh is an object inside GameMaker with dozens (if not hundreds) of polygonal Box2D fixtures attached to each mesh, each polygon being a triangle. This means that Box2D treats the entire mesh as one object with one centre of mass even though it's comprised of lots of triangles. Meshes record the position of each triangle relative to the mesh's centre of mass, and importantly, which triangles are connected to which triangles. These triangle-triangle connections form a network.

When an explosion goes off, triangles are deleted from whatever meshes are in the explosion radius. Each affected mesh performs a floodfill across its network and works out which triangles (if any) have been detached from the mesh's centre of mass. Triangles that have been detached get put into their own mesh. Any fixtures that no longer need to be handled by Box2D are destroyed. Since the new mesh is disconnected from the old mesh, the new mesh can now move freely. This gives you dynamic and responsive terrain which can be deformed.

This is all networked too, and I have no idea how I managed that, so let's not dwell on that aspect. I'm content with this solution in general, and it seems to be an effective solution, if a bit clumsy in places. I wrote Glitch Witches in a little under two weeks.

The reason this runs at a reasonable framerate is because the number of objects is very low - it's rare you'll get more than 20-or-so physics objects. Box2D is doing all the heavy lifting because single objects contain many fixtures. If you want to implement a similar system in another project, you'll need to put a limit on how many GameMaker objects you have in your world. Box2D is decently fast, but GameMaker doesn't like lots of objects (especially physics objects).
 

Yavga

Member
Glitch Witches takes advantage of Box2D's physics system. If you want "realistic" physics in GameMaker then that's your best choice.

GW treats terrain as meshes made from many, many triangles. The process of breaking down a shape into a collection of triangles is called "triangulation", and GW creates terrain by triangulating sprites. Each mesh is an object inside GameMaker with dozens (if not hundreds) of polygonal Box2D fixtures attached to each mesh, each polygon being a triangle. This means that Box2D treats the entire mesh as one object with one centre of mass even though it's comprised of lots of triangles. Meshes record the position of each triangle relative to the mesh's centre of mass, and importantly, which triangles are connected to which triangles. These triangle-triangle connections form a network.

When an explosion goes off, triangles are deleted from whatever meshes are in the explosion radius. Each affected mesh performs a floodfill across its network and works out which triangles (if any) have been detached from the mesh's centre of mass. Triangles that have been detached get put into their own mesh. Any fixtures that no longer need to be handled by Box2D are destroyed. Since the new mesh is disconnected from the old mesh, the new mesh can now move freely. This gives you dynamic and responsive terrain which can be deformed.

This is all networked too, and I have no idea how I managed that, so let's not dwell on that aspect. I'm content with this solution in general, and it seems to be an effective solution, if a bit clumsy in places. I wrote Glitch Witches in a little under two weeks.

The reason this runs at a reasonable framerate is because the number of objects is very low - it's rare you'll get more than 20-or-so physics objects. Box2D is doing all the heavy lifting because single objects contain many fixtures. If you want to implement a similar system in another project, you'll need to put a limit on how many GameMaker objects you have in your world. Box2D is decently fast, but GameMaker doesn't like lots of objects (especially physics objects).
Thanks a bunch Juju! This will help out a lot, probably others as well!
 

Yavga

Member
Glitch Witches takes advantage of Box2D's physics system. If you want "realistic" physics in GameMaker then that's your best choice.

GW treats terrain as meshes made from many, many triangles. The process of breaking down a shape into a collection of triangles is called "triangulation", and GW creates terrain by triangulating sprites. Each mesh is an object inside GameMaker with dozens (if not hundreds) of polygonal Box2D fixtures attached to each mesh, each polygon being a triangle. This means that Box2D treats the entire mesh as one object with one centre of mass even though it's comprised of lots of triangles. Meshes record the position of each triangle relative to the mesh's centre of mass, and importantly, which triangles are connected to which triangles. These triangle-triangle connections form a network.

When an explosion goes off, triangles are deleted from whatever meshes are in the explosion radius. Each affected mesh performs a floodfill across its network and works out which triangles (if any) have been detached from the mesh's centre of mass. Triangles that have been detached get put into their own mesh. Any fixtures that no longer need to be handled by Box2D are destroyed. Since the new mesh is disconnected from the old mesh, the new mesh can now move freely. This gives you dynamic and responsive terrain which can be deformed.

This is all networked too, and I have no idea how I managed that, so let's not dwell on that aspect. I'm content with this solution in general, and it seems to be an effective solution, if a bit clumsy in places. I wrote Glitch Witches in a little under two weeks.

The reason this runs at a reasonable framerate is because the number of objects is very low - it's rare you'll get more than 20-or-so physics objects. Box2D is doing all the heavy lifting because single objects contain many fixtures. If you want to implement a similar system in another project, you'll need to put a limit on how many GameMaker objects you have in your world. Box2D is decently fast, but GameMaker doesn't like lots of objects (especially physics objects).
on that note, I managed to seperate and isolate the terrain generation code from everything else and managed to utilise it fully in my own projects' assets. The game you used it in is open-source; but do other creators/developers have permission to use the code in commercial projects/What is your policy?
 

Juju

Member
"Open source" isn't the same as a permissive license, as I think you're probably aware, and the project is technically All Rights Reserved. Having said that, in this specific case I think it's more helpful for this to be available with as few barriers as possible.

You have permission to use the code and technique in a commercial closed source project for free with the stipulation that you must credit me properly, in full, using the following: "Deformation Programming: Juju Adams". This permission does not extend to the shaders, art, or audio assets (other people made those, not me!). If you find bugs, I cannot promise that I'll be able to fix them - I will try to help when and where I can, but I'm a busy boy these days. Please do not republish this code in an open source project without my consent.

It'd be nice if you tag me in other posts too so I can follow your progress, but I won't get mad if you forget. If you'd like me to retweet anything to my meagre following on Twitter, you're welcome to ask too.
 
Top