because the video was so nice to watch, that he has to tell its authour that he's gonna have to make more videos without any concern for his wishes and needs. i think that being very sorry for this kind of statement is quite fitting, as the author might not want to make videos, and nobody should be able to tell him what to do. would you want to be told, that you made a good video, so make more? anyways, would you mind showing me your fidget spinner?@@TheEggToBehold
One of my first forum bans on the internet was the falling sand game forums. I crashed the server by trying to roll 100000d1000000 dice in the IRC chat.
I was banned because I worked a lot with a modder named Pyromaniac who made a game called PyroSand (or something like that?). And he went and created a new forum to compete with the fallingsandgame forums, the admins didn't like that and banned him, and because I worked with him, the admins just assumed I was affiliated with him and banned me too. I ended up going to his forum because of that even though I didn't originally plan to
@@gsami1256 dude seriously its insane to me how many small games projects just have some story like that. where some people are working on a new thing and try to make a different forum and they get banned for it. the discord kids have no clue what sort of feudal shit occurred on The Boards
I really liked how you made this video! I'm also an avid TodePond watcher. It's pretty cool seeing you go through the same bugs and ressources I did when I wanted to create a falling sand game. Much love and encouragement on your future projects! You have talent!
Nice video! It's a good start for working with reaction-diffusion equations from fluid dynamics. It's a branch of physics/biochemistry where elements in your biome diffuse themself in the environment through thermodynamic laws (what you have done so far) and react to other elements. For example you can have a fish sand particle that will eat algae and poop seeds. Watchout though, this domain is so vast and rich that you can easily be hooked for a while 😉
I'm of a younger demographic, but my main experience of this genre was through this game called Powder Toy which for some reason was installed on all my schools computers. Fun to make H bombs in lol
I made this week something like this too. But with water, wood, stone, lava, glass, acid and smoke. Like Sandboxels (1:35). Coincidence this video showed up in my homepage (or youtube knows ":))
4:00 - THANK YOU!! I also had trouble with my sand being biased to fall on one side or the other, depending on buffer traversal direction, and I couldn't for the life of me find any mention of this on the Internet, let alone a solution.
It was an odd bug to track down. I thought I'd messed up the diagonal falling code for a little while. A similar issue happens if you don't randomize the direction the water disperses in as well. You start getting water "pooling" uphill in one direction and very slowly leveling out over time. Assuming you implement it like I did, anyway
Hell of Sand, now THAT'S something i havent thought about in ages. I mostly spent time exploding things in those sims. Thanks for unlocking that memory 👍
8:35 ... I'm by no means a rust developer... but ... just define getter functions in your traits for the properties you need, and in the implementation have a baking field.... (you probably don't even need a baking field, I guess, since most of your values would be quite constant anyways per type!?) but yeah, I guess ECS might even be better in terms of performance, since you do not bloat everything with a lot of potentially-used-fields, and the fields you're using are usually quite good memory aligned if everything is done right.
Awesome video, the only way to make it better would be to include more Ark and Kerrigan. Can't help but list my own favorites: dan-ball's powder game includes a basic cellular automata wind simulation! OE-CAKE and phyzios studio still have an active community around them. There's some really good source code on shadertoy if you search for falling sand. My own hunch on how to approach powder sims is that you shouldn't worry about general solutions. Each powder type is going to have its own concerns and code it has to run, and what matters is that the overall effect looks good. So, hacky solutions where the behavior depends on the update order, weird interleaving, bitwise tricks, are all A-OK. But I haven't published a powder game so take that with a grain of salt.
I hadn't thought of those videos for years before making this, lol. I have a bad habit of abstracting too early in programming. It always feels like there should be a more clever solution and brute forcing is "wrong" haha. I'll have to check out the ones you mentioned!
Hmm. For the problem about not wanting to store all the data in the grid I would probably just link the id of particles to a list of dyn Particle trait objects which can be a simple lookup that allows access to any abstract function for interaction which means you could simplify the process have introducing more particle types. Realistically u would probably want look up tables to just go from Id to a struct of data references and function pointers that hold all the different functionality. This means both sand and gravel have the same movement criteria by referencing the same function pointer but could have different function pointers for reaction with water for example
Yeah! I played around with it for much longer than I meant to when researching for the video, haha! There was a lot of interesting mechanics, but I really liked the weather effects! I played around with the temperature changes for quite a while too.
so far, everything is dependent on gravity falling down, so it would be difficult to add magnets or change the gravity direction. Everything moves at the same speed with a binary pressure. if every type has a density, you can calculate the slope of the density in the direction you are moving, so it works the same moving in any direction. each particle could have an angle of repose. You could also add a panning displacement map, that makes the grass and kelp wave, with a gradient towards their roots so the root doesn't wave as much as the top.
Hmmm... I wasn't planning on pushing this to be that complex, but these are some cool ideas. I may have to try some of that out! Thanks for the suggestions!
I used to play this one falling sand game that would sprout these super complex trees from seeds, and had LSD. If any living creature touched LSD, the whole screen would go into LSD mode.
For a rules manipulation interface, you might consider treating the inputs as a sort of "2d regular expression" -- which gives an obvious answer for how to make it fast, and that's compiling those regexes into FSM kernels.
i think if you're doing an ECS in realtime it might get really slow with like 100000 particles, maybe you could have ECS while you're building the engine and then flatten the structures at compile time so it runs fast and it's not all dynamic (it seems like something that should be possible but I might not know as much as i think i do)
it really depends, while I haven't used ECS all that much beyond making a basic implementation Golang, I would say that it may do better than you may at first think. An ECS's main advantage is its contiguous memory that optimizes for the most cpu cache hits and its very good at storing very little amounts of data on each entity* (I know that entities are only ids you get the idea) and iterating over many thousands of entities very quickly. But beyond just that theirs also other questions that must be asked, how many times do you delete or spawn entities/add or remove components, in the implementation that I went with this was the slowest thing you could do in it, as well as if you want air to act like a particle in which case you would already have an array that you could just loop over without having to worry about wasting time on null tiles like you would have if air did nothing. If you don't want air to act like a particle, how much do you have? If you have a lot of air you may need to optimize around that but if you only have a few pixels you could just skip over it. In an ECS one of the nice things is that you only go over what you need to iterate over for each entity and can chose the update order by changing which systems are called first, do you want to update some particles before others? What about storing data? If you want to store unique data on each particle you will need much more than an id and an ECS would likely be the way to go as at least with most implementations it would store that data in a separate archetype. but its also important to remember that an ECS isnt just one thing, its a whole group of things that are similar in that they have entities, components, and systems but are also different in how they work. Even if an ECS isn't the best solution, I think a system like it would probably be your best bet! (or Timid's best bet) Anyway I have no idea what I just wrote so ima just leave a link to a great GDC talk by one of the Noita devs: ruclips.net/video/prXuyMCgbTc/видео.html
then there's also other things, like if you have a particle that hasn't been acted on in a while, you could make it inactive until a force or particle acts on it and wakes it up. How could something like that be implemented? The easiest way if you were to use an ECS would be to add or remove an "active" component and then only iterate over entities with that active component, but adding and removing components is slow so it may be better to have a list of entities that are active and look them up and iterate over them, but that DESTROYS cache efficiency. So how often do entities change state from active to inactive? Do you want entities to go inactive at all? Is an ECS even a good fit for a cellular automaton? Those are all very hard questions to answer! (and I have no clue)
Traits can in fact have constants in Rust, which seems to be what you meant. If you mean non-constant, why in the world would you want variables in traits? Just have the variables in the struct
Hahaha, I wouldn't worry too much about that happening, I don't know that I plan on fleshing this out too much. Even if I did, make it anyway! Never be afraid to make cool stuff!
@@timidautomaton5950 ive got some ideas for a cell life sandbox game that i might call automa but i literally only have it on paper at this point 😅 i look forward to seeing what you do with this channel either way!
I'm super sorry but unfortunately you're gonna have to make more videos because this one was really nice to watch
same but i'm saying it more threateningly
Why're you sorry???
because the video was so nice to watch, that he has to tell its authour that he's gonna have to make more videos without any concern for his wishes and needs. i think that being very sorry for this kind of statement is quite fitting, as the author might not want to make videos, and nobody should be able to tell him what to do. would you want to be told, that you made a good video, so make more? anyways, would you mind showing me your fidget spinner?@@TheEggToBehold
The comments have spoken
@@timidautomaton5950ur videos are awesome bro
One of my first forum bans on the internet was the falling sand game forums. I crashed the server by trying to roll 100000d1000000 dice in the IRC chat.
lmfao
I was banned because I worked a lot with a modder named Pyromaniac who made a game called PyroSand (or something like that?). And he went and created a new forum to compete with the fallingsandgame forums, the admins didn't like that and banned him, and because I worked with him, the admins just assumed I was affiliated with him and banned me too. I ended up going to his forum because of that even though I didn't originally plan to
@@gsami1256 dude seriously its insane to me how many small games projects just have some story like that. where some people are working on a new thing and try to make a different forum and they get banned for it. the discord kids have no clue what sort of feudal shit occurred on The Boards
my favorite version of a sand game is 'powder game' by dan ball. it came out in 2007 and is a certified classic
I loved that one. Some of my uploads went viral. My first taste of internet fame.
@@PopeGoliath sharing levels was such a cool feature, I remember playing tons of obstacle courses
Love Danball. His stick figure RPG will live in my mind forever
@@OvermasterP same here man, loved that game
That's the same one I played!
I really liked how you made this video! I'm also an avid TodePond watcher.
It's pretty cool seeing you go through the same bugs and ressources I did when I wanted to create a falling sand game.
Much love and encouragement on your future projects! You have talent!
This is super fascinating! The only sand physics based game I remember is Sugar, Sugar, but I never thought about the possibilities.
Awesome voice btw
Nice video! It's a good start for working with reaction-diffusion equations from fluid dynamics. It's a branch of physics/biochemistry where elements in your biome diffuse themself in the environment through thermodynamic laws (what you have done so far) and react to other elements.
For example you can have a fish sand particle that will eat algae and poop seeds.
Watchout though, this domain is so vast and rich that you can easily be hooked for a while 😉
I'm of a younger demographic, but my main experience of this genre was through this game called Powder Toy which for some reason was installed on all my schools computers. Fun to make H bombs in lol
I loved poweder toy
It had a steam release just this year!!
Powder toy is absolutely amazing
@@shadesoftimeindeed
I made this week something like this too. But with water, wood, stone, lava, glass, acid and smoke. Like Sandboxels (1:35). Coincidence this video showed up in my homepage (or youtube knows ":))
4:00 - THANK YOU!!
I also had trouble with my sand being biased to fall on one side or the other,
depending on buffer traversal direction, and I couldn't for the life of me find
any mention of this on the Internet, let alone a solution.
It was an odd bug to track down. I thought I'd messed up the diagonal falling code for a little while. A similar issue happens if you don't randomize the direction the water disperses in as well. You start getting water "pooling" uphill in one direction and very slowly leveling out over time. Assuming you implement it like I did, anyway
Haven't gotten to water yet, but I'll keep that in mind :)
Hell of Sand, now THAT'S something i havent thought about in ages. I mostly spent time exploding things in those sims. Thanks for unlocking that memory 👍
8:35 ... I'm by no means a rust developer... but ... just define getter functions in your traits for the properties you need, and in the implementation have a baking field.... (you probably don't even need a baking field, I guess, since most of your values would be quite constant anyways per type!?)
but yeah, I guess ECS might even be better in terms of performance, since you do not bloat everything with a lot of potentially-used-fields, and the fields you're using are usually quite good memory aligned if everything is done right.
Awesome video, the only way to make it better would be to include more Ark and Kerrigan.
Can't help but list my own favorites: dan-ball's powder game includes a basic cellular automata wind simulation! OE-CAKE and phyzios studio still have an active community around them. There's some really good source code on shadertoy if you search for falling sand.
My own hunch on how to approach powder sims is that you shouldn't worry about general solutions. Each powder type is going to have its own concerns and code it has to run, and what matters is that the overall effect looks good. So, hacky solutions where the behavior depends on the update order, weird interleaving, bitwise tricks, are all A-OK. But I haven't published a powder game so take that with a grain of salt.
OE-CAKE! Just unlocked a distant memory
I hadn't thought of those videos for years before making this, lol. I have a bad habit of abstracting too early in programming. It always feels like there should be a more clever solution and brute forcing is "wrong" haha. I'll have to check out the ones you mentioned!
Flushing all those minnows at the end felt surprisingly tragic
Agreed! It feels really bad doing it!
Hmm. For the problem about not wanting to store all the data in the grid I would probably just link the id of particles to a list of dyn Particle trait objects which can be a simple lookup that allows access to any abstract function for interaction which means you could simplify the process have introducing more particle types. Realistically u would probably want look up tables to just go from Id to a struct of data references and function pointers that hold all the different functionality. This means both sand and gravel have the same movement criteria by referencing the same function pointer but could have different function pointers for reaction with water for example
Wow lmao I’ve just started programming one of these for my final IT Practical and this video released the same day I started. Neat coincidence.
the impl keyword isn’t a dynamic type checking.
You probably meant trait objects, such as
Box
Yes, you're right! I didn't catch this in editing. Combination of ignorance and poor wording
falling sand games are really nostalgic to me and I love watching stuff about them
I clicked on your video because it made me think of TodePond, lol.
thanks for mentioning sandboxels!!
Surreally small world
Yeah! I played around with it for much longer than I meant to when researching for the video, haha! There was a lot of interesting mechanics, but I really liked the weather effects! I played around with the temperature changes for quite a while too.
Very excited to see this channel grow, very cool
powdertoy... save me powdertoy
Dan-Ball, the Powder Toy. Classic man.
Todepond mentioned!!!!!
nice
Thanks for stopping by! I love the blending of creativity and tech in your videos!
nice video discovery, happy to been recommended this video :)
Beat me to it by 30 minutes
I think static lists might be exactly what i needed…
so far, everything is dependent on gravity falling down, so it would be difficult to add magnets or change the gravity direction. Everything moves at the same speed with a binary pressure. if every type has a density, you can calculate the slope of the density in the direction you are moving, so it works the same moving in any direction. each particle could have an angle of repose. You could also add a panning displacement map, that makes the grass and kelp wave, with a gradient towards their roots so the root doesn't wave as much as the top.
Hmmm... I wasn't planning on pushing this to be that complex, but these are some cool ideas. I may have to try some of that out! Thanks for the suggestions!
super cool
I used to play this one falling sand game that would sprout these super complex trees from seeds, and had LSD. If any living creature touched LSD, the whole screen would go into LSD mode.
lmao
LETS GO TOADPOND!!!!!!!!!! (also ecosystem simulator????? rainworld mentioned??????)
You should use an enum with values to represent the different cells with their specific data
Good video
I like
looks neat
powdertoy
I played dust on a site that had Thursday in the name? I think.
dope
Rust mentioned 💪
For a rules manipulation interface, you might consider treating the inputs as a sort of "2d regular expression" -- which gives an obvious answer for how to make it fast, and that's compiling those regexes into FSM kernels.
This is an interesting idea, I'll have to look into that
i think if you're doing an ECS in realtime it might get really slow with like 100000 particles, maybe you could have ECS while you're building the engine and then flatten the structures at compile time so it runs fast and it's not all dynamic (it seems like something that should be possible but I might not know as much as i think i do)
it really depends, while I haven't used ECS all that much beyond making a basic implementation Golang, I would say that it may do better than you may at first think. An ECS's main advantage is its contiguous memory that optimizes for the most cpu cache hits and its very good at storing very little amounts of data on each entity* (I know that entities are only ids you get the idea) and iterating over many thousands of entities very quickly. But beyond just that theirs also other questions that must be asked, how many times do you delete or spawn entities/add or remove components, in the implementation that I went with this was the slowest thing you could do in it, as well as if you want air to act like a particle in which case you would already have an array that you could just loop over without having to worry about wasting time on null tiles like you would have if air did nothing. If you don't want air to act like a particle, how much do you have? If you have a lot of air you may need to optimize around that but if you only have a few pixels you could just skip over it. In an ECS one of the nice things is that you only go over what you need to iterate over for each entity and can chose the update order by changing which systems are called first, do you want to update some particles before others? What about storing data? If you want to store unique data on each particle you will need much more than an id and an ECS would likely be the way to go as at least with most implementations it would store that data in a separate archetype.
but its also important to remember that an ECS isnt just one thing, its a whole group of things that are similar in that they have entities, components, and systems but are also different in how they work. Even if an ECS isn't the best solution, I think a system like it would probably be your best bet! (or Timid's best bet) Anyway I have no idea what I just wrote so ima just leave a link to a great GDC talk by one of the Noita devs: ruclips.net/video/prXuyMCgbTc/видео.html
then there's also other things, like if you have a particle that hasn't been acted on in a while, you could make it inactive until a force or particle acts on it and wakes it up. How could something like that be implemented? The easiest way if you were to use an ECS would be to add or remove an "active" component and then only iterate over entities with that active component, but adding and removing components is slow so it may be better to have a list of entities that are active and look them up and iterate over them, but that DESTROYS cache efficiency. So how often do entities change state from active to inactive? Do you want entities to go inactive at all? Is an ECS even a good fit for a cellular automaton? Those are all very hard questions to answer! (and I have no clue)
Algorithm doing good work today
Algopush
i would assume bitflags could help alot
Seems like a good solution, I think I was dancing around this idea without realizing it until I read these comments
Hey I think what you're looking for in rust is trait objects
About your architecture question… did you consider using a bit field / enum flags?
I have types as enums, but seeing the comments mentioning bit fields directly gives me some ideas. Seems like a good solution!
Couldn't you update bottom-up? it even gets rid of the annoying lines for free
it should update bottom up and switch left right and right left behavior each tick
Traits can in fact have constants in Rust, which seems to be what you meant. If you mean non-constant, why in the world would you want variables in traits? Just have the variables in the struct
The real answer is I was too stuck on solving it in a specific way and staring at the problem too long to see more obvious solutions
now do the impossible. add superfluid
NOOO youre gonna make my game before me :((
Hahaha, I wouldn't worry too much about that happening, I don't know that I plan on fleshing this out too much. Even if I did, make it anyway! Never be afraid to make cool stuff!
@@timidautomaton5950 ive got some ideas for a cell life sandbox game that i might call automa but i literally only have it on paper at this point 😅 i look forward to seeing what you do with this channel either way!
Have your parents found out that you are gay?
TODEPOND MENTIONED 🏳️⚧️❤🎉
REWALLLL