t3hprogrammer

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.

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

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

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

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 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.

It's worth playing around with - I would definitely like to have the image fill as much of the space as possible.

Sorry about that, just added a link!