So I downloaded the applet, decompiled it, spent a few minutes figuring out exactly where the dimensions were setup, changed them to 960x640, compiled it all, and hosted it on my site: http://chir.ag/stuff/sand/
I'm always apprehensive about taking any credit for the Falling Sand Game because I DID NOT make it but I'm always glad to see it in the wild. First it was Fark, then a few months later Digg, then Reddit. At one point someone created a Wikipedia page linking to the enlarged version I was hosting, then it got deleted as not-notable, then someone wrote a song about FSG, then a hundred different versions of FSG popped up, many non-Java and functioning much better than the applet, then the Wikipedia page came back up.
I've long stopped getting giddy emails from office slackers about how much time they waste on my site but even though I didn't really create this amazing game/toy/zen-garden, I feel lucky to have been a tiny part of the arcane pop-culture movement.
Damn, the game's 27 years old.
I was playing Sandspiel and it was bringing back vaguely positive memories of a similar game but I couldn't remember what it was or when I played it, then I saw your comment, opened falling sand game and instantly remembered the game. I must have spent so much time playing this when I was younger, it's great to have a working version again.
If you have the jdk installed (https://www.oracle.com/technetwork/java/javase/downloads/jdk...) you can simply run:
$ appletviewer http://chir.ag/stuff/sand/
This usually solves for weird, deprecations, and routes around profoundly unfriendly browser barriers, which, sadly and admittedly are required from a security standpoint for most clueless users.
I prefer using Eclipse over IntelliJ CE, because Eclipse settings for static libraries that aren't handled by source control are a bit more concrete. IntelliJ CE is well-suited for many professional coding activities, but buries some commonly used, yet clunky settings that are right on the surface with Eclipse. Namely JRE/JDK choices, and build path settings for static jar files.
On the other hand, you might need to know a bit about Java, to do this. For most HN users, and even many gamers, this is generally not too much of a problem.
 Original Fark thread: https://www.fark.com/comments/1826196/Draw-lines-to-alter-fl...
 My attempt to show others how to run this offline: https://www.fark.com/comments/1826196/17784666#c17784666
 My comment about the rehosted/recompiled 960x640 version: https://www.fark.com/comments/1826196/17784943#c17784943
 I'm smiling at Finger51's comment: Works great in FF1.5!
 My original blog entry a few days later: http://chir.ag/200512302250
 It's a bit sad that all the links to Digg, Reddit, and MSNBC are broken now. And I totally forgot about the traffic behemoth that delicious was! Here's a fixed version of the Reddit link, at least the page is up, even if the URL changed: https://www.reddit.com/r/reddit.com/comments/21509/
can anyone find an earlier falling sand type game?
edit: Found this after some googling:
very interesting! (includes assembly source code)
Atari ST game, in the same genre, from the Jan 1993 issue of ST Format: https://www.youtube.com/watch?v=SHZB9nIzZ64
And here you can find the full issue:
I also spent an unreasonable amount of time in that era at dofi blog playing many other variants.
Found this when I was in grade school and I remember spending HOURS on it.
Thank you very much.
If you've never seen this kind of thing before, the canonical PC example is The Powder Toy, which is so amazing I wish there a 3D Minecraft-like version. But it's really CPU-heavy even in 2d.
Observe boiling water.
But when I put oil (in a separate compartment) beneath the bowl of water, and light it on fire, the oil burns off, but doesn't boil any water.
What should happen? All I see is the surface 'sparkle' effect that is the same as still water.
There are a couple of other 3D falling sand games (http://csiuo.com/Sand3d/, https://github.com/TheTomster/sandish, https://powdertoy.co.uk/Discussions/Thread/View.html%3FThrea...) but none of them are very good due to the factors you mentioned. UX is also a pretty big problem, as traditional mouse or touch controls don't work well in 3D, which is why I wanted to go the VR route, but something like a very dynamic Minecraft as you mentioned could work as well.
Most falling sand game implementations are sequential, so parallelizing the simulation using a margolus neighborhood (https://en.wikipedia.org/wiki/Block_cellular_automaton) or double buffer could greatly improve performance. Most falling sand games tend to not be pure cellular automata, and some are implemented as particle systems with particle in cell grid collision instead of CA, but particle and fluid sims are easy to parallelize. I haven't seen a falling sand game (2D or 3D) that runs entirely on the GPU, and my goal was to do that, eventually ending up with some complex Claybook (https://www.claybookgame.com/) style engine.
still great though.
The only downfall is that the Pythagorean Cup didn't work?
1. If a sand pixel had an empty pixel below it, exchange them.
2. If more than two sand pixels are stacked but there's space to the side, kick one sand grain out to that side.
These rules were enough to make the sand form simple hill shapes. All of the cores bash on the same shared memory array; rather than use locks or synchronization I just had each core start in a different column of the screen and all move left to right by columns - in theory there should be enough separation that they'd never conflict.
However - and this is the part I thought interesting to post about - somehow after a few seconds or minutes the 7 cores would catch up with each other and start running in lockstep (effectively reducing the speed of the simulation to equivalent of 1 core).
Barring a bug that was simply crashing cores, what I think was happening was that not every control flow path took the same number of cycles, so a core processing a column with a complex sand pattern might slow down and allow another core to catch up to it. Once two cores were operating on exactly the same data, they'd be doing the same deterministic logic on the same inputs and writing out the same result, effectively just duplicating the work in lockstep.
As long as we have the internet archive and a few awesome humans we will be fine =)
Recently, I made a particle game which originally planned to be implemented with WASM. However, I decided to implement it with pure JS firstly. The result is some surprising that the JS version runs so smoothly that I think a WASM version is not essential any more.
(Disclosure: it's being developed by a bunch of my old co-workers.)
I hope they can find a balance that allows you to take risks with the physics interactions without loosing your entire run.
I had remembered that one a decade or so ago and it turned out to be the single hardest thing I tried to find for my WinUAE collection :-(
Funny how one misremembered character can make an internet search that hard. :-)
You most certainly made my day! Thank you very much!
Interestingly enough, while we've all been taught "never use water on an oil fire", this is actually pretty similar to real life. Generally speaking, using water on a flammable liquids fire will just spread the fire and make it worse. But if the fire is small enough and the application rate of the water is sufficient, you can sometimes extinguish such a fire with water.
Note: do NOT take this as advice to ever try to extinguish a kitchen fire or something like that with water. When I talk about "application rate" above, I'm thinking of the 100+ gallons per minute you get from a 1-3/4" (or larger) handline from a fire engine. If your frying pan catches on fire, call 911 and then use a class B rated fire extinguisher, or smother the fire by putting a lid on the container. If you have any doubts whatsoever about your ability to extinguish the fire, exit the structure and let the fire department handle it.
It's a bit similar, but uses GPU and spawns millions of particles. On the other hand, it's less of a sandbox and more of a demo. You can write your own code in the browser too, but it's a bit tricky to program, because it compiles to shader language and it has some weird limitations.
I tried to embed the "scripting" language as a texture in WebGL to keep the implementation very fast (note that every pixel is a cell), but I think I worked myself into a corner.
Source code here: https://github.com/ericleong/sand.js
The smoke effects are based on another project about Fluid simulation https://github.com/PavelDoGreat/WebGL-Fluid-Simulation
It also has a working demo with controls (it's collapsed by default I think, and kind of hard to see if you're not looking for it in the upper right hand corner). It's pretty astonishing how beautiful it is.
As far as I can tell, the filters and the code isn't too complicated. I am just wondering how they got those values to begin with because that's where the real magic is. There are some references there as well. One of them links to a gpu gems page that I am pretty sure I've seen before that looks really similar to this. So it's really just incremental improvements from previous works. But this version looks a lot more polished.
erase the thingy to the right, and the planets on the left grow upwards again.
Awesome game, I love the options :)
The effect is worth it.
You know what feature I miss? Fast-forwarding!
Does anyone have the same problem?
I got a lot going, 25fps Samsung Note 8, Power Saving Mode
32 fps Performance Mode
btw, adding oil over lava produces a very cool smoke effect.
Not that it needs improving anyway... just curious.
e.g. my phone lacks float textures (i.e, to render-to-texture to output floating point calculations), so this fluid simulation doesn't work http://jamie-wong.com/2016/08/05/webgl-fluid-simulation/ (not a guess; I've been through the source, reimplemented some in java)
The article also discussed some weird things that existed outside of the definition that the article arrived at, such as ClickerHeros and similar "grinding" "games".
(I wish I could find a link to it. Perhaps someone else here remembers and can find it…)
E g.: Sid Meier's famous definition: "a series of interesting decisions". (But what would he know?)
FWIW I asked the question because I'm designing a simulation "game" without explicit win-conditions, but I'm concerned it won't be very engaging without them. e.g. Minecraft added monsters (to survive the night), and the enderverse.
For the case of your game specifically, one option is to expose game stats that the player can form their own challenges around. E.g. if the game UI shows how many times you've jumped, that implicitly lets the player form "do X without jumping more than Y times" sorts of challenges, etc. Or the more formal way to do it is like e.g. Minecraft achievements - there's no "win condition" for putting a saddle on a pig or whatever, but the mere fact that there's a piece of UI tracking whether you've done it or not, creates a challenge by itself.
 yeah I said it! ;)
But actually, I don't want those sort of win-conditions for this particular game, not even DIY stats. It's just an immersive simulation. Guess I'm just not too sure it WILL be immersive or engaging - even for me to play! Just have to see, I guess.
Taking your lead, I suppose if a movie can be immersive, why not a "game" which has no win-condition? But the moment I say that, I immediately realize that movies do have "win-conditions" - just of the protagonist, not the viewer/player. Goals, stakes, motivation, obstacles are all important narrative components.
Can you have an immersive movie without narrative? Sort of maybe, some experimental/arthouse, but they aren't very popular (and arguably do have some kind of narrative).
You're probably right about definitions, but they do inevitably lead to the components of a game/non-game, and whether they are engaging, and what makes them engaging... and they're easy to ask.
"Challenge" implies an objective or purpose.
e.g. there are rules to writing a syntactically correct program; ways to drive a car; use a GUI. Does that make them games?
If a user can make a game out of them, what do they add, to make it into a "game"? Is the thing added an objective of some kind (i.e. a win condition)?
I'd suggest that in order to make something into a game, the user is adding "playfulness", which is pretty subjective and may or may not include a simple goal.
In an open game or fun simulation, the player is going to be coming up with their own goals or roles of play. Or maybe they will just be going with a simple open ended goal of curious exploration.
No, it should also not be tied to some productive outcome, which this does not.
I think the parent comment makes a good point that if you do define games as the mentioned, this and a few other things certainly doesn't necessarily fit with the definition. Still, games are often a fill-in word for many interactive things that use a computer.
But whatever, people use words the way they use them. For example RPG, based on the logic of how the word is used, has almost meaning. Zelda is often called an RPG but it's got almost zero in common with say FF7 and more in common with Ratchet and Clack. And the word Role Playing Game. Well, by that logic any racing game is an RPG. I'm playing the role of a race car driver. Or FPS, I'm playing the role of a soilder. Or flight sim, I'm playing the role of a pilot. Or God Sim, playing the role of a god. RPG in actual use seems to mean "game about character with sword" at best.
The latest atrocity is "roguelike" which is applied to any game that has randomly generated levels. For example Galax-Z is called "roguelike" even though it's basically Asteroids.
The word "game" people use it interchangeably with anything you can fiddle with interactively on a computer and see some graphics change even though that describes photoshop and ms paint as well.
Will this user-defined game need to have an objective (i.e. a win condition) to be a "game"?
Or, is just making up rules, without any direction, purpose, objective or "win-condition", enough to make it a "game"?
I subscribe to Chris Crawford's definition. Games are competitions between multiple players and they must be able to interfere with each other. A painting, a toy, a puzzle, a race, are all not games. The difference between taking a stroll while carrying a ball and playing a game is keeping score.
The most controversial result of that is that God of War and Dark Souls are actually puzzles, and not games, and although it's unintuitive upon reflection it rings true to me.