This is awesome! A few years ago I built a more rudimentary version of a falling sand game with just Javascript and WebGL: http://ericleong.me/sand.js/

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

String did "virtual graffiti" in 3d in 2011! https://vimeo.com/15935674

When I last explored this idea, "stickers" are necessary since most surfaces in real life are generic "textures", so there's no way to know which section of a wall you're looking at if you're too close to it.

Interesting how it's in 3D, and pretty interesting considering how early it was done. (back before all the Oculus hype) Oh and sorry what I meant by stickers were colorful cartoon drawings popular in Facebook and LINE. Although what you're saying does make sense in regards to manipulating surfaces.

I share a similar sentiment with a different phrase: "code is a living history of past ideas, good and bad."

Code is a liability. The best code is code that doesn't need to be written.

If it doesn't need to be rewritten, if it is that good, then it is an asset because you can depend on it.

Problem is... that code is an asset, until it's not. As most cases, it depends on the project, but changes in requirements have insidious effects on code, which might turn your asset in a liability before you realise it.

Ideas are more important than code.

One of my favorite quotes: "the future is a disagreement with the past about what is important." (http://carlos.bueno.org/2010/10/predicting-the-future.html)

Awesome! Replacing one block with another is clever, although it's tricky when organisms of one species are adjacent to organisms of another species.

I've played around with a similar idea in falling sand games [0], where individual cells interact to create new cells, but I got stuck developing a language flexible enough for greater expressiveness while still being performant.

[0] https://github.com/ericleong/sand.js

You were developing a new language? Javascript is great because you can see the results in a browser. I'm a bit torn because java is easier for developing this kind of data intensive thing.

I recently wrote about the gap between product-motivated and technically-motivated engineers: https://medium.com/@ericwleong/the-product-technical-spectru...

Certainly startups are interested in hiring engineers motivated by product, but technical interviews obviously don't look for that.

One of the "not good" explanations of this was probably mine (and I agree!) written many years ago [1]. I wish I could remember why my code ended up so much more complex.

[1] http://ericleong.me/research/circle-line

Goes hand in hand with new government requirements (in NYC, for example) to increase building efficiency!

http://www.nyc.gov/html/gbee/html/home/home.shtml

exactly!

We're really excited to start launching projects in the NYC area.

I've done a lot of amateur research into this field, but I am by no means an expert. Either way, I have a few comments. Let's take this line for example:

  ball.y += ball.vy;
  ball.vy += gravity;

It looks okay and seems to match the constant acceleration kinematics formulas, but what we're really doing is Euler integration, a first-order numerical integration method. It's pretty bad even for numerical integration, so we should use fourth-order Runge-Kutta (RK4) instead [1].

Taking a look at the collision detection, look at this line of code:

  ball.y = platform.y - ball.radius;

It works in the given situation, of course, but wait a minute - if the ball is moving at 5 cm/frame and, at that particular frame, happens to be 1 cm above the platform, then the ball will move only 1 cm/frame! This means that the velocity has apparently dropped to some nonsensical value! But we can't move it anywhere else, because we haven't checked for collisions yet, and this example also assumes that there is only one other platform the ball could collide with - if it was an acute corner of two platforms, then we're in a bit of a rough situation.

Lastly, in this particular line of code:

  ball.vy *= -0.4;

The value, 0.4, is called the coefficient of restitution. In his particular case, where the platform is immovable, it's fairly reasonable (if we had immovable objects in reality!) but obviously a more sophisticated collision will need to consider energy factors.

Conclusion? Collisions are hard [2]!

[1] http://gafferongames.com/game-physics/integration-basics/

[2] ftp://www.myphysicslab.com/beta/Collision-methods.html

I made a flash game at one point with gravity as the core feature, tuned the acceleration, etc, then added collision detection. The simplest way I found was to give everything a destination x, y first, then collision detection checked current to destination vector and updated destination with the results (drag, bounce, etc.). Destination then became current. The downside was the multi wall reflection caused n + 1 collision checks (n being number of collisions). This wasn't an issue for my game, but one with lots of collisions could have slowed it down.

I would like to a "loading" indicator too, but I'm not sure what the best way to integrate it is. I've noticed the other issues you've pointed out - there definitely needs to be some more refinement that needs to be thought about.

Done! I thought you needed it to view photos, but it doesn't seem like that's the case.