GML How to do Pixel Based Terrain?

H

Harper

Guest
Hi all,
I'm trying to figure out the best practice for pixel based terrain and I'm looking for answers. Something like worms that isn't tile based. My idea right now is to divide my map up into square sectors, and assign each of those sectors a object with a sprite on it that I want the terrain to be. From there I can create simple collisions but I don't think I can make destroy-able land with that method, which I think I want to implement into my game. If you want context, I'm making a open world scuba diving game, however I might try to make it rogue like instead of open world so that I can learn procedural generation.

Thanks!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
The most common way to do this would be to use surfaces to create the landscape sprite and then use the different blend modes to "punch" a hole in the surface and recreate the sprite. The GM48 game "Dweller of the Depths" does this quite well and is a nice simple example to start with. Check it out here: https://gm48.net/game/310/dweller-of-the-depths Click the arrow on the Download button and select "Project" to get the GM:S 1.4 source code (which can be imported into GMS2) and then check out the object obj_terrain.

There's also a number of tutorial vids on YouTube that could help you, for example (this one is for GMS2):

Finally, you may want to consider an asset from the MP like mine ;) (which uses a completely different approach with primitives and the marching squares algorithm): https://marketplace.yoyogames.com/assets/8179/dynamic-destructible-terrain
 
H

Harper

Guest
Check this:
GML - Slopes and Platformer Movement for Beginners | GameMaker Community
https://forum.yoyogames.com/index.php?threads/slopes-and-platformer-movement-for-beginners.42064/
I appreciate the effort but I'm not sure if this is exactly what I'm looking for... It doesn't provide any actual info on destructible terrain and it mostly just focuses on collisions which I believe I already know how to handle. I'm also trying to find out if using objects with sprites set as terrain is the best practice if I'm creating a pixel based terrain, and there was criticism in the comments so I'm skeptical...
 
H

Harper

Guest
The most common way to do this would be to use surfaces to create the landscape sprite and then use the different blend modes to "punch" a hole in the surface and recreate the sprite. The GM48 game "Dweller of the Depths" does this quite well and is a nice simple example to start with. Check it out here: https://gm48.net/game/310/dweller-of-the-depths Click the arrow on the Download button and select "Project" to get the GM:S 1.4 source code (which can be imported into GMS2) and then check out the object obj_terrain.

There's also a number of tutorial vids on YouTube that could help you, for example (this one is for GMS2):

Finally, you may want to consider an asset from the MP like mine ;) (which uses a completely different approach with primitives and the marching squares algorithm): https://marketplace.yoyogames.com/assets/8179/dynamic-destructible-terrain
Thanks! I'll definitely check this out when I get home. For some reason the site is blocked on my school wifi...

Edit: Also I was looking at your asset earlier today lol, this is not the first I've come across it!

Another edit: I'm looking into the marching squares algorithm... This is awesome, I might try to implement it into my game without using your awesome asset.
 
Last edited by a moderator:

Nocturne

Friendly Tyrant
Forum Staff
Admin
Another edit: I'm looking into the marching squares algorithm... This is awesome, I might try to implement it into my game without using your awesome asset.
Good for you! It can seem intimidating at first, but it's actually not that tough to program and is very useful for all sorts of things. Check out our tech blog by Banov about his upcoming game "Chicory"... it gives some great info on how he implemented the algorithm: https://www.yoyogames.com/blog/530/how-painting-works-in-chicory-a-colorful-tale
 

Yal

šŸ§ *penguin noises*
GMC Elder
The core idea behind how Unreal Engine and some other engines does advanced collision shapes is by having a list of "fills" and "holes" (not sure if those are the actual terms) which are basic shapes like circles or cubes. As you blow things up, you add new hole entities to this list. To make a collision check, you list all the collision entities that intersects that point. If there is a filled entity there, there's a collision... unless the point also intersects a hole entity, which means whatever object was originally there was destroyed at least partially. (Reconstruction and more complex shapes are handled with fills being able to supersede holes hierarchically, and in turn be superseded by other holes - the simplest way to handle this is to just check whichever entity was spawned last: if it's a hole, there's no collision, if it's filled, there's collision... and if there's no entity, there's no collision)

So what's the idea with this system? It's that you can recreate the surface data from knowing where the holes and fills are, and that it's fast (you might only need to iterate through a list of a few dozen shapes at most to see if there's a collision, and it's simple rectangle/circle maths checks while surface_getpixel and its ilk, color comparisons etc are notoriously slow because of CPU <---> GPU communication delays to access VRAM and all sorts of fun technical stuff)
 
Top