Hacker News new | past | comments | ask | show | jobs | submit login
The Powder Toy (github.com/the-powder-toy)
144 points by agluszak on July 4, 2021 | hide | past | favorite | 29 comments



Here is one of the earlier iterations in this genre, which I remember playing around with a lot in my childhood:

http://dan-ball.jp/en/javagame/dust2/



Powder Game was what got me into Powder Toy


Fans of this should check out Noita, a rogulike game based on a similar idea (every pixel being a simulated substance/effect)

https://noitagame.com/


I loved powder toy but found noita very boring. Aside from being able to blow up part of the map and burning things, I felt the pixel simulation part to not add much. It certainly wasn't the creative sandbox that powder toy is.


It certainly is a very different game, I don't think the comparison is apt either (though noita is a contender for my favorite game ever and one that I plan to sink dozens more hours into)


Yes, the falling sand roots of Noita make it a little tricky, because it's a really good Roguelike platformer/shooter, that has a lot of interesting systems and mechanics, but the sand mechanics and physics are kind of a "value add" rather than core gameplay. I haven't played much Noita, but from what I know the wand system is more important for success than taking advantage of the environment. It somewhat misleading because the game was introduced with "ever pixel is simulated", but that doesn't actually matter as much as advertised in most runs.

For years (I even pitched it to Dennis Gustafson, the creator of Teardown) I've wanted to do a 3D falling sand game that could naively be described as Noita x Teardown, but outside of the technical challenges I haven't thought of a concept that truly takes advantage of falling sand automata and isn't just a sandbox.


I think that's the trouble, there aren't a wide range of stories that benefit at their core from detailed "atomic/particle" level physics. You can get 90% of the gameplay for half the cost in most cases.

The only thing I can really think of are games centered around construction and civil engineering, fluid dynamics, mining and infrastructure systems. I'm not sure if you have played the game "Infra" but it made me think it would be fun to have a procedurally generated structural inspection game based on real physics, and you were tasked with fixing it with the right materials and processes.

Another example would be a game centered around big engineering projects, like what you see on Discovery channel documentaries. Having to build or maintain a water treatment plant, or some kind of simplified oil rig.

Teardown did a great job of gamifying the mechanic of detailed destruction and physics but it did always feel like it was a story trying to sell the mechanic, which is fine, I absolutely loved the game.


The Noita team explored some game ideas along those lines and had challenges. If you haven't seen the GDC 2019 talk about tech and design of Noita I recommend checking it out. They show some early prototypes focused on building https://youtu.be/prXuyMCgbTc


Agreed, it was a bit of a disappointment for me as well in that regard. I've been hoping they'll add a "sandbox mode" or something in one of their regular updates l.


> I've been hoping they'll add a "sandbox mode" or something in one of their regular updates l.

that'd be nice, but feels unlikely given their message to the community about the Epilogue update.

Noita Epilogue update is out now. It's one of our biggest updates yet and is also going to be the last major update for Noita. The change list alone is 319 entries long. You can read the full release notes at the end of this post. [0]

[0]: https://store.steampowered.com/news/app/881100/view/30089413...


I don't understand how they can make this performant. I've made sand simulators but just one static screen at 640x480 pixels is very taxing. Anyone has any idea?


A sibling comment links to a talk the developers gave. A quick summary - they break the world into sections via a quadtree like structure any only simulate active regions.


Thanks! It was very interesting and exactly what I was looking for.


There are some interesting electronics driven by arcane magic

R216K2A by LBPHacker. A 16-bit computer https://powdertoy.co.uk/Browse/View.html?ID=2303519

Complete with instruction manual and assembler: https://trigraph.net/powdertoy/R216/manual.md

Of which siraben has written a Forth implementation for: https://github.com/siraben/r216-forth


This is insane. Hats off and all that :)


Oh wow I played this game so much on the middle school computers. We got the binary on the whole district's blacklist too.

I remember searching the most elaborate and cool-looking... recipes and had a dozen... boom devices memorized. (am trying to be careful to not get on NSA's blacklist here)

It was really fun and we probably got dozens of hours of enjoyment out of it. I still have it on my old school USB, so this is extra cool to me.


The "Powder Game" version used to be my favorite "game" of all time. However, I always got limited by how many things you could use at once which I thought should be no problem on modern hardware.


I spent far too much time playing Powder game before Minecraft came along to scratch the same itch. Some of the popular maps were incredible works of art within the limits of the game. A larger canvas, determinism, and better zoom/editing capabilities are all that would be needed to make it perfect.


Most powder models have O(n^2) interactions per step, so it's nontrivial to approximate it in O(n log n) while keeping it just as fun, especially when pushing the models to their limits.


Where does the O(n²) come from? Is the number of neighbors unlimited? I was always under the impression that only a constant number of immediate neighbours counts.


Yes, it is linear, with a few small exceptions. The vast majority of element types in the game only check a fixed number of neighbours. Neighbour checking uses a 2-D map so it's constant-time.


Just randomly selected neighbours then I assume?


Most elements check the entire immediate neighbourhood at a taxicab distance of 1 or 2 (between 8 and 24 neighbours).

Not all elements check neighbours, An A+B interaction may have A checking for B or B checking for A.


Isn’t it automatically O(n log n) if you don’t have accurate gravity and you use some sort of special tree to find neighbors?


it is mostly linear and there are lots of optimisation opportunities. rapid movements like explosions are the exception. then again you have the gpu and the other cores, i rarely see below 60fps on my sand game and map size is the only limitation.


with toz[0][1] the only limit is the map size (which is 256x256). more than 90% of the gameplay is perfectly parallelizable (1 neighborhood automata)

[0] https://store.steampowered.com/app/1170330/toz/ [1] https://old.reddit.com/r/toz/


A couple past threads:

The Powder Toy - https://news.ycombinator.com/item?id=24389920 - Sept 2020 (37 comments)

The Powder Toy - https://news.ycombinator.com/item?id=11052473 - Feb 2016 (16 comments)


There are many impressive computers build in this, they look really cool when running: https://www.youtube.com/watch?v=h4eHgnLFk9k




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: