Originally I saw https://twitter.com/CasualEffects/status/1390290306206216196 which the author says was based on a pico8 original (which I remember seeing, but can't find now). Those earlier ones had the pong bats as well, but when I did the demake in basic, I couldn't fit the code into a tweet to get the bbcmicrobot to run it. So, I removed the bats.
Mine is a bit slow and janky, @rheolism (I think?) posted back a much faster, smoother version using custom characters instead of plotting, and then I saw a remake of the demake in processing? These things take a life of their own.
Anyway, long ago deleted my twitter account, but dug it out of the archive.
The smaller the area, the more bounces its ball gets per time unit compared to the opponent and more chances to expand the area. So any extreme case of one ball being super-confined will be very short-lived.
Mine seems to have reached a meta-stable state after running for a few hours around 320/704, where the ball with less area is bouncing almost vertically, and a nearly flat border between the two.
The first time I opened the link, I kept watching until both balls ended up in a point where they blocked each other between opposite side’s tiles. The was no way to go and they kept bouncing off each other in a tiny space. I wouldn’t call it an end but there was no progress anymore either.
I didn’t grab a screenshot, but I did see how the simulation can end. The day and night balls collided with each other at the boundary and got locked in place in a tight infinite loop, and never moved again.
I'll give it a rough swing. I probably overcomplicated the endgame I describe below, and maybe make some assumptions that aren't actually how the mechanics work, but hopefully it's understandable.
The balls are about the same size as the blocks. Lets say they are infinitesimally smaller, so they can still fit down a 1 block wide tunnel.
Imagine the gameplay somehow gets into the condition that both balls are in tunnels, but white in the worst way (perfectly aligned, so it just bounces off the far ends) and black in the best way (barely zigzagging in a nearly straight line, killing all wall blocks, leaving a 3 block wide tunnel in it's wake).
This would result in whites tunnel rapidly shrinking. Even if white exists in a 2x1 tunnel and is getting kills, black is still killing at almost 2x the rate.
White will be in their 2x1 tunnel, make it into a 3x1 tunnel, but it will become a 2x1 tunnel again by the time it's bounced a little over a block. Now suppose black then reaches the (white) end of their tunnel, scoring 3 kills in almost the same instant. There's nowhere to spawn those three that doesn't clash. The app will either crash with a null value error, or some other result that qualifies as an end condition since it would break the fundamental rules of the game.
It would be interesting to know if it can get into a looping state after which it just repeats previous moves forever. I guess that would be an “end” of sorts.
It should suffice to check out what happens (code-wise) if one of the "players" has only one square left. Does the "winning" player have a chance to hit that square and conquer it? Or does the program immediately register a collision for the "losing" player, who goes back to two squares?
I expected a side to win or score a point once it hit the ‘goal line’ of its opponent.
Would make a nice game if there was a way for players to have some control over the ball. Could be as easy as standard pong paddles, with some time delay whenever your ball passes your own goal line.
It's ambiguous. The end condition could be a pixel spawning with overlap on a ball because there's nowhere else to go. What will happen when there's no room left to add one more pixel, and it tries to add one more pixel? Will it place it with the collision boundaries on the wrong sides? Will it crash with a null value error because there's no good spot to place it? Can't know without understanding the code. But there are many possible end conditions.
They're asking if one can prove that you never reach any situation where an end condition (intended or not) could ever exist.
Imagine black has a long horizontal 1 pixel tunnel, but it's zigzagging down hitting every side pixel rapidly, while white has a long white tunnel and it's bouncing perfectly horizontally, taking a long time to hit each end. As the ends close in on white, is there some perfectly aligned timespan where black can hit a pixel while white doesn't have a full pixel of open space on either side? It would be interesting if someone can articulate logically why or why not that would ever happen.
I'm greatly fascinated by this kind of thing, but I have to call it "this kind of thing" because I don't even know if there are genre terms to categorize and analyze them.
They're inspired by game algorithms, but they aren't games; Conway's "Game of Life" was a misnomer. They're animated, but they aren't scripted like animations. In the real world we have someone like David C. Roy, who calls his art "kinetic sculptures".
Algorithmic motion pictures? Game simulators? Autonomous automatons?
Chaotic systems? As in, fully deterministic systems that are highly sensitive to initial conditions?
EDIT: browsed the code a bit and there is some randomness in the bounce dynamics, so it's only "fully deterministic" if you count the PNRG seed as part of the initial conditions.
It is really cool. It would be interesting to make the speed proportional to the either the number of squares owned or the square root of that. Because right now as the area the ball owns gets smaller, the number of hits will increase at the same speed.
This is genuinely beautiful on a few levels. Esthetically it is pleasing to just sit and watch. Philosophically it is interesting in that it is a digital metaphor for an ongoing struggle.
Lastly, and most interestingly, it remixes two really simple old ideas into something new. This is an exceedingly rare thing to do well.
3 colors would get interesting, because as the other two bully one into a corner, the small space causes rapid block zapping, quickly bringing it back from the brink of defeat.
I was inspired by this and created a version with customizable ball count, accessible code... and a speed slider, to satisfy the less patient among us.
Readit News
Quote: "The endless fight for #genuary23 #genuary #genuary2024
It's not an original idea, I've seen this before but couldn't put a hand on it."
It says the battle is endless. I wonder if there's any way to mathematically prove that.
https://hachyderm.io/deck/@bazzargh/111829275276749971
Originally I saw https://twitter.com/CasualEffects/status/1390290306206216196 which the author says was based on a pico8 original (which I remember seeing, but can't find now). Those earlier ones had the pong bats as well, but when I did the demake in basic, I couldn't fit the code into a tweet to get the bbcmicrobot to run it. So, I removed the bats.
Mine is a bit slow and janky, @rheolism (I think?) posted back a much faster, smoother version using custom characters instead of plotting, and then I saw a remake of the demake in processing? These things take a life of their own.
Anyway, long ago deleted my twitter account, but dug it out of the archive.
https://i.ibb.co/7bNTtsK/daynight.png
I'll give it a rough swing. I probably overcomplicated the endgame I describe below, and maybe make some assumptions that aren't actually how the mechanics work, but hopefully it's understandable.
The balls are about the same size as the blocks. Lets say they are infinitesimally smaller, so they can still fit down a 1 block wide tunnel.
Imagine the gameplay somehow gets into the condition that both balls are in tunnels, but white in the worst way (perfectly aligned, so it just bounces off the far ends) and black in the best way (barely zigzagging in a nearly straight line, killing all wall blocks, leaving a 3 block wide tunnel in it's wake).
This would result in whites tunnel rapidly shrinking. Even if white exists in a 2x1 tunnel and is getting kills, black is still killing at almost 2x the rate.
White will be in their 2x1 tunnel, make it into a 3x1 tunnel, but it will become a 2x1 tunnel again by the time it's bounced a little over a block. Now suppose black then reaches the (white) end of their tunnel, scoring 3 kills in almost the same instant. There's nowhere to spawn those three that doesn't clash. The app will either crash with a null value error, or some other result that qualifies as an end condition since it would break the fundamental rules of the game.
Deleted Comment
An interesting question might be around how many distinct loops there are and whether there's some pattern to the loop lengths.
Would make a nice game if there was a way for players to have some control over the ball. Could be as easy as standard pong paddles, with some time delay whenever your ball passes your own goal line.
This means that even if there was anything resembling a "win" condition it would be hard to achieve.
They're asking if one can prove that you never reach any situation where an end condition (intended or not) could ever exist.
Imagine black has a long horizontal 1 pixel tunnel, but it's zigzagging down hitting every side pixel rapidly, while white has a long white tunnel and it's bouncing perfectly horizontally, taking a long time to hit each end. As the ends close in on white, is there some perfectly aligned timespan where black can hit a pixel while white doesn't have a full pixel of open space on either side? It would be interesting if someone can articulate logically why or why not that would ever happen.
Deleted Comment
They're inspired by game algorithms, but they aren't games; Conway's "Game of Life" was a misnomer. They're animated, but they aren't scripted like animations. In the real world we have someone like David C. Roy, who calls his art "kinetic sculptures".
Algorithmic motion pictures? Game simulators? Autonomous automatons?
Deleted Comment
EDIT: browsed the code a bit and there is some randomness in the bounce dynamics, so it's only "fully deterministic" if you count the PNRG seed as part of the initial conditions.
There is time, rules, etc...
And an important element is the outcome not being known.
It is that last bit which makes these kinds of programs interesting to write and run.
https://scratch.mit.edu/projects/957461584/
Lastly, and most interestingly, it remixes two really simple old ideas into something new. This is an exceedingly rare thing to do well.
Kudos. Many kudos.
https://explorers.toxicode.fr/?remoteWorkspace=pong-war