explain xkcd - User contributions [en]

Talk:3015: D&D Combinatorics

2025-03-20T22:14:38Z

172.71.241.45: /* Am i the only one being extremely confused by the trivia section? */

The bot originally created this page as “D Combinatorics”. I renamed it to the correct title and tried to get as many of the references as possible (including a few redirects). [[User:JBYoshi|JBYoshi]] ([[User talk:JBYoshi|talk]]) 00:54, 23 November 2024 (UTC)

:The title in the Atom feed (which I'm assuming the bot consumes) is "D Combinatorics". I'm guessing something in Randall's pipeline didn't like the ampersand. --[[Special:Contributions/162.158.154.160|162.158.154.160]] 01:41, 23 November 2024 (UTC)

::Yup, if you look at [https://xkcd.com/3015/info.0.json 3015's JSON] you see that <code>title</code> and <code>safe_title</code> differ, and if you look at the HTML page source you'll see '''3''' different things: <code><title>xkcd: D Combinatorics</title></code>, <code><meta property="og:title" content="D&amp;D Combinatorics"></code>, and <code><div id="ctitle">D&D Combinatorics</div></code>! So probably what happened is Randall entered D&D but was supposed to enter D&amp;D, and the openGraph tags adder code, having to be HTML-aware, decoded & normalized D&D as HTML would, but the other parts of the pipeline just ate it for some reason. {{unsigned ip|172.69.65.224|06:09, 23 November 2024}}

::: The problem now is that the feed doesn't validate (because it contains a bare &) and it's also not updating (maybe because of the previous problem). --[[Special:Contributions/172.71.119.13|172.71.119.13]] 11:10, 28 November 2024 (UTC)

::: Well, it's updating now, but it still doesn't validate. Sigh... --[[Special:Contributions/172.70.160.195|172.70.160.195]] 11:33, 10 December 2024 (UTC)

What are the odds of rolling 16 or higher on 3D6+D4? 3D6 average 10.5, D4 average is 2.5, total average should be 13. I do not know how to proceed from here. {{unsigned ip|172.71.147.206|01:14, 23 November 2024}}
:By raw combinatorics: 71 + 52 + 34 + 20 + 10 + 4 + 1 ways to get each of 16 - 22 respectively, for a total of 192, out of 4(6^3) = 864 total. 192/864 simplifies to exactly 2/9. I have no idea how Randall found this; if anyone has an idea, please let me know. [[User:Kaisheng21|Kaisheng21]] ([[User talk:Kaisheng21|talk]]) 01:33, 23 November 2024 (UTC)
::I used some simple python code to loop over every dice and confirm and it's 2/9 [[Special:Contributions/162.158.158.111|162.158.158.111]] 12:11, 23 November 2024 (UTC)
::I suspect there is no better way of doing it than looping over the dice. As to how Randall discovered it, it was obvious that at least 2d6 would be needed (since d6 is the only D&D dice that has a multiple of 3 sides), and after that my guess is Randall used a combination of a python script and some experimentation to land on the correct choice of dice. [[Special:Contributions/172.70.162.56|172.70.162.56]] 14:15, 1 December 2024 (UTC)

It seems like we edited the transcript at the same time. The odds of rolling 16 or higher in this situation seem to be 2/9? [[User:Darkmatterisntsquirrels|Darkmatterisntsquirrels]] ([[User talk:Darkmatterisntsquirrels|talk]]) 01:29, 23 November 2024 (UTC)

: There are 864 possible rolls (6 * 6 * 6 * 4). If you enumerate all of the rolls you will find that 192 are 16 or higher. 192/864 = 2/9, the value from the explanation. [[Special:Contributions/172.68.54.139|172.68.54.139]] 01:41, 23 November 2024 (UTC)

I added a table of outcomes to clarify how it works out to 2/9, anyone know how to make it pretty? -- Laurence Cheers {{unsigned ip|172.71.150.247|02:03, 24 November 2024}}

A much simpler approach: Roll two six sided dice and sum the result. You are successful if the result is 5 or 9. That happens 8 times out of 36. 8/36 = 2/9. (Or successful if the sum is 4 or 6, or 2 or 7, or 2,3,4 or 11, or several other combinations.) [[Special:Contributions/172.68.54.139|172.68.54.139]] 01:41, 23 November 2024 (UTC)
:Clever, but dice rolls in D&D involving summing all the dice, applying modifiers, if any, and then comparing to one or more threshold values. Your method makes it very difficult to apply modifiers. [[Special:Contributions/162.158.41.8|162.158.41.8]] 02:49, 23 November 2024 (UTC)
::I think you misunderstand the problem here. This is not skill, no modifiers apply, it's purely probability [[Special:Contributions/162.158.158.111|162.158.158.111]] 12:11, 23 November 2024 (UTC)

Minor quibble, arrows aren't fired (unless they're flaming or self-propelled, perhaps), they are shot. (Shotguns are fired of course.) [[Special:Contributions/162.158.41.73|162.158.41.73]] 02:52, 23 November 2024 (UTC)
:Arrows are "loosed", even more accurately. At least to avoid the confusion from how so many things may be shot, or ''a'' shot. (Many different nouns, from a physical measure of liquer/coffee/vaccine to a projectile, or an even abstract fundemental of chance; and, as verb, projectiles perhps may be shot, then so may their targets.) [[Special:Contributions/172.68.205.178|172.68.205.178]] 14:32, 23 November 2024 (UTC)
:Well, lets not quarrel over it.[[Special:Contributions/172.71.103.67|172.71.103.67]] 14:37, 25 November 2024 (UTC)
:Too many barbed comments, and I'd be all of a quiver... [[Special:Contributions/141.101.99.153|141.101.99.153]] 14:51, 25 November 2024 (UTC)

Rolling 22 or lower on percentile dice (or, equivalently, 79 or higher) is close enough, and easier to come up with. (Give or take whether 00 is treated as 100 or zero.) Or directly represent the action: roll a d10. If it's 1-5, you lose. If it's 6-10, roll again; if it's 1-5 you lose, 6-9 you win, 10 roll again. (Modify slightly if you want to distinguish the case of grabbing *two* cursed arrows.) [[User:Jordan Brown|Jordan Brown]] ([[User talk:Jordan Brown|talk]]) 03:26, 23 November 2024 (UTC)

Alternative exact solution for getting this probability using dice: Roll: 1d8, 2d6, 1d4 succeed on 19 or higher.{{unsigned ip|172.68.55.11|03:54, 23 November 2024}}

I couldn’t remember the formula for binomial coefficients (“n choose k”), but there’s an easy way to calculate that the probability of drawing no cursed arrows is 2/9 without that formula. You just need to multiply the probabilities that each of the arrows drawn is not cursed. Since only two arrows are drawn, you only have to multiply two numbers.

The probability that the first arrow is not cursed is 5/10 – there are 5 non-cursed arrows and 5 cursed arrows out of 10 total. After taking out one non-cursed arrow, there are 4 non-cursed arrows and 5 cursed arrows out of 9 total, so the probability that the second arrow is not cursed is 4/9. Multiplying the two probabilities, the probability of drawing two non-cursed arrows is (4*5)/(10*9) = 20/90 = 2/9.

I was considering writing this observation in the Explanation section of the page, but I’m not if it belongs there. This solution avoids using formulas from combinatorics, so it might not be connected enough to the comic.—[[User:Roryokane|Roryokane]] ([[User talk:Roryokane|talk]]) 06:02, 23 November 2024 (UTC)

My simple-minded approach:
* Roll d10 once for your first arrow: if 1 to 5, the arrow is cursed, otherwise not;
* Roll d10 again for your second arrow: same rules, but repeat until you have a different number from the first one (so d10 is in fact only a d9 this time)
* I won't calculate probabilities – these are your arrows, live with it ;-) [[Special:Contributions/172.69.109.51|172.69.109.51]] 07:33, 23 November 2024 (UTC)
:That has the benefit (over 3d6+1d4) of telling you which arrow(s) (if either) was cursed. [[User:RegularSizedGuy|RegularSizedGuy]] ([[User talk:RegularSizedGuy|talk]]) 07:52, 23 November 2024 (UTC)
::Also tells you how many cursed arrows are left, which is useful if the next player wants to take their chances with them too.[[Special:Contributions/172.71.103.68|172.71.103.68]] 14:40, 25 November 2024 (UTC)
:If you don't like re-rolls, you can make d9 out of 2d3. Nine possibilities, so just assign one of them (perhaps by rolling them one at a time) to be the more significant digit. Don't have a d3 handy? Use d6 and modulo off the extra! (1=1, 2=2, 3=3, 4=1, 5=2, 6=3) [[Special:Contributions/172.68.150.91|172.68.150.91]] 05:59, 24 November 2024 (UTC)

There seems to be doubt that a "N locks and M keys to unlock them" system could be easily accomplished. I think it could be trivial, with strategically interlocking locked-restraints. A chain formed of bike-locks can give a larger locked loop that can be unlocked by just unlocking any ''single'' one of the constituent locks, leaving the other locked loops to not matter (or you could also try the {{w|Borromean rings}} system, whereby it is again secure against itself, until just one ring is opened up to reveal that the rest now ''aren't even locked at all''...). With almost arbitrary ability to cross-link (or, if you will, repeated/alternating-reflected Borromean triplet connections), you can extend the requirements to more than one unlocking being required (by looping chain elements to mre than just the 'adjacent' loops, sideways onto a parallel meta-loop or up/down the chain, all you might do is allow some slack (could be sufficient to get a thing held directly closed by the taut loop-of-loops, but not enough if the passage of the loop through a hasp/sneck actually prevents the otherwise free movement of the final slide-to-unlock action to occur), but a second (or third, or fourth) unlocking can be required to open-end the whole metaloop of locks. At the top end, M=N solutions are also trivial (e.g. two keys, two locks popularly of safety deposit boxes or [[2677: Two Key System|other things]]). Which is not to say that a specific M-of-N puzzle (where 1<M<N) might not need a ''little'' bit of thought to actually design and implement, but there's no obvious reason why all such combinations shouldn't be nicely doable. [[Special:Contributions/172.69.79.165|172.69.79.165]] 14:56, 23 November 2024 (UTC)
:Can we first confirm that the M-of-N Encryption was what Randall was referencing in the first place? [[Special:Contributions/172.71.154.140|172.71.154.140]] 03:17, 24 November 2024 (UTC)
::No, first confirm that this is what the explanation treats as what Randall was referencing. As it was, "complicated lock mechanics" and/or "magic" were suggested as the only ways of doing this, when this (or what we thought this was) just needs a little thought and N bike-locks suitably entangled. [[Special:Contributions/172.70.58.45|172.70.58.45]] 13:17, 24 November 2024 (UTC)
:I'm glad someone else chimed in on this, because it is definitely ''not'' difficult to require unlocking of multiple discrete locks! I can't even figure out why one might think it would be? [[User:ProphetZarquon|ProphetZarquon]] ([[User talk:ProphetZarquon|talk]]) 15:55, 24 November 2024 (UTC)
::I had assumed that the locks were built into the chests (as they sometimes are), and that the chests were physically separated. Using m of n keys on a single chest would merely be complicated, but wouldn't really fulfill the description. Leaving the chests unlocked, but tightly wrapped in a locked chain would be more like drawers of a single "chest". I instead assumed that each of m chests had to be individually opened with its own proper key, but you had n chests to choose from. It was unspecified what would happen if you tried pairing a chest to the wrong key; perhaps both the key and the chest would be disabled (melted/stuck/burned/teleported). (And yes, needing only a subset of the chests, but any sufficiently large subset will do, is a semi-standard class of problem; a search for Byzantine Generals or PAXOS algorithm will get you started.) [[User:JimJJewett|JimJJewett]] ([[User talk:JimJJewett|talk]]) 07:45, 5 December 2024 (UTC)
:::For certain combinations of Ms and Ns, one solution is to have each chest have M locks (that must all be unlocked), such that each possible combination of M keys fully opens (at least) one chest, within which are the necessary complimentary keys to now fully unlock every other chest. A looser version is to have possibly only M/2 (or M/3, etc) locks in a configuration whereby you get to open any given two (or 3+) chests that only produce the full set of keys (and probably spares), but does leave it open to being exploited as "we could only open the one chest, and maybe one or two others with (M/2)<(owned keys)<(M) partial key overlap but at least it had ''some'' of the available treasure", unless designed to not work like that.
:::The limited subset of workable {M,N} values makes it impractical as "I have N chests and M chests, how do I...?" puzzle-setting, but still leaves it possible to force a puzzle from scratch that works this way (e.g. "you must have visited at least M antechambers and deceated the Key Guardians within, before you can open the chests within which are all the components necessary to create the potion that makes you ElementalLevelBoss-Proof"), for which you can determine a convenient set of requirements.
:::One (simple) combination would be two of three distinct keys (#1, #2 and #3) and three chests ("A", needs #1+2, contains #3; "B" needs 1+3, contains 2; "C" need 2+3, contains 1).
:::Add in the feature of duplicate keys but also a mechanism (or magic, or valid physical reason) which causes keys to be stuck in the locks (or vanish/melt/shatter/etc) upon being used, and you can create an even more complex puzzle, whereby having keys enough to (theoretically) open two chests is actually only enough to open one of them initially as you then lose the ability to attempt to open the other... at least until the opened chest provides new keys enough to open (perhaps by opening a different interim chest, with its own new keys, etc) the one that you did not initially choose. This would greatly expand the number of higher-order "M-of-N" combinations that you could facilitate. And could even created "M>N" requirements (three keys, two (combo-)locks: chest A needs 1+2, chest B needs 1+3; both render any keys inserted beyond further use but also contain a 'spare' 1; you need to externally gain 1+2+3 to eventually open A+B).
:::Exactly how (and why) you do it is open to your own needs.
:::And, if you're open to add an intermediate "locked box", you can exploit the trivial many:one ''and'' one:many relationships by just compounding them together, and maybe even adding more steps; e.g. with the last example of keys 1+2+3 opening A+B, you can offer up (from A, 4)+(from B, 5). To unlock C needs both 4+5 (thus 1+2+3, once removed), which itself handily contains ''all'' the further individual keys (or copies of the one key) required to open D, E, F, ... Z, so grants the stipulation of "3 needed to open 23". Or the earlier 2 keys (non-sticking, or regained by copies) for 3 chests grants the full co-keys needed to open that same key-store (see also {{w|Annett's key}}). Arbitrarily higher permutations of pretty much any initial number of (original) keys and however many intermediate openings (to match the singular key-safe's relatively simple multi-key requirements) steps you through the means to then open an arbitrary number of (final) locks, but you won't get ''any'' of the last locks unlocked if you have not fully satisfied the very first requirement.
:::...although it'd be neater if it was an M-and-N that was more direct, I still think. [[Special:Contributions/141.101.99.85|141.101.99.85]] 18:13, 5 December 2024 (UTC)

"other polyhedral dice, with the number of faces denoted by dX (e.g., d10 is a 10-sided die, with numbers from 1 to 10 on it)." - the d10 may be a poor choice as exemplar here; Back in the last century, when I was playing D&D, d10 were typically (and uniquely) numbered 0-9, not 1-10. This may no longer be the case, and I may be showing my age, but if it is still the norm, the d8 or d20 might be a better choice of example. [[Special:Contributions/172.68.210.6|172.68.210.6]] 02:40, 24 November 2024 (UTC)
:Typically, I've only seen 0-9 d10s, as part of a "d100" dice pair, with one reading 0-9 & the other reading 0⁰-9⁰... Single d10, mostly seem to come in 1-10? Maybe it depends which reseller one shops at... [[User:ProphetZarquon|ProphetZarquon]] ([[User talk:ProphetZarquon|talk]]) 15:49, 24 November 2024 (UTC)
::They are usually numbered 0-9, but the 0 represents 10, since writing 10 would require that face to have a different font size. It is still a d10, since the die has ten sides, and still cannot roll at 0. The d100 variant does the same thing with 100, but for the added reason that the 00 face actually does mean 0 when the other die rolls a 1-9. This is the convention, so a die that actually writes 10 on it instead of 0 will be rare. [[User:Stardragon|Stardragon]] ([[User talk:Stardragon|talk]]) 23:14, 24 November 2024 (UTC)

You've all been nerd-sniped. [[User:CalibansCreations|'''Caliban''']] ([[User talk:CalibansCreations|talk]]) 10:53, 24 November 2024 (UTC)

Combinatorics degree? Does such a degree really exist? --[[Special:Contributions/162.158.130.37|162.158.130.37]] 17:19, 24 November 2024 (UTC)
:There are degrees for all kinds of things. A quick search reveals a number of "Combinatorics" or "Combinatorics and <Foo>" (e.g. "Optimisation") degrees. Some of them are marked as Masters degrees, and I haven't dug into the others to see if there are any 'pure' undergraduate ones (apart from anything else, I know there are crucial differences between the structures and scopes of UK and US 'degree courses' to consider, in particular), but there seems to be representation on both sides of the Atlantic (and elsewhere, e.g. Oceana).
:At the very least, it could be a selected specialised segment of an even wider mathematical degree course, or a cross-disciplinary one (like my own, which was part under Physics and part under Computing, but could have included a Stats-based element). [[Special:Contributions/162.158.74.49|162.158.74.49]] 19:07, 24 November 2024 (UTC)
::So "Combinatorics and <Foo>" would be meta-combinatorics, since it is combining something with something else. :) [[User:RandalSchwartz|RandalSchwartz]] ([[User talk:RandalSchwartz|talk]]) 20:19, 28 November 2024 (UTC)
:::I shall do my degree in "Combinatorics, Selectivity, Comparison, Decision Making and/or Cross-Designation (Choose Any Three)"... [[Special:Contributions/172.70.90.5|172.70.90.5]] 21:28, 28 November 2024 (UTC)

I'm trying this on my DM. -[[User:Psychoticpotato|P?sych??otic?pot??at???o ]] ([[User talk:Psychoticpotato|talk]]) 15:11, 25 November 2024 (UTC)

Can someone put into the Explanation the current details regarding the nature of cursed arrows, in whatever edition of DnD we're currently up to. (8th? I've lost track.) In different DnD-like media, I know that it can act somewhat negatively (reduces aim accuracy) or even outright problematic (it curses the person loosing the projectile; or even renders the bow otherwise useless, as analogue to a cursed weapon), or else reduces/inverts the damage (breaks easier, or essentially acts like a thrown beneficial potion to increase health/strength/stamina/etc of the target). I assume that it one of these, from the assumption that the player desires a "good enough" roll to avoid. On the other hand, cursed projectiles could be treated akin to poisoned arrows or vengeful weapons in doing more, better or more targeted damage (in which case it's a powerful aid, the archer is instead taking a chance of using up a stock of 'special arrows', perhaps in line with not knowing whether their foe ''needs'' that extra degree of offensive power). But, at least from the explaining text's approach to dice-roll results, that doesn't exactly mesh with the typical "higher is better" rolling mantra. [[Special:Contributions/172.70.86.129|172.70.86.129]] 22:43, 25 November 2024 (UTC)

I don't think making an M-of-N mechanism with physical locks would be "extremely cumbersome". For example you could have a bolt that must be drawn back to open the mechanism, with several padlocks over it, where the shackle of each padlock blocks the motion of the bolt, such that the distance you can draw the bolt is proportional to how many padlocks are removed. Removing any m of the n padlocks gives you enough range of motion to open the mechanism.
[[Special:Contributions/172.71.154.224|172.71.154.224]] 23:17, 27 November 2024 (UTC)

A DM with a degree in Combinatorics would be unlikely to find this annoying.[[Special:Contributions/162.158.62.245|162.158.62.245]] 05:30, 30 November 2024 (UTC)

With up to three D&D dice, it is impossible to achieve 2/9 exactly. The closest you can get is with d6 + 2d10x10 >= 146 (where d10x10 denotes the tens die, ranging from 10 to 100) yielding a probability of 133/600 = 0.2216667. [[User:Vandof|Vandof]] ([[User talk:Vandof|talk]]) 06:27, 30 November 2024 (UTC)

With four D&D dice, 2d6 + d8 + d10 >= 21 and d10 + 2d12 + d20 >= 36 are alternate solutions. The former is more feasible than 3d6 + d4 for those who don't have three d6's. [[User:Vandof|Vandof]] ([[User talk:Vandof|talk]]) 06:49, 30 November 2024 (UTC)

You can do it with two dice, although not by summation. Roll 2d3; if 1,1, or 3,3 pass, else fail. [[Special:Contributions/162.158.167.88|162.158.167.88]] 19:41, 3 December 2024 (UTC)

Could someone explain option 6, multiplying two six-sided dice, with a threshold of > 20? I think 66, 65, 64, 56, 55, and 46 all work, making it ... equivalent to 1D6.
[[User:JimJJewett|JimJJewett]] ([[User talk:JimJJewett|talk]]) 07:25, 5 December 2024 (UTC)
:It's >= 20, so 54 and 45 work as well. That brings the probability up to 8/36 = 2/9. [[User:Vandof|Vandof]] ([[User talk:Vandof|talk]]) 13:31, 5 December 2024 (UTC)

;Scales for locking
Wouldn't using scales for the chests that measure their current mass and lock/open the doors based on whether the chest still has the object work for an M-of-N encryption? A simple example: A chest has 2.5 kg of Au, with the chest itself and its combination lock being 20 kg. The next door opens iff the chest's total mass is less than 21 kg. Removing all the Au from the chest opens the door. The second one has an object with the mass of 3 kg, and the chest itself is 22 kg, with ''that'' door opening if the chest's mass is between 23 and 24 kg. Removing the object and replacing it with 1 kg of Au opens the door. Long story short: no, one does not need magic for realizing an M-of-N encryption, one just needs scales for a physical M-of-N encryption. [[Special:Contributions/172.68.245.25|172.68.245.25]] 08:16, 13 December 2024 (UTC)

== Randall doesn't understand probability or games ==

You don't need to combine the probabilities. You just make two checks. The first check is even odds of cursed / normal. If the check fails and it's cursed, presumably you proceed with the consequences of grabbing a cursed arrow, whatever that might be. In any case, whether the first arrow was normal, or the curse doesn't prevent you from grabbing and firing another arrow, the second check is either 4:9 (if the first arrow was normal) or 5:9 (if it was cursed). (These odds are written as the number of normal arrows remaining : the total number of arrows.)

There is no reason to roll the dice given in the comic. He just made up some dice rolls vaguely similar to those that he heard someone mention in the context of tabletop games, and he's certainly never actually played in one. You can convert these probabilities into decimal form and use a d100 for every check. Probabilistic results like these are the reason the d100 is in the game. (You can also roll 2d10, selecting one of them to be the tens digit and the other to be the units digit.)

The chance of succeeding (choosing a normal arrow) on the first check is 50%, so you can use any type of dice, and success is rolling above X/2, X = faces of the dice.

The chance of succeeding on the second check is 4/9 if the first arrow was normal, or about 44%. So you succeed on a roll of 44 or less. The chance is 5/9 if the first arrow was cursed, or about 56%. So you succeed on a roll of 56 or less.

You don't need a degree in anything to reach these conclusions. {{unsigned ip|172.70.83.67|20:51, 17 March 2025‎}}

== Am i the only one being '''extremely''' confused by the trivia section? ==

This is the current trivia section, emphasis mine:
:When this comic was originally released, the '''official title of this page was "xkcd: D Combinatorics", instead of "xkcd: D&D Combinatorics", due to an apparent error on Randall's end.''' [...]

:Whatever the precise problem, the ampersand also presumably [[explain_xkcd:Community_portal/Admin_requests#RSS_Feed_Broken|broke the RSS feed]], an issue that is said to be only fixable by [[User:Jeff]], who has been inactive for over a year now.

Am i the only one who sees the issue?
*3 times it says (or alludes to the fact that) Randall made a misktake on the xkcd.com website, which has nothing to do with this wiki.
**"official title", so on xkcd.com
**""xkcd: D Combinatorics", instead of "xkcd: D&D Combinatorics"" - only pages on xkcd.com start with "xkcd: "
**"error on Randall's end"

*2 times it says (or alludes to the fact that) the issue was on '''our''' end.
**"title of this page" - "this" means the one you're reading, the wiki
**"presumably [[explain_xkcd:Community_portal/Admin_requests#RSS_Feed_Broken|broke the RSS feed]]" - Our wiki's rss feed

Am I missing something? Was this an error on xkcd.com, on this wiki, or both? People keep treating it as if it's coherent. --[[User:FaviFake|FaviFake]] ([[User talk:FaviFake|talk]]) 17:10, 20 March 2025 (UTC)

:Ok the trivia is definitely wrong, as you can see [https://web.archive.org/web/20241123024448/https://www.xkcd.com/ here], it's the official xkcd.com page name that was wrong. Also, and this isn't mentioned anywhere, the official title displayed on the xkcd.com site was wrong too! It had an additional semicolon. The trivia needs to be updated, i also added it to edited comics cat. --[[User:FaviFake|FaviFake]] ([[User talk:FaviFake|talk]]) 17:22, 20 March 2025 (UTC)
::As I understand it (and understood it at the time), Randall did something wrong in creating his initial comic such that the "Created by a BOT" script created the page (and Talk page, and ''possibly'' populated a new RSS entry) with erroneous data.
::Whether that was done before or after the web.archive page, I don't know (my browser insists it can't open a secure connection there), nor if/when any subsequent change was done by Randall.
::I do know that I tested several browsers, at the time, and "&D" (and/or "&D;") and the lower-case equivalents only ever showed as a literal. But some kind of ''cleanHTML()'' function might well have been less willing to 'transmit' an unknown code, as it doesn't necessarily have access to all the DTD <!ENTITY ...> settings that a downstream browser might use (or the inbuilt latest HTML5 standards) so might have wanted to play safe upon finding ''anything'' that vaguely fits the "<ampersand><NAME><semicolon>" format, and just splice it out. I have no idea how RSS writers/readers deal with this (except some basic sanity checking for allowable character sequences, which seems to be the exact problem here after initially invalid data was entered upstream if it should have been <nowiki>&</nowiki> when added in). I would check how my Perl environment and HTML-related modules deal with it, but I suspect it's done through sometging like PHP instead.
::(Escaped/unescaped data is notorious, when raw data is HTMLised, but that read in as raw and ''further'' HTMLised in multiple cycles, you end up with stuff like <nowiki>&amp;amp;pound;</nowiki> popping up in things.)
::As far as most of the Trivia is concerned (including the currently hidden bits of it) I don't think it's wrong, though I can't say it's right without investigating the editor's(/editors'?) line of thinking all the way through at leisure. But it's a short and sweet precis of the basic issue, unless you want to start with XHTML Processing 101 and then get properly into DOM object parsing and various applicable WebTestKit criteria before deciding ''exactly'' where the fail-unsafe happened.
::With the "xkcd: D Combinatorics" bit, that looks like a browser header (or browser-tab's 'tab') announcing "<site name>: <page title>", but the only browsers I can test right now (Chrome and Firefox, both as Android versions) don't do that. I've used more different browsers than you've had hot keyboards, however, and I can believe that someone's does that sort of thing. If it's not a non-browser renderer/scraper, instead. Noting that the error came from xkcd(.com) and then caused problems on explainxkcd(.com), so I don't think there's an issue with that, but it's trivial to change to the browser-nonspecific (''and'' site-nonspecific) barebones "D Combinatorics" if that's what it is for someone ''with'' a better title-bar or tab-titling system than I have at the moment.
::Barring some rephrasing/reformatting, it looks Ok to me. But then I think I understood it already, so maybe I'm just not spotting the n00b-trap detail. [[Special:Contributions/172.71.241.45|172.71.241.45]] 22:14, 20 March 2025 (UTC)

2916: Machine

2025-03-05T13:57:19Z

172.71.241.45: /* Transcript */ Missed one.

{{comic
| number = 2916
| date = April 5, 2024
| title = Machine
| image = machine_2x.png
| imagesize = 740x740px
| noexpand = true
| titletext = The Credible Machine
}}
{{TOC}}To experience the interactivity, visit the [https://xkcd.com/2916/ original comic].

==Explanation==
This interactive game is the 14th [[:Category:April fools' comics|April fools' comic]] released by [[Randall]]. The previous April fools' comic was [[2765: Escape Speed]] from 2023, which was released on Wednesday, April 19, 2023. "Machine" has been updated multiple times in the weeks following its release, adding the following features:
* the trophy and shot glass props
* the cat, which swats balls in front of it
* the inanimate kitten and bun decorations
* a system of links, which encodes the XY coordinates of the currently viewed cell, and the time (i.e. the entire machine's state after a certain moderation action)
* a button to follow a nearby ball as it traverses through the machine, also preventing it from despawning

As referenced in the title text, this game is a spiritual successor to the 1990s and early 2000s PC puzzle game series {{w|The Incredible Machine}}, a game Randall played as a kid. Both games have several objects in common:
* fan
* cat
* ramps
* balls of varying densities

The comic starts in a main screen where the user can create a {{w|Rube Goldberg machine}} in a "Cell" where the goal is to route a constant stream of colored balls from inputs on the ceiling or walls to outputs of matching colors on the walls or floor. After the comic is first opened a window pops up over the machine where Cueball in a lab coat tells you to route the balls from the inputs to the outputs. A button opens a “tool panel” where there are large and small boards available for use, as well as some gimmicky stuff like prisms (which deflect marbles) and fans (which blow marbles around), plus decorative elements which have no effect on the balls.

Typically, inputs and outputs only accept balls of a single color. However, some outputs accept multiple colors, indicated by a double arrow, and some inputs produce multiple colors. When the player is designing their 'machine', this will involve multiple full streams merged into one (supplied by a double-exit on the adjacent submission). Machines now working in the full grid may, however, find that their sources now contain stray balls of other types that were not handled properly, but there is no way to force a re-edit of the machine to alter its behavior to account for this.

If any balls are left in your cell for more than 30 seconds, they fade away. The first time a ball fades away another popup informs you that the balls are removed for security reasons. An indicator next to each exit increases for each ball of the correct color that passes through an exit, and reduces when no balls pass through, or if balls of the wrong color pass through it. While that exit is not properly supplied it displays a red cross, which changes to a green tick when a sufficient, and sufficiently clean, stream of balls is supplied. The first time you have built a machine which succeeds in routing enough balls of the correct color to ''all'' relevant outputs, a popup will prompt you to submit your cell to be added to the public machine. (Subsequently, the submit button will quietly change from 'inactive' (pale) to clickable (dark). This will change back again if any ball transfers dip back below the required threshold for any reason, such as further editing or an end to a 'fluke' glut of accumulated balls.)

Choosing to submit your cell will give you a textbox to give this cell a name. Proceeding through that, you will now see your cell within the 'grid' and a 'live' feed of balls from any relevant neighboring cells (which may be more sporadic then the feed you designed your cell with, and contain stray balls of different types). If any supplying-neighbors are still marked as "under construction", they ''may'' provide the balls as if perfectly routed from their own (eventual) source, but will eventually dry up. If your newly submitted creation is placed in the lowest row of cells, balls will be dispensed through the exit at the bottom, but there will be no launcher to propel them towards the pit, and they will vanish as they leave the exit.

Upon reopening the link to this comic without coordinate and time parameters, your recently created machine will most likely not be visible in the space you built it in. [https://www.reddit.com/user/xzaphenia/comments/ Reddit user xzaphenia] has claimed on r/xkcd that this is because there is a moderation team (of which they are a member) and that [https://www.reddit.com/r/xkcd/comments/1c1ixmb/comment/kzc3rmg/ the main page only shows public, approved machines]. This team of people, including those credited as co-creators of this comic, select machines according to their preferences (and little to no formal criteria besides [https://www.reddit.com/r/xkcd/comments/1c0sp60/comment/kz6hbgl/ coolness, innovativeness, effectiveness], and [https://www.reddit.com/r/xkcd/comments/1c0bsk2/comment/kyvfean/ privacy concerns]). Given the number of 'bottom-layer' cells that are likely primed ready to be completed (e.g. the grid-width of twelve, perhaps staggered across adjacent rows) and the many possible worldwide contributors at any one time, it may be that the chances of being picked for permanence is low; and certainly would have been lower early on in the comic's existence during the initial frantic rush to participate. [https://www.reddit.com/r/xkcd/comments/1c0sp60/comment/kz6hbgl/ It is also claimed that at some point, moderation will be cut off and the machine will be considered "complete"].

<gallery heights="200" widths="150">
File:2916_popup_intro.png|Introduction popup
File:2916_popup_time.png|Time limit popup
File:2916_popup_submit.png|Submission popup
</gallery>

The button in the bottom right corner allows you to toggle between editing your own machine and a page where you can drag around to view all of the machines that have been submitted and accepted, with a title for each in the upper left corner. In this view you can see that all of the outputs are also inputs for another cell, except for the top row where the inputs come from off screen and the lowest row which output through a launcher of some kind to a set of four colored-coded containers far below. Any empty cells are marked off by yellow tape with the words "UNDER CONSTRUCTION" as well as "DJIA ↑ 31415" once in each cell. "DJIA" stands for the Dow Jones Industrial Average, with "DJIA ↑ 31415" indicating that it rose to 31415 points, 31415 being the first five digits of pi, without the period. This would often be displayed on a yellow 'ticker', which might look superficially similar to the yellow barrier tape.

When viewing the whole machine, a button in the bottom left corner, added later, allows you to follow the path of the nearest ball as it passes from cell to cell. This will also make the ball you are following immortal - not subject to the 30s timeout rule. However, it will stop following at the bottom of the base machine -- it will not follow into the bottom holding containers, nor keep it immortal once down there. Another later addition was a button in the top left corner which copies a URL that will take you directly to the current cell that you are viewing. However, the link that is created will always show you the version of the machine at the time that you were viewing it, without any subsequent additions.

Whenever balls reach the bottom of the grid, they are directed towards four containers, one of each color. Most balls are accurately sent to their appropriate container, though there are some misfires. These containers are above a pit, and dump their contents every 11.5 seconds. Balls in the pit are subject to a 97 (approx) second culling rule (including time spent in the holding containers), unlike the balls in the cells above. If no balls are directed towards the containers, the pit will be empty. If at least one stream of balls is making it, Cueball and Megan sit in a small boat named the USS Buoyancy, and when sufficient balls are being deposited, the boat begins to float and move. Balls that miss or overspill the pit fall out of the bottom of the frame.

Under construction cells will feed balls of the appropriate color into neighboring cells so long as you are not looking at them. Once you scroll to look at them, the supply of balls stops and subsequent cells in the chain will not receive any; scroll away from them again and the supply will resume.

The grid is 12 cells wide, and grows in height. The largest size observed so far is 12x128, for a total of 1536 cells. The machine's height is determined by the lowest cell; this can be either your submitted cell, or a cell created by another user.

Imperfections in the machines (whether accidental or by design) and the impossibility of entirely avoiding collisions when crossing streams inevitably lead to significant levels of losses and pollution with the wrong color balls. Indeed, using the follow ball function appears to demonstrate that it is quite rare for a ball to survive more than several machines without getting stuck somewhere. This should mean that effectively no balls would reach the lower layers. This implies that there is some 'creative accounting' going on to ensure that cells lower in the grid still have balls to process - simulating flow only for a few nearby cells, while assuming that those cells themselves have pure, steady inputs.

There is a hard limit of 100 items (both physically interactive and purely decorative) that can be placed in any given arena. If you have placed 75 items, a count will appear in the component bar of your piece-count ("''##''/100"), which will go away again if you delete items to bring it below this count. The count text turns red at "100/100", at which point no more items can be added, only existing ones moved (or removed, to lower the count again).

===Toolbox items===
{| class="wikitable" style="margin:auto"
|+ List of objects
|-
! Description !! Effect !! Image
|-
| Plank || Static obstacle || [[File:2916_plank.png|frameless|upright=0.25]]
|-
| Hammer || Static obstacle || [[File:2916_hammer.png|frameless|upright=0.25]]
|-
| Sword || Static obstacle || [[File:2916_sword.png|frameless|upright=0.25]]
|-
| Hinged scoop&dagger; || Rotates around its hinge, tries to stay horizontal with a springy effect || [[File:2916_scoop.png|frameless|upright=0.25]] [[File:2916_scoop_mirrored.png|frameless|upright=0.25]]
|-
| Anvil || Static obstacle || [[File:2916_anvil.png|frameless|upright=0.125]]
|-
| Brick || Static obstacle || [[File:2916_brick.png|frameless|upright=0.125]]
|-
| Fan || Blows away balls in front of it. Different colors are affected by differing amounts (yellow balls are lightest, and can be levitated above an upward-facing fan).|| [[File:2916_fan.png|frameless|upright=0.125]]
|-
| Pillow || Balls will not bounce if they hit it || [[File:2916_pillow.png|frameless|upright=0.125]]
|-
| Bumper || Bounces balls away at significantly higher speed || [[File:2916_round_bumper.png|frameless|upright=0.125]] [[File:2916_bumper_left.png|frameless|upright=0.125]] [[File:2916_bumper_right.png|frameless|upright=0.125]]
|-
| Attractor/Black Hole* || Pulls balls toward center || [[File:2916_attractor.png|frameless|upright=0.125]]
|-
| Repulsor/White hole* || Repels balls away from center || [[File:2916_repulsor.png|frameless|upright=0.125]]
|-
| Prism || "Refracts" and internally-reflects balls as they otherwise pass through the object, the color of the ball ''may'' cause them to react (as much as possible) according to the respective color across the element. || [[File:2916_prism.png|frameless|upright=0.125]]
|-
| Wheel&Dagger; || Spins, deflects balls, can jam with enough resistance (e.g. glut of balls or against other elements). || [[File:2916_wheel.png|frameless|upright=0.125]]
|-
| "Good job" trophy || Static obstacle || [[File:2916_trophy.png|frameless|upright=0.125]]
|-
| Glass cup || Static obstacle. Container, with a nominal capacity of up to four balls (in whole or in part) within it. || [[File:2916_cup.png|frameless|upright=0.125]]
|-
| Cat || Swats away balls in front of itself (was added later) || [[File:2916_cat_new.png|frameless|upright=0.25]]
|-
! colspan="3" style="text-align:center" | Non-physical items
|-
| Right-facing Ponytail, with raised arms || Intangible decoration || [[File:2916_ponytail_arms.png|frameless|upright=0.125]]
|-
| Right-facing Ponytail, standing || Intangible decoration || [[File:2916_ponytail.png|frameless|upright=0.125]]
|-
| Left-facing Cueball, with raised arms || Intangible decoration || [[File:2916_cueball_arms.png|frameless|upright=0.125]]
|-
| Left-facing White Hat, standing || Intangible decoration || [[File:2916_whitehat.png|frameless|upright=0.125]]
|-
| Rightwards-facing Knit Cap, in an 'action' pose || Intangible decoration || [[File:2916_knitcap_resting.png|frameless|upright=0.25]]
|-
| Right-facing Knit Cap, standing || Intangible decoration || [[File:2916_knitcap.png|frameless|upright=0.125]]
|-
| Helmet-wearing figure, standing || Intangible decoration || [[File:2916_helmet.png|frameless|upright=0.125]]
|-
| Squirrel || Intangible decoration || [[File:2916_squirrel.png|frameless|upright=0.125]]
|-
| "Probably Deterministic" sign || Intangible decoration || [[File:2916_deterministic.png|frameless|upright=0.25]]
|-
| [[1682: Bun|Bun]] || Intangible decoration || [[File:2916_rabbit.png|frameless|upright=0.125]]
|-
| Cat || Intangible decoration || [[File:2916_cat.png|frameless|upright=0.125]]
|}

:<nowiki/>* — The Attractor and Repulsor are omnidirectional, but the area of effect can be resized to extend or restrict its influence. You do this by way of its bounding box with corner and mid-edged 'drag nodes' and a circular area that shows the current extent, which are only visible when the element is actively selected. This resize can be no larger than will make the box/circle touch the edges, no smaller than the fixed graphic and will always be identically proportioned in both axes.

:&dagger; — The hinged scoops are strictly horizontal, on building. They will rotate away from and (spring back to) horizontal according to interactions with balls or other non-decorative items that may be placed to disturb their balance, sometimes with further interesting interactions (that may or may not be intentional or useful). There are two selectable versions of this item. (The only ''other'' object class with a clear (and practical) asymmetry, for which a mirrored chirality can be chosen from the sidebar, are the two versions of triangular "Bonk"-bumpers.)

:&Dagger; — The wheel is an actively rotating element that starts off, by default, spinning anticlockwise. Pressing or tapping left/right arrow keys, when a placed wheel is selected, will adjust that wheel's rotation rate to be more/less anticlockwise. Adjusting it beyond zero rotation allows you to make it spin in the opposite direction.
:Rotation can be increased well beyond the point at which the {{w|wagon-wheel effect}} occurs, which may make it difficult to work out the spin direction of an overspeed wheel element (and thus which arrow keys will slow or speed up its rotation, if you have forgotten), though observing its impact upon any balls that strike it ''should'' make its current spin-direction obvious.
:The 'bounding editing box' will usually appear rotated, possibly according to the spinning graphic's current orientation upon selection, but remains at that (often non-orthagonal) angle even as the wheel spins (if it can) during this period of selection for editing.

All other items can be manually re-angled by a 'loop node' arm extending from the bounding box. If you cannot see the 'angle node' for such a selected item, which is normally at the top of any freshly placed item but follows any re-angling that may have already applied, it could be that you have placed the item too close to the edge in which direction the node extends. To rotate it, move the object away from the edge to access the construction node (after which, you can drag the object back if required – but see below).

Rotation may be limited by the {{w|minimum bounding box}} that is the 'selection box', this is not necessarily the more flush {{w|convex hull}} of the collision-map built into the graphic. Should a corner of the bounding box need to move across the edge of the build-area, it will do nothing more than touch the edge until there is sufficient angle-drag to snap it to the angle from which that corner now comes back away from the edge; or, when it has a long straight edge currently flush with the edge boundary, it may snap to exactly 180°, in rotation, whereupon the opposite long straight edge is flush to the construction area edge. All objects that are drag-moved, similarly, cannot be moved any further than their current bounding box touching the construction-area edging. The bounding box for the rotating wheel is a notable exception to this, being not under any direct angle-control by the player. Instead, it seems to use the bounding inscribed circle that defines the wheel edge iteslf.

Apart from some interactions between the hinged scoops and any element (including other hinged scoops), there is no preventative 'collision detection' between objects during user-placement, which may overlap/cover each other (the most recently spawned item graphically overlays any earlier one). The wheel object will only spin if not constrained by other physical elements (including the spokes of an adjacent wheel, not in counter-rotation) but can still be dragged and placed anywhere within the boundary of the construction area.

The continuous stream(s) of balls respect all ''tangible'' objects, which includes any currently being dragged/rotated, though may prematurely vanish if forced between two items moved to touch/overlap each other. It is possible to indirectly nudge balls by carefully moving a tangible object's surface into them (or holding them within it, e.g. the "cup"). This may be useful for rescuing temporarily stray balls (before they time-out anyway), unjamming an area with a construction-induced glut ''or'' for testing a ball-path that is not currently being fed 'naturally'. Doing so ''can'' then conceivably fulfil all the exit-gate requirements (temporarily), as it might also transiently spoil some required routing, but the manual intervention will not be possible once a 'machine' has been submit.

===Non-player items===

Ball containers at the bottom of the machine
{|
|[[File:2916_container_red.png|thumb|center|50px]]
|[[File:2916_container_yellow.png|thumb|center|50px]]
|[[File:2916_container_blue.png|thumb|center|50px]]
|[[File:2916_container_green.png|thumb|center|50px]]
|}

Cueball and Megan in the ''USS Buoyancy''
[[File:4d425c.png|thumb|left|150px]]
 

Pit below the ''USS Buoyancy'' (not to scale)
[[File:2916_pit_bottom.png|thumb|left|300px]]
 

=== Color routing ===
The different ball colors have different physical properties. Red balls are more bouncy than other balls, green balls are heavier, and yellow balls are lighter and slightly bouncy. The following values were extracted from the code:
{| class="wikitable sortable"
! Color
! Mass
! Density
! Restitution (bounciness)
! Linear damping (drag)
|-
! data-sort-key="00F" | Blue
| 0.08
| 1
| 0
| 0
|-
! data-sort-key="F00" | Red
| 0.08
| 1
| 0.8
| 0
|-
! data-sort-key="0F0" | Green
| 0.75
| 9.325
| 0
| 0
|-
! data-sort-key="FF0" | Yellow
| 0.024
| 0.3
| 0.6
| 2
|}

Balls also have spin, but it is subtle and hard to see because the balls have no visible texture.It can be seen, with effort, using green balls (which are heaviest). Rolling down a slope (say, two boards), green balls accumulate spin in the direction they are rolling. Let them drop off the end and then bounce off a brick such that they travel upward, but with very little sideways motion. Then "catch" the balls with a brick just past their apex, when they are moving slowly. If the ball lands on a horizontal brick, it can be seen that the ball will suddenly accelerate left or right based on the spin.

For certain combinations of inlet and outlet 'gates', it is necessary to 'cross the streams'. e.g. to direct righthand-entry balls to a lefthand-exit and vice-versa. It is possible to just construct the field to send two (or more!) sets of balls to fly across a common gap, to land on an appropriate reception area that leads to the chosen exit. But, though this is not {{w|Proton pack#Crossing the streams|completely inadvised}}, the timing of the balls cannot be guaranteed to be in sync (or, rather, anti-sync) with each other and collisions ''will'' occur, especially under the variations of delivery that might significantly alter the ballistic path across the gap. Even if the trial machine works, in isolation with a steady stream of all balls entering the field of play, once submitted it will inevitably be fed by a more chaotically-routed preceeding construction.

In order to maintain sufficient correct arrivals at exits, it may be necessary to add a method of filtering the hues.

This could just mean introducing a 'wrong hue trap' beyond any crossing point(s) that send the occasionally wrong ball back to the cross point (or let them time-out in a dead-end, relying upon few enough failures from the rest of the balls, along with all colliding balls that subsequently missed ''any'' chance of reaching an exit). Alternatively, two (or more) feeds of marbles could be fed through a deliberate 'sorter' that does a sufficiently reasonable job of separating the combined sets out towards their intended target-exits.

The various physical qualities of the balls suggest a number of methods for redirecting separate hues to separate onward journeys. This can be done by isolating a hue from every other hue, then passing on (if necessary) to a setup extracting a different one from the remainder, and perhaps also a third time. It may also be possible to merge 'arrangements' of sorting mechanics to efficiently distribute straight into three ''or even four'' onward tracks towards the desired outputs, but that is left as an exercise to the reader.


{| class="wikitable"
! style="background-color:black; color:white" | To separate !! style="background-color:lightblue" | Blue !! style="background-color:lightgreen" | Green !! style="background-color:yellow" | Yellow !! style="background-color:red" | Red
|-
! style="background-color:red" | Red
| *R/B* | '''Use 'bounce''''
The sole difference is how much balls will rebound from objects. Well managed and constrained ricochets should allow a sorting action.
| *R/G* | '''Use mass or 'bounce''''
Green balls are not affected by a fan or a black hole, making it easier to sort from other balls. On the other hand, it also means it is very hard to precisely accelerate green, since the only components able to accelerate green is the bonk and the kitten. Green, like Blue, rebounds differently to Red. Green balls are also affected by black holes much less than all other balls.
| *R/Y* | ''See Y/B+G''
| *R/R* style="text-align: center; background-color:black; color:white" | n/a
|-
! style="background-color:yellow" | Yellow
| *Y/B+G* colspan=2| '''All methods'''
Yellow, alone, exhibits high drag against any unforced motion. It is also unique in all other ways; e.g. can be levitated highest, against all other hues (though most profoundly against Green).
| *Y/Y* style="text-align: center; background-color:black; color:white" | n/a
| *Y/R* style="text-align: center; background-color:gray" | ''See Y/B+G'' 
|-
! style="background-color:lightgreen" | Green
| *G/B* | '''Use mass'''
Green balls are not affected by a fan. There is also a not so marginal difference in density that might be exploited, such as by using black holes, which only minimally effects Green (perhaps showing an effective difference between mass of attraction and mass of inertia).
| *G/G* style="text-align: center; background-color:black; color:white" | n/a
| *G/Y* style="text-align: center; background-color:gray" | ''See Y/B+G'' 
| *G/R* style="text-align: center; background-color:gray" | See R/G
|-
! style="background-color:lightblue" | Blue
| *B/B* style="text-align: center; background-color:black; color:white" | n/a
| *B/G* style="text-align: center; background-color:gray" | See G/B
| *B/Y* style="text-align: center; background-color:gray" | See Y/B+G
| *B/R* style="text-align: center; background-color:gray" | See R/B
|}

Even when not strictly necessary for one's own submission, once submitted into the full playing grid the player's own contribution may find itself working with less 'pure' delivered ball-streams (from an imperfectly separating feed-in contribution). It is possible that this more interactive disruption can make the new setup behave erratically or even entirely incorrectly.

It might be thought good practice (but not ''necessary'') to deliberately combine any or all inputs and do a full job of splitting them again, just in anticipation of possibly having to deal with such cross-contamination and being able to 'clean up' the onward stream(s) for the benefit of others. This would of course be particularly difficult if the isolated building-phase does not provide all four hues to 'test' against, so any speculatively added filtering would have to be added 'blind' (and only on the offchance that any anticipated incorrect balls will actually enter the arena) and without any legitimate exits to which such rejects could be shunted (therefore could accumulate, up until any 'time out' that might apply to any ball once operational as part of the combined grid).

Single-input/single-output designs might not particularly require ''any'' sorting mechanism, in theory, though the unexpected 'contamination' of the system with balls of different masses/etc could perhaps introduce malfunctioning passage from the added chaos it might succumb to.

==Transcript==
{{incomplete transcript|Do NOT delete this tag too soon.}}

:[The placeholder image shows four balls, colored red, green, yellow and blue, bouncing on top of three white blocks. Text in the center: "[visit xkcd.com to view]"]

:[In the game, colored balls fall out of rotating half-gears that spawn at random from the wall and/or ceiling while an opposite set of half-gears rotate with a colored triangle pointing to that intersection of said set of gears. There is a button that says "view machine" button in the bottom right corner. When clicked, it takes you to a larger grid of others' machines that you can view in a larger grid. There is another button with a wrench which is a menu that gives you tools and decorations to move the balls to the set of gears with the colored corresponding triangle.

:[Cueball with lab coat, intro popup]
:Cueball: Balls falling into your cell should be routed to the outputs at a steady rate.

:[Cueball with lab coat, warning popup]
:Cueball: For security reasons, balls that remain in your device for more than 30 seconds will be removed and destroyed.

:[Cueball with lab coat, submit popup]
:Cueball: Congratulations! Your contraption has passed all tests. Press [submit button] to submit it to be added to the machine!

==Trivia==
* Once again an April Fool's Day Comic came out late, as Randall did not release this on April 1st, even though April 1st did fall on a Monday, a normal release day. It first came four days later with the Friday release on April 5th. That this is to be considered an April fools' comic, in spite of the later release, was confirmed on the xkcd Facebook page.
*Randall acknowledges the people who helped him create this comic in a [[Header_text#Machine|comic-specific header text]].
**With 11 different involved apart from Randall this is by far the comic with most people involved.
*Some hidden keyboard shortcuts have been found:
** Follow balls: Ctrl + Alt/Option + B (now also accessible by using the button provided)
** Show debug overlay: Ctrl + Shift + Win/Cmd + D
*** This may particularly clash with browser functionality, e.g. Firefox's "New Bookmarks" dialogue which will need closing, though still activating the overlay graphics.
** Delete selected item: Delete (Fn + Delete on Mac)
*When Randall posted a [https://www.facebook.com/TheXKCD/posts/pfbid0Cs97awQZi1ZiaEXouAex9tXrwAS3qJV3RmAiuCq5uvZQwqZVMgDmcqJ7JU9LYodYl link to this comic] on his [https://www.facebook.com/TheXKCD Facebook feed], he directly wrote that it was a late April Fools' Day!
**MACHINE
**Happy Belated April Fool's Day!
**This thus ends any discussion of whether this should be seen as an April Fool's comic or not.
**It just came out 4 days late. This has also happened several times since [[Garden]].
[[File:2916 Machine Facebook April fools' confirmation.png]]
*The [https://github.com/xkcd/incredible source code] for the comic was released on GitHub on May 8, 2024.
**chromakode, one of the developers, also published a [https://chromakode.com/post/xkcd-machine/ blog post discussing the design and development process].

* If you put a fan interlocking with a wheel it might eventually freeze your machine.

{{comic discussion}}

[[Category:April fools' comics]]
[[Category:Comics with color]]
[[Category:Dynamic comics]]
[[Category:Comics with animation]]
[[Category:Interactive comics]]
[[Category:Comics featuring Cueball]]
[[Category:Comics featuring Megan]]
[[Category:Comics featuring Ponytail]]
[[Category:Comics featuring White Hat]]
[[Category:Comics featuring Knit Cap]]
[[Category:Characters with hats]]
[[Category:Squirrels]]
[[Category:Buns]]
[[Category:Cats]]