Reading this write up is funny, because I had no idea this is what was happening. There didn't seem to be an explanation of what was going on. I didn't know it was a shared experience, just that various random things seemed to be chaotically happening. I completed a couple of tiles and I guess submitted them as I thought that was how you got to "the next level", but gave them really stupid names like "test 1b" - mostly this is because I assumed it was single player and only I'd be seeing the name!
I also got bored after creating a couple of tiles. I scrolled around and saw very complicated things, but didn't realise they were submissions, just starting points for solving the level...
They should've started with an example that you can edit, OR just start with the final result and a call to action, e.g. by focusing it on an empty slot.
LOL. I'm much much worse. I played with it for like 2 minutes and had no idea what was going on and gave up. Maybe because I never used that machine game is was patterned after? :-)
Same. And it took me 10 minutes to realize I could scroll right on the tool selection area... I could only see like a wood bar, a sword and a couple of other things on my phone.
With the other tools it's so much fun. My kids will love it.
I was adding a lot of "bonk" elements and I seem to have murdered rapier...
Uncaught Error: recursive use of an object detected which would lead to unsafe aliasing in rust
at jt (rapier_wasm2d_bg.js:4836:11)
at 4ea5626ea4b1e4145572.module.wasm:0xf061c
at 4ea5626ea4b1e4145572.module.wasm:0xf0638
at 4ea5626ea4b1e4145572.module.wasm:0xb5e7b
at H.remove (rapier_wasm2d_bg.js:1051:14)
at l.remove (collider_set.js:87:18)
at y.removeCollider (world.js:343:28)
at PhysicsContext.tsx:258:15
Also, this is super fun, and I'm sad I didn't learn about it when it was still live. It'd be really really cool if people could still permalink individual machines created. I know that might be an issue for storage. Maaaaaybe just base64 encode the JSON into a URL param??? Please?? I'd love to create weird maps and share them with people.
Machines that make it into the overall public version can be permalinked, but there's no permalinks for individually created things that don't get selected via the moderation queue. This was an intentional decision to avoid the risk of hosting unmoderated user-generated content on the comic's domain.
Oh, gotcha... I submitted a few, but thought the event had ended and the overall machine was finalized. It would've been nice to have a messaging explaining that the machine will be reviewed and maybe a way to check back if it got added.
> There was no incentive to carefully consider where to place a sticker. Players didn’t have enough agency to advance the plot through their individual action. This limited creativity to simple patterns like tiling similar stickers or forming lines.
I tried participating when it came out. I think I spent an hour building something that was as reliable (in terms of getting the correct balls to the correct output) as I could. After I submitted it, I refreshed the page and found at that spot someone else's contraption (which was, admittedly, prettier, but not as reliable). Oh well; though, I wish that sort of thing was a bit more up front.
It also looks like I'm not the only one who hasn't figured out that the list of building blocks is scrollable!
I feel like I'm missing something - why do certain elements seemingly only effect a specific color of ball in the machine? I assume it's to prevent the colors from getting totally jumbled up, but it doesn't seem like that's explained in this write up?
We gave each ball different physical properties. Yellow balls are light and have lots of air drag. Green balls are massive. Red balls are very bouncy. This allows physical sorters to be designed.
Ah, I was confused by this as well, this information is missing from the article. I couldn't find any explanation about the colors in the application either.
I wish they had a way of easily figuring out if any of the machines you built made it into the final version or not. Maybe for a future design it would be neat to store the titles of previous submissions in something like local storage and you could provide a notification.
The thing I'm most confused about is I thought xkcd was one guy named Randall's webcomic, but this post makes it sound like there are several people involved in creating the comics. Is that the case? Does Randall still draw them or is it like a company with a whole creative team now?
Most comics are just Randall, but there are a handful of people who contribute to the occasional more unique / interactive comics, such as the April Fools ones.
I believe his April 1st "comics" have always been coded by someone else; there's been development notes by the developer(s) like this posted after each one.
I am actually a little relieved because everytime one of these interactive XKCD comic is published I wonder how does Randall find enough time to work on them, plus What If, etx.
Of course there are some people that simpliy are hyper productive, but the level of detail and complexity of these comics always made me feel a bit "inadequate" :)
tbf, I don't think he has another job, so if he's only creating 3 comics a week and writing his books, there is def enough time as a side project to put out a fun annual comic that requires a bit of work, obviously it would need to be planned well in advance, which it appears this was not.
I've always assumed he has a large backlog of comics, and a script that pushes them out on schedule.
He can always push new comics into the queue based on current events or fresh ideas, but at other times he can probably go for weeks without needing to draw new comics.
Right. Maybe the workload is manageable, especially for someone with the amount of experience he has, nevertheless the breadth of the stuff he does is what amazes me the most.
Just programming one of those interactive comics must be quite a challenge, to then add the story, the wittiness, depth, etc is what blows me away.
It is reminiscent of the very old DOS game "The Incredible Machine": you receive a certain number of various items (fans, conveyor belts, basket balls, tennis balls, cat, mouse (cat would follow mouse upon seeing it), mirror, candles, etc.) and with the items you had, you had to solve a problem like, say: "To win the level, you must send 32 tennis balls above the wall".
> On April 5th, xkcd released Machine, our 15th annual April Fools project.
Wait, “our”? I thought XKCD was just Randal Munroe.
> Machine’s backend was written in Haskell by davean and Kevin
So at least two other people. Three when counting the author of the blog.
The Wikipedia page for XKCD doesn’t show these names. Is XKCD a multi-people effort now, or are these “friends of the comic” who work on interactive stuff?
There's been a large "friends of the comic" group since day one, there was (and likely still is) an active IRC group that included Munroe that discussed old comics and generated ideas for new ones, the alternative text behind the comics and related facts sheets get a good going over by a small cadre of friends and regulars with an engineering | physics | maths | chenistry, etc bent.
(And besides - if Randall f*ing Munroe contacted a few people, who were experts at $Foo, $Bar or $Baz, with "I've got this really cool idea, but I'd need some help..." - how hard would it be for him to get some "yes" answers?)
Really cool, I really enjoy the "follow" feature. Unfortunately, the balls get stuck sometimes and I have to follow a different one. I guess a few bugs slipped through the mod queue.
The piece was well written and explained the functionality quite elegantly with enough technicality without overburdening the reader with technobabble.
Honestly every time I start to think I'm rather quite good at frontend development, someone posts something like this and makes me feel like an intern by comparison. To have built this in 3 weeks is Herculean to me. It probably would have taken me 3 weeks to figure out the physics context alone.
Open your browser's debug console and paste this in:
function solveSecondOrderODE(b, c, y0, dy0, dt, tMax) {
let t = 0;
let y = y0;
let dy = dy0;
while (t <= tMax) {
console.log(`At time ${t.toFixed(2)}: y = ${y.toFixed(4)}`);
let ddy = -b * dy - c * y; // Compute the acceleration (second derivative)
y += dy * dt; // Update position
dy += ddy * dt; // Update velocity
t += dt;
}
}
// Example usage:
// Constants b and c for the damped harmonic oscillator
const b = 0.5;
const c = 1.0;
// Initial conditions: y0 (initial position), dy0 (initial velocity)
const y0 = 1.0;
const dy0 = 0.0;
// Time step (dt) and maximum time (tMax)
const dt = 0.1;
const tMax = 10;
solveSecondOrderODE(b, c, y0, dy0, dt, tMax);
The basic concepts translate well from other languages like say, Python.
I work for a major University. The only major numerate discipline for which we do not teach programming to undegraduates is Medicine, and my guess is that Medics are already completely buried by the tremendous amount of stuff they're expected to have at least some knowledge of to do their eventual jobs, without us showing them how to make apps.
Like sure, if you come here to study Fine Art, we don't (by default) teach you to write software, but if you come to learn like mech eng. or electronics or chemistry or something you're going to be shown how to write software. You can probably flunk that in most of these subjects and still get a degree because it's not on your critical path, but we tried.
These are not software engineering courses. You're not going to learn how to be in charge of a major software project, you won't learn how to design software, nor even stuff like CI and revision control - if you try to scale what you learned in one course as a Biologist into a Chrome-sized application that's going to be a disaster, but you've written software, you know what a loop is, what a variable is, and so on.
"Machine is rendered entirely using the DOM. During early dev I was leery I’d reaching the end of my rope perf-wise. I expected I’d eventually ditch DOM rendering for PixiJS or canvas when it got too slow. However, I wanted to see how far I could take it
...
I’ve heard comparisons drawn between modern browsers and game engines, with their tightly optimized GPU rendering and DOM / scene graph. The similarities have never felt more apt."
The DOM might have become faster, but using the GPU directly via Pixi is still a world above in terms of performance and using Pixi could have made everything more smooth. But dev time was limited .. and the result is still impressive.
Agreed. DOM started as a prototype and I stayed on it primarily for dev speed due to momentum (and some React DX things -- I checked out the Pixi React binding but decided not to go down that rabbit hole). It's amazing how efficient Pixi is!
I'm just the tiniest bit disappointed to have confirmation that mods probably didn't wait around for one of my zero-element machine submissions (I imagine I called it "patience is a virtue", given how long I had to sit around waiting to click submit on it) to eventually pay off :)
Some tiles are ~solvable without building anything.
Sometimes this is dead-simple (the balls just drop from the top on through).
Sometimes, they'll solve if you're patient enough (the balls pile up, shift around, and sooner or later enough of them exit within the time window necessary to trigger the submit UI).
Edit: to finish connecting the dots just in case--I waited quite a while for one, probably at least 10 minutes--to do this. When the clearance rate for a machine is poor, it will usually drop back under the submit threshold very quickly. In these cases, you have to watch very carefully to be prepared to submit in the brief window that the submit UI is enabled. The OP suggests that during moderation they generally waited 30 seconds for a submitted machine to do the thing before they moved on.
We also set up the minimum requirement for the submit button to be unlocked to not be too strict, to avoid frustrating people, but held a bit of a higher standard for the things we selected to be part of the public machine. So designs that only just barely work well enough to occasionally unlock the submit button are probably too unreliable to get selected for inclusion (but we made occasional rare exceptions if the submission was particularly interesting / inspired for other reasons).
Because the machine is a physics simulation. Where users can set up simulated physical objects like barriers and bumpers, and you want the animation to display a simulation of what happens according to the laws of physics.
I think you may be missing the point if you think this is an animated rendering of a static setup?
The problem description is ”Could we make a really big tiled mechanism like the blue balls GIF? Where everyone contributes a small square?”.
There is a stated rationale for every other design choice, but the blue balls GIF is an animation, not a simulation. It didn't even start as a simulation. So why the choice of making this a simulation, not an application for users to animate tiles?
As a nerd, I hunger for consistency. This wasn't - it took snapshots and handwaved them together.
Can't help but feel it would have been a lot better with constrained physics and automated submissions.
The current version is probably more fun to be on "the inside" of, evaluating submissions and stitching them together, but at the expense of the finished product.
As a nerd, I love to see carefully maintained illusions that give a convincing impression of something much more grand going on than is actually happening. Games that push for more and more realism make me wonder why I don't just wander around the real world. Games grounded in realism but augmented with nonrealism (magic, special powers, added knowledge, selective relaxation of physical laws, ...) are fun.
Your "constrained physics" seems to mean adding constraints to make it implementable. I want constraints aimed at making it cool or fun, and implementable. Which is what this project did.
Plus: if you tell me something is smoke and mirrors, I get excited. "Ooh! How did you time the smoke? Oh, this mirror is half-silvered?! That's awesome, I wouldn't have thought of that! What would happen if..."
I may be missing something, but that seems to be an apples to oranges comparison.
How is your turn based app example analogous to a complex physics simulation? And what exactly do you consider about the app's multiplayer to be the bar?
Edited since, but what that game does is let you participate asynchronously in a completely distributed way. It's a real miracle of game design.
This one is kludging from every angle. They're cheating with the physics, they're cheating with who sees what, they're cheating by handpicking levels. It results in an experience that isn't grounded, because none of the foundational dimensions are real.
As much as I hate to spoil the illusion, the kludging you mentioned is basically the sum of the natural drawbacks faced in virtually all game design. Whether it's a skybox, an NPC, or a virtual bullet, it's all basically cheating through constraints and illusions.
Great example: Space Engineers, a very popular game in which you can build ships, bases, etc. with an incredible consideration for automation, moving things around, etc. One of my favorites. But the game intentionally (1) limits the top speed of all entities to 100m/s, (2) doesn't actually simulate orbital mechanics despite having planets, and (3) forces you to construct things on a 'grid'. All of these constraints are arguably shortcomings, but they also enable the physics engine to live and collisions to work.
You're asking a lot from an April fools joke from a comic creation team.
Also, what you're asking for is very hard to do with physics engines as they exist now. Simulating a bunch of non-static elements like that is incredibly expensive.
The explainxkcd wiki says that cats were added later, and that permalinks go to a snapshot of the machine. So it's possible all the cats are lower in the machine, or the permalink is from before cats were added. There's some cats at the bottom of the machine right now. https://xkcd.com/2916/#xt=2&yt=105&v=1402
I have a bookmark for it, and whenever I want to kick back a bit, perfect.
However, I've noticed that it has a tendency to go blank (i.e. fail and stop working) when multiple colour spectrum triangles are in play and in particular when they are on top of each other.
I'd really like to see some additional objects to place into the machine.
One other problem I have is that the "perma-link" button doesn't seem to do anything. When I come back to the URL, my machine isn't there.
Permalinks are only for machines that have already been approved via the moderation queue as part of the shared public machine. Submitting a machine only submits it as a candidate for inclusion, it doesn't guarantee that your submission is the one picked for the slot.
Haha I've had the same problem with triangles, stopped using them because they always crash. Only when editing, not when viewing.
Have a look at my repo if you want to search for any of your submissions to see if they ever got published.
https://github.com/scpso/incrediblexkcd
I also got bored after creating a couple of tiles. I scrolled around and saw very complicated things, but didn't realise they were submissions, just starting points for solving the level...
I guess I was the April Fool!
Machines that make it into the overall public version can be permalinked, but there's no permalinks for individually created things that don't get selected via the moderation queue. This was an intentional decision to avoid the risk of hosting unmoderated user-generated content on the comic's domain.
https://news.ycombinator.com/item?id=39953514
Ah, the game turned into a big corp job!
It also looks like I'm not the only one who hasn't figured out that the list of building blocks is scrollable!
Ugh. Just submitted two, and had no idea the list could be scrolled. Can't be bothered going back and looking now though. :(
Cool to see a more refined and well-functioning version of the idea.
https://www.myabandonware.com/game/the-incredible-machine-1m...
https://explainxkcd.com/wiki/index.php/2916:_Machine
Of course there are some people that simpliy are hyper productive, but the level of detail and complexity of these comics always made me feel a bit "inadequate" :)
As if this is not an absolutely breathtaking creative accomplishment, especially so consistently and after so many years!
I agree with another commenter that it probably does get easier with experience, but nevertheless impressive.
He can always push new comics into the queue based on current events or fresh ideas, but at other times he can probably go for weeks without needing to draw new comics.
Just programming one of those interactive comics must be quite a challenge, to then add the story, the wittiness, depth, etc is what blows me away.
Wait, “our”? I thought XKCD was just Randal Munroe.
> Machine’s backend was written in Haskell by davean and Kevin
So at least two other people. Three when counting the author of the blog.
The Wikipedia page for XKCD doesn’t show these names. Is XKCD a multi-people effort now, or are these “friends of the comic” who work on interactive stuff?
Edit: I've updated the first para of the post to hopefully clarify this better
Several years ago XKCD released a comic that was different depending the browser, operating system, ip, and referrer you use to view it.
I know people uncovered hundreds of versions of it but I never heard a detailed write up about how it worked or how many comics there were available.
Does anyone know if they ever figured it out?
A few more links for the record (don't read too soon, possible spoilers):
https://www.reddit.com/r/xkcd/comments/1bxg43b/xkcd_2916_mac...
https://www.explainxkcd.com/wiki/index.php/2916:_Machine
https://github.com/xkcd/incredible
Its not like you can solve a 2nd order differential equation in bowser.
I work for a major University. The only major numerate discipline for which we do not teach programming to undegraduates is Medicine, and my guess is that Medics are already completely buried by the tremendous amount of stuff they're expected to have at least some knowledge of to do their eventual jobs, without us showing them how to make apps.
Like sure, if you come here to study Fine Art, we don't (by default) teach you to write software, but if you come to learn like mech eng. or electronics or chemistry or something you're going to be shown how to write software. You can probably flunk that in most of these subjects and still get a degree because it's not on your critical path, but we tried.
These are not software engineering courses. You're not going to learn how to be in charge of a major software project, you won't learn how to design software, nor even stuff like CI and revision control - if you try to scale what you learned in one course as a Biologist into a Chrome-sized application that's going to be a disaster, but you've written software, you know what a loop is, what a variable is, and so on.
...
I’ve heard comparisons drawn between modern browsers and game engines, with their tightly optimized GPU rendering and DOM / scene graph. The similarities have never felt more apt."
The DOM might have become faster, but using the GPU directly via Pixi is still a world above in terms of performance and using Pixi could have made everything more smooth. But dev time was limited .. and the result is still impressive.
In my defense, I did personally find it quite suspenseful to wait for my vague sense that chaos would eventually reward me to cash out.
Now that I reflect, I might have also called it "WU WEI". I know I also used that for (at least) one of my zero-element submissions.
Also--apologies if the "ONLY FANS" submissions wore out their welcome. I'm sure I wasn't the only one, but I was probably a fair fraction :)
Sometimes this is dead-simple (the balls just drop from the top on through).
Sometimes, they'll solve if you're patient enough (the balls pile up, shift around, and sooner or later enough of them exit within the time window necessary to trigger the submit UI).
Edit: to finish connecting the dots just in case--I waited quite a while for one, probably at least 10 minutes--to do this. When the clearance rate for a machine is poor, it will usually drop back under the submit threshold very quickly. In these cases, you have to watch very carefully to be prepared to submit in the brief window that the submit UI is enabled. The OP suggests that during moderation they generally waited 30 seconds for a submitted machine to do the thing before they moved on.
I think you may be missing the point if you think this is an animated rendering of a static setup?
There is a stated rationale for every other design choice, but the blue balls GIF is an animation, not a simulation. It didn't even start as a simulation. So why the choice of making this a simulation, not an application for users to animate tiles?
Can't help but feel it would have been a lot better with constrained physics and automated submissions.
The current version is probably more fun to be on "the inside" of, evaluating submissions and stitching them together, but at the expense of the finished product.
Your "constrained physics" seems to mean adding constraints to make it implementable. I want constraints aimed at making it cool or fun, and implementable. Which is what this project did.
Plus: if you tell me something is smoke and mirrors, I get excited. "Ooh! How did you time the smoke? Oh, this mirror is half-silvered?! That's awesome, I wouldn't have thought of that! What would happen if..."
How is your turn based app example analogous to a complex physics simulation? And what exactly do you consider about the app's multiplayer to be the bar?
This one is kludging from every angle. They're cheating with the physics, they're cheating with who sees what, they're cheating by handpicking levels. It results in an experience that isn't grounded, because none of the foundational dimensions are real.
Great example: Space Engineers, a very popular game in which you can build ships, bases, etc. with an incredible consideration for automation, moving things around, etc. One of my favorites. But the game intentionally (1) limits the top speed of all entities to 100m/s, (2) doesn't actually simulate orbital mechanics despite having planets, and (3) forces you to construct things on a 'grid'. All of these constraints are arguably shortcomings, but they also enable the physics engine to live and collisions to work.
Also, what you're asking for is very hard to do with physics engines as they exist now. Simulating a bunch of non-static elements like that is incredibly expensive.
I have a bookmark for it, and whenever I want to kick back a bit, perfect.
However, I've noticed that it has a tendency to go blank (i.e. fail and stop working) when multiple colour spectrum triangles are in play and in particular when they are on top of each other.
I'd really like to see some additional objects to place into the machine.
One other problem I have is that the "perma-link" button doesn't seem to do anything. When I come back to the URL, my machine isn't there.