Algodoo

I like the idea, and I never saw a 2048 with a bowl like this, but I'm a bit bummed at how much of a lottery you made it be. Blocks fly out of the bowl almost entirely unpredictably, and your only way to have a chance to avoid that is by keeping it rather empty, which is not always possible (and it will still happen - i made a chain reaction of 4 or 5 blocks, and two flew out of the half empty bowl). something strange going on with the X blocks, i got 4 in a row. and I couldn't find an explanation anywhere on what "easy mode" does, or why it gets toggled by the down key (i guess that's a bug?).

last thing, the next block indicator is way out of view from the bowl, think about Tetris where the next piece shows up right beside the game screen. Hell, you could easily just spawn the block and keep it stuck to the "spawner" by making its pos equal to the spawner's pos, until you hit down or click, then unclamp it. Then the spawner would be the next block indicator, which is arguably the best choice for this imo.

I really don't see how this would work in real life. As I understand it, you would be getting rid of static friction, but dynamic friction should be pretty much the same, so the block would be subject to an acceleration depending on the angle of the ramp (like any regular ramp with friction). At least on paper, I think those are the only forces at play, other than the canceled out roller forces etc.
Now if the rollers were slightly more separate on one of the ends, that would definitely create a force, but still not self-regulating as you describe?

Hmm, now I see what you mean. by applying a lateral relative motion with the rollers, you "deflect" the friction vector and thus reduce the component parallel to the movement. but if the box moves faster, the vector will rotate as the relative velocity of the box will be higher in the movement direction, and the "braking force" increases. Is that right?

I guess I qualify. I was considering doing it, using a couple of smooth 8mm rods as the rollers. or maybe piping of some sort. i'll see what i can come up with

holy hell that's good!

For loops are pretty simple, you have to do

for(5, (x)=>{
spawn code here
})

my advice is, first write the for structure like this:

for(5, (x)=>{})

and THEN put the spawn code in between the brackets. that way you don't forget a parentheses or whatever

also try using less, but bigger radius spawned circles, it may halp with performance if you can manage to get them out of the combustion chamber

it doesn't actually seem to work for me, but it may be because of the beta. It always fires the round while in the middle of rotating the bolt, or the shell clips through the bolt and everything breaks

It's not impossible if the density is not enough, lol. But yeah I suspect it's just some difference with the beta, on my end. Frequency is set to 720 Hz too.

wow, very good! You actually had to lower the sim speed to make the mechanism visible. I guess I should start using more frequency for stuff, now that most of us have way newer hardware and the beta improved things noticeably.

Looks really cool, ahd honestly the rope is a very nice addition lol. I'm a bit conflicted about the reflections though, they seem odd and the "character" being the entire height of the viewport is weird. It seems that the reflected objects are taller when the camera is farther away from the mirrors, which seems odd. Also I think you should somehow add a slight effect so you know you're looking at a mirror (maybe render the mirror very slightly, and/or make the reflected objects lighter or something).