Type in a number when prompted. Try to avoid large numbers; the performance drops off quickly when there are too many objects onscreen. I think it looks nicest with between 6 and 8 (depending on computer, browser, etc.), but with the recent optimization, 20 can run without a lot of trouble.
tl;dr (I wouldn't blame you): This is a simulation program that doesn't check collisions in the traditional way (Is A touching B? Is A too close to B?) but instead uses an expression for the time required to reach a collision, given the initial positions and velocities of the two objects. There are a series of progressively more specific explanations below. As it turns out, this simulation indeed conserves energy - I wrote a script that calculated kinetic energy (K) and potential energy (U) for all the balls; their sum, K + U (total mechanical energy) was a constant. ++++++++++++ More specific explanation: One of the biggest problems associated with Scratch physics projects is collision detection. Since most projects model time as discrete - broken down into "steps" (that usually correspond to frames) - the continuity we observe in the real world gets lost along the way. Projectiles that move too fast go through walls; objects behave differently when they start in different places. We've all run into these pesky issues. We usually compensate for this by introducing inaccurate physical constraints; for example, an object that will collide with another object one frame in the future will process the collision early to avoid getting "stuck" to its partner. Or, after the intersection has occurred, both objects will move a tiny bit away until they're not intersecting (this method is used a lot in platformers, to prevent characters from sticking to the ground). This looks fairly good, but isn't completely accurate - and why settle for an approximation when we could do it mathematically? So I sat down with a piece of paper (many pieces of paper, actually) and derived a little expression for the time required for two objects to collide, given their initial velocities and positions. I'm quite happy with how this came out - this is something that has bothered me for about three years now, so it feels nice to have found a solution. This is just a demonstration of a concept (and a chance for me to show off some math). I'll make an actual game pretty soon... I'm thinking of a pool table, with to-scale balls, accurate collisions, a computer player (I'm psyched) and everything. ++++++++++++ Even more specific explanation: The time expression spits out the number of timesteps required for two objects to touch, given initial positions and velocities. The program creates a list with all the times for all possible collisions. For example, with 5 balls (named 1, 2, 3, 4, 5), the list would look like this: Time for 1 - 2 Time for 1 - 3 Time for 1 - 4 Time for 1 - 5 Time for 2 - 3 Time for 2 - 4 Time for 2 - 5 Time for 3 - 4 Time for 3 - 5 Time for 4 - 5 Then, it searches this list for the smallest positive time value - this represents the first collision that will happen (I say "positive" because the expression will return negative values for collisions that happened in the past - or that would happen if the velocities were reversed). A similar method is used for wall collisions: each ball finds the time it will take to reach each of the four walls, and stores those times in a list. The circle- and wall-time values are compared to find which will occur first (will a circle strike a wall, or another circle?). The simulation advances at a normal pace until it reaches the determined minimum time. Then, it sets the time to the moment of collision, registers the collision - changes the speed(s) of the object(s) involved - and repopulates the list with new collision times. Hopefully that made sense :) ++++++++++++ Known glitches: - Lag, or unevenness (due to the fact that the simulation advances fractional frames near collisions: if many collisions are being processed in a short amount of time, all the balls appear to slow down). - Currently, the program can't handle two collisions that happen at exactly the same time. Please tell me about any any bugs you encounter! ++++++++++++ To-do list and notes to self: A. (Done) Optimize the time recalculation routine by ignoring collisions that won't be affected. In principle: if 1 hits 2, then the collision time between 3 and 4 won't change (though the times for 1 - 3, 1 - 4, 2 - 3, and 2 - 4 will). Consider the case with eight balls: 1, 2, 3, 4, 5, 6, 7, 8 There are 28 possible circle-circle collisions and 32 possible circle-wall collisions; a total of 60 time values. Say 1 hits 2. Right now, the program will immediately make the 60 calculations. But with optimization, the program would only worry about all of 1's and all of 2's collisions: 1 - 2, 1 - 3, 1 - 4, 1 - 5, 1 - 6, 1 - 7, 1 - 8 and 2 - 3, 2 - 4, 2 - 5, 2 - 6, 2 - 7, 2 - 8 = 13 circle-circle collisions + 8 circle-wall collisions = 21 total. Compare with 60. This may facilitate simulations of larger numbers of objects (I'm almost certain that the time procedure is the bottleneck). For the unaffected possibilities, I can just subtract the current time value, i.e. fast-forward a bit.
