Question Best way to go about making destructible pixel terrain?

I'm in the early stages of a pixel game where digging/excavation is a rather key element. What would be the best way to make randomly generated pixel terrain that is completely destructible? Something like falling sand games or Noita (Pixel physics are not required but would be nice if its not too hard). Need a decent looking and good performance solution. Thank you in advance! :]

 

I would start with tutorials. There's plenty for "unity noita tutorial"

Tutorials and example code are great, but keep this in mind to maximize your success and minimize your frustration:

How to do tutorials properly, two (2) simple steps to success:

Step 1. Follow the tutorial and do every single step of the tutorial 100% precisely the way it is shown. Even the slightest deviation (even a single character!) generally ends in disaster. That's how software engineering works. Every step must be taken, every single letter must be spelled, capitalized, punctuated and spaced (or not spaced) properly, literally NOTHING can be omitted or skipped.

Fortunately this is the easiest part to get right: Be a robot. Don't make any mistakes.
BE PERFECT IN EVERYTHING YOU DO HERE!!

If you get any errors, learn how to read the error code and fix your error. Google is your friend here. Do NOT continue until you fix your error. Your error will probably be somewhere near the parenthesis numbers (line and character position) in the file. It is almost CERTAINLY your typo causing the error, so look again and fix it.

Step 2. Go back and work through every part of the tutorial again, and this time explain it to your doggie. See how I am doing that in my avatar picture? If you have no dog, explain it to your house plant. If you are unable to explain any part of it, STOP. DO NOT PROCEED. Now go learn how that part works. Read the documentation on the functions involved. Go back to the tutorial and try to figure out WHY they did that. This is the part that takes a LOT of time when you are new. It might take days or weeks to work through a single 5-minute tutorial. Stick with it. You will learn.

Step 2 is the part everybody seems to miss. Without Step 2 you are simply a code-typing monkey and outside of the specific tutorial you did, you will be completely lost. If you want to learn, you MUST do Step 2.

Of course, all this presupposes no errors in the tutorial. For certain tutorial makers (like Unity, Brackeys, Imphenzia, Sebastian Lague) this is usually the case. For some other less-well-known content creators, this is less true. Read the comments on the video: did anyone have issues like you did? If there's an error, you will NEVER be the first guy to find it.

Beyond that, Step 3, 4, 5 and 6 become easy because you already understand!

Finally, when you have errors, don't post here... just go fix your errors! Here's how:


Remember: NOBODY here memorizes error codes. That's not a thing. The error code is absolutely the least useful part of the error. It serves no purpose at all. Forget the error code. Put it out of your mind.

The complete error message contains everything you need to know to fix the error yourself.

The important parts of the error message are:

- the description of the error itself (google this; you are NEVER the first one!)
- the file it occurred in (critical!)
- the line number and character position (the two numbers in parentheses)
- also possibly useful is the stack trace (all the lines of text in the lower console window)

Always start with the FIRST error in the console window, as sometimes that error causes or compounds some or all of the subsequent errors. Often the error will be immediately prior to the indicated line, so make sure to check there as well.

Look in the documentation. Every API you attempt to use is probably documented somewhere. Are you using it correctly? Are you spelling it correctly?

All of that information is in the actual error message and you must pay attention to it. Learn how to identify it instantly so you don't have to stop your progress and fiddle around with the forum.

 

unity doesnt offer anything if you want to make a noita game, even drawing a pixel on screen is hard

 

I have looked for tutorials but none seem to actually explain how to go about making the script for pixel based physics, or even just destructible terrain in unity. I get the basic principle of it but I just don't know where to start. Thanks for the advice on tutorials and errors though!

 

Ah I see, I questioned using tilemaps but I figured a tilemap with millions of pixels wouldn't be very good performance wise.

 

Another option I have considered is that I'm using a pixel perfect camera so everything is pixel aligned, meaning I could make a mesh based destructible terrain. Seems like a bit of an easier option than per pixel calculations

 

An asset came to mind which might be useful or offer solutions you could work with, either directly or to learn from - I haven't used it personally [yet] but I've had it wishlisted on and off for ages. If I was doing a 2D game with destructible terrain and so on, I would start here. It's got a great rating and reviews, also on sale at the moment, has been in development for almost 10 years and latest update was just a few months ago.

 

youll never make it with tilemaps, just setting a 1 tile is already an expensive operation forget it

I guess what I want to say is that unity was not made to make noita

for example look how far you have to go to draw a pixelated line in unity:
https://forum.unity.com/threads/lin...e-renderer-for-unity-urp-2d-renderer.1021708/

I dont want to diss unity but it just doesnt have the feature to draw pixels

of course if you really push it YOU COULD MAKE SOMETHING WORK
but it will have horrible performance, tons of restrictions, you were better off using something like the noita devs used if you really want to make noita

 

Yeah I remember seeing this asset a while ago, I am definitely considering it as it seems easy to use. Just not really sure I want to pay for anything just yet in case there's a better solution. Thanks for reminding me of this though!

 

Yeah I see what you mean, gonna have to find some other way to do this then, however the Noita devs made their own game engine which I wouldn't even know where to begin doing that, plus I have experience in Unity so ill stick to that for now. However I'm thinking about using mesh based terrain like worms or something, then using the pixel perfect camera to give it a pixelated effect. Thanks for the advice though

 

for example it would be super nice for the line renderer to have a pixel perfect mode, and be able to sort it like a sprite renderer

 

That's not really where "pixel perfect" takes place.

Thought exercise: if a line renderer were to "handle" this, what would that line renderer do if you gave it a line with a slope of x = 1 and y = 10? That's why it just isn't the correct place to handle pixel perfection.

Pixel perfect is a function of matching camera view extent precisely to device output pixels and also source frame buffer pixels, or having only integer multiples of same.

Modern hardware has such extremely high pixel ranges today that many of the "pixel perfect" games out there today actually aren't. They only filter and snap, they don't enforce integer ratio multiples. If you study the output pixels they will not all be the same number of screen pixels across.

Integer ratios are far harder in the general sense as they entangle your UI presentation and spacing.

 

well what i mean is not actual pixel perfect just something that looks pixel perfect, and then would require additional effort to make pixel perfect like a normal sprite coming from a sprite renderer

if you made a line with x=1 and y=10 and you gave it a bad PPU, then its fair that it would give a buggy bad result

 

Starting is easy: how about make a 16x16 texture, put it onscreen, read its pixels in and try processing them the way the above video I linked shows you?

Then increase to 32x32... then 64x64... very soon you will begin to get a feel for what kind of processing you're up against, and realize you will need to optimize the inner loop of anything that considers an extremely high number of computations per frame.

Here, I just tried it. Full demo scene in my MakeGeo project. Source code:

https://github.com/kurtdekker/makeg.../Assets/Pixels/PixelTerrain1/PixelTerrain1.cs



EDIT: Added the ability to blow holes in the terrain, which collapse in down:



MakeGeo is presently hosted at these locations:

https://bitbucket.org/kurtdekker/makegeo

https://github.com/kurtdekker/makegeo

https://gitlab.com/kurtdekker/makegeo

https://sourceforge.net/p/makegeo

 

Oh thanks that's really cool! However would it actually be possible to give it a collider with this method? Also upon trying to increase the resolution it closer to something I need it seems to start loosing frames quickly. Also afraid I don't really know how GetPixels, SetPixels or any of that stuff works as I've never used it before so not too sure how much I would be able to replicate/modify something like this. Sure I'll be able to find a solution sooner or later. Thanks though!

 

Yes, at a significant performance cost. You would need to reconstruct the shape of the dirt as collider vectors / elements and put them into a GameObject that the physics engine can observe.

GetPix/SetPix are just the naive ways of getting this working, likely NOT the methods you will use for your final product.

You will want to focus on getting 100% of what you need working at a trivial pilot scale, such as 16x16 pixels for the entire game world.

The point of this step is to get your hands on all parts of your problem space.

Only once you have all the parts operational can you begin to contemplate scaling up.

As you scale up you are likely to encounter performance limitations and you can address them as you go.

This is engineering. It's not really like you can gloss over stuff and hope for the best and still make meaningful engineering contributions to your problem space.

Keep in mind you are doing something that no game engine does for you, at least in 2023.

 

Ah ok I see, I think I might use a different method for destructible terrain without per pixel physics as it seems far too complex for my current scripting knowledge. After all, per pixel physics aren't necessary for my game and were simply a potential bonus. Any idea on how I could make randomly generated caves with a destructible mesh based terrain system? Sorry for the inconvenience by the way and thank you for all the help so far :]

 

Probably about 10x times more complicated... be prepared for marching cubes and mesh synthesis and hurry over to Youtube for any one of the ten million tutorials on this.



Tutorials and example code are great, but keep this in mind to maximize your success and minimize your frustration:

How to do tutorials properly, two (2) simple steps to success:

Step 1. Follow the tutorial and do every single step of the tutorial 100% precisely the way it is shown. Even the slightest deviation (even a single character!) generally ends in disaster. That's how software engineering works. Every step must be taken, every single letter must be spelled, capitalized, punctuated and spaced (or not spaced) properly, literally NOTHING can be omitted or skipped.

Fortunately this is the easiest part to get right: Be a robot. Don't make any mistakes.
BE PERFECT IN EVERYTHING YOU DO HERE!!

If you get any errors, learn how to read the error code and fix your error. Google is your friend here. Do NOT continue until you fix your error. Your error will probably be somewhere near the parenthesis numbers (line and character position) in the file. It is almost CERTAINLY your typo causing the error, so look again and fix it.

Step 2. Go back and work through every part of the tutorial again, and this time explain it to your doggie. See how I am doing that in my avatar picture? If you have no dog, explain it to your house plant. If you are unable to explain any part of it, STOP. DO NOT PROCEED. Now go learn how that part works. Read the documentation on the functions involved. Go back to the tutorial and try to figure out WHY they did that. This is the part that takes a LOT of time when you are new. It might take days or weeks to work through a single 5-minute tutorial. Stick with it. You will learn.

Step 2 is the part everybody seems to miss. Without Step 2 you are simply a code-typing monkey and outside of the specific tutorial you did, you will be completely lost. If you want to learn, you MUST do Step 2.

Of course, all this presupposes no errors in the tutorial. For certain tutorial makers (like Unity, Brackeys, Imphenzia, Sebastian Lague) this is usually the case. For some other less-well-known content creators, this is less true. Read the comments on the video: did anyone have issues like you did? If there's an error, you will NEVER be the first guy to find it.

Beyond that, Step 3, 4, 5 and 6 become easy because you already understand!

Finally, when you have errors, don't post here... just go fix your errors! Here's how:

Remember: NOBODY here memorizes error codes. That's not a thing. The error code is absolutely the least useful part of the error. It serves no purpose at all. Forget the error code. Put it out of your mind.

The complete error message contains everything you need to know to fix the error yourself.

The important parts of the error message are:

- the description of the error itself (google this; you are NEVER the first one!)
- the file it occurred in (critical!)
- the line number and character position (the two numbers in parentheses)
- also possibly useful is the stack trace (all the lines of text in the lower console window)

Always start with the FIRST error in the console window, as sometimes that error causes or compounds some or all of the subsequent errors. Often the error will be immediately prior to the indicated line, so make sure to check there as well.

Look in the documentation. Every API you attempt to use is probably documented somewhere. Are you using it correctly? Are you spelling it correctly?

All of that information is in the actual error message and you must pay attention to it. Learn how to identify it instantly so you don't have to stop your progress and fiddle around with the forum.

Imphenzia: How Did I Learn To Make Games:

 

Fair enough, there seems to be plenty tutorials on this. (I probably should have checked before asking lol) Thank you for all the help though!