6 ms·
The code links this tweet as the source of the idea: https://twitter.com/nicolasdnl/status/1749715070928433161 https://twitter.com/nicolasdnl/status/17497150709
by archon1410 3y ago
The code links this tweet as the source of the idea: https://twitter.com/nicolasdnl/status/1749715070928433161 https://twitter.com/nicolasdnl/status/1749715070928433161 [nitter: https://nitter.net/nicolasdnl/status/1749715070928433161 https://nitter.net/nicolasdnl/status/1749715070928433161]
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.
- baq 3y agoBy definition… if there’s no end condition, it won’t end ;)
- praptak 3y agoOn top of this there's a negative feedback loop. The ball whose territory gets smaller has less distance to travel between hits. This means that even if there was anything resembling a "win" condition it would be hard to achieve.
- mrec 3y agoYou'd think, but I'm currently looking at a 161/863 split which has been pretty stable for a while now. I thought at first that ball speed is being scaled by territory size to cancel out the negative feedback, and the "winning" ball is moving noticeably faster than the losing one, but I can't see that being deliberate in the code. (There is some randomization of speed on a bounce, but it ought to be pure noise.) EDIT: 120/904 now.
- yellowapple 3y agoOne possible win condition would be a ball reaching the opponent's side. That happened in my case, with "night" eventually breaking through to the left-most edge.
- geor9e 3y agoThat just explains why it tends towards balance. It's just like all the air molocules in a room reliably bouncing around where you can inhale them. There's no hard law of nature saying all the air wont move to one side, suffocating you. It's just statically extremely improbable. But they asked for proof for or against a possibility at all, not whats probable.
- deleted 3y ago[deleted]
- keyle 3y agoWhich makes the name War even better. There is no winner in war and the cycle repeats itself.
- geor9e 3y agoIt'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.
- sgtnoodle 3y agoWell, it seems like there must be a relatively stable equilibrium. As the owned area decreases, the rate of annexation increases.
- GolfPopper 3y agoMine 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. https://i.ibb.co/7bNTtsK/daynight.png https://i.ibb.co/7bNTtsK/daynight.png
- fifilura 3y agoThis is very interesting, mine did too, but with an even narrower dark patch. It is like an attacker-defender equilibrium situation where the vertical guy runs up and down a trench and the attacker tries different paths for orthogonal attacks.
- fifilura 3y agoIt would be interesting if this distribution found use in military theory!
- conductr 3y agoEach ball will occupy a minimum area of 1x1, so the opposing ball can never occupy 100%
- barnabee 3y agoIt 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.
- cjg 3y agoBecause there are a finite number of states, it will always loop. An interesting question might be around how many distinct loops there are and whether there's some pattern to the loop lengths.
- schwartzworld 3y ago> Because there are a finite number of states, it will always loop. No it wouldn't. The fact that it will pass through every state infinite times doesn't mean it will do it in the same order each time. Each digit of pi has only 10 possible states, but it never loops.
- tedsanders 3y agoIf the state evolution: (a) is deterministic (b) depends only on the current state, and (c) can only occupy a finite number of states then it will loop. Pi digits do not satisfy this because while the digit space is finite (10), the next digit depends on more than just the prior digit. Related (but not the same): https://en.wikipedia.org/wiki/Poincaré_recurrence_theorem https://en.wikipedia.org/wiki/Poincaré_recurrence_theorem
- BriggyDwiggs42 3y agoOoh that’s cool I’ve never seen that before.
- bobsmooth 3y agoThe speed of the balls are changed by a small random amount when they hit a tile, so it's not deterministic.
- hombre_fatal 3y agoYou can see what happens when the left ball has one tile and the right ball has the rest of the tiles: x1 = y1 = y3 = squareSize, x2 = canvas.width - squareSize squares = Array.from({ length: numSquaresX }, (_, i) => Array.from({ length: numSquaresY }, (_, j) => i === 0 && j === 0 ? TEAM1 : TEAM2))
- eps 3y agoThe 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.
- realPubkey 3y agoBut it seems that the balls speed increases with a bigger are.
- throwup238 3y agoI think the changes to speed are random: https://github.com/vnglst/pong-wars/blob/main/index.html#L161 https://github.com/vnglst/pong-wars/blob/main/index.html#L16...
- teraflop 3y agoFrom what I can see from a quick glance at the code, you have the causality backwards. Each bounce adds a small random variation to each ball's velocity, and if one of them randomly ends up moving faster, then it will tend to gain more territory.
- bazzargh 3y agoI think further back, part of the idea may have been mine. https://hachyderm.io/deck/@bazzargh/111829275276749971 https://hachyderm.io/deck/@bazzargh/111829275276749971 Originally I saw https://twitter.com/CasualEffects/status/1390290306206216196 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.
- geraneum 3y agoThe 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.
- lou1306 3y agoIt 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?
- onionisafruit 3y agoThat could show that it’s endless, but it wouldn’t necessarily show that an end is possible.
- noSyncCloud 3y agoI don't believe an end is possible. As one player's territory sprinks, it should quite naturally follow that it will have less travel time, hence more collisions.
- noSyncCloud 3y agos/sprinks/shrinks
- nonfamous 3y agoI 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.
- mlhpdx 3y agoI saw this as well. Shall we call it “entanglement “?
- Someone 3y agoI 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.
- deleted 3y ago[deleted]
- geor9e 3y ago>mathematically prove 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.