[HN Gopher] Show HN: Pong Wars
___________________________________________________________________
Show HN: Pong Wars
Author : vnglst
Score : 109 points
Date : 2024-01-27 20:19 UTC (2 hours ago)
(HTM) web link (pong-wars.koenvangilst.nl)
(TXT) w3m dump (pong-wars.koenvangilst.nl)
| throwaway2046 wrote:
| So hypnotizing... I was waiting for something magical to happen
| when the two balls touch.
| zeeZ wrote:
| The dividing line slowly shifted to diagonal and then
| horizontal.
| JKCalhoun wrote:
| Saw them get kind of intertwined briefly.
| orenlindsey wrote:
| Only a single HTML file. All you need.
| geor9e wrote:
| I thought this comment was saying they only used html like this
| other HN post was talking about
| https://www.htmhell.dev/adventcalendar/2023/2/ . But no, the
| comments just saying they put all the .js and .css inside the
| .html file.
| qwertyforce wrote:
| dx1*=2; dy1*=2; dx2*=2; dy2*=2;
| senkora wrote:
| See also OP's post on Mastodon:
| https://hachyderm.io/@vnglst/111828811496422610
| geor9e wrote:
| 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.
| brown wrote:
| 4 players: https://codyebberson.github.io/pong-wars/
| archon1410 wrote:
| The code links this tweet as the source of the idea:
| https://twitter.com/nicolasdnl/status/1749715070928433161
| [nitter:
| 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 wrote:
| By definition... if there's no end condition, it won't end ;)
| praptak wrote:
| On 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 wrote:
| You'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 wrote:
| One 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.
| sgtnoodle wrote:
| Well, it seems like there must be a relatively stable
| equilibrium. As the owned area decreases, the rate of
| annexation increases.
| conductr wrote:
| Each ball will occupy a minimum area of 1x1, so the opposing
| ball can never occupy 100%
| barnabee wrote:
| 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.
| cjg wrote:
| Because 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.
| hombre_fatal wrote:
| You 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 wrote:
| 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.
| pbiggar wrote:
| Would love to be able to speed this up!
| sbarre wrote:
| I had the same thought... If you drop this in the console you
| can speed things up:
| dx1*=2;dx2*=2;dy1*=2;dy2*=2;
|
| edit: someone else in the thread figured out a better way, I
| updated mine, but credit to them.
|
| Although it has accuracy issues when you get too fast...
| TacticalCoder wrote:
| There's beauty in knowing that one could be ported and run
| perfectly fine on any old 8 bit computer! So simple yet
| mesmerizing...
| tamimio wrote:
| It look like the white ball is faster..
| sbarre wrote:
| The code introduces some speed variation on each bounce, either
| positive or negative so it's possible that over time one ball
| ends up a lot faster?
| billylo wrote:
| What if it has real paddles? left-hand (using A,Z) vs. right-hand
| mode (K,M)? :-)
| NKosmatos wrote:
| Hey, I can see an addictive mini game being developed pretty
| soon... I'm sure one of the bright minds of HN will offer us
| this game so we can alter/control/influence this never ending
| battle of the two pongs :-)
| sega_sai wrote:
| 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.
| JKCalhoun wrote:
| Like the card game, "War", it seems to self-regulate that way.
| I assume neither side will ever win.
| yellowapple wrote:
| With "War" it's indeed possible to win, though.
| ericskiff wrote:
| Oh man - I love this, but I thought it was going to be a loving
| write up of the freeware "mortal kombat but it's pong" game from
| 1994 https://archive.org/details/msdos_Pong_Kombat_1994
| layer8 wrote:
| There's a universe in which it will reach a yin-yang
| configuration.
___________________________________________________________________
(page generated 2024-01-27 23:00 UTC)